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.
Related
I am debugging a program, and see compilation error
cs8300 "merge conflict marker encountered"
What does this mean? Is there any Microsoft Documentation for this? We are working with Git Source control, and trying to compile Net Core program.
I believe this is if you have being doing a merge or a pull from either another branch or from the remote source control, there was a conflict i.e. someone has changed the same line as you have. This begins a "conflict resolution" in Visual Studio asking you to choose which lines you want.
However I suspect you have attempted to build the project without completing the conflict resolution.
The conflict will add little bits of text to your files indicating to Git where the conflicts are, if you open the files in a plain text editor like notepad you will see them.
For further background information here is the documentation regarding resolving merge conflicts in Visual Studio: https://learn.microsoft.com/en-us/azure/devops/repos/git/merging?view=azure-devops&tabs=visual-studio
Here is a screen shot taken from that documentation which you will likely see in Visual Studio.
My apologies for this very basic question that has assuredly been asked and answered before, also for my very dated terminology. I searched for an answer, but failed to find anything helpful. I am using the latest update of VS 2017 Community, and I'm trying to manually add what I used to call a "function library" to a project, which sits under a "solution".
The project is simply a C++ or C# console application. What I have is a .h (header) file, a .lib (static library) file, and a .dll (dynamic library) file. I intend to make "function calls" to this library. I'm aware that I need to have my dll in the debug folder where the executable resides, but I'm not sure how to "add dependencies" in VS 2017. I know how to manage and install NuGet packages, but these files aren't a handy-dandy NuGet package.
I hope to get advice on doing this the right (VS 2017) way.
What I do in a situation like this is to create a folder, I use C:\Etc\SDKs\<name_of_library> and then within that folder create an include subfolder, and a lib subfolder. Note that the top level folder choice is completely arbitrary, place it where it makes the most sense to you.
In the C/C++ section of project properties on the General tab, or the corresponding section for C# projects, there's an entry for Additional include directories. Add the path to your newly created include folder there. That'll let you include the header file and have it work right.
In the Linker section of project properties, also on its General tab, there's a corresponding entry for Additional library directories. Add the path to your lib folder there. On the next tab down: Input there's an entry for Additional Dependencies. Add the actual name of the library file there.
Those steps should allow your project to be built using the .h, .lib and .dll files you have.
-- Edit to address comments --
The .lib file does go in the ...\lib folder, and the .h file in the ...\include, that's correct. However, you had the location of the .dll correct in your original question. That needs to be somewhere on the search path that the executable will find, so the easiest place is the same folder as the executable.
General tab is a poor choice of words on my part. General section might have been better here. When looking at the project properties, the left most pane is a tree view of the various property sections. With everything closed up, except the very top item open, you'll see
Configuration Properties
General
Debugging
VC Directories
> C/C++
> Linker
...
If you then double click on C/C++ it'll open up, and show the sections specific to the C/C++ compiler:
Configuration Properties
General
Debugging
VC Directories
V C/C++
General <<<<<
Optimization
Preprocessor
...
> Linker
...
If you click on the word `General that I've highlighted, that'll get you to the General section / tab I was talking about.
Likewise, double clicking the word Linker will open up that section, and under that you'll find the Linker General and Input sections.
Let me know if this still isn't clear, and I'll try to clarify.
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?
I am using some NuGet packages in my projects which have their source publicly available in GitHub (example OrmLite).
How can I configure their repositories as debugger sources in Visual Studio (the same way I could configure ReferenceSource for the .NET Framework etc... like here)?
ReSharper is able to decompile the DLLs, but I am more interested in seeing the comments which are obviously not available this way.
Update:
I know about the pdb files, but the initial intension was to see the source code when I hit F12. For the .NET Framework that is acheived by simply adding the ReferenceSource as I explained before
What you are looking for is http://symbolsource.org, which is a platform for hosting open source pdb (debugging) files.
To use it, you'll need to update your Visual Studio instance to pull pdb's from there (http://www.symbolsource.org/Public/Home/VisualStudio):
Go to Tools -> Options -> Debugger -> General.
Uncheck “Enable Just My Code (Managed only)”.
Uncheck “Enable .NET Framework source stepping”. Yes, it is misleading, but if you don't, then Visual Studio will ignore your custom server order (see further on).
Check “Enable source server support”.
Uncheck “Require source files to exactly match the original version”
Go to Tools -> Options -> Debugger -> Symbols.
Select a folder for the local symbol/source cache.
Add symbol servers under “Symbol file (.pdb) locations”. Pay attention to the correct order, because some servers may contain symbols for the same binaries: with or without sources. We recommend the following setup:
http://referencesource.microsoft.com/symbols
http://srv.symbolsource.org/pdb/Public or the authenticated variant (see above)
http://srv.symbolsource.org/pdb/MyGet or the authenticated variant (see above)
(other symbol servers with sources)
http://msdl.microsoft.com/download/symbols
(other symbol servers without sources)
Note: Not every nuget package also uploads symbols to SymbolSource (as it requires an additional publishing step). So you might need to contact the developer of the project and ask them to upload it, or if the project is open source, you could do it yourself.
Use the original source-code from GitHub by download the relevant VS code projects and add them to your solution for references instead of using the binaries.
Are there any good programs out there to compare to compile .NET assemblies?
For example I have HelloWorld.dll (1.0.0.0) and HelloWorld.dll (2.0.0.0), and I want to compare differences how can I do this?
I know I can use .NET Reflector and use the Assembly Diff plugin. Are there any other good tools out there to do this?
Ways to Compare .NET Assemblies suggests
Commercial:
NDepend
Free:
JustAssembly (only shows differences in API)
BitDiffer (same)
Reflector Diff Add-in (which you've already discovered, but not available anymore)
Existing compare tools like Beyond Compare (commercial) can do this by special configuration. Here's how to do this for Beyond Compare:
Go to Tools → Options
Click New.., select "Text format", click OK
Give it a name (say, EXE, or DLL), and specify the mask as *.exe or *.dll
Click on tab Conversion and select "External program (Unicode filenames)"
Under "Loading", specify the path to ildasm and add %s /OUT:%t /NOBAR (i.e.: C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.8 Tools\ildasm.exe %s /OUT:%t /NOBAR)
Make sure to check disable editing.
Click Save, then Close
Restart BC and open two exe files to compare, it should decompile into ilasm automatically now.
You can also add syntax highlighting to this new format. I plan to send the syntax file to them so that it'll become available to share.
Two ways.
You could ILDASM and diff with classic tools.
Or you could use NDepends, which will cost for that feature.
[Piece to C# bloaters..]
I just had to compare two revisions of the same DLL, which had the same version (I needed to implement a small hotfix, and deploy the DLL in production, but I wanted to make sure that no other changes leaked into code). Ideally, I would want the Assemby Diff add-in to show me the difference, but it does not work (it thinks that I'm comparing a DLL to itself). So this is what I did:
Created two folders to hold disassembled source files.
Used the Reflector's Export option (from context menu) to generate source files from each DLL in the folders created in previous step.
Used the free DiffMerge tool to compare two directories; the tools showed me the modified files and the difference.
It's a bit kludgy, but seems to work. I wish the Assembly Diff add-in worked, though.
UPDATE: The latest version of the Assembly Diff add-in is supposed to fix the issue of comparing two versions of the same assembly. Give it a try.
The tool NDepend offers many features to compare compiled .NET assemblies.
First from the NDepend Start Page click: Compare 2 versions of a code base. This will let you provide older and newer versions of your assemblies.
Then after NDepend has analyzed both older and newer assemblies, you can use the panel Search by Change. It is dedicated to browse assemblies code diff. Notice that:
If source code is available, just right click an element and click Diff Source. In the NDepend options you can plug to NDepend any code diff tool (Visual Studio, Beyond Compare...)
If you don't have the source code and just only the raw assemblies, there is the option Compare older and newer version disassembled with ILSpy. ILSpy v7.0 and upper versions are supported. This menu works on assembly, namespace, type and method level and you can choose to decompile to C# or IL.
Notice also in the screenshot that a CQLinq code query is generated to browse the diff.
from m in Application.Methods
where m.CodeWasChanged()
select new { m, m.NbLinesOfCode }
Many others default diff queries and rules are proposed by default, that will let you browse .NET code diff in a smart way.
Types that used to be 100% covered but not anymore
API Breaking Changes: Methods
Avoid making complex methods even more complex
Avoid decreasing code coverage by tests of types
From now, all types added or refactored should respect basic quality principles
Avoid transforming an immutable type into a mutable one
Heuristic to find types moved from one namespace or assembly to another
Disclaimer: I am one of the developer of the tool.
One more option is LibCheck from Microsoft.
Pretty old console tool for just getting public API diff. I could not run without debugging and retargeting to a more recent .net version. However, it gave me very clear output and I am going to use it later.
Here is an article with screenshots.
Here's a thinking outside the box approach whcih works fine.
Dump your old and new assemblies with dnSpy, dotPeek or JustDecompile into projects.
Create a new Git repo and commit the old assembly code first.
In your local repo folder delete all the files/folders except for ".git" and paste the new assembly files.
Either commit the new changes and view changes on say Github or use a Git viewer like Fork. Easy code comparison for free.
Java has a nice one: Semantic Diff Utilities