I recently spent far too long debugging a problem with our Azure application. We have two Azure cloud projects, and they both started refusing to start at about the same time, with different error messages. The web applications they house both worked absolutely fine when deployed to local IIS. There turned out to be two different problems - both very simple - so I thought I’d share what they turned out to be :)
One application failed to start in Azure, with the error message “Unable to find the constructor for
FormattedDatabaseTraceListener”. We’d recently switched from logging to Azure Table Storage
DiagnosticMonitorTraceListener to logging to a database using a
This had been succesfully tested on one cloud project (an MVC application) but the other (a WCF service)
refused to start. We’re using the Enterprise Library for logging, but commenting out the logging
configuration didn’t make any difference.
I eventually noticed the difference between the MVC app and the WCF service - the MVC app had an Azure
config transform which added a
FormattedDatabaseTraceListener to the
section; there’s no way of specifying constructor arguments for listeners registered in this section
(unlike in the Enterprise Library configuration), the
FormattedDatabaseTraceListener doesn’t have
a parameterless constructor, and the exception was indicating this problem. I fixed this by creating
a subclass of
FormattedDatabaseTraceListener which had a parameterless constructor and registering
that instead - presto!
The MVC app was failing to start, saying that there was no configuration file. Specifically, the Azure
wasn’t able to use the application’s DI system to resolve its dependencies, as there was no configuration.
Our Azure projects are configured to use
mode, which means the applications run in IIS, and the
RoleEntryPoints run in
Hosted Web Core. The application
web.config, and the
WaIISHost.exe.config. It turned out the build
WaIISHost.exe.config was set to ‘Never copy’ - setting it to ‘Copy always’ did the trick.
It pretty much always seems to turn out that horrible bugs have simple solutions!