Be careful when you use both Windows Azure Diagnostics and auto cspack build

Recently, one application I work on encountered an interesting issue. We have configured WAD to forward the Windows event logs to a storage account. And it used to work very well. However, after a recent new deployment, all Windows event logs on the web role machines stopped to forward. Logs on worker role machines are still transferred, though.

We re-examined all the configurations, Entry Point codes to start WAD monitor, storage account connection string. Everything looks fine because we didn’t change them for the latest release.

Then what the heck happened to the web role machines? The application works fine, logging works fine. Only WAD doesn’t work? And I didn’t notice any WAD related errors.

I searched the Internet and came to this post which helped resolve the problem. I actually use another approach to resolve this particular issue. But the essential part of the approaches are the same.

So, the issue is due to we changed the auto build approach for the latest release. Originally prior to the new build method, we simply use the Publish target of Windows Azure MS Build extensions. However, for the latest release, since we enabled CodeSign to all our assemblies, we need to repack the Azure package to include the CodeSign-ed assemblies. And the original Publish target is not very convenient to be integrated into the TFS build system.

We updated the TFS build template to include a new activity which simply invoke the cspack to repack the Azure deployment package. And in the arguments of the cspack command, we missed the EntryPoint part of the /role parameter for the web role of our application.

After simply changing the TFS build template, now the new package restarts to initialize WAD and all the logs on the web role machines come to storage as expected.

Hope this helps,


Be careful when you use both Windows Azure Diagnostics and auto cspack build