I was working on enabling continues deployment from GitHub to Azure WebApp for the sample Glimpse and Application Insights integration application. It is easy to implement this integration. Simplest way is to create “Deploy to Azure” button in your GitHub repository like I explained in this blog post. You can also do it manually:
- Open Settings blade of your web app
- Click on Continuous deployment
- Select External Repository and set your repository URL
Once enabled - KuDu will pull sources from repository, compile it and deploy web application.
This time it didn’t work smoothly for me. I got an error:
1 2 3 4 5 6 7 8 9 10
My web project doesn’t have StyleCop enabled so the error was quite misleading. The good thing - this error message had original msbuild command. So I opened KuDu debug console using URL:
https://<webAppName>.scm.azurewebsites.net/DebugConsole and typed the following command:
1 2 3 4 5 6 7 8 9 10 11
Note, the command text is different from the original. Specifically, I changed verbosity
/verbosity:detailed and redirected output to the file
> buildLog.txt. Resulting error message was much easier to troubleshoot:
1 2 3 4 5 6 7 8 9 10 11 12 13 14
Project that my web application referencing has StyleCop enabled. Also it seems that StyleCop fail to run.
At this point I decided that I don’t need StyleCop when publishing to azure. So I’ve added extra condition into target import
AND ('$(_PackageTempDir)' == ''). This condition is the best I come up with to distinguish the build for deployment from regular compilation. Here is corresponding commit and full import statement:
1 2 3 4 5
So I unblocked myself, but this solutions seems hacky. I was thinking of more robust solution with setting special parameter for build using application setting
SCM_BUILD_ARGS that will disable StyleCop. See KuDu wiki for details. However I wanted to get to the root cause of why StyleCop needs registry access. So I decided to troubleshoot it further.
I know there is an exception happening in StyleCop and I need its callstack. So I decided to use remote debugger to get it. First, I found github project that will run StyleCop from command line. I found one called StyleCopCmd. I downloaded and compiled it with the proper version of StyleCop.dll. I also added an extra
Console.Read in the beggining of it so I’ll have time to attach debugger. This is how I’ll run it from KuDu console:
I followed instructions to attach remote debugger to
StyleCopCmd.exe process. There are caveats:
- At first I used wrong credentials and was getting error like this:
--------------------------- Microsoft Visual Studio --------------------------- Unable to connect to the Microsoft Visual Studio Remote Debugging Monitor named 'sitename.scm.azurewebsites.net'. The Microsoft Visual Studio Remote Debugging Monitor (MSVSMON.EXE) does not appear to be running on the remote computer. This may be because a firewall is preventing communication to the remote computer. Please see Help for assistance on configuring remote debugging. --------------------------- OK Help ---------------------------
The reason was - I used user name
$glimpse-play-ai-2 instead of fully-qualified
glimpse-play-ai-2\$glimpse-play-ai-2. You may have the same message with the completely wrong credentials.
- When I run Attach to the process from Visual Studio I haven’t seen the process
StyleCopCmd.exe. The reason is that this process is SCM (KuDu) process and I needed to specify “sitename.scm.azurewebsites.net” as a Qulifier, not “sitename.azurewebsites.net” in Attach to the Process dialog.
- When debugging external code in Visual Studio - make sure to uncheck the box “Just My Code” in debugger options.
I set Visual Studio to stop on every CLR exception and let
StyleCopCmd.exe run. It paused on excpetion with the following call stack:
1 2 3 4 5 6 7 8 9 10 11 12 13 14
Using disassembler I found that StyleCop tries to set registry key when checks for the latest version:
So I’ve added this flag to StyleCop settings file to disable this version check. Here is the commit:
And it solved the issue.
Azure Web App infrastructure gives you great flexibility and power deploying and running your web applications. Even though it’s infrastructure has some limitations - it is really easy to troubleshoot issues with all the tools it provides.