Usually when I want to debug a nuget package I download the source code and add the .csproj file to my solution and add a project reference instead of using the nuget package. This lets me step through the code and see what is going on with my live project.
I have a nuget package I want to debug but it is very large. I downloaded the source code and the solution has around 20 projects in it. I tried just adding a few of them but ended up with lots of dependency issues.
Is there a way I can tell visual studio that the source code for the nuget package exists on my HD so I can step through it without having to add 20 projects to my current solution? Or perhaps some way to add a reference to the entire solution?
My goal here is to be able to set breakpoints so when the third party compiled code executes I can step through it and see what is going on. What is best way to do this?
Assuming the application is .NET 4.7.2. You could try dnSpy which allows you to debug & edit a built executable/dll.
GitHub Page: https://github.com/0xd4d/dnSpy
Latest Release:https://github.com/0xd4d/dnSpy/releases/download/v5.0.0/dnSpy.zip
Once downloaded
Start up dnSpy.exe for 64-bit or dnSpy-x86.exe for 32-bit applications.
Use File->Open to locate your exe's and dll files.
Apply your breakpoints within dnSpy.
Hit start as you would in Visual Studio
Emcrank has very interesting solution for not having the source code but it wasn't right for me.
The answer for me was actually very simple. When going to add existing project you can change dropdown to add a .sln file. I created a folder then added the solution to it and it pulls everything in with single transaction and now I can easily debug all the code.
Related
This error occurs immediately after building the project, I've tried changing the dot net framework from 4.6 to a lesser version it still does the same thing.
Reinstalling visual studio 2015 doesn't still correct this issue.
Did you check your build path under project > properties> build > output ?
Ok, you don't provide a lot of details so I am going to make some assumptions as I have seen this issue before and it can be a bit tricky.
It sounds to me like you have other issues.
You probably have another project being referenced by your main project. This second project is not building. That's what you need to focus on. Try and build only that project first, when that succeeds you can build your main project and this issue won't happen.
The way things work is like this.
You try to build your main project.
The compiler goes to the referenced projects and tries to build those first, if that succeeds then the dlls generated are copied over to the bin folder of the main project.
If my assumptions are incorrect then please edit your question and add all the details you can so we can actually help you.
I have a WPF app that works with local SQLite and Entity Framework Core. I want to distribute my app using ClickOnce.
Everything works fine when I run it using Visual Studio 2017. But app had a crash on a start when I used ClickOnce. The crash was so early so I couldn't even log the exception. After some time I found that in publish folder some dlls were missed. For example System.Runtime. All references are NuGet packages. Then I found that despite of I have a reference to the dlls in my project ClickOnce application files list doesn't contains it.
The only solution I have found for now is to add missed dlls as files in root of my project and set build action to Content. In ClickOnce application file dialog I set publish status to Include.
It works now but it looks like not the best way to do it. The question is why they are missed in the first place. More likely I missed something or I am not understand the root of the problem.
UPD:
You can find an example code here.
It works from Visual Studio but crashes on a start when you try to install it as ClickOnce application.
UPD: The problem was fixed in Visual Studio Professional version 15.6.1
There are two ways solving solve this.
At first, you have to go Properties → Publish → Application Files, and at this place, make your DLL files include in your project
But if it does not work, go to References and make the DLL file CopyLocal = False. You add a DLL file like Existing Item in your project and make them Copy Always.
It will work correctly.
But for your sample I watch this and I solved it. Look at this image:
You have four DLL files. You need do this for them:
System.Diagnostics.Tracing.dll
System.Reflection.dll
System.Runtime.dll
System.Runtime.Extensions.dll
At first go to your reference and make them Copy Local False:
Then go to the path of each DLL file and add them like Existing Item, and then make all of them Copy To Output Directory CopyAlways
Then Publish it and run it like in this picture. I run it from publish file and it works.
Even if you set the dll to copy local, the dll will not get copied over unless you actually use the dll in your code. You might try adding System.Runtime in your code somewhere like this maybe?
var dummytest = System.Runtime.GCSettings.IsServerGC;
Based on Issue 9 on https://blogs.msdn.microsoft.com/bclteam/p/asynctargetingpackkb/ I was able to do the following:
Symptom
ClickOnce applications targeting .NET Framework 4.0 that reference the Microsoft.Bcl or Microsoft.Bcl.Async packages may experience a TypeLoadException or other errors after being installed.
Resolution
This occurs because ClickOnce fails to deploy certain required assemblies. As a workaround, do the following:
Right-click on the project and choose Add Existing Item
Browse to the folder where the System.Runtime.dll lives
In the File name text box paste in the path of the file
Click the down-arrow next to the Add button and choose Add as Link
In Solution Explorer, holding CTRL select System.Runtime.dll
Right-click the selection, choose Properties and change Copy to Output Directory to Copy always
Republish
I am having an issue with my ASP.NET Web-Api solution where my build agent cannot clean its working directories because the library Microsoft.Bcl.Build.Tasks.dll is still in use by some process so it cannot be deleted. The only things I do in my build agent are to build the solution using standard MSBuild.exe, and then I run a few unit tests using MSTest.exe.
I notice that Microsoft.Bcl.Build version 1.0.14 (the version im using) is listed as a dependency by the Microsoft.Net.Http and also by Microsoft.Bcl libraries.
My workflow in the agent is like this:
clone a git repo to the agent
build the solution using msbuild
test the solution using mstest
some time later, maybe 10 minutes, I try and clean up the current iteration
cleaning of the files fails due to the described error
My question is this:
Does anyone know why is this library in use by some process even after many minutes? Is there a common process on windows that would be using this library in the background? I would use the process manager to find why this file was in use, but these build machines are considered to be production boxes and are nearly impossible to get admin access to.
Thanks in advance for the help!
First delete any usages from processes via a program like LockHunter, then restart VS. It worked for me
If your solution contains custom msbuild targets and those same msbuild targets are in use by another csproj in the same solution, you'll run into a conflict at compile time. Effectively, you'd be trying to compile a part of the compilation process mid-compile and you'll run into these types of file lock errors. The workaround is to split your custom msbuild target project(s) out into a separate solution and build them as-needed. I think you'd need to unload & reload the project that depends on the msbuild targets anytime you rebuild them. Once or twice, I needed to restart VS.
If you didn't add any custom msbuild tasks, you can figure out what is causing the problem by looking at the installed NuGet packages. Right click on your solution and click 'Manage NuGet Packages'. Try to remove Microsoft.Bcl.Build from the Installed packages list. It should fail because something depends on it. Make note of what package depends on it. If the first suggestion didn't help, post back a comment with which packages depend on it and I'll see if I can dig up/remember where else I've seen this before.
This question has more details & links about what Microsoft.Bcl.Build is and what it's used for if you're interested: What does the Microsoft.Bcl.Build NuGet package do?
I just came across the same problem on my gitlab build server which does a git fetch before every build set.
After adding Microsoft.Bcy.Async from nuget to my project, the step after the build failed with warning: failed to remove packages/Microsoft.Bcl.Build.1.0.14/tools/Microsoft.Bcl.Build.Tasks.dll
With LockHunter I identified several msbuild.exe tasks.
With that info I found the solution here on so: https://stackoverflow.com/a/12193759/98491
Long story short: the msbuild processes are kept open to improve performance while building. This can be disabled by setting the environmentvariable MSBUILDDISABLENODEREUSE=1 or passing /nodeReuse:false to your msbuild itself.
That fixed it for me.
I come from a long Java background and very new to C#. I was trying to run one of the starter kit applications from Windows phone and I am getting this error.
A first chance exception of type 'Newtonsoft.Json.JsonReaderException' occurred in Newtonsoft.Json.WindowsPhone.dll
I am finding it hard to debug this because I am directly referring to the dll file under References pointing to Newtonsoft.Json.WindowsPhone. In Java, I would have searched for the library and downloaded the source to step into the exact location during debugging.
If that is possible, how would I do it in C# (as in how would i refer the library source for my project to pick up at run-time)? I am using the Visual studio 2010 Express Edition as the IDE.
Download the third party library you are dealing with
Add this library's project into your solution
In your project, remove the reference to the 3rd party library
Add a project dependency into your project, make it depend on the 3rd party library project you have just added to your solution
Compile and run, happy debugging
My best guess is you should download last release of Json.NET, remove the compiled library from your project's references and add reference to the source code project. (Add Reference... > Projects > Browse...)
Once you have stopped your program in the debugger, you can use the modules window to load the symbols for Json.NET. Obviously, you need to have the symbols on your machine so you can browse to them.
Failing that, you can switch to a project reference and include Json.NET in your solution as Dan suggested.
The easiest way is to download their latest build then inside visual studio right click your solution and under add menu select existing project point to project file of the library and click open button. after that u will be able to set brakepoint wherever u want.
I have a Visual Studio solution (C#) which represents the core of our application. We build this and it comprises about 10 or so DLLs with corresponding PDBs.
I have several other VS solutions each of which is used for a customer of ours. These VS solutions use the core DLLs and add their own bits as required. The "core" has the main .exe so we do the following in customer specific solution
Post build step in the a project to copy the EXE/DLLs/PDBs into the $(TargetDir)
Set project debug settings to "Start External Program" pointing to the .exe
This all works, tho seems a bit clumsy.
My questions are:
When running via the customer specific solution, how can I
Have the code for the core project open automatically when I step into it
Be able to open a core file and set a breakpoint
I'm used to Java where you reference the compiled and source jars/directories from the Java IDE and that's pretty much it. How can do the same in visual studio (DLLs and PDBs)?
(I would prefer to avoid the GAC if possible because we sometimes have several local builds of the core around at the same time working on different projects)
Mike, if you open an "higher in stack" solution which references a core solution, you can open the source file of the core solution and put a breakpoint in it, then when you debug the current solution Visual Studio is smart enough to step into and trigger your breakpoint if the .pdb files are available in the bin folder.
TO automatically have the debugging control traverse into the core source files, make sure to refer the core dlls from locally build core solution and make sure that have access to it.
Another way is after having the core dlls refered, just open the CS file in which you want to put a break point and debug.