Friday, December 21, 2007

Working With en Existing App in Visual Studio .NET

I have recently started work on an existing ASP.NET application. The first challenge was to get the application properly installed, built and working in my development environment. If you're lucky references to sub-projects in your solution will be through relative paths. That's half of your problem gone if that is the case. If you're not lucky, I'd suggest you do that.

Step 1: make all sub-projects referenced through relative paths.

This will require that some of the project files/folders are moved around a bit, but they should be somehow made a logical structure. (hm, my last sentence makes me think about Maven and the way in which project dependencies are handled there... I ought to lookup somethings on good practices with VS dependencies).

Step 2: sort out web projects and their virtual directories and applications.

Next, check for web projects. Each one referenced in the visual solution should have a virtual diretory created for it in the IIS root directory (unless your placing your code directly into the IIS root). In addition, chances are that you'd have to create an application for each virtual directory mentioned in the VS solution file. To create an application for a virtual directory in IIS 5.0 do this: Settings > Control Panel > Administrative Tools > Internet Information Services > Local Computer > Web Sites > Default Website > Properties (right click the virtual folder in question) and click Create next to the text box with the label Application Name.

Keep opening your Visual Studio project until you get it to stop complaining about not being able to open one of its sub projects. Once this step is done, we can move on to building things.

Step 3: do a clean build of all projects

Once you're here, you should build a project. In my case this was, to my great surprise, successful as well. However when I tried running the application the stack trace kept on reporting errors which occur in controls referenced by paths that are not on my machine! I figured this was really weird as I just built the whole solution successfully and there must be a place where paths to controls were hard-coded. Again, I was wrong.

Two things you should pay attention to:
1. DLLs used in the bin folder of the application
2. Your build configuration

I think the final solution is really related to your build configuration, but its worth talking about the first one as well.

Checking the /bin folder of your project (and any of the sub-projects) you should be able to see all required DLLs being inside it. Look at the dates. If you have been rebuilding your solution these dates should be very recent, if not a few minutes ago. However, if you're seeing that some of the DLLs are much older then chances are that you're not rebuilding them properly. Obviously if there are 3rd party DLLs in your bin folder these are not applicable for this discussion - look at only the DLLs that are built through one of the sub projects of your solution.

It turns out that lots of these DLLs in the bin/ folder of many sub-projects were not rebuilt and carried a timestamp of a few years back. That suggests that the build configuration either skipped this completely or did not copied the relevant DLLs where they were supposed to be.

So, what to do? Simple: open your VS Configuration Manager and make sure that all the projects have their build checkbox checked. Build again. It is supposed to build the entire set of projects that go into the solution.

Quick check into the bin folder should verify that those timestamps are showing that most of the DLLs are up to date.

Unfortunately, its still possible that this will not properly rebuild your solution. I found that my "main" project which depended on all these sub-projects still had references to some really old DLLs from a few of them. If you manually copy the affected DLLs you're 99% of the time going to be OK - the application should start running properly. But why were these DLLs not in place? I would have thought that VS would take care of these dependencies for me.

Well, as usual, the error is not with VS, but with the programmer. Its all about project dependencies. Right-click your VS solution and choose Project Dependencies.... It reveals a small dialog box that shows for a selected project what are its dependencies. Similarly, it shows a an overall build order (derived from the Configuration Manager setting).

Looking at my problematic "main" project it showed that it did not depend on a few of the sub projects it should have. I'm yet to figure out how is this information generated but my best guess is that the way in which project references are handled is the reason why this configuration would not be properly done. Ticking the dependency properly causes the solution to start being built the way its supposed to.

Final Notes

All these problems really suggest a deeper need for properly dealing with the way your projects are built. Most of us take it for granted and not pay too much attention to this. However, builds should be automated (as we all know, right?). Some effort should be spent to get the project in a state that allows it to be downloaded and built in a few minutes so that a development environment is setup very quickly. I guess its still sad that we must waste time on these things. I'll hopefully figure something more useful then this comment and do another post on that. Its either some "proper" building of projects in VS usage of something like NANT.

Typical Problems

If your project is perhaps suffering from the above build configuration what happens is that when you try running the application you get all sorts of weird stack traces. But a common theme is that the stack trace will show paths (on the HDD, not URLs) referring to paths that are not on your machine but instead residing most likely on the machine of the previous developer. This suggests that the runtime application is picking up DLLs that were built by someone else on another machine.

No comments: