Let's just call this Part 1 in a potentially lengthy series of frustrations suggestions aimed at Microsoft.  

To be clear, I like Microsoft: I make my living using Microsoft tools.  However, as with all things, I occasionally encounter frustrations with their tools and/or services and need a place to vent.  Well, here it is.

Suggestion: Please decouple the different tools within Visual Studio
One huge frustration for me is the apparent assumption that most/all Microsoft customers use the full stack of Microsoft tools.  I see this theme manifest itself in many different areas of software development, but for this post, I just want to focus on the tools for building, testing, and deploying .NET applications (mainly web applications).

So, here's my caveman view of the software development lifecycle (absent project management methodology jargon and concepts like iterative development):



In my diagram, I've identified different activities and where they occur: for instance, coding and authoring of unit tests take place on the developer's workstation while I expect formal builds, formal unit testing and analysis and even formal packaging operations to occur on the build server.  Finally, I've added suggested tools that are used for each activity.

Now let's talk about my frustrations: thanks to the tight coupling of the different tools within the umbrella of Visual Studio, we have to be very careful about what tools we use in development because those tools may not be available to build/test/package our code on the build server.  Unlike other shops, my company has quite a mixture of technologies in the software development stack--most important, this means no Team Foundation Server.  Note: I've observed most of these frustrations under Visual Studio 2005, but I'm not optimistic that they've been remedied under Visual Studio 2008.

My first problem is with unit testing.  When Visual Studio 2005 rolled out, my inclination was to run with MSTest.  That is, until I realized that MSTest required an instance of Visual Studio be installed on the build server.  Others have railed against MSTest in general, but my most immediate problem with it is the fact that I would have to corrupt my formal build environment with a developer tool.  It seems to me that having a development tool on the build server would be a violation of the separation of duties we try to practice at my organization, not to mention the silliness of having to buy an extra Visual Studio license just so it can sit on a build server and facilitate unit testing.  Frustration #1: MSTest cannot stand alone from the Visual Studio IDE.

So, let's scrap MSTest like Jeff Palermo did and go with one of the open source testing frameworks like NUnit (maybe, some day, Microsoft will decouple MSTest from Visual Studio).  That's great, but how do I calculate code coverage?  Visual Studio Team System will calculate code coverage but I assume that only works against tests written on the MSTest framework.  If I don't go MSTest, I guess that means I'll have to scrape together a few bucks (albeit not that much) and buy something like NCover.  Frustration #2: VSTS Code Coverage only works with MSTest (this is an assumption, to be sure, so if I'm wrong here, someone please let me know--and let me know how to configure VSTS to calculate code coverage on NUnit tests).

Alright: let's assume we've moved past the unit testing and code coverage issues.  We've made all the right decisions so that our code is going through formal builds and unit tests on a nice, clean build server.  Now, how do we push out our compiled artifacts to our Production server?  I get the impression that most folks at Microsoft advocate either XCopy or Visual Studio Publish.  These tools either require the Visual Studio IDE outright or a deeper knowledge of Microsoft deployment tools than the average deployment lackey will have (remember, separation of duties means that developers won't be the individuals deploying applications to Production servers).  

Personally, I'm a fan of deploying via Windows Installer files--that is, an MSI or installation EXE.  What's more, Visual Studio includes Setup project templates that make it easy for a developer to author the script that installs his product on the Production server--after all, who better knows how an application should be installed on a server than the developer himself?  

So, on my clean build machine, I have MSBuild or, perhaps, Nant compile my source code, run my unit tests, and maybe even do some code analysis.  Once that's all done, I have MSBuild use the instructions of my Setup project to build my MSI and...er, that didn't work?  You mean to tell me that MSBuild can't build my Setup project?!  Well, that's just nice.  And what's Microsoft's suggestion: use devenv.exe.  Yes, once again, sully my formal build environment with the Visual Studio IDE.  Frustration #3: MSBuild can't build my MSI.  

So, now, I either have to scrape together more dollars for a commercial product like Wise or InstallShield or learn to grapple with Windows Installer Xml (there do appear to be some MSBuild tasks for building WiX artifacts, though).

Confound it, Microsoft!  You have great tools, but your build and deploy story is a Grimms fairy tale!  Ok.  I feel a little better (not really).  If I'm totally off track here or if you have any better suggestions, please let me know.

Pretty descriptive error code, eh?  Well, I was going to put together an example of what aspnet_merge.exe can do, so the first thing I wanted to do was grab an example application, particularly one that makes use app_code files.  I decided to use the code from BlogEngine.NET.

Yes...I know, I know...the BlogEngine.NET code was never designed to live under a WAP-type model, but surely it can live under that model, right?  Well, uh, not without difficulty.

