After recently installing Visual Studio 2010 Beta 2 and creating a .Net 4.0 site, I tried to step out of Cassini and into IIS only to get “503 Service Unavailable” and a killed worker process. Checking the event viewer I found the following errors.

The worker process failed to initialize correctly and therefore could not be started.  The data is the error.

Followed by…

The worker process failed to pre-load .Net Runtime version v4.0.20506.

The Google was no help. It returned a handful of result that weren’t all that helpful, but one post was interesting. Someone had a similar problem with the  2.0 runtime when upgrading to the beta and found there were tiny bits of the other runtime sticking around.

I had .Net 4.0 Beta 1 installed before, so I did some digging and found I had the Beta framework:

C:\Windows\Microsoft.NET\Framework\v4.0.21006
C:\Windows\Microsoft.NET\Framework64\v4.0.21006

I also had folders from the Beta 1

C:\Windows\Microsoft.NET\Framework\v4.0.20506
C:\Windows\Microsoft.NET\Framework64\v4.0.20506

I deleted those folders, restarted the .Net 4.0 app pool’s and and hard restart just to be safe. Everything worked. Two hours on a Friday wasted, but we weekend free of worry.

We’ve recently upgraded to the shiny new Visual Studio 2010 Beta 2. With the go live license we hope we can transition to the RTM once it drops. It has some nice features everyone already knows about.

First step to the future, the conversion. The conversion went pretty smooth. It doesn’t like the MVC 1.0 project, but that’s OK since it was just a shell placeholder. We plan on converting that to the MVC 2.0 before we get any real work in there.

After fixing a few minor things the conversion wizard missed, we fire up the app in Cassini….and it looks awful.

OK, well maybe it doesn’t look awful, but it doesn’t look how our talented designers want it to look. It is mostly there. That bottom block should appear to the right of the login. Fire up the same VS 2010 project in IIS and it looks fine.

Weird huh? Looking at the HTML there are a few differences between the two, but none that we would really expect to cause the two to render differently. Some URL’s were changed to absolute URL’s and include the hostname and port of each site. There are some view state differences, but nothing else.  Hmm…Why don’t we just stop using Cassini and debug through IIS.

There were just a few steps needed to set that up. First, tell Visual Studio to use a different server besides the development server.

Here we’ve already setup a host header IIS site and added dev.mysite.localhost do the hosts file. We have a hybrid of ASP.Net and classic ASP, so we already used ISS for a lot of testing.

Second step, run Visual Studio as administrator. You can default the shortcut to always run as administrator by editing the advanced properties of the shortcut.

That’s it. It looks like Visual Studio automatically attaches to the IIS process. The best part; It is a worlds faster than Cassini. I don’t know why you would debug through Cassini, unless you had to because you were missing either administrator privileges or missing IIS with your Home version of Windows.

We’re starting a new project at work, one that will take our web development in a new exciting direction; MVC. We’ve struggled with the lack of control ASP.Net Web Forms gives us over the markup and and felt the pains of countless update panels trying to be Web 2-point-ohy. Today marks our first step into the ASP.Net MVC, but why stop there. Why not a whole new stack.

Here is what we are considering:

Move to Visual Studio 2010 Beta 2. Since it has a go-live license, we’re in line for the RTM, whenever it drops, and are (mostly) assured the upgrade path will be mostly painless. All (three) of our developers are running triple monitors so 2010’s multi monitor support is greatly anticipated. That’s not the only benefit though, the features of VS 2010 and .Net 4.0 are well enumerated. I won’t bore you with them, but there are a few .Net 4.0 features that look enticing, although we might still target 3.5 for our production releases until .Net 4.0 goes RTM. I’m not sure we are that bleeding edge.

Shipping along with VS 2010 is ASP.Net MVC 2.0 Preview 2. We are looking at using a lot of ASP.Net MVC Contrib, and other projects in conjunction with MVC 1.0, but with MVC 2.0, we get a lot of that same benefit. The type safe views in MVC 2.0 work slicker than the fluent views in MVC Contrib. The designers will be able to work with them a lot easier and not get lost in all the C# needed to write HTML. I’m not totally sold on the ASP view engine, due to its lack of XML formatting, but making it type safe is a huge selling point for me over Spark, the other XML compliant view engine I would consider.

We are also looking at upgrading TFS 2008 to TFS 2010 Beta 2. TFS 2008 is pretty painful when dealing with work items, branches, etc. We’ve seen some promise with TFS 2010. It does a better job at visualizing the merge relationships and hopefully a better job at handling work items. We’re struggling where to house our work items now. Hopefully TFS 2010 will be a good home. This above all other upgrades is the scariest. Loosing the source repository, even though we have backups of it, is scary.

Switching to from TFS to Team City for out CI and build server is another step in order to give us more control over our build process, and hopefully, dropping MSBuild as our build script platform. Scripting in XML was a horrible concept. Team City will better report our Nunit, Xunit, MBUnit, etc test, but also let us easily start using something like Rake for our build scripts. We’re not to the point of using Rake yet, but that is the goal. Getting Team City up and running was really simple. There were some firewall issues with the build agents, but for the most part it is dirt simple. Team City also has plugins to pre-test commits and task tray build monitoring. We do loose a little integration with TFS, but not much.

Taking our first step with ASP.Net MVC 2.0 Preview 2 gives us the ability to segregate our giant application into smaller projects using areas, hopefully making our source more organized, and more modular. We are writing a new checkout and order process for our main selling tool, the huge WWW website. This site is huge, and we would like to keep the amount of change needed to minimum, not only now, but going forward. MVC 2.0 has a bunch of new features over the 1.0 release and a ton of control over Web Forms.

Starting with a new project, we’re making strives to more loosely couple our dependencies. The heart of that is using StructureMap as our DI Container. From what we’ve read, StructureMap is simpler and easier to pick up than Windsor or Unity. We’ll give it a go and as we’re not doing anything all that complicated, it should be suit us just fine.

Following the patters of DI/IoC, we have a great opportunity to start narrowing our system under test. Previously we were using Selenium to accomplish almost all of our testing, and it works perfectly. That is, it works perfectly until you accumulate 40 or so tests that take 20 minutes to run through the browser. This is too long for me to run several times a day. We are testing specific classes in isolation and mocking all the dependencies using Rhino Mocks. Our test times are dropping dramatically, but we do sacrifice testing all the javascript and AJAXy goodness. That’s OK. We’re not throwing away all of the Selenium, just limiting our dependency on it to a more appropriate level.

I hope to cover more of these topics in detail, as I find them interesting and gain more experience with them. ASP.Net MVC 2.0 and the new tag team of VS and TFS 2010 Beta 2 will surely have a lot of interesting experiences to pass on. For now, our only pain is downloading them.