UWP Debugging Broken

[MelbourneDeveloper]

I upgraded to the latest version of UWP 16299. I then upgraded my .NET Standard projects to 2.0. Debugging is completely broken now. I can't debug anything inside the .NET Standard project. I am using Visual Studio 15.5.3. I can however debug the code in the UWP project.

[MelbourneDeveloper]

I cannot recreate the problem in a new solution. I created a new Xamarin Forms solution and upgraded all the NuGet packages and UWP version. When I ran the project, I was able to debug fine. This problem only exists in my current solution which unfortunately, I cannot post here. I have tried creating the .NET Standard 2.0 project from scratch and copying all the files in to it again. It compiles and runs fine, but debugging this .NET Standard 2.0 project does not work at all. It's stopped my development dead in its tracks.

[MelbourneDeveloper]

I thought it might be related to this bug: dotnet/sdk#955 but the PDBs are getting generated fine and they are getting copied to the outputted UWP debug folder.

[trylek]

Hi @MelbourneDeveloper! According to my recollection there are two pieces at play w.r.t. the bug #955:

1. Parts of the VS / msbuild infrastructure don't yet properly handle the new flavors of PDB files, namely portable and embedded portable PDB files. You should be able to work around this by using legacy (Windows) PDB files. I understand it might be annoying as the portable PDB files are much more compact. Apologies about this - it just takes a bit to propagate each new technology across the entire development and tool stack. Let me assure you we're at top gear working to streamline the developer experience in this respect.

2. There's apparently one more bug in the msbuild scripts that manifests as some missing properties; as I described higher up the e-mail thread, as a temporary hotfix for these it might work to set the following environment variables in your build environment:

set VC_ExecutablePath_x64_x64=%VCToolsInstallDir%bin\HostX64\x64
set VC_ExecutablePath_x86_x86=%VCToolsInstallDir%bin\HostX86\x86

I apologize if I missed some finer points of your particular problem - please try to elaborate on what exactly fails for you; I can easily understand that you may not be able to disclose your complete source code with us, customer privacy is an absolute priority for our company, but without any additional detail we're going to have a hard time figuring out what your problem is.

Thanks a lot

Tomas

[MelbourneDeveloper]

Hi. Thanks for this. 1) How would I use legacy Windows PDB files?

[trylek]

Hi @MelbourneDeveloper! Thanks for your quick response. I actually doubt PDB file flavor can be the cause of your trouble - if you don't know how to switch the PDB format, I would be surprised if you were able to switch it to portable in the first place :-). You go to Debug | properties, then there's this multi-tab dialog showing, so go to Build, the [Advanced] button, that will let you switch a couple of obscure options including the PDB format.

[trylek]

If we're able to rule out portable PDB file usage, we'll need to understand why .NET Native debugging fails for you for other reasons. As a first cut, please try to watch out for any suspect entries in the "output" window that captures debug output from both the app and the runtime, that's a likely place for a potential configuration or late build problem to pop up.

[MelbourneDeveloper]

@trylek , I found your post here on how to do this:

Add this to the .NET Standard DLL.

<PropertyGroup>
    <DebugType>pdbonly</DebugType>
</PropertyGroup>

It has allowed me to work around the problem!!!!

Thankyou so much. You have saved my day. I was about to crawl in to the fetal position and start crying.

I strongly suggest that you leave this ticket open and find some way to fix this so that other developers don't hit the same problem.

[trylek]

Thanks a lot @MelbourneDeveloper for letting me know; it's a relief to know that you're unblocked in your immediate efforts. Amusingly enough, I'm more or less a lame witness to this game just because I got looped in after having written a bit of .NET Native compiler code implementing the consumption of portable PDB files ;-). If I understand you correctly that the primary cause of your problem was indeed the not yet fully supported portable PDB format, I believe that's already committed and assigned on the VS team for the 15.7 release but that's beyond my primary area of expertise.

Have a nice afternoon - are you at something like 3:30 PM assuming you really work in Melbourne :-)?

Tomas

[MelbourneDeveloper]

Thanks. It's actually morning 10:30am here.

I guess I have a general comment for everyone at Microsoft working on the tooling these days. The tools are in a state of flux. When we create a project with a new format, or structure, or simply download a new update, we never know what has changed and what may be a breaking change. The pain is real. Some days, we literally get nothing done because some functionality like debugging is broken.

In this case, it seems that the new PDF format was to blame. What I'd have to say is that the team should not be rushing to release new features at break neck speed. Instead, they should be thoroughly tested in all scenarios, platforms, and so on before they become standard features in Visual Studio. I know it's important to get new features in, but when they break something, days go down the tube.

Anyway, I'm just very grateful that my day wasn't wasted today.

[trylek]

Fair enough, thanks @MelbourneDeveloper. We're often mistaken - just like me with my miscalculation of your time zone :-). Our recent efforts were targeted at maximizing agility in the sense of being able to act on customer problems / security fixes etc. so that naturally shortened the developer cycle of a particular release. I'll forward your message to my bosses as something to think about :-).

[MelbourneDeveloper]

Thanks again.

[trylek]

FYI @tmat

[Inrego]

<PropertyGroup>
    <DebugType>pdbonly</DebugType>
</PropertyGroup>

Worked for me too. I had the same issue, and I was going crazy over why debugging didn't work. Thank you!

[MelbourneDeveloper]

@trylek , this ticket can be closed.

[trylek]

Glad to know @MelbourneDeveloper - at least I hope this means success rather than resignation ;-).