Step 1: Run aspnet_merge and see what happens
So, I used the Visual Studio 2005 Web Deployment Projects to construct a WDPROJ--an MSBuild project with sweet tasks to run the aspnet_merge utility.  (Note: as far as I can tell, BlogEngine.NET is still a Visual Studio 2005 solution)

At the command line, I typed: msbuild BlogEngine.web_deploy.wdproj



The build started and 54 seconds later...blam!  error MSB6006: "aspnet_merge.exe" exited with code 1.

So, what happened?  Sounds like this error happens when class names collide.  Like so many things, the Web Site project tends to let you get away with bad coding practices like using the same class name for a page's code behind in multiple places--so long as the pages are in separate folders.  Aspnet_compiler will compile separate DLLs so there's never the chance that a single assembly will contain two classes of the same name; however, when aspnet_merge tries to merge all the assemblies into one, the class names will clashes and cryptic errors like "error code 1" will get thrown.

Step 2: Figure out where my problems are and fix them
Unfortunately, the default console logging behavior of MSBuild does not tell me where my errors are, so, after consulting with my handy-dandy MSBuild command line reference, I figure I can do something like this to get more detail on where my errors are occuring:

msbuild /nologo /v:diag BlogEngine.web_deploy.wdproj > msbuild.log

Scrolling up from the bottom of my log, I see this error:

An error occurred when merging assemblies: ILMerge.Merge: ERROR!!: Duplicate type 'widgets_LinkList_edit' found in assembly 'App_Web_nbdnprem'.

Ah-ha!  Multiple classes each named widgets_LinkList_edit.  A quick search for that name reveals that, yes, that class name is used for both the edit.ascx code behind of the LinkList and TextBox widgets.  To fix, I'll go to the TextBox's edit.ascx.cs file and change that class name to widgets_TextBox_edit and to the page declaration in the associated ASCX page and update that, as well.

1...2...3...4 error code 1 issues later and it looks like I have a build!  But do I have a good build?

Step 3: Fire up my BE build to see if it works
Seems like the easiest thing to do is to fire up an instance of the ASP.NET Development Server to host my BE build, so I execute this at the command line:

WebDev.WebServer.EXE /port:8080 /path:"D:\MyTests\BE_Test1\BlogEngine.Web_deploy\Debug_test1" /vpath:"/BE_Test1"

And I get...a Parse Error:



It looks like the page is barfing when it tries to load the PostCalendar user control.  Interestingly, the PostList user control loads fine.  I wonder why?

Looking at the default.aspx markup code, I see that the PostList user control is registered at the top of the page, but the Calendar user control is not.  What gives?



Well, it looks like, as Phil Haack once explained, the controls with the "blog" prefix are registered in the web.config.  Didn't know you could do that.  Pretty cool.

<pages enableSessionState="false" enableViewStateMac="true" enableEventValidation="true">
<controls>
<add namespace="Controls" tagPrefix="blog"/>
</controls>
</pages>

This doesn't fix my problem, though.  ASP.NET Parse Errors are usually an indication that the CLR can't find the referenced class in the assembly.  Well, I know the PostCalendar class is in my single assembly (.NET Reflector told me that), so maybe the CLR is not able to find the assembly itself.  Maybe I can help.  Let's modify the control registration in the web.config with the assembly attribute:

<pages enableSessionState="false" enableViewStateMac="true" enableEventValidation="true">
<controls>
<add namespace="Controls" tagPrefix="blog" assembly="BlogEngine.Web_deploy"/>
</controls>
</pages>

Hey, what do you know?  It worked!  Now, the page loads up just fine.  Note that this last change I made in the web.config in my build folder; if you try to change the original web.config and then run BE from the IDE, you'll get a compiler error.  It seems to me that these kinds of issues can introduce a lot of challenges to development, as you try to account for the fact that the web.config you deploy to a Production server will need to look slightly different than the web.config that you run in your IDE.  I wonder if there are any MSBuild tasks designed to modify the web.config spit out by the build engine?  Scott Guthrie has talked about other important changes that should occur in your web.config before deploying it to Production.  I wonder if anyone has written a MSBuild task to accommodate those changes?

Clicking around in my pre-compiled BE instance, everything seems to work fine; however, I did encounter one show-stopping error that prevents me from doing important administration tasks--like adding a new entry.  At least I know that issue's related to the BE distribution I downloaded, not my build experiment with aspnet_merge.

So, what have I learned?  Doing pre-compilation on complicated Web Site projects can be tricky business--particularly when using aspnet_merge.  I wonder if I should just demo how to migrate a Web Site project to a Web Application project?