I am working with Newtonsoft.Json (a.k.a. Json.net) now and multiple C# solutions need to reference it. Seems the most convenient and widely-used way is to install Newtonsoft.Json with NuGet package manager. But I find that the package is installed in the solution root directory (anyway, the installation is based on a given solution) and its size cannot just be neglected (a bit over 10M), so I wonder if there is an elegant way to share this package among different C# solutions.
I searched Google and found few satisfying results (maybe it's because I didn't express my requirement properly); the only sound answer is to create a .nuget folder both in the directory and in the solution and fill it with a NuGet.config file, as follows:
Create a .nuget folder in the root of the solution (by entering ".nuget.", actually)
Inside that folder, create a file NuGet.config.
In Visual Studio 2015, right click on the solution and add a new solution directory called “.nuget”
Right click on that folder and select to add an existing file and select the NuGet.config file created in (2).
Add content like this inside the NuGet.config file:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<solution>
<add key="disableSourceControlIntegration" value="true" />
</solution>
<config>
<add key="repositoryPath" value="E:\JsonExamples\C#Examples\UseJsonInCSharp\packages" />
</config>
</configuration>
Restart Visual Studio 2015.
But that didn't work because the using directive
using Newtonsoft.Json;
is still not recognized! Maybe there are something else that must be done, which isn't known to me but is common sense to veterans? Or perhaps this is because the version of the Newtonsoft.Json is too new for this to work? Can somebody help me? thanks a lot!
One more word: I'm currently using VS 2017, but I only found answers related to VS 2015, so I wonder the previous approach, if somehow works on VS 2015, will ever work for VS 2017.
Lets first clarify some things about NuGet and references in projects:
The job of references in project is to tell what external code this projects must look into - you can NOT go around this, you have to make a reference to Newtonsoft.Json in every project you want to use it.
The job of NuGet is to download/restore the nuget in some folder - the default "dumb" setting for old pre NuGet 4 versions is to make a seperate packages folder in every solution. Lets Focus on how to make this smarter.
Option 1 (Recommended) - Migrate everything to PackageReference
It is available since NuGet 4 in VS 2017+ (i recommend at least VS 2017 15.7+ which got wizard for automatic migration from older nuget versions). This is the most clean way of referencing NuGets since PackageReference in project does not hardcode NuGet download location. Instead it leaves this decision to local NuGet settings. By Default it is set to "%USERPROFILE%\.nuget\packages". No nuget package is duplicated, it acts as global cache for this computer. To force all new project to use PackageReference by default you must modify NuGet.config, here is how: Defaulting Package Management to PackageReference
Option 2 - specify common NuGet location for all project in the same repository
NuGet config settings are loaded per Solution. Having a common config file for NuGet is recommended even if you use PackageReference since download location is just one of many settings you might want to centrally manage for all Solutions (the other popular one is a setting which external NuGet repositories you want to use). NuGet download location setting is ignored by new PackageReference so it is safe to use it in mix scenario. VERY IMPORTANT, projects using this old NuGet use hardcoded reference to NuGet folder, so everytime you change this NuGet location setting you have to manually fix all NuGet references in your every project (by editing .csproj file manually or be deleting and re-adding NuGets), so chose wisely and do not change.
Details on how to correctly set global NuGet.config:
So first let me explain how shared NuGet.config settings work. NuGet scans all NuGet.config files from solution location up the hierarchy to root drive (it also check all .nuget folders). If multiple config files are detected it takes the one closest to solution. So for example you have "C:\Code\Repository1\Project1\Solution1.sln". If you want to have common NuGet settings for every solution in Repository1 put config file to a location like this "C:\Code\Repository1\NuGet.config". Also make sure this is the only config file inside whole Repository1 folder. Next step is to decide where to download all packages, for example "C:\Code\Repository1\NuGetPackages". To make everything work dynamically on all computers put relative path inside NuGet.config like this:
add key="repositoryPath" value="NuGetPackages"
I upgrade to Visual Studio 2017 15.8.1 and am having issues creating an Azure function project. The project I am trying to create is through the template wizard, just a new V1 empty function project.
I receive the following error, which seems to be .net core related.
NETSDK1004 Assets file '\obj\project.assets.json' not
found. Run a NuGet package restore to generate this
file. FunctionApp1 C:\Program Files\dotnet\sdk\2.1.400\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets 198
Run a NuGet package restore to generate this file.
But my project file states:
<PropertyGroup>
<TargetFramework>net461</TargetFramework>
<AzureFunctionsVersion>v1</AzureFunctionsVersion>
</PropertyGroup>
Just to be clear, I do want a 4.6.1 project, not a core one.
I have looked at other answers to this issue but none resolve it. Package reinstall, dotnet restore etc. I get more errors if I select a different template (e.g. HTTP Trigger)
Any ideas?
I thought I had a solution to reboot, then open %temp% and delete all the temporary files in that folder. Then reboot again for good measure and it worked from a blank / empty project, but as soon as I try include this in another solution or move the project it fails.
Seems I have it working now and I'll leave this here in case anyone else has the same.
I did try many many things to resolve, but I believe the crux of my fix was to reboot, then open %temp% and delete all the temporary files in that folder. Then I rebooted again for good measure and it worked from a blank / empty project.
Well that wasted a chunk of my day. I had created a repo in git which had a space in the name. When cloned I ended up with an encoded view of the repo - i.e. a %20 for the space, which appeared in the folder path. Since this was just some demo work I had left it as is instead of tidying it up to a clean namespace.
Turns out if you have a %20 or some other encoded value in your path you will get the NETSDK1004 error. I hope this answer saves someone else some time!
We have a solution that contains a project that uses TestFramework from NuGet.
We've another solution that references that project.
The project/solution file system structure looks like this:
- Tests
- Tests
- Properties
- AssemblyInfo.cs
- packages.config
- Tests.csproj
- Tests.sln
- RefToTests
- RefToTests.sln
RefToTests.sln contains a reference to Tests.csproj.
If I open the Tests.sln and try to build it I get an error that tells me that the referenced NuGet dependencies could not be found. No problem - open the NuGet management for solution, click restore and build it again. Works fine.
The same clean folder but now open RefToTests.sln. Same error. Same workflow. That restores the packages to RefToTest\packages. The project is looking for them at ..\packages what means Tests\packages. That will not build.
We tried to fix that by manually change the folder to the packages in the project file from ..\packages to $(SolutionDir)packages. That worked great. The missing packages are downloaded automatically (wow that doesn't work without that change).
But now let's update the package. The package manager is not able to find that references in the project file, leaves the old entries untouched and added completely new references. The project won't build in any solution. That seams to be a bug in NuGet project management. In my opinion the package resolution should crash if it finds $(SolutionDir) or the package management should be able to handle that.
But what is the solution? Changing the directory to $(SolutionDir) and check every project file after every update? Leave the specified folder as it is and never do a cleanup on the repository?
I hired a contractor to do some coding for me. He setup nuget.config in the solution folder with the following repository path:
<configuration>
<solution>
<add key="disableSourceControlIntegration"
value="true" />
</solution>
<config>
<add key="repositoryPath"
value="../lib" />
</config>
</configuration>
And I'm not too happy about his decision: this will place the nuget package folder outside the solution folder. I can easily change the repository path, simply by setting:
value="../<mySolutionFolder>/lib" />
However when I do this a curious thing happens: every single reference that I use in my solution is now broken. And nothing that I change in the .csproj files or other *.config files will allow my projects to find their references.
The only workaround is to re-create each project in my solution by starting from scratch, and add->existing items, etc. and reference->manage nuget packages, and install every reference again.
I have many projects in my solution and performing this for every one is understandably time consuming.
I would like to know if there is an easy way?
It seems like there should be a way for Nuget and VS to play nicely so that I can easily move the repository folder to a different path location.
One way to fix the reference paths is to use the Package Manager Console.
From the Package Manager Console you can run the following command to reinstall the NuGet packages which will fix the hint paths for the references.
Update-Package -reinstall
This will reinstall all NuGet packages in the solution. I am assuming you have the code under source control so you can see what changes are made to the projects if you need to revert them after this reinstall.
There is more documentation on reinstalling NuGet packages on the NuGet documentation site.
Another way to fix this is to do a find and replace in the .csproj files to fix the hint path.
I encountered this problem when I moved the actual folders around in my solution. I usually do a find/replace with VS Code looking for >..\packages\ and replace it with >..\..\packages\. This time I did the following:
Perform Update-Package -Reinstall
this worked for everything with hint paths
does not work when your project uses NuGet packages to build your project because there are custom MSBuild statements that need to be manually fixed, see next step.
Edit the .csproj files manually that do not build, in my example:
<Import Project="..\..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.8\build\net45\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props" Condition="Exists('..\..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.8\build\net45\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props')" />
<Import Project="..\..\packages\Microsoft.Net.Compilers.2.4.0\build\Microsoft.Net.Compilers.props" Condition="Exists('..\..\packages\Microsoft.Net.Compilers.2.4.0\build\Microsoft.Net.Compilers.props')" />
Notice that there are 2 condition statements in the <Import> that use relative pathing to ..\..\packages.
Hopefully these steps will help someone else.
Package.config is used for put file somewhere else from the folder, it help best to not upload package unusually when you add something in your project through Nuget.
Try to copy the package to that folder (new path you set) or simply close the project, open it again and click on Restore after going to Manage project reference.
After trying all solutions posted here I could not escape one primary issue: references to non nuget items, such as System and System.Core remained invalid (yellow triangle listed next to them). Removing them and adding them did not make them valid again. Further (as we all know) Visual Studio is terrible and giving reasons for why a reference is considered invalid.
So while Matt's solution does indeed relocate the nuget package folder, the solution in not left in a working state. Further, updating hint paths did not help because those are specific to the nuget packages. I cannot explain why basic references suchas System also become invalid. Perhaps someone reading this a year from now can leave a message with an explanation.
What I ended up doing is rebuilding my entire project without a nuget.config file (I deleted it). This causes nuget to use all defaults. Downloaded packages get stored in \\<solution_folder>\packages\. After the solution was working again, I added back the nuget.config file but with the following removed:
<config>
<add key="repositoryPath"
value="../lib" />
</config>
...and removing that section causes nuget to rely on default behavior which turns out to be exactly what I wanted (installing packages to \packages, etc).
If anyone else is about to undertake this laborious effort, I found this SO solution helpful for moving folders and files from the old solution to the new one.
I managed to do this to my own solution without realising how (and ended up with a packages folder at the *.sln level and another one at The level below that) - but I'm pretty sure now that this all has to do with migrating from using a packages config file, to the new method of using package references. This can occur if you use a newer version of visual studio (which is possibly what your contractor did) or via a button/commend in NuGet, or via a right-click context menu.
One of the things that happens is the creation of a 'global' packages folder (the one at .sln level) which is meant to save your space since it means you can have multiple solutions using the same package without having huge duplicate package folders repeated in every solution.
I found this out when I was merging The text is two csproj files and needed to Google: import project difference to package reference
See https://learn.microsoft.com/en-us/nuget/reference/migrate-packages-config-to-package-reference
I want to use debug symbols, but I am receiving the following error:
a matching symbol file was not found in this folder
What is this problem, and how to solve it?
One of the things I've ran into with was because debug was off on the project referenced where the code lives. In my case, I made a new configuration called "Developer" and by default debug was turned off.
Right click the project in question
Properties
Build
Advanced (right bottom corner)
Set Debug Info to full
Recompile
I had the same problem as #DmainEvent. Apparently the dll that I was using was not the same version as the pdb that I had just compiled, so I got the error message.
If you have this problem, try using the dll and pdb from the same compilation run.
The error I got was "a matching symbol file was not found in this folder" in the Debug => Modules window even after both the DLL and PDB were available and built together, so I was unable to debug into the target DLL referenced by my main project.
Posting this here in case it helps someone browsing with "Mixed Platform" build for target DLL. I did two things to get past this:
In the solution using the target DLL, Uncheck "Just My Code" in Tools => Options => Debugging => General => Enable Just My Code (JMC).
Check "Enable native code debugging" in target DLL solution in relevant Project Properties => Debug.
I tried all the possible solutions, finally it worked when I disabled the option Enable native code debugging under the Debugger engines of Properties > Debug.
I ran into this problem and the answer was simple.
Visual studio has two project level settings that can create .pdb files.
Linker: Configuration Properties -> Linker -> Debugging -> Generate
Program Database File = "xxxx.pdb"
Compiler: Configuration Properties -> C/C++ -> Output Files -> Program Database File Name =
"yyyy.pdb"
You want #1 for debugging. Forget about #2.
Give file #2 a different name than file #1 to solve this error.
I don't know why microsoft specifies #2 as a .pdb file. That is just confusing.
I have fixed my debug symbols, forcing them to match using this tool:
chkmatch tool
edit: the website is down now. the wayback machine helps: https://web.archive.org/web/20210205095232/https://www.debuginfo.com/tools/chkmatch.html
So, my problem was I was trying to debug my project and the debugger couldn't step-in to the in-house nugets sources. I had the source files of the nuget project. Still the visual studio didn't accept the pdb files I was trying to show it to.
Showing exact same error:
a matching symbol file was not found in this folder
So, what I did was I added this to the .proj file of the nugets project:
<DebugType>full</DebugType>
And created the dll and pdb file again using the rebuild option.
In the command line I ran:
.\ChkMatch.exe -m name_of_your.dll name_of_your.pdb
It said this:
Writing to the debug information file...
Result: Success.
Great success!
So, next, I referenced this dll instead to the proj I was trying to debug. I worked when I tried to load the symbol again.
Hope it helps.
Without more details as to what you're doing, it's difficult to go beyond "the debugger is looking for a symbol file which matches the compiled code, and couldn't find one in the folder where the compiled code lives."
Some things to think about:
Are you creating symbols as part of your compilation? (check the project properties)
Are you using a symbol server (if so, does it point to the right place)
Is this compiled code from a third party? In which case, as you apparently have the source, compile it yourself.
Consider clarifying your question if you want a better answer. Especially what do you mean by "I want use of Symbols".
For BizTalk (and other) projects, it could be because there's a version of the assembly you're trying to debug already in the GAC. When you run a unit test or hit F5 to debug, a new version is compiled locally. However, the version in the GAC is being used, and the newly created PDB doesn't match the DLL in the GAC.
One way around this is to deselect a build for everything except your unit test project using the Configuration Manager, as shown below:
Well, the solution depends on your specific problem. I tried everything that could be possibly found on Stackoverflow and other sites. One of the thread that I followed is this. That did not help too.
The problem was at once resolved when I noticed that my executable project did not contain a reference to the library that I wanted to debug. So I just added the reference to that project.
**PS: ** This problem might also arise because the assembly referenced by the executable assembly might not match that in the references. So in that case, you just remove the already existing reference and add the new one.
Hope this helps!
The same happen to me because the .pdb file of the project have not been copied to the debug\Bin folder, so the symbols could not be loaded from the .pdb file.
You must rebuild your project and manually copy the symbols (.pdb file) to the debug\Bin folder of executable project.
I was trying to load symbols for a installed nuget package published on our local dev server. I had to uninstall and add a normal reference built from the code instead. This worked for me. Just remember install the original nuget package again once finished debugging.
If it works for you, try to embed debug symbols in the dll itself, so the symbols are loaded automatically. This worked for me in netcoreapp3.1 and net5.0:
<DebugType>Embedded</DebugType>
<EmbedAllSources>True</EmbedAllSources>
Beware that you may find this in documentation:
<AllowedOutputExtensionsInPackageBuildOutputFolder>$(AllowedOutputExtensionsInPackageBuildOutputFolder);.pdb</AllowedOutputExtensionsInPackageBuildOutputFolder>
but it does not work.
I ran into this with Visual Studio 2022, tried the most of answers here. Fixed by switching back to Visual Studio 2019, seems like a bug in 2022.
My issue was a bit simpler to resolve, but still the issue the question asked. At first, I was not publishing the pdb file with the nuget package another project was using. Once I confirmed that, I removed the nuget package from my project and readded it from our network nuget source. That still didn't let Visual Studio pick identify the PDB location.
Then I noticed that if you select one of your nuget packages, ( Project --> Dependencies --> Packages --> Choose nuget package), there is a Path property. I checked that location and it pointed to %USERPROFILE%.nuget\packages. The pdb was not at this location and the Date Modified was older than the latest package I published. Once I deleted the folder for the given package version, removed it from my project, and re-added it, the latest .dll and .pdb file were added to this location.
After that, I was able to step into the code of my nuget package and had no further issues.
To get the nuget project to produce the pdb file in the first place, I added <IncludeSymbols>true</IncludeSymbols> inside of a PropertyGroup within the csproj file as other answers had directed.
Once I rebuilt that nuget project, it generated 2 *.nupkg files:
Namespace.x.x.x.x.nupkg
Namespace.x.x.x.x.symbols.nupkg
I found this was because the Properties => Debug => Start Action was set to Start external program instead of the Project. So the newly generated pdb file didn't match, because the actual exe was the wrong one.
I have had this problem recently as well.
Was able to fix it by selecting MyProject->Properties->Linker->Debugging->Generate Debug Info->"Optimize for debugging (/DEBUG)".