Debugging ASP .Net Core symbols and source don't match - visual-studio

I'm trying to track down an issue with MVC so I thought I would step into the ASP .NET Core source code. I've unchecked "Enable Just My Code" and I've checked "Enable .NET Framework source stepping" (although I guess that's not necessary). I've also checked "Enable source server support" and enabled the Microsoft symbol server.
I step into this line
app.UseMvc();
and eventually I get to this code in MvcApplicationBuilderExtensions.cs.
VerifyMvcIsRegistered(app);
var options = app.ApplicationServices.GetRequiredService<IOptions<MvcOptions>>();
if (options.Value.EnableEndpointRouting)
{
Stepping through this code the program counter starts to jump around and I receive an error that several of the local variables cannot obtain the value because it is not available or it's been optimized away. I assume this is because the source file and the symbol files don't match.
I'm running this on Visual Studio 2019. It's .net Core 2.2.203. I've deleted the symbol cache and the SourceServer cache. I'm trying to figure out what I've done wrong in my code and exactly why.
Actually, I've tried to debug .NET source code several times over the past several years and I always have the same issue. None of the online help seems to have an answer. Am I doing something wrong or is this just unreliable?

The message is accurate and explains exactly what happens. It has nothing to do with mismatched symbols.
The (non) problem as the message explains is that the IL has been optimized during compilation, those variables no longer exist. A Release build performs a lot of optimizations that usually end up eliminating parts of the code that aren't needed.
Functions can and quite often are inlined. A variable may be replaced by a register for example. A loop may be eliminated entirely. When that code runs the variables or functions are no longer there so they can't be displayed.
Debug symbols can still be generated in a Release build. They'll reflect the IL generated for a release build though. One would need assemblies compiled in a Debug configuration to get IL that matched the source without any optimizations.
That's true for the .NET Core runtime, our own code when run a Release build and all NuGet packages.

If you want to debug .NET Core source code you can download it from github (https://github.com/dotnet/corefx). It's very easy to debug, like your own project.
There is very good video, where explains how .NET Core MVC request life cycle works (https://app.pluralsight.com/library/courses/aspnet-core-mvc-request-life-cycle/table-of-contents), maybe there you can find information which you need.
P.S. you can get 3 months free in pluralsight with microsoft account.

Related

UnityPlayer_UAP_ARM64_release_il2cpp.pdb not loaded

I've installed several packages in a Unity (2020) app I'm building. Namely: World Locking Tools, MRTK, PUN2. World Locking Tools provides some examples that are built with assemblies defining scripting symbols that any derived files I want to build would need access to. I'd like to create my own version of certain files from one of these examples. To do this and have access to the scripting symbols in one of those examples, I created an assembly reference to reference the assembly for that example code within World Locking Tools package installed in my project space. In so doing, I kept running into the common "...not found, are you missing an assembly reference" issue, which ultimately led me to creating assembly references for many of the assemblies provided by the various packages I needed to use (not just the particular example code I initially wanted to modify). Once my project finally built successfully in unity, I then tried to upload to a Hololens 2 headset in Visual Studio. This provided the error in the title of this post. Coincidentally, the app also appears to fail to start on the headset. Before I tried to alter my codebase with modified versions of files from that World Locking Tools example and with assembly references, the code would successfully build in Unity and successfully deploy to the Hololens 2 headset.
Does the behavior and missing .pdb error I describe mean that I'm missing assembly references for yet other packages even though Unity successfully builds the project?
This is my first foray into using assemblies so be please be gentle :)
For the .pdb message, that one is ignorable since will not have that symbol available. However, the app not starting is definitely likely due to a missing component or loading issue. When ran in debugger, may get a better idea on what is missing or from a debugger log in Unity.

Blazor WebAssembly - cannot debug an assembly that contains some specific type of code

I try do debug a blazor webassembly app, that references a shared project named Test.Shared. I've been trying to set breakpoints in that projects code but nothing helped - breakpoints just aren't hit.
When I'm trying to set a breakpoint outside in the calling code and then step into "Test.Shared" source - it just seems to go step by step through the underlying code (I have to hit "step forward" multiple times before it proceeds the debugging to the next line, and the number of hits changes when I reduce/increase the number of lines in the underlying method code) but its not displayed in the debugger window.
So, after some investigation, I figured out that I can make the debugger work when I throw away all the code from the Test.Shared and leave only one simple test static method. Based on this fact I guess there is some specific type of C# code that causes the whole containing library to be invalid for debugging.
Any suggestions what this code type might be?
The environment I use:
Visual Studio Enterprise 2019 16.6.2
NET Standard 2.1 as a target platform for both Blazor app and shared library
NET Core 3.1 as a target platform for the hosting web app that serves webassembly app packages
Microsoft.Components.WebAssembly 3.2.0
The issue is with having attributes that have enum values inside of them.
Many people are having this problem and it's better explained in Blazor Wasm: debugging broken when referencing #attribute with enum contructor argument #25380 by zbecknell:
Here's a simple repro project: https://github.com/zbecknell/Undebuggable.
See Counter.razor:4 for the line that breaks debugging for the project:
#* The following line breaks debugging for the project, no matter how long you wait *#
#attribute [BadAttribute(BadEnum.Default)]

VS2015 Community - Debug Classic ASP pages / Ignore Compile Errors

So I'm a lucky boy, I've been tasked with upgrading the development environment but not the code of a monster classic ASP product. It has been developed over several years and contains huge amounts of superfluous code in.
In order to modernise the development environment I'm targeting the IDE and moving away from FrontPage (yes, I know!); I've created an empty .Net project in VS2015 Community edition, manually added the legacy classic ASP code.
The advantage is by using VSnn it can be linked into TFS seamlessly and allow proper SDLC process to be enforced.
The problem is, I cannot attach a process in order to debug because the legacy code does not compile when I Build -> Build Solution. As I understand it the solution must build in order for the break points to be enabled?
There are 4 error types repeated hundreds of times during build;
Statement cannot appear outside a method body
Identifier expected
Declaration expected
End If must be preceded by a matching If
My questions are, how can I debug this beast if it will not compile?
Is it possible to ignore these warnings for a successful compile?
Is it possible to add break points and hit them in VS2015 for script only debugging?
And yes, I would burn this beast to the ground and use .Net but its not an option.
Something doesn't add up here. Classic ASP files aren't compiled, they are evaluated at runtime. I created a test project with both a WebForms page and Classic ASP page. Both worked by default. I attempted to reproduce your scenario by removing an opening if block but didn't receive any compile errors or warnings.
I am using VS2015 but would suspect to see the same since at least VS2012 if not early versions.

VS Go to definition failing / source code not available

I've just started experimenting with Visual Studio in order to explore F# but I'm never able to navigate to third-party dependencies code through the "Go to definition" option.
I'm getting this error message:
"Cannot navigate to definition. Source code is not available."
My main language is Java and I'm used to IntelliJ IDEA source retrieval mechanism (usually done through the Maven repositories). I consider this an indispensable functionality when developing code. Isn't there anything similar for .NET?
EDIT
After reading the comments and answer, I went looking for some packages on SymbolSource and I found them (e.g. SymbolSource page for JSON.Net).
I've tried the PM commands shown and the page but they kept producing errors:
Install-Package : An error occurred while processing this request.
So I've downloaded NuGet.exe and by running the command in verbose mode I could obtain the URL it was requesting (e.g. SymbolSource FeedService URL for JSON.Net).
As you can see it is showing an error:
Gettting packages from the NuGet feed is temporarily disabled. But you don't need it for debugging!
Is this to be expected?
P.S.: I've also tried with the pre-authenticated links. Same problem.
P.S.2: Seems that I can step into source code of third party dependencies during debug, but I still can't access it through "Go to definition" (neither in Debug nor in Edit mode).
In Visual Studio, you might be able to Go to Definition to third-party source code if:
You are in Debugging mode
'Enable source server support' options are turned on (you seem to do that already)
The third-party assemblies have their pdb files in source servers
Go to Definition in Editing mode doesn't have that capability in either C# or F#. In F#, 'Navigate to Metadata' hasn't been implemented yet.
We haven't been able to add 'Navigate to Source' to Visual F# Power Tools because they have many tricky issues e.g. (1) The feature is unusable if source server support isn't enabled, which is unfortunate (2) It relies on external data source that might be slow or unavailable (3) There is a good chance that pdb contents are outdated or incorrect, etc.
That said, 'Navigate to Metadata' seems to be less tricky to handle. We have required information from FSharp.Compiler.Service, it requires some effort to filter what we need and present it to users. This feature may be available in a future version of Visual F# Power Tools.

How to fix "Unexpected error (32801)" when compiling VB 6 program?

I have to maintain an old VB 6 ActiveX DLL called by another third-party program for which I have no sources. This DLL works and compiles fine against the API of said program for about 6 years and 3 major versions.
But now when I try to compile the DLL against a new major version the mentioned error occurs. It seems the error occurs before "my" code is called so there´s no use debugging or logging. The only remedy was to compile w/o binary compatibility which is no real option. My Google search turned up quite some people with the same problem but no solution.
Does anybody here know how to fix this issue ?
I finally figure out how to diagnose VB6 error 32801 in a systemic way.
My theory is When the VB6 compiler is creating a project or binary compatible library, the compiler decompiles the type information from the referenced library. Error 32801 occurs the source code's type information is not the same as the referenced library.
There is a tool called OLEView. This tool can decompile the COM type information into an IDL text. What I do is decompile the referenced library in to IDL and take the last good build of the failing library. Most times it is a build server version but the build does not work on a developer workstation. Decompile the last good build. Use a text comparison tool, like WINMerge, and find the differences between the type libraries. The differences make it easy to track down the problem.
Depending on the difference will determine how to correct. Mitigation can be done by either correcting the reference DLL, or by source code correction, or source code references.
It sounds like one of the types in the interfaces defined in your new DLL is different from one in the previous DLL. I'm deducing you use types defined in the third party program in your public interfaces of your DLL. It sounds to me like the third party has changed the definition of one of the types but kept the name and GUIDs the same. You could use something like OLE/COM Object viewer to check whether that's true. If it is true then you can complain to the publisher of the 3rd party program. Do you have enough political power to succeed?
Bruce McKinney, the guru who wrote Hardcore Visual Basic 6, ran into the same issue with a structure in a type library, where he changed some of the member types. The only fix he could find was (essentially) to break binary compatibility - and that's after some correspondence with the VB6 compiler team, who he knew fairly well. I don't think anyone else could do better.
There is a discussion about this error on devx.com that seems to indicate that the problem stemmed from Microsoft's Scripting Runtime (scrrun.dll).
FileSystemObject compatibility Unexpected error (32810)
Does your DLL reference that library? If so, can you remove the reference (e.g., replace FileSystemObject functionality with intrinsic VB file handling functions and/or API calls).
Are any of the files associated with the core project being compiled marked as Read-Only (i.e. not checked out of SourceSafe or similar repository)?
*.exp
*.vbw
*.lib
---------------------------
Microsoft Visual Basic
---------------------------
Unexpected error (32810)
---------------------------
OK Помощ
---------------------------
This the message I was getting trying to reference in VBIDE an old OCX that has been recompiled recently.
After somewhat long research the offending lines of code causing this error appeared to be
Property Get MouseActivate() As BookmarkEnum
Just changed this to
Property Get MouseActivate() As Boolean
. . . and the error was gone.
BookmarkEnum is an enum from ADO. Our build server is Server 2003 and my dev machine is Win10. The project references ADO 2.8 but apparently this typelib has some differences on Server 2003 vs Win10

Resources