This post is related to two of my previous posts:
- Automating Azure 1.4 Packaging using MSBuild and CSPack
- Windows Azure Diagnostics with SDK 1.6 for WebRoles
Azure 1.5 ate my diagnostics
I had diagnotics working quite happily until SDK 1.5 came out. Then all of a sudden data was no longer being transferred to Azure storage. Even more mysteriously diagnostics would happily transfer data to Azure storage when being emulated locally, but not when on the Azure cloud (in other words a nightmare problem)
I didn’t get around to investigating why till this week. I saw that several people had the same problem, and assumed that the problem was that I wasn’t configuring the diagnostics correctly in the OnStart method.
Finally I saw this forum thread. The thead described that if you upload your solution from visual studio diagnostic works correctly, but not when deployed from the build process. I tried for myself, and yep diagnostics would magically work when the solution was deployed from Visual Studio. This finally clued me into the fact that the problem had nothing to do with the code, but everything to do with packaging. Which leads us to this update on Auto Packaging your Azure solution.
Configuring Your Azure Continuous Integration process with CSPack and SDK 1.6
My previous post on using CSPack to automatically build your deployment packages is largely still correct. But as of (I assume SDK 1.5) there’s a new EntryPoint property.
So you need to specify the name of the DLL that is the entrypoint to your solution. In mycase HuzuSocial.App.dll. So my AzureProperties.txt file now looks like this:
Now configured correctly, Diagnostics works as expected from our Continuous Integration process.
After months of not having Trace in my Web Roles and days of trying to figure out why, this is the article that solved the problem for me. Many thanks!
Thanks, John. Glad it helped 🙂
Pingback: Be careful when you use both Windows Azure Diagnostics and auto cspack build | Jack Ma, a developer's random stuff