debug ASP.NET MVC system code in Azure Compute Emulator

Question

I'm developing an ASP.NET MVC (still v2) Azure web application. I've run into a problem that seems to require me to step through the MVC code itself. I can do this but also need to be able to inspect the code as I step, so I need to be an unoptimized version (so as to not get the "Cannot obtain value of local or argument ...") message in the debugger.

The standard way of circumventing the optimizations ( http://blogs.msdn.com/b/sburke/archive/2008/01/29/how-to-disable-optimizations-when-debugging-reference-source.aspx ) doesn't seem applicable to running in the Compute Emulator.

I also tried this by creating a local debug build of the System.Web.Mvc project but my web role hangs when I try to start it in the Compute Emulator.

So ... Any help with either of the following would be much appreciated:

Running an Azure web app in Visual Studio (2010) so that it will ignore code optimizations in system dlls.

OR

Creating a local system debug build so that it can be referenced by an Azure web app being debugged in the Compute Emulator.

Answer 1

If the Azure Compute Emulator is giving you issues you could run your MVC project using IIS Express. Just right click and and Select Debug/Start New Instance.

Answer 2

I was finally able to get unoptimized ASP.NET code while debugging in the compute emulator. The basic approach described on MSDN ( http://msdn.microsoft.com/en-us/library/9dd8z24x%28v=vs.100%29.aspx ) and elsewhere ( http://martin.bz/blog/asp-net-mvc-source-debugging-the-easy-way among others) is to put an .ini file that tells the JIT compiler not to optimize in the same directory as the DLL.

The first challenge was to determine just where that was; it finally dawned on me to watch the logs in the Compute Emulator UI and see where they loaded the DLL (in this case System.Web.Mvc) from.

The second challenge was getting the .ini file there. Windows Explorer didn't work because it uses a different way of viewing assembly caches that doesn't give you direct access to the files. One of the posts I read reminded me that using the Command Prompt might give me that access and it did. The last step was realizing, when the Command Prompt wouldn't permit me to move the .ini file into the assembly directory, that I needed to run Command Prompt as admin.

Once I could view variables while debugging, I pretty quickly realized where my bug was.