I'm getting a null-object exception deep within XsltCompiledTransform, and I'd like to use the .Net Framework Source debugging feature to see what isn't being initialized, but even after following the directions for enabling it, I can't figure out how to step into the .Transform() method and start spelunking.
The tutorials I've found online say you can load the symbols for the framework library by using the Call Stack window while debugging, but this isn't useful when the callstack has yet to contain the library you want to debug. I've also tried loading symbols from the Modules window, but Step-Into still doesn't work.
Is the System.Xml.Xslt namespace source even available to step into when debugging?
If you have trouble fetching the sources on the fly, you might want to try out .NET Mass Downloader
As it looks, the sources for XsltCompiledTransform are included.
Related
I'm trying to port my console app over to a Blazor app. Everything worked fine inside the console type project, but it's not inside the Blazor project so I'm trying to troubleshoot. The app calls some things from a separate "class library" type project within the same solution.
The troubleshooting process itself is having issues of its own though. After a little bit of confusion I realized that the breakpoints set inside the referenced class library type project's code are not being hit.
Checking to console, I see it gives the error:
L: Unable to insert breakpoint at FtxApi.FtxWebSocketApi/<Test>d__5:MoveNext ():15
Is there anything I need to do (project settings or something) for the debugger to hit these? Or is it not supported at the moment?
Right now I'm just using a lot of Console.Writeline sort of as a workaround/replacement. And I noticed that the Console.Writelines inside the referenced class library type project are being called.. but only up to a certain method call that comes from a third party package. Execution seems to return from that point (nothing is called after it). Not sure what's going wrong there - more troubleshooting is needed, which brings us back to the breakpoints not firing (ideally I'd be able to make use of them).
I understand Blazor is new (and I'm an absolute beginner at using it), so not everything needs or is going to be perfect. I'm asking about the breakpoints kind of out of curiosity (I'd like to get them working but no big deal otherwise).
What I'd really like some insight into is: What might be going on with the code seemingly stopping execution / returning at that one particular method call? The method I'm calling is WebSocket.Open(), from the package WebSocket4Net. As mentioned above, I've tested this before (in a Console app) and it worked fine, so I'm guessing it's somehow related to Blazor which I'm unfamiliar with. I'm unsure how to get any more info to help debug this problem. Any help appreciated.
Edit:
I managed to find a solution to my problem without the use of debugging tools like breakpoints and such (I just used Console.Writeline a lot). I guess Blazor does not support some websocket implementations or something, because I found this error: System.PlatformNotSupportedException: Operation is not supported on this platform. blazor.webassembly.js:1 at System.Net.Sockets.Socket coming from websocket.Open(). I managed to get it working by implementing System.Net.Websockets instead, similar to this. Though my troubleshooting is over (for now), I'm still wondering if it's somehow possible to use breakpoints inside other referenced projects.
There are 2 solutions:
Solution 1: Right-click at Solution, choose Properties, choose Common Properties, Choose Multiple startup project, choose Action Start for Foo.Client, Foo.Server, Foo.Shared . Something like this
See https://blog.magnetismsolutions.com/blog/paulnieuwelaar/2015/04/07/debug-multiple-projects-at-the-same-time-in-visual-studio
Solution 2: Compile SharedProject, attacht PDB for debugging.
https://learn.microsoft.com/en-us/visualstudio/debugger/how-to-debug-an-executable-not-part-of-a-visual-studio-solution?view=vs-2019
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.
I am trying install OpenGL on VS2010.
I use this tutorial.
And I get the following error:
Unable to start program 'C:\Users\s151310\Tutorial 0.3.8\frameworkD.lib'.
The specified file is an unrecognized or unsupported binary format
How can I fix this?
Actually don't have to install anything at all to start OpenGL development with Visual Studio. As long as you limit yourself to OpenGL-1.1 and core Win32 APIs everything is already in place for you.
However to get modern OpenGL features one must use the so called extension mechanism to load pointers to functions of newer versions – a tedious and uninteresting process. Hence extension loader wrappers have been developed.
Also creating a window and setting up a matching OpenGL context is laborous as well. So you want to use some framework for that two.
Extension loader wrappers and frameworks are 3rd party libraries that need to be installed separately.
Unable to start program 'C:\Users\s151310\Tutorial 0.3.8\frameworkD.lib
Why are you trying to execute a library file? This is the framework library that's supposed to be linked into your executables. So this raises the question: How did you setup your project, specifically which build options did you configure. Without that I can't give better advice.
I've been rather confused by some SGEN stuff. I've enable the generation of serialization assemblies for one of my projects. Originally I got the follow error which I believe I've solved by doing some caspol stuff on a remote assembly.
Unable to load one or more of the request types. Retrieve the
LoaderExceptions propery for more information
Now however, I don't get an assembly generated. Adding some debugging/verbose output provides the message "SS.dll does not contain any types that can be serialized using XmlSerializer". I've read that this is because of a proxy switch applied by VS. The odd thing is it doesn't seem to be a problem with any other project.
So if I disable the proxy switch (example here) it seems to work. The linked build events however seem to do all projects. I don't know enough about MSBuild to tweak to just a single project, does anyone know what I need to change?
Additionally, if this change is made, is there a way I can automatically include this in a installer (VDProj)? I can't statically link to the SS.XmlSerializers.dll because the each dev uses a custom path.
Discovered the following post which talks about adding the <SGenUseProxyTypes>Off</SGenUseProxyTypes> to the csproj file which seems to work :)
This I think is related to my use of the nlog C++ API (and my question on the nlog forum is here); the purpose of my asking this question here is to get a wider audience to my problem and perhaps to also get some more general ideas behind the VB6 IDE's failure to build in my particular scenario.
Briefly, the problem that I am having is that I am having trouble building VB6 components which reference unmanaged C++ components which have calls to nlog's C\C++ API (which is defined in NLogC.DLL). The build problems are not occurring during compile time, they are occurring when the binary is being built which suggests to me that it's some kind of linker type problem? Don't know enough about how VB6 binaries are produced to tell. The VB6 binary is produced, but it is corrupted and crashes shortly after it is invoked.
Has anyone had any similar experiences with VB6 (doesn't have to be related to nlog or C++)?
edit: Thanks for all the responses to this rather obscure problem. Still no headway unfortunately; my findings since I posted this:
'Tweaking' the compile options doesn't appear to help in this problem.
Adding a reference to the nlog-enabled C++ component from a 'blank' VB6 project doesn't crash it or cause weird build problems. So it isn't a 'native' VB6 issue, possibly an issue with the interaction between nlog and the various components and 3rd party libraries used by other referenced components?
As for C++ calling conventions: the nlog-enabled C++ component is - as far as I can see - compliant to these conventions and indeed works fine when referenced by VB6 as long as it is not making any nlog API calls. Not sure if the nlogc.DLL itself is VB6 compliant but I would have thought that that is immaterial since the API calls are being made from the C++ component; VB6 shouldn't know or care about what the C++ component is referencing (that's as far as my understanding on this goes...)
edit2: I should also note that the error message obtained during build is: "Errors during load. Please refer to "xxx" for details". When I bring up the log file, all that there is in there is: "Cannot load control xxx". Interestingly, all references to that particular control disappears from that particular project resulting in compile errors if I were to try to build again.
Got around the problem by using NLog's COM interface (NLog.ComInterop.DLL) from my unmanaged C++ code. Not as easy to do as the C\C++ API but at least it doesn't crash my VB6 components.
I would try tweaking some of the Compile options found in the Project, Properties menu, Compile panel to see if they yield any additional hints as to what is going wrong.
For example if you compile the executable to p-code rather than native code does it still crash on startup.
What error message do you get when you run your compiled binary?
I doubt the compiler/linker is the problem: project references in a VB6 project are not linked into the final executable. A project reference in VB6 is actually a reference to a COM type library (which may or may not be embedded in a .dll or other binary file type). Project references primarily serve two purposes:
The IDE extracts type information from the referenced type libraries which it then displays in the Object Browser (and in the Intellisense drop-down)
At compile-time, the compiler extracts the type information stored in the referenced libraries, including the CLSID of each class that you instantiate, and embeds this data into the executable. This allows your executable to create instances of classes contained in the libraries that you referenced.
Note that the compiled binary doesn't link to any code in the referenced libraries, and it doesn't even contain the filenames of the referenced libraries. The final executable only contains the CLSID's and other type information that it needs to instantiate COM objects at run-time.
It is much more likely that the issue is with NLog, or with how you are calling it from your code, rather than something gone awry in the VB6 compile process.
If you think it might be a linker problem, this should crash it the same way:
create a new standard project (of any kind)
add a new module and copy the "declare"-statements into it
compile
If it doesn't crash it is something else.
It would help an exact description of the error or a screenshot of what going on.
One thing to check is wherever NLogC.DLL or the C++ DLL you built have the correct calling convention defined. Basically you can't have the DLL function names mangled or use anything but the STDCALL calling convention. If the C++ DLL has not been created with those two things in mind then it will fail to work with VB6.
MSDN Article on Calling convention.
"Cannot load control xxx" errors can be caused by .oca files which were created from a different version of an .ocx than currently used. If that is the case, deleting the .oca files helps.