Blogging About .NET : .NET Stuff

A new home for Reflector

cchrism — Mon, 25 Aug 2008 04:40:00 GMT

A few days ago Red Gate has announced that it acquired Reflector from Lutz Roeder, which is big news given the fact it is kind of core tool for .NET.

In case you don't know yet Reflector was listed in top 10 of the tools that every .NET developer must have, as can unlock many of the misteries of the .NET Framework and almost every other tool based on .NET. Red Gate announced that it will keep Reflector free so we don't need to worry at least for now and maybe we will find more addins for Reflector and community will be more interested to create for it.

In my opinion this move was somehow determined by the fact that some of the products from Red Gate's portfolio have now some competition from Visual Studio Team System, but this is the subject of another post.

Working with Wix - Patching reloaded

cchrism — Sat, 15 Dec 2007 20:15:00 GMT

Since my last update some changes have appeared in the steps needed to create a patch using Wix. The good news is that you no longer need MSIMSP to create a patch (and all the hurdles required to obtain MSIMSP).

Pyro is the new tool that can be used instead of MSIMSP and streamlines the patch creation process.

For more information about Pyro and how to use it you can use this link

Also here you can find "updated instructions for building patches using the new WiX v3.0 patch building system".

With this information Wix gains new strength, and it seems that Wix will be incorporated into Visual Studio Rosario (the one after Visual Studio Team System 2008, just released), instead of existing infrastructure for creating Windows Installer packages.

Working with WiX - Patching hints

cchrism — Sat, 03 Mar 2007 06:33:00 GMT

If you are trying to create MSP files ( aka MSI patches ), one of the best tool I found to create PCP files is Wix. The amount of documentation for MSP creation is extremely small in my opinion, most of the required hints are in the Wix documentation. However I want to emphasize some of the steps that might be skipped by mistake:

You need MSIMSP Wix automates the creation of PCP files only. It's not a one stop shop
MSIMSP doesn't work with compressed MSIs. Yes! It's true, do not try to bend this rule.

Otherwise the process it's fairly simple. Type the wxs file (using your favorite text editor), compile the file to PCP and run MSIMSP tool after having administrative install MSIs (uncompressed versions).

A good start to more information about Windows Installer can be found here

Clutter free plugin hosts in .NET

cchrism — Sun, 04 Feb 2007 21:20:00 GMT

This post is inspired from another post (in Romanian, sorry for the not Romanian speakers), which asks about the usefulness of System.Reflection.Assembly class.

