While developing with Windows Azure SDK and local Azure development fabric, when things go wrong, they go really wrong.

It could something as obscure as leaving an empty element somewhere in Web.config or a certificate issue.

The problem is, that before Visual Studio attaches a debugger into a IIS worker process, a lot of things can go wrong. What you get, it this:

There's no Event Log entry, nothing in a typical dev fabric temp folder (always, check 'C:\Users\ \AppData\Local\Temp\Visual Studio Web Debugger.log' first), nada.

Poking deeper, what you need to do is allow IIS to respond properly. By default IIS only displays complete error details for local addresses. So, to get a detailed report you need to use a local address.

You can get a local address by fiddling with the site binding with IIS Manager and changing what Azure SDK does, so:

• First, start IIS Management Console.
• Then right click on your deployment(*).* and select Edit Bindings.
• Select All Unassigned

If you hit your web / service role using the new local address (could be something like http://127.0.0.1:82), you are most likely getting the full disclosure, like this:

In this case, a service was dispatched into dev fabric, which had an empty element somewhere in Web.config. The web role was failing before Visual Studio could attach a debugger, and only HTTP 500 was returned through normal means of communication.

This is the content from my Bleeding Edge talk on pub/sub broker design and implementation.

Due to constraints of the project (European Commission, funded by EU) I cannot publicly distribute the implementation code at this time. I plan to do it after the review process is done. It has been advised, that this probably won't be the case.

Specifically, this is:

• A message based pub/sub broker
• Can use typed messages
• Can be extended
• Can communicate with anyone
• Supports push and pull models
• Can call you back
• Service based
• Fast (in memory)
• Is currently fed by the Twitter gardenhose stream, for your pleasure

Anyway, I can discuss the implementation and design decisions, so here's the PPT (in slovene only).

Downloads: Bleeding Edge 2011, PPTs
Demo front-end: Here

I'm just poking around the new framework, dealing with corflags and CLR Header versions (more on that later), but what I found is the following.

Do a dir *.dll /o:-s in the framework directory. You get this on .NET FX 4.0 beta 2 box:

[c:\windows\microsoft.net\framework64\v4.0.21006]dir *.dll /o:-s

 Volume in drive C is 7  Serial number is 1ED5:8CA5
 Directory of  C:\Windows\Microsoft.NET\Framework64\v4.0.21006\*.dll

 7.10.2009 3:44   9.833.784  clr.dll
 7.10.2009 2:44   6.072.664  System.ServiceModel.dll
 7.10.2009 2:44   5.251.928  System.Windows.Forms.dll
 7.10.2009 6:04   5.088.584  System.Web.dll
 7.10.2009 5:31   5.086.024  System.Design.dll
 7.10.2009 3:44   4.927.808  mscorlib.dll
 7.10.2009 3:44   3.529.608  Microsoft.VB.Activities.Compiler.dll
 7.10.2009 2:44   3.501.376  System.dll
 7.10.2009 2:44   3.335.000  System.Data.Entity.dll
 7.10.2009 3:44   3.244.360  System.Data.dll
 7.10.2009 2:44   2.145.096  System.XML.dll
 7.10.2009 5:31   1.784.664  System.Web.Extensions.dll
 7.10.2009 2:44   1.711.488  System.Windows.Forms.DataVis.dll
 7.10.2009 5:31   1.697.128  System.Web.DataVis.dll
 7.10.2009 5:31   1.578.352  System.Workflow.ComponentModel.dll
 7.10.2009 3:44   1.540.928  clrjit.dll
 7.10.2009 3:44   1.511.752  mscordacwks.dll
 7.10.2009 3:44   1.454.400  mscordbi.dll
 7.10.2009 2:44   1.339.248  System.Activities.Presentation.dll
 7.10.2009 5:31   1.277.776  Microsoft.Build.dll
 7.10.2009 2:44   1.257.800  System.Core.dll
 7.10.2009 2:44   1.178.448  System.Activities.dll
 7.10.2009 5:31   1.071.464  System.Workflow.Activities.dll
 7.10.2009 5:31   1.041.256  Microsoft.Build.Tasks.v4.0.dll
 7.10.2009 2:44   1.026.920  System.Runtime.Serialization.dll

Funny how many engineer dollars are/were spent on middle tier technologies I love.

Proof: System.ServiceModel.dll is bigger then System.dll, System.Windows.Forms.dll, mscorlib.dll, and System.Data.dll.

We only bow to clr.dll, a new .NET 4.0 Common Language Runtime implementation.