One of the new things in Visual Studio Windows Azure tools 1.4 Augustus update (what a mouthful) is that MVC 3 is a standard WebRole. But also Profiling is now a serious option for debugging, besides the already present Web deploy possibility.
So when I was playing with the Tools update, I took a vanilla MVC 3 WebRole and deployed this one to my second Hosted Service with all options.
So with profiling on. If you select this option, you have to select a level of profiling. I choose CPU sampling, I will have a look at the other choices later. But I also selected the Web deploy option and that proofed to be very handy. But more about that in a moment.
After setting up those options and selections and deploying my new Windows Azure application, I tried the URL of my Hosted Service staging environment. Surprisingly this took a while and then I also got an error. What went wrong? Before deploying it to Windows Azure, I run the solution on my box of course and I did not find any errors.
I was surprised, but alright. What we all do in such a event, we change the web.config like stated in the error message. We rdp to our WebRole, browse to the E of F drive in search for the web.config. We change the file and voila, the vague message is clear.
But I told you I check the Web deploy option. So this time I would do it otherwise. In my solution I changed the Web.config. Of course I did it in the debug version of the web.config, so the release version could be deployed after solving the issue. While doing this, I was wondering, why this wasn’t an out-of-the-box setting or why I did not changed it on default. Again, I crossed this road many times before.
Web deploy is rather simple. On the Web project in je Windows Azure solution you select Publish from the pop-up menu.
A screen appears with all the necessary options. Alright, that took me a while before I got those right. The service URL had to be: http://<staging>.cloudapp.net and not, like the help suggested something with port 8172/MsDeploy.axd. The Site/Application in my case was called: MvcWebRole1_IN_0_Web or <name web project>_IN_<instance number>_Web. As User name en Password, you give the credentials of RDP. Then push Publish and of you go.
Seconds later the status bar tells it succeeded and the output window shows it too.
And on the Website the vague message was much clearer.
In the web.config of the MVC 3 web projects a connection string to a SQL Express database for the Application Services and the Session state provider is default. After I changed those to a SQL Azure database, my first MVC 3 WebRole was alive and kicking.
Of course I was warned before, but I did not pay any attention to the Warnings in my project. Because a warning is not an error, so I was not triggered in any way.
Luckily I was not the only one, Wade Wagner of the Cloud Cover show saw this too and his blog post contains more information about the ASP.NET Universal Provider package related with this error.
In my next blog post something about Profiling.