This class is primarly your one stop shop if you want to implement a plugin host in .NET Framework. The implementation of a plugin host in .NET Framework is somehow different than the old "C/C++" way of implementing by the simple fact that we no longer have header files to ship to the plugin writers in order to describe our interface. But no worry, this doesn't means that it's more complicated to do such a thing in .NET. The closest way to do this is to generate a class library DLL project, that doesn't implement code (or maybe just some utility classes) but to have the definitions of our interfaces. This is the easy way, but in my opinion it's not the cleanest way. If we go this route we will have to ship our "interface" DLL to clients since it's a required dependency. For large projects where you have hundreds of files shipped to client, it might be fine, but for small project where you ship just your host and few plugins the clutter it's less desirable. A clever way to do this is to implement your interfaces in your host project, and make the plugins dependant on your host .exe file. This way you will have always up-to-date dependencies, since you cannot break the host (or, your code won't compile at all). Prior to Visual Studio 2005, you weren't able to add to a project a dependency to another project whose output is a .exe file. This was recognized more or less a bug, since .exe and .dll files doesn't differ at all internally, so the workaround for Visual Studio 2002 and 2003, was to build your project, get the output, rename it to .dll extension, and add the dependency to your plugin project.

If you are new to plugins in .NET and you come from C/C++ plugins a warning that might save you a lot of time: do not try to reimplement your host interfaces with the same definition in your plugin project, just to remove the intermediary DLL file dependency (the easy way above). IT WON'T WORK. Objects in .NET (interfaces, classes, etc) have the same identity only if they have the same name AND come from the same assembly.

Someone said there that is not normal that Visual Studio accepts dependecies to .EXE files. Well, the fact that they prevented explicitly this (I believe, since they were filtering some types of projects) in VS 2002 and 2003, and now it works in 2005, it might mean that some people finds the feature useful. And I come and say why not accept dependencies of .EXE files/projects?

Reporting Services Uploader

cchrism — Sun, 15 Oct 2006 20:26:00 GMT

Quite some time ago I have written a small utility that allows users to upload multiple Reporting Services reports (RDL files) at once to a Reporting Services Server. I have decided to make this utility public as others might find it useful.

The main problem with Microsoft SQL Reporting Services (either 2000 or 2005) is the lack of capability of uploading or downloading multiple RDL files at once. I know that the RS.exe utility exists, and it's presence is more proeminent in the 2005 version by adding the SQL Management Studio ability to script files of RS.exe, but you cannot upload quickly a locally stored folder full with RDL files, or for example copy a lot of reports from one server to another. That's why I decided to create this utility named RSUploader at this time at the version 0.5. Although I intent to update it a little bit I cannot promise that this will happen or a timeline for it's improvement.

RSUploader was built using .NET framework and presently the user interface is not the best in the world, but still gets the job done. The minimum requirement is .NET Framework 2.0 and it can connect to Microsoft SQL Reporting Services versions 2000 and 2005. You can download it from here

Among it's features you can:

Browse the folder structure of Reporting Services
Download all report definitions from one Reporting Services folder
Upload a local folder containing RDL files in a reporting services folder
Delete reports
Hide/Unhide reports

In addition to the ZIP archive I also attached a screenshot to know what to expect.

In order to successfully use RSUploader you have to type the URL of Reporting Service Web service, usually http://[machine]/ReportServer, do not swap it with the URL of Reporting Service Manager, and also if you are not using Integrated Authentication, type the username and password in the corresponding textboxes, and click Refresh in order to connect to the Reporting Services. Any time you change the URL or user / password you must click on Refresh in order to pick the new location.

Then expand the folder structure in the left view and in the right view you will have the actual list of reports and datasources. The checkbox in the front denotes the visibility of the item (if it is not checked it means it is hidden). Also you will have fix datasources for reports if you uploaded reports before you created your datasource and the GUID that Reporting Services is using for matching the datasources is not in sync.

If you find this utility useful please drop a note using the contact form.

Of course, the information in this post and the utility is provided "AS IS" with no warranties, and confers no rights. I am not responsible if any thing doesn't work as expected or for any loss of data.

Waiting for Whidbey

cchrism — Thu, 06 Oct 2005 18:21:00 GMT

In case if you leave on another planet, let's reiterate the old news: Whidbey launch date is November 7th.
So far I have used Beta2, in a VMWare virtual machine which has 512 MB RAM dedicated, on an Athlon 1800+ CPU, and I am pretty impressed by it's speed. My team-mates say that they want an upgrade to 1GB on their computers when will switch to Whidbey, but I think that the speed won't be very different than Visual Studio 2003.
Anyway, I wait it because it comes with many good things, all the annoying stuff that was present in VS 2002/2003. It will probably come with another round of annoying things, but hey, that's life.
One thing I like a lot, is the fact that the mobile development and desktop development is under the same roof without any additional installations. Still, in Beta2 I tried to develop last week a desktop utility that connects to the mobile to display databases info. Unfortunately I did not find rapi.lib and rapi.h, and had to copy them from a Smartphone SDK. Is this a miss of the Beta2, or it will be also in the final version. On the other hand, ARM emulator simply rocks.
The first thing that I'll do after I install the final release is to have it build for previous frameworks (1.0 & 1.1) and we are all set.

PS: Today I even found someone from Microsoft asking if there is interest in getting this feature of targetting the previous runtimes.

Visual Studio 2005 Rocks

cchrism — Fri, 17 Jun 2005 11:37:00 GMT

In case you live on another planet and didn't heard yet (but you read my blog) here is the news: on 7^th of November 2005 the brand new version of Visual Studio will be released.

I received my media kit from BetaExperience, and I installed Beta 2 release some time ago. Well, IT ROCKS. It is the first time that within a single IDE you can develop for all plaforms. Before this, for Windows CE, you had to install Embedded Visual Tools for native code, or VS 2003 for managed, different tools, different debuggers and so on.

When I started the first time, I was impressed about the new look. I am using the screen in 24 bit true color, and looks very nice, similar to Office. I installed it in a virtual machine (ok, ok, not a VPC one, but from VMWare), and I was a little bit disappointed about the speed, mainly because I've seen Beta1 and it worked pretty smoothly. Well, my virtual harddisk file (4.5 GB) had over 50000 segments. Defragmenting the disk get reducing the number of fragments to 2 or 3 greatly improved the speed. Now you can develop quite fast, and I haven't noticed performance degradation between VS2003 and Beta 2. The machine is a Athlon XP 1800+, and VMWare machine has 512MB.

Another interesting stuff is the ARM emulator. Now you can test the real software in emulator also, and not by disturbing the actual device, which a nice thing. Before a very limited number of software had binaries for Windows CE / X86. Actually I found only one software, which is the SmartMonitor plugin, if I remember correctly.

To my own disgrace, I haven't installed yet the Team Foundation Server, primarly due to lack of time, but I will test it, I promise.

A negative point is related to the new way of storing web projects. I had a serious problem when I converted the old solution, because I had some projects, which were excluded from build for historic reasons, but were included in the converted project. With the new way of storing projects, you will lose this capability of excluding files from build, or at least I haven't found how to do it.

Also, the resx files for aspx are getting dropped, I didn't understand yet, which was the reason to be added in the first place for this kind of files (ASPX/ASCX), so will unclutter your source control system.

A nice hack is that located here, and this gives you the ability to target the binary for an older framework. Still, when the web project is converted it will add partial attribute to all codebehind files, so you should go and remove the attribute in order to target 1.1 or 1.0 version. And when you have over 300 pages, is quite some work to do.

Update: June CTP for VS2005 is released: you can find here if it worths the update.

VSIP Partner DVD

cchrism — Fri, 19 Nov 2004 20:00:00 GMT

Yesterday I've received my ordered DVD with goodies from Microsoft's partners that are in the Visual Studio Industry Partner Program. It can be ordered from http://msdn.microsoft.com/vstudio/extend/partnerdvd/ and contains 67 products and trials, from all categories such as: Architecture & Design, Cross Lifecycle & Support Tools, Deployment, and so on. A interesting note is that the estimated arrival time printed on the package is 2nd December 2004, and I've received it 2 weeks earlier. Wow, very good response time.

With this ocasion I found out a product evaluated long time ago, named StarTeam now branded as Borland StarTeam. A few years ago, when I evaluated it, the company was named StarBase, and it seems that Borland bought it. It is mainly a change and configuration management system that can be used to replace VSS and improve the development process by providing traceability (another key requirement for MSF) of the business requirements into the actual output. At the time of the evaluation (back to 1999 - 2000) I was quite impressed by the capability of StarTeam: it was cross-platform, with both GUI native Windows application, and a command line either native and java based application, it provided a SDK in order to access the full capabilities and automate them.

There are a lot of other goodies included on this DVD, so I have to find some time in order to fill the bag.

Best practices on custom exceptions? (where we derive it from?)

cchrism — Thu, 04 Nov 2004 15:16:00 GMT

I found today an older post that links to an interesting book, named “.NET Framework Standard Library Annotated Reference, Volume 1: Base Class Library and Extended Numerics Library”, and I discovered an interesting discussion: should we derive our custom exceptions from Exception or from ApplicationException. To be honest, I didn't paid attention to ApplicationException when I browsed the documentation, and I went straight, and derived from Exception. Apparently it was a good choice.

Just my 2 cents.

Microsoft usage on .NET code (a.k.a. dogfood)

cchrism — Tue, 02 Nov 2004 09:44:00 GMT

Yag has compiled a list of products created by Microsoft that are developed either entirely, or just some features, with .NET code. As we can see the list contains some interesting products like UDDI server or Sharepoint Portal Server (from Windows 2003), and most important the list is increasing. At a MSDN conference here in Romania, in regards with this subject, it was said that the next version in Office will have more modules developed using .NET (this should mean no more PIAs?).

The conclusion is: Winforms is gaining momentum, which is a very good thing.

We did it! Edit & Continue for C#

cchrism — Sun, 17 Oct 2004 10:55:00 GMT

Maybe only if you are living in a isolated island you didn't heard the great news: we will have Edit & Continue in C# for Whidbey (aka Visual Studio 2005). You can read the announcement here. So, now all the major development languages (sorry J# guys) will experience the Edit & Continue feature. A great productivity enhancement.

Why do people write such a lousy code in .NET?

cchrism — Fri, 04 Jun 2004 03:03:00 GMT

Because they can.

Instantiating objects, retrieving records from database when you need it, loading a full table with thousands of records, and the examples can continue indefinitely. .NET made this much simpler. In two lines you'll put a big pressure on your memory, and your clients will find your application not so responsive. Loading an XML document is so easy. You don't have to think to much, you don't have to count references, and remember to release memory when you don't need it.

In C++ to retrieve records from database was quite difficult. You didn't have datasets so you had to make sure you use them efficiently. Now, you have a rowfilter on client in dataset. Programmers think: “super cool invention, let's use it!“. Even if you use it to retrieve a record by it's primary key (where Find should do it very fast). In case you don't found it already, Rowfilter search linearily where Find is a binary search.

If programmers are not very experienced it's easy to write code with lousy performance. Then, people that don't trust .NET a lot see that the performance is bad, and discard .NET. But with a little coding discipline .NET applications can be made very fast. It doesn't take a lot to write high performance code. You have to want it, and you'll have it.

What to do and what NOT to do in each layer of your application

cchrism — Wed, 02 Jun 2004 16:42:00 GMT

Scott posted
A reminder on "Three/Multi Tier/Layer Architecture/Design" brought to you by my late night frustrations.

So, before writting DataLayer stuff in your .aspx page (or worse, open connections), please review the article. One interesting note. Usually due to lack of time, and need to deliver the product yesterday, communications between layers is made of datasets, which used properly are ok, but cannot be enforced easility to be read-only. So, beware of code that modifies datasets directly in your UI Layer.

If you think that life is boring

cchrism — Wed, 02 Jun 2004 03:38:00 GMT

Found a new blog: http://thedailywtf.com/

Super cool, one of my favorite.
WTF was in head of the one that wrote the code?

Performance & Paralellism

cchrism — Wed, 02 Jun 2004 03:26:00 GMT

Since I often remind to people to optimize their code (or at least remove the redundant stuff they do) I found an interesting article about performance & paralellism: http://weblogs.asp.net/simonme/archive/2004/05/31/145024.aspx.

Quote:

Now 2GHz is a difficult thing to imagine for a human. Put simply that is 2 billion (Dr Evil pose) instructions per second at maximum throughput. So lets put this on our terms. Let's say once processor “clock cycle” is not 1/2,000,000,000 of a second but rather 1 second. On that scale accessing the nearby L1 on-chip cache takes 6 seconds, the off chip (L2) cache 2-3 minutes, and accessing main memory takes 3-4 weeks. Accessing the disk (just one disk access) by comparison takes a whopping 1 year on this timescale

Now think you call an DataAdapter to fill your dataset in every step of your for loop. Why? Because it's so simple to write dbAdapter.Fill(myDS).