Many questions have been asked about this, and many answers have been proposed, but nothing's worked for me.
At one point, I turned on .NET symbol loading for WPF projects, using these instructions: http://blogs.msdn.com/sburke/archive/2008/01/16/configuring-visual-studio-to-debug-net-framework-source-code.aspx
Worked great, all cool and that.
Except in Silverlight projects, it would also try to load symbols from that server, but they didn't exist, so startup time to debug a project was huge.
So, I turned off symbol loading, and it did stop trying to load all the symbols, except for one namespace: System.Windows.Browser. VS still tries to load those with each F5, taking several seconds and driving me crazy.
I tried to add the symbol server mentioned here as well: http://blogs.msdn.com/seema/archive/2008/10/08/xperf-a-cpu-sampler-for-silverlight.aspx
Thinking that maybe the symbols were there, they'd get loaded and cached, and all would be well. But no, not only do they not get loaded, but VS tries to load symbols for every other DLL in my project, including those for which symbols have never been available, making it take even longer to start up.
Frankly, I don't even need to debug into the sources of these DLLs, I just thought it would be cool. Now I can't turn it off and it's driving me batty. What's the fix?
Tools -> Options -> Debugging -> Symbols -> Check "Search the above locations only when symbols are loaded manually", or remove everything from the list.
If you check the box, then you can rclick -> Load Symbols on DLLs in the Modules list / Stack window.
I think you may have
_NT_SYMBOL_PATH
defined in your environment. That seems to override whatever you do in Tools->Options->Debugging->Symbols. I had the same problem, and it almost drove me bananas, but in a moment of creativity I directed procmon (from sysinternals) at devenv.exe and searched the log for "symbol", and the first thing that appears was that environment variable mentioned above. There could be other similar sinister sidechannels too, but I wouldn't be surprised if you could out those too with a little aid by procmon.
I suspect that this behaviour comes from the fact that symsrv.dll, which is loading symbols, is used with other tools and there are different ways to signal that symbols should be loaded and... well, I guess this goes to the "shit-happens" account.
On a side-note -- this behaviour can be really bad for you if you have code using wininet-functions such as HttpSendRequest(). It will quickly deadlock visual studio and all instances of internet exploder. Add to that symbol loading that doesn't let itself be turned off. You can imagine what a day I've had so far...
But I feel better now :)
//P
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 having a weird problem with Visual Studio 2010 Ultimate:
One of my Nunit(2.6.2) test cases is failing in the debug mode but passing in the run mode, as if we had completely different code paths for the two scenarios.
Is this a known bug? or is there some option in vs I'm missing?
Please enlighten me!
Thanks a lot.
EDIT - MORE INFORMATION
My application submits some requests to a dll written by a group of people within the organization. The dll does some computation and returns the results back to me.
In a test case exploring the dll's behavior (e.g. submit a request having certain parameter, check the dll's output), running the Nunit test works fine, but debugging the test case gives me an error - an exception was thrown from within that dll.
IMPORTANT: Running/debugging another test case gives me consistent results.
So, for the weird test case:
1, either the dll is good, and something under the debug mode breaks the dll
2, or, the dll has a bug, which is triggered by something under the debug mode.
To my knowledge, the ONLY difference between running and debugging a piece of code in visual studio is that, when debugging, a pdb file is loaded while when running it's not. Essentially, a symbol table is loaded to identify code execution.
Then the issue doesn't make sense in the first place - why would loading a symbol table affect the dll's behavior? (It's unfair to ask anyone to give an explanation without seeing any code; however, since it's corporate prop. code, I can't show it here. Please, if you've ever encountered such things in your career, do share with me what happened in your case - let's hope my problem has the same cause so that I can actually know what went wrong. Thanks)
Are you using code coverage?
If so, try disabling it and run. It will probably work.
For more details, check: http://social.msdn.microsoft.com/Forums/en-US/aba3d58f-f19f-4742-b960-8ac2be29bb88/unit-test-passes-when-in-debug-but-fails-when-run
You may have run into a situation where you're taking the same code path, but the results are subtly different in debug vs non-debug due to optimizations. There are a couple of distinct possibilities here:
Your code has a subtle bug, e.g. a race condition
Your test is being overly specific, e.g. for floating point comparisons where you should use a tolerance
It's a pain not being able to debug, but I suggest you add logging throughout the method and the test so you can see what's going on. (And hope that the logging itself doesn't change the test result, which is also possible...)
Thank you for your response.
I've identified the reason: it's due to a false parameter which drives the dll nuts. My bad.
It still doesn't answer the question why the behavior at debug time goes crazy, but good while running the test case.
However, I guess, since the parameter is wrong in the first place, I can't really blame the dll for going nuts. Anyway, when I passed in the correct param, all went good.
Thanks a lot guys.
I'm using Visual Studio 11's profiler (sampling), and am having trouble getting the report to show me the code I need it to. The problem is that several of the assemblies won't load because they're "Native Images". The primary one I'm concerned about is "System.Core.ni.dll". Because that symbol isn't loading, when I go to view the report I can't see why my Expression is slow. Instead, it just bundles all of the samples related to Expressions into a line reading "System.Core.ni.dll".
If I look at the Output window, I see the following two lines:
Failed to load symbols for C:\Windows\assembly\NativeImages_v4.0.30319_64\System.Core\713a8c0e41e664d349efcc0cec7f5e86\System.Core.ni.dll
Loaded symbols for C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.Core\v4.0_4.0.0.0__b77a5c561934e089\System.Core.dll
Notice how the first symbol doesn't load?
What are my options? Can I stop native images from being used? Can I load the symbols for native images?
I had a similar problem on Windows 8 and found a post here that helped me solve the problem. Don't know if it will solve the OP's issue but it worked for me.
I experience a strange behaviour in Visual Studio 2010 when creating Windows Phone 7 apps. After some time VS starts to complain about Invalid XAML although there is no problem and the app compiles and runs just fine.
It bugges me because I cannot use the visual desingner saying "Exception was thrown on "DataTemplate": Invalid XML" and there is a DataTemplate higlighted in the code. The data template is always ok, VS does not complain about it when copy-pasted to another project.
I found out that problematic are usually the DataTemplates with custom converters or when usin g classes like PhonePerformance.
Sometimes the error is "Exception thrown was due to document error: Invalid XML" and nothing is even highlighted in the XAML file.
I tried reinstalling .NET. Visual Studio etc. and the problem occurs on two separated machines so I do not think it is specific to my configuration. It may be specific to my code.
Anyone experienced similar behaviour?
When using XAML, if you reference a library that needs to be evaluated but can't be at design time you get this kind of error. You can turn off the visual editor and just work in XAML - that will stop the error (and save you time).
You reinstalled .NET and VisualStudio??? You should have just spun up a second instance, opened the solution in both, then attached the debugger from one to the second and opened up the visual editor. It would have told you exactly what in your code was causing the problem. Also DesignerProperties.IsInDesignMode in your converters. Jeez. You wasted so much time :(
As for design time data, that's tricky. Either you have DesignTimeDataWithDesignTimeCreatableTypes that aren't or DesignData that can't create proxies for your real types (for whatever reason, had this issue many times deep in the past).
The only way to figure this out is to debug one instance from another. Its actually not that hard. I do it alot (debugging WF4 ActivityDesigners).
A friend has found a solution and you would not believe where the problem is. This happens if you have a space in the name of your assembly. I found out that I really have a space in assembly name in all the problematic projects, renamed the assemblies and the designer works again.
The solution is also mentioned here http://forums.silverlight.net/t/115011.aspx/1
I recently added a new project to my Visual Studio 2008 solution. Now, as I make edits in the new project, I receive a ton (~50) of type checking errors - indicating that an assembly reference may be missing. However, when I actually build the solution, the errors go away. As best I can tell, my dependencies are set and the build order is correct. What could be wrong?
It doesn't prevent me from building and deploying, but it's a major nuisance. It makes it hard to tell when I actually have introduced new errors (until I do compile). Thus, it erodes the usefulness of having the error window do static analysis.
Example, one of the 50 errors is this:
"The type of namespace name 'PersonManager' does not exist in the namespace 'Gideon' (are you missing an assembly reference?"
In reference to this line of code:
Gideon.PersonManager pm = new Gideon.PersonManager()
PersonManager is underlined in both places, and when I right click the type and selected 'find all references' I get an alert box that says "Cannot navigate to PersonManager"
However, the references are definitely there, because when I build, it works.
One other detail is that there is a mixture of C# and VB.net code, though I don't think that should make a difference.
Well, yes, the IntelliSense parser is not an exact replica of the C# compiler. It has a very different job to do, it needs to do something meaningful while the code is utterly broken since you are editing it. Tough assignment, they did a tremendous job with it. But as a side-effect, it can fail to parse things that are actually legal. It's quite rare but not unheard of, seen it myself a few times.
This won't go anywhere concrete until you at least give us some idea of what kind of errors you are seeing, along with a snippet of the code that generates them. You didn't do so, I can only recommend that you select another window so you don't have to look at them.
I had the same problem. I had a project in my solution that was causing the problem - I removed the project from the solution, then added a reference to that project in the main solution and the errors went away. Strange that it only happened on 1 machine. Opening the solution on another machine was fine...