I'm using Visual Studio 2017 and I'm developing WPF application that load dlls from other users by using:
Assembly.LoadFile(filePath);
After every load, the visual studio try to load the symbols from these dlls and sometimes it take a lot of time.
I have found several solutions that didn't work for me:
Enable "Just My Code" - didn't work
Specify excluded modules - didn't work because I use cache mechanism that gives every time the dlls different file name, so I can't specify the actual file name.
_NT_SYMBOL_PATH variable is not defined.
Is there a way to load the dlls without the symbols? Or prevent from visual studio to load symbols from specific folder (All the dlls are in specific folder)?
Update:
I tried also:
Delete All Breakpoints - didn't work
Uncheck all non-local sources for Symbol file (.pdb) locations e.g. Microsoft Symbol - didn't work
Load only specified modules - Could work but I prefer not to maintain this list because I use many projects and I open the solution from different locations. Maybe there is a way to load only .pdb files from the solution?
Related
I have a C# project with several different branches. I'm trying to separate out code for a specific feature into its own branch using git cherry-pick.
This involves cherry-picking about 20 or so commits from a Development branch into a separate Feature branch.
I'm kind of in the middle of this process (cherry picking in chronological order) and I'm trying to build the project in Visual Studio as I go along to check that everything is going OK.
However I'm getting some strange 'Source file .... could not be found' errors, for both .cs files and .xaml files.
Some of these errors refer to files I know will be added in future commits, so I'm not too worried about them. However others refer to files that were in the Development branch which I don't intend to bring to my Feature branch (as they are not part of the feature).
The strange thing is, while it's true that the offending files don't exist, I can't understand why Visual Studio is even looking for them - e.g. they hadn't been added to the project at the time of the commit, and indeed if I open the .csproj file there is no reference to them.
I've tried "Rebuild Solution" and even "Clean Solution" followed by "Rebuild".
Why would Visual Studio look for these files and then show an error that they don't exist? Is there some sort of build cache that I need to clear? (e.g. that may have been created the last time I built while on the Development branch?)
We have a scenario like this:
We have ~100 solutions containing 10 projects each.
Each solution copies its artefacts (i.e. its 10 dlls) to a shared single folder like C:\code/assemblies.
If I develop something for feature X, I'll open up SolutionX.
The source for all solutions/projects is local in a single Monorepo C:\code.
During debugging, when the method/class/whatever is implemented in project Y, it opens the corresponding file (which is nice). So there must be information available how to get to the source.
But when developing, I cannot navigate to the implementation e.g. by using F12 ("go to definition") but just get the signatures gathered from meta data. I'd like to have the same experience like during debugging.
So right now I open up a Visual Studio Code, open the folder containing the sources and do a "search in files".
Any better ideas?
N.b. Resharper is not an allowed option. Also doesn't play nice with Postsharp.
N.b. I don't know if it is important but all except one solution start an external program (the shell), since all except one solution contain only dlls.
I have done similar in Old project.
You can use Symbol with Visual Studio 2019. Simple steps can be:
A. Generate Symbols for projects :
In Solution Explorer, select the project.
Select the Properties icon (or press Alt+Enter).
In the side pane, choose Build.
In the Configuration list, choose Debug or Release.
Select the Advanced button.
In the Debugging information list, choose Full, Pdb-only, or Portable.
Refer for more information:
Set debug and release configurations in Visual Studio
Publish symbols for debugging
B. Use Symbol in Visual Studio:
In Visual Studio, open Tools > Options > Debugging > Symbols (or Debug > Options > Symbols).
Under Symbol file (.pdb) locations,
To use the Microsoft Symbol Servers or NuGet.org Symbol Server, select the checkbox.
To add a new symbol server location,
Select the + symbol in the toolbar.
Type the URL (http), network share, or local path of the symbol server or symbol location in the text field. Statement completion helps you find the correct format.
Tools - Options - Debugging - Symbols page
For more Details refer:
Configure symbol locations and loading options
I think you should analyze project dependencies (for example with https://www.ndepend.com/docs/visual-studio-dependency-graph ) and cluster your projects in less Solutions
Edit : I am editing this answer based on your comment. I think you are looking for two use cases
Peek into the source code of referenced binaries
Navigate to the source and then edit them in place
To achieve option (1)
In Visual Studio 2019, use the built in decompiler to help you with navigating to code outside of the solution. This is an experimental feature as of May 2020. By default this is disabled and you should enable it. Once enabled the F12 navigation will decompile and allow you to peek into the source code.
On the other side, the more you relax the compilation the better the decompilation. Meaning, you can turn off optimisations (if any). This doesn't have to do anything with symbol generation options.
If you are using visual studio 2017 (or) less, the same can be achieved by Telerik Just Decompile plugin (free). Check the feature View decompiled code in tabs
To Achieve option (2) :
You should reference source files rather than binaries, because you won't get the natural in-place edit with referencing binaries. There are always going to be caveats irrespective of the solution you choose. Referencing source can be done using the "Add as link" feature in Visual studio, where the source code belong to one solution and can be referenced as link (something like windows shortcuts) in all the other solutions. (https://andrewlock.net/including-linked-files-from-outside-the-project-directory-in-asp-net-core/). If you are referencing source, you need to remove the binary references.
And you also have to decide from an architectural standpoint on how this changes the way people develop and commit code. The point of referencing binaries is to make sure they are not edited for convenience, but that depends on the nature of the development team purely.
Conclusion
From a best practices standpoint, you either have to reference binaries and don't allow them to be edited (or) you allow source references and edit in place. But that depends purely on what you want to achieve.
I'm trying to check in an existing project to Visual Studio Online (VSO) for the first time but I keep getting errors due to missing files. These files appear to be items that we removed. I keep adding them to "Exclude" list but there are too many of them e.g. simple PNG images, JS files, etc.
I'm not sure where the "inventory" of files are kept in Visual Studio 2015.
Is there a quick and easy way to remove these missing files' records from Visual Studio so that I can check my project into VSO?
Yes, you're correct that the error message you got is mainly caused when you're trying to check in files which are no longer exist on the machine.
You can go to Source Control Explorer -> select these missing files -> Undo Pending Changes, and then you don't need to exclude these missing files every time when you check in files.
I'm having an issue with loading symbols on my ASP.NET MVC project. The first time I load visual studio and debug my project, symbols are loaded in roughly 2 seconds. I then end the debug session, make a code modification, and debug again, and the symbol load time is about a minute. Based on the research I have done, here are some applicable settings on my machine/VS:
In Options/Debugging/Symbols/Symbol file locations, "Microsoft Symbol Servers" is unchecked, and there are no additional locations.
Options/Debugging/Symbols/Cache symbols in this directory is "G:\Symbol Cache". I did click "Load all symbols" and I have inspected that directory and I see lots of symbols.
Just my code is enabled.
The _NT_SYMBOL_PATH and _NT_ALT_SYMBOL_PATH environment variables are not defined on my machine.
Options/Debugging/Symbols/Automatically load symbols for is set to "Only specified modules", with no modules specified.
I have tried both debug and release builds, with identical results. Ctrl + F5 loads the site almost immediately.
I too had this problem, the cause was that I had accidently enabled the "Microsoft Symbol Server"
You can disable it by going to Tools > Options > Debugging > Symbols and uncheck the "Microsoft Symbol Server"
Now it loads just as fast as it used to.
I too had this problem and noticed that it was mostly related to 3rd-party assemblies acquired via NuGet. In these cases, Visual Studio was trying to load PDBs from paths that apparently existed on the original author's machine (i.e. D:\OriginalAuthor\MyVisualStudioProjects\AwesomeNuGetPackage) but on my machine the same path referred to an optical drive. I then discovered via Command Prompt that if you tried to change directory to an optical drive that didn't have a disc in the tray, it took a very long time (~30 seconds) to fail. With this in mind, my solution was to simply place a DVD in the tray. At that point Visual Studio was able to very quickly determine that the path didn't exist, skip loading the PDB, and go straight into debug.
So, if Visual Studio is taking a long time to load symbols, watch the Output window for the paths it's trying to access and verify that you can quickly access (or quickly fail to access) those paths yourself via Command Prompt.
This brings up an interesting question about security/privacy--apparently Visual Studio is storing the absolute path of the original PBD within the assembly. I suppose this isn't a super critical issue, but from a privacy perspective I don't really want my absolute filesystem paths being exposed to the public without my knowledge.
Just try this Debug -> Delete All Breakpoints.
Its works on me.
I had 2 .dll's giving me grief that I didn't need to debug that started taking minutes to load. The afore mentioned solutions didn't help. So I went to Options -> Debugging -> Symbols and under the radio button for "All modules, unless excluded" click on "Specify excluded modules" link. Then type the .dll's that are causing issues.
When is "Browse To Find source" enabled in Visual Studio 2010? (see below)
In addition, I want to have it enabled so that I could browse to already-downloaded source code
files from http://referencesource.microsoft.com/.
This would be useful since Microsoft doesn't always release PDB/source code at the same time with their latest patches. So if I want to step for example into DateTime, I really don't care about the latest patches which didn't involve DateTime. I just want to browse to its code which I downloaded from http://referencesource.microsoft.com/.
After some investigations I found dia2dump which is a useful tool to view PDB file contents. (It's in C:\Program Files (x86)\Microsoft Visual Studio 10.0\DIA SDK\Samples\DIA2Dump\)
It looks like when I can't see source code for something like DateTime, using .NET Framework stepping, a mscorlib.pdb file actually gets downloaded.
But if you look inside it with dia2dump it doesn't contain source file mappings. In other words useless, because even if you could browse to the source code like my initial idea, it wouldn't work because there are no source file mappings and no start addresses of the functions, and a lot of stuff missing :(
I think the solutions here are to use .NET Reflector Pro for or keep a virtual machine at hand, with releases of the framework which have source code and then disable updates.
Introduction
Whenever you do a build from Visual Studio, normally, you also get a PDB file besides your executable file. You can see this file in the ..bin\Debug or ..bin\Release directory.
This PDB file keeps a mapping to your source code lines and executable code in your assembly. Also, the original locations of the source code files from which a build was done is stored inside a PDB file.
This means that if you build a class library which had a single file located at G:\ClassLibrary\Class1.cs, this path will be stored inside ClassLibrary.pdb.
What is important to remember from all this is that without a PDB file it is impossible to do source code step-in debugging.
Real-life scenario
So, suppose I do a build on my drive G:\ClassLibrary1, for a class library.
I give you a ClassLibrary.dll and a ClassLibrary.pdb file, or you get them by checking them out from source control.
You reference the ClassLibrary.dll in your project and you use a class from the library.
If you now try to step into class code from the library the following will happen:
Visual Studio tries to locate a ClassLibrary.pdb file in a couple of locations
1.1 If it doesn't find it, you get a "Browse to find source" disabled
page. Remember, you can't debug without a valid PDB file.
1.2 If it does find a PDB file, it looks inside the PDB file and sees that you are trying to debug Class1.cs which was originally built from
G:\ClassLibrary1\Class1.cs
and looks on your computer for that file.
1.2.1 If it finds it, it steps into the code automatically.
1.2.2 If it doesn't find it, you get the following dialog:
If you press Cancel, you will be presented with the: "No source available" and you will have "Browse to find source" enabled in this case.
Why? Because you have a valid PDB file, but Visual Studio can't possibly know where you have the source code for ClassLibrary1 on your computer or if you even have it on your computer. That's why you got the dialog -> so that you can point Visual Studio to the exact location of the source code file.
Final notes
So what will you do when you get a browse to find source disabled?
In Visual Studio, you open menu Debug -> Windows -> Call stack.
You right click on the top call stak instruction and you choose "Symbol Load Information". It will show you the locations where Visual Studio has tried to find a valid PDB file.
1.a If you only see "Cannot find or open PDB file" messages put a valid PDB file at any of these locations. (You might have to scroll right to see the messages) Stop and start debugging again.
1.b If you see a "PDB does not match the image" message it means the following. Visual Studio has found a PDB file, but it is for another build. If I build ClassLibrary1.dll and give it to you, and then I build it again without changing a single line of code and then give you the PDB, and you try
to debug classLibrary1.dll you will get this message. The assembly and its PDB file must be exactly from the same build, otherwise you will get this message. (This check is done using some unique number put inside the assembly and PDB file every time you do a built)
1.c You see a "symbols loaded" message but still get a "Browse to find" disabled. It means that the PDB file you have is not good for step-in debugging. Some PDB files you try to use don't have all the information in them necessary for step-in debugging. I think you can control this from somewhere in the advanced build settings, but I haven't tried it though, because I want to have usable PDB files generated everytime I do a build. This situation often happens if you try to debug the source code of the .NET framework itself and Microsoft hasn't put usable PDB files for the source code, but instead Microsoft has put some PDB files which can't be used for step-in debug. This happens more often than you think, because often Microsoft makes updates (patches) to the .NET Framework source code. These updates silently install onto your computer via Windows Update, and you are surprised to see that yesterday you could debug .NET Framework source code and today you can't. It usually takes some time until they put a valid PDB file for the latest code. In this case you can use .NET Reflector Pro step-debug ability or a virtual machine which has a .NET framework version with usable PDB files and disable Windows Update on that machine.
Check out the article Step Into .NET Framework 4.0 Source Code.
If you encounter the “No Source Available” screen, try to press “Browse to Find Source” and find the file you need in the source directory. You should probably need to use files search to find it.
This is done only once, since from now on Visual Studio remembers this location and searches there for missing source files.
I hope it's about what you are looking for.
Similar issue in Visual Studio 2019 can be resolved by checking "Enable Just My Code".
Debug > Options... > Debugging > General > Enable Just My Code
More detail explanation can be found here How to fix debugger is looking for executioncontext.cs