I've been trying out the new Remote Debugging feature for Azure Websites, but I think I may have come across an issue: I can only get it to work properly if I use Web Publish. If I deploy a site with local git deploy, the debugger attaches but the debug symbols aren't loaded (breakpoints show the warning).
I tried both setting the Release configuration to include PDB files (since Azure's git deploy uses the Release configuration by default) and by using a custom deploy script generated by the azure site deploymentscript
command detailed here and setting the build command to use the Debug configuration. In both cases, I still get the same issue that the symbols aren't loaded.
I feel like the problem is probably one of the following:
Ultimately I'm hoping to write some automated deployment scripts and I'd much rather use git deployment than Web Publish to accomplish this. What really baffles me is that this fails even with the Release configuration set to include the PDB files. It really makes me think there must be something extra being done on Azure for Web Publish that's not done for git deployment. Does anyone have any ideas of what may be causing the difference here?
I'm including the custom deployment script generated by azure site deploymentscript
for reference and to show the build flags it uses. The relevant parts are after the :: Deployment
section.
@if "%SCM_TRACE_LEVEL%" NEQ "4" @echo off
:: ----------------------
:: KUDU Deployment Script
:: Version: 0.1.5
:: ----------------------
:: Prerequisites
:: -------------
:: Verify node.js installed
where node 2>nul >nul
IF %ERRORLEVEL% NEQ 0 (
echo Missing node.js executable, please install node.js, if already installed make sure it can be reached from current environment.
goto error
)
:: Setup
:: -----
setlocal enabledelayedexpansion
SET ARTIFACTS=%~dp0%..\artifacts
IF NOT DEFINED DEPLOYMENT_SOURCE (
SET DEPLOYMENT_SOURCE=%~dp0%.
)
IF NOT DEFINED DEPLOYMENT_TARGET (
SET DEPLOYMENT_TARGET=%ARTIFACTS%\wwwroot
)
IF NOT DEFINED NEXT_MANIFEST_PATH (
SET NEXT_MANIFEST_PATH=%ARTIFACTS%\manifest
IF NOT DEFINED PREVIOUS_MANIFEST_PATH (
SET PREVIOUS_MANIFEST_PATH=%ARTIFACTS%\manifest
)
)
IF NOT DEFINED KUDU_SYNC_CMD (
:: Install kudu sync
echo Installing Kudu Sync
call npm install kudusync -g --silent
IF !ERRORLEVEL! NEQ 0 goto error
:: Locally just running "kuduSync" would also work
SET KUDU_SYNC_CMD=node "%appdata%\npm\node_modules\kuduSync\bin\kuduSync"
)
IF NOT DEFINED DEPLOYMENT_TEMP (
SET DEPLOYMENT_TEMP=%temp%\___deployTemp%random%
SET CLEAN_LOCAL_DEPLOYMENT_TEMP=true
)
IF DEFINED CLEAN_LOCAL_DEPLOYMENT_TEMP (
IF EXIST "%DEPLOYMENT_TEMP%" rd /s /q "%DEPLOYMENT_TEMP%"
mkdir "%DEPLOYMENT_TEMP%"
)
IF NOT DEFINED MSBUILD_PATH (
SET MSBUILD_PATH=%WINDIR%\Microsoft.NET\Framework\v4.0.30319\msbuild.exe
)
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: Deployment
:: ----------
echo Handling .NET Web Application deployment.
:: 1. Restore NuGet packages
IF /I "azure-test.sln" NEQ "" (
call "%NUGET_EXE%" restore "%DEPLOYMENT_SOURCE%\azure-test.sln"
IF !ERRORLEVEL! NEQ 0 goto error
)
:: 2. Build to the temporary path
IF /I "%IN_PLACE_DEPLOYMENT%" NEQ "1" (
%MSBUILD_PATH% "%DEPLOYMENT_SOURCE%\azure-test\azure-test.csproj" /nologo /verbosity:m /t:Build /t:pipelinePreDeployCopyAllFilesToOneFolder /p:_PackageTempDir="%DEPLOYMENT_TEMP%";AutoParameterizationWebConfigConnectionStrings=false;Configuration=Debug /p:SolutionDir="%DEPLOYMENT_SOURCE%\.\\" %SCM_BUILD_ARGS%
) ELSE (
%MSBUILD_PATH% "%DEPLOYMENT_SOURCE%\azure-test\azure-test.csproj" /nologo /verbosity:m /t:Build /p:AutoParameterizationWebConfigConnectionStrings=false;Configuration=Debug /p:SolutionDir="%DEPLOYMENT_SOURCE%\.\\" %SCM_BUILD_ARGS%
)
IF !ERRORLEVEL! NEQ 0 goto error
:: 3. KuduSync
IF /I "%IN_PLACE_DEPLOYMENT%" NEQ "1" (
call %KUDU_SYNC_CMD% -v 50 -f "%DEPLOYMENT_TEMP%" -t "%DEPLOYMENT_TARGET%" -n "%NEXT_MANIFEST_PATH%" -p "%PREVIOUS_MANIFEST_PATH%" -i ".git;.hg;.deployment;deploy.cmd"
IF !ERRORLEVEL! NEQ 0 goto error
)
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: Post deployment stub
call %POST_DEPLOYMENT_ACTION%
IF !ERRORLEVEL! NEQ 0 goto error
goto end
:error
echo An error has occurred during web site deployment.
call :exitSetErrorLevel
call :exitFromFunction 2>nul
:exitSetErrorLevel
exit /b 1
:exitFromFunction
()
:end
echo Finished successfully.
In Solution Explorer, right-click the project, and click Publish. In the Profile drop-down list, select the same profile that you used in Create an ASP.NET app in Azure App Service. Then, click Settings. In the Publish dialog, click the Settings tab, and then change Configuration to Debug, and then click Save.
Some fixes were made in WAWS, and it is now possible to make debugging work when using git, by having VS correctly load the server-side PDBs. For it to work, you need to do one of two things (i.e. you don't need to do both). It can work in both VS 2012 and 2013.
SCM_BUILD_ARGS
, with value -p:Configuration=Debug
(more details here). Then go to the Deployments page and hit the Redeploy button (for the current deployment). Then attach from VS and it should all work!Indeed, this doesn't work today, and we're trying to see how we could make it work. At the root, the problem appears to be the Visual Studio debugger expects to find the PDBs on the client, while in the git case they only exist on the server.
This article discusses changes to how the debugger works between 2010 and the newer versions, and that probably affects things.
More investigation needed, but this is the state of things right now.
I was having this problem with a .Net Core Azure Function project, using the Cloud Explorer right-click functionality to attach. The following github issue speaks to it, but solution didn't solve my problem:
https://github.com/Azure/Azure-Functions/issues/872
I finally stumbled across the answer here:
http://dontcodetired.com/blog/post/Remote-Debugging-Azure-Functions-V2-The-breakpoint-will-not-currently-be-hit-No-symbols-have-been-loaded-for-this-document
It boils down to manually attaching to the process in Azure, rather than relying on the Cloud Explorer right-click functionality.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With