I have a library of nuget packages we use throughout our solutions, hosted in Azure Artifacts. These nuget packages are built with debug enabled so symbols are created and included in nuget packages.
Our projects in Visual Studio (mainly Net Core 3.1) reference these nuget packages in the normal way using Nuget Package Manager.
Each solution has SourceLink enabled so if I have any debugging requirements which require stepping into code within the referenced nuget package, I can set a breakpoint and do so quite nicely as Visual Studio downloads the sourcecode directly from Azure Artifacts.
That all works perfectly.
The issue is a productivity one. If code within the nuget package needs to be changed, I have to open the solution for the nuget package, change it, push it and wait for Azure to build. When built, I go to Nuget Package Manager, update the package, restart the app and 'hopefully' have resolved the issue. For something tricky, I can loop this process a few times which is a productivity killer.
Is there any way to debug directly in the solution for the nuget package from the solution referencing it? Or does anybody have a better process they use which is more productive?
You may try to use floating version that can resolve to the latest version in nuget. In this way, when there is updated package, your solution will load the latest version of the package during build.
<ItemGroup>
<PackageReference Include="NuGet.Packaging" Version="*" />
</ItemGroup>
Is there any way to debug directly in the solution for the nuget package from the solution referencing it?
Using project reference instead of the nuget package when you need to frequently modify and debug the source code in the nuget package.
When you consider production efficiency, please consider using project reference, when you consider portability, please try to use nuget. You could check my previous thread for detailed explanation.
For your situation, you could add the project for the nuget package to your referencing solution by the option Existing project：
Then select the project file .csproj for the nuget package.
After adding that project into your solution, you could add that project as project reference for your referencing project. Now, you could directly modify and debug the project for the nuget package.
When you finish this stage of work, you can return to the solution where the project for the nuget package is located, pack the new version of the nuget package and publish it.
Related
I have a multi-project solution with Prism Nuget packages installed in several projects. I then attempted to add a Prism Mef extensions package to one of the projects using the Nuget Package Manager UI (I have already added it to one of the other projects).
The first time I attempted to add the package, it failed to install one of the dependencies, no specific error reason, just "failed". So, I installed it a second time, all seemed to be fine, no errors reported, but a few of the references did not resolve.
So, I uninstalled the package and all dependencies and installed it again. Again all appeared fine, but more references do not resolve.
I have tried uninstalling and installing the package more times but get the same result every time now.
I have had this problem many times and I know its not specific to the Prism package as I've had it with loads of different packages.
I think its just a major bug with Nuget, but I'm hoping somebody will know an easy way to fix it. I think I usually have better success with the Nuget console, but I find it more effort to use.
I've done some searching online and not really found a good explanation of the cause of the problem or a way to resolve it.
Somebody at work completely refuses to have anything to do with Nuget as he has so many of these issues, but I am determined to make it work!
Within the Package Manager Console run the following command:
Update-Package -reinstall
This will reinstall each nuget package within that project which should resolve any missing references.
If you know you're missing a specific reference:
Update-Package -reinstall <Package-Name>
I just closed Visual Studio and reopened it and references are resolved...!
You need to follow this procedure.
1. Update-Package -reinstall
2. Restart visual studio.
You may want to check the .NET version of the package vs. your project.
I had an instance where my project was .NET 4.6.1, and the package I was attempting to install was using version 4.6.2. After updating my project to the same .NET version, the reference showed up.
I recently encountered this error on visual studio 2012, solution for me was to delete .nupkg file from nuget cache. Nuget cache location can be found from nuget settings > general > browse.
Note: I did not clear cache, I just deleted a specific file from cache directory and reinstalled the nuget package.
Delete all the <assemblyBinding> references from your .config file, then run this command from the Nuget Package Manager:
Get-Project -All | Add-BindingRedirect
This is how I fixed it.
I was working on a legacy .NET framework project (using <Reference Include... rather than PackageReference). The .dlls were referenced with a relative path that wasn't being resolved.
Fixed by changing to absolute paths, building, then changing back to the original relative paths.
For example:
<Reference Include="My.Package">
<HintPath>..\..\packages\My.Package.dll</HintPath>
</Reference>
Changed to:
<Reference Include="My.Package">
<HintPath>C:\Users\will\Documents\MySolution\packages\My.Package.dll</HintPath>
</Reference>
Then built and changed back to the relative path and the build still worked.
In our case, on one machine VS was holding onto an old version of a dependency, so references to newly added methods in the dependency were not resolving (even when package manager was reporting the latest version installed). The solution was to restart visual after uninstalling the dependency, then install again.
My c# app target framework is 4.6.2
I downloaded from NuGet some packages, my question:
when I open my app in file explorer, under packages\somepackage\lib I have this:
do I really need net 40 and net45 folders?
can I delete that? how do I know what is unnecessary?
Reason why NuGet keep the folders
Nuget uses two different methods to manage packages of every project:
packages.config
PackageReference
packages.config is only used for old project files which cannot import and reference NuGet packages automatically. NuGet will change the *.csproj file to add the references. Because it changes the code which is under version control and cannot use an absolute path, so it should put the NuGet package cache folders in every solution. In this case, NuGet might have the ability to remove the useless folders. But this is the behavior of legacy NuGet version (version 2.x). NuGet doesn't want to fix a legacy behavior.
PackageReference is the new behavior of NuGet references. NuGet put all the NuGet cache in a common folder so that it will not take too much disk space by the same NuGet packages. In this case, NuGet doesn't know every lib version on your whole computer projects, so it can't remove the useless version folders.
Conclusion： NuGet doesn't know whether it is safe to remove them in PacakgeReference and doesn't want to remove them in packages.config.
Upgrade packages.config to PackageReference
UPDATE:
From VisualStudio 2017 version 15.7 there is an integrated feature that allows you to do this upgrade without using third party tools Migrate from packages.config to PackageReference
In Solution Explorer, right-click on the References node or the packages.config file and select Migrate packages.config to PackageReference...
You can try a Visual Studio extension NuGet PackageReference Upgrader to upgrade your packages.config to PackageReference so that it will not store libs in every solution folders to eat up your disk space.
P.s.
NuGet take me nearly 10GB on my C:\ .
I have a project that consumes a NuGet package from a private NuGet feed. I also have a source code of that package in a separate project/solution. When I work on the project I want to be able to, temporarily add the mentioned source code of the package to the solution, so i can work on changes in both the project and nuget package simultaneously.
In Visual Studio 2015, with dotnet core and project.json/global.json I could add the NuGet package to the project and then modify the global.json to include the source from the disk.
global.json:
{
"projects" : [ "src", "../<path_to_external_source>/src" ]
}
That would, temporarily, change the reference to the project on disk. Before pushing to the build server, I'd just remove one line from global.json and remove projects from solution.
In Visual Studio 2017 and csproj based dotnet core I cant't seem to get that functionality. I have to remove the nuget package, add source code manually through "add/existing project" to solution, then manually add reference instead removed NuGet references. Then reverse all that before pushing to build server.
It's especially problematic when solution has several projects consuming the NuGet package, and I need to go thorugh that process with every one of them.
Is there a way to reproduce the functionality of global.json in VS17?
I have some 3rd party DLL's i need migrating into a TFS Nuget Feed, and I haven't been able to find many articles on the internet about installing specific versions of a given Nuget Package at runtime, could anybody link me to some relevant material and/or provide some pointers to this effect?
Ideally this would be done as an MSBuild Target I think?
Thanks in Advance :)
To promote a cleaner development environment and to reduce repository
size, NuGet Package Restore installs all referenced packages before a
project is built. This widely-used feature ensures that all
dependencies are available in a project without requiring those
packages to be stored in source control (see Packages and Source
Control on how to configure your repository to exclude package
binaries).
This should help NuGet Package Restore
One of the topics
MSBuild-integrated restore in Visual Studio, for NuGet 2.6 and
earlier.
When I try to compile my program I get the following error:
This project references NuGet package(s) that are missing on this computer. Enable NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=317567.
Now when I right click on the solution and press
All packages are already installed and there is nothing to restore.
I tried manually reinstalling every package which didn't solve the problem, I tried reinstalling NuGet but that didn't help either and I even tried reinstalling visual studio.
I also tried moving the package folder from the tfs folder to overwrite my package folder but that didn't solve anything. I also tried redownloading them with this package missing, that didn' t solve the problem either.
Anybody know how to restore the nuget packages?
Use Package Manager Console in Visual Studio to run this command.
1.This will restore all packages from solution
nuget restore YourSolution.sln
2.If you want to reinstall the packages to the same versions as were previously installed
Update-Package -reinstall
Honestly, whoever developed the NuGet command for VS needs to go back to the drawing board. They totaly missed the fact that sometimes these DLL(s) and/or files get corrupt or deleted. a "NuGet Get-Packages -Force" option would really save their bacon. The only GAP I see is that VS and the Package console does not allow you to invoke a forced download from NuGet. Even clearing the cache via VS is useless.
I ran into this issue when I tried to build my project on a computer where the packages-folder did not already exist in the solution root.
When the project file was initially created, it seems VS2019 added the following into the project file:
<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
<PropertyGroup>
<ErrorText>This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.</ErrorText>
</PropertyGroup>
<Error Condition="!Exists('..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.2.0.1\build\net46\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props')" Text="$([System.String]::Format('$(ErrorText)', '..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.2.0.1\build\net46\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props'))" />
</Target>
From what I understand those settings are deprecated nowadays, no idea why VS inserted it in the first place.
Anyway, after removing those lines VS restored the packages and built the solution correctly again.
It's probably a good idea to clear the Nuget Cache by deleting the contents within this directory: C:\Users\{your_username}\AppData\Local\NuGet
All you need is that:
Open the Package Manager Console and run this command: Update-Package -reinstall
P.S: VS2017 and above NuGet Package Manager is included with Visual Studio, no need to install anything else.
The problem with the functionality of the NuGet package can also be caused by the fact that NuGet package is requiring certain dependency that the project does not meet.
NuGet package can have a declared dependency in Dependecies section, e.g. .NETFramework,Version=v.4.6.2 while the project is targeted to an older version (Target framework: .NET Framework 4.6.1.).
Instead of the NuGet system notifying the user of this fact, the project simply does not compile.
In my case, I have different Nuget configurations, and somehow the HintPath in the project file didn't fit.
Maybe you should check if the HintPath leads to the right NuGetPackages folder.
You should also check the following entries at the top of the file:
And at the bottom of the file:
All these paths should point to the right NuGetPackage folder in your file structure.
In my case the problem was solved by deleting the "obj" folder(s) and then rebuilding the solution.
The "obj" folder had several NuGet related files that still referred to version 0.0.2 of a package while all projects in the solution were already using version 1.0.0 of that package. Building the solution failed with the error message "package with version 0.0.2 could not be found". The solution with build folders included was recently copied from another machine.
Well it's probably a bad way but I found that it works if I just delete the line
http://go.microsoft.com/fwlink/?LinkID=317567." HelpKeyword="BCLBUILD2001" />
from the project.csproj , not sure if this is going to cause problems later on but it works for now.