In the company I work, inside every solution we have one folder packages, which contains all dll dependencies. This folder is not in repository with the rest of the solution.
Every time I build one project, all files inside folder packages are restored and any missing dlls appear again. This happens in the beginning of the build, no matter if the build succeeds of fails. Even if the project has no dll dependencies, any missing dlls in packages are restored.
I suspect it is a setting in msbuild but I cannot find it. Does anyone know where it might be or if there is a place with msbuild *.targets files?
thanks for any help
This is because Visual Studio restores packages defined in the packages.config files.
You can control this behaviour in Visual Studio in options:
From the MS Docs regarding regarding Nuget:
MSBuild: use the msbuild -t:restore command, which restores packages
packages listed in the project file (PackageReference only). Available
only in NuGet 4.x+ and MSBuild 15.1+, which are included with Visual
Studio 2017. nuget restore and dotnet restore both use this command
for applicable projects.
Further down, there's quite a bit about enabling/disabling and modifying this behavior in a variety of ways.
Allow NuGet to download missing packages: controls all forms of
package restore by changing the packageRestore/enabled setting in the
NuGet.Config file as shown below (%AppData%\NuGet\NuGet.Config on
Windows, ~/.nuget/NuGet/NuGet.Config on Mac/Linux). In Visual Studio,
this setting allows the Restore NuGet Packages command on the
solution's context menu to work.
Appearing to be more to your issue:
Automatically check for missing packages during build in Visual
Studio: controls automatic restore by changing the
packageRestore/automatic setting in the NuGet.Config file as shown
below (%AppData%\NuGet\NuGet.Config on Windows,
~/.nuget/NuGet/NuGet.Config on Mac/Linux). When this option is set,
running a build from Visual Studio automatically restores any missing
packages. The option does not affect builds run from the command line
using MSBuild.
Related
I'm helping a colleague who cannot get a Visual Studio WPF project to build in our TFS 2015 build server. I've pulled (get latest) the latest version of his code into my VS 2019 instance. I can't get it to build on my dev box. When I try to build the solution on my dev box I get errors like thing:
The tag 'ModernDialog' does not exist in XML namespace 'http://firstfloorsoftware.com/ModernUI'.
The tag 'Interaction.Triggers' does not exist in XML namespace 'http://schemas.microsoft.com/expression/2010/interactivity'.
When my colleague checks in changes into TFS, it fails with errors like this:
Unable to find version '5.2.0' of package 'MvvmLightLibs'.
Unable to find version '1.0.9' of package 'ModernUI.WPF'.
I started by trying to update the NuGet packages he had in the project, but that hasn't worked well. Even restoring back to the latest version doesn't build on my machine.
My colleague's approach is to rip all NuGet packages out of the Visual Studio solution, then look around to find the DLLs, then put them into the project and reference them in the project. It does build on his system but doesn't on the TFS build server.
So, I've been looking around for probable causes. I came across this Microsoft document Migrate from packages.config to PackageReference. I'm not familiar with either packages.config or PackageReference, but I get the feeling that PackageReference is the "preferred" way of including NuGet packages.
This raises problems. Currently our TFS build server's highest version of Visual Studio is VS 2015. According to the referenced article, VS 2015 uses packages.config files. Anything newer than VS 2015 uses Packages (PackageReference I presume).
I've compared the failing WPF solution with another one I've worked on which builds fine on the build server. The solution that builds, I'll call it SolutionA, has a packages folder at the root of the solution, but it also has packages.config files in each project in the solution. The solution that fails to build, I'll call it SolutionB, has the packages folder at its root, and one packages.config file in the unit test project. (I think the unit project builds fine.)
Even though we're working with newer versions of Visual Studio, I suspect that the problem the build server is having is due to the build server having an older version of Visual Studio. We have a limited number of licenses for Visual Studio, so I can't put a newer version of Visual Studio on the build server. So, how do I get those packages.config files into each projects?
First, your solution actually uses packages.config nuget management format. And this format makes every project has a file called packages.config which lists all the nuget packages and their versions. That is the feature of packages.config nuget management format. So you should also make sure that you have commit that file into TFS.
Second, that migrate packages.config into PackageReference is not an easy work and it should be done with VS IDE. Mostly, you have to make a big change to every csproj file of the project. Actually, PackageReference is flexible and lightweight, it does not have the packages.config file and packages folder which stores all the nuget packages. Just embed them directly in proj file. And so far, PackageReference is the mainstream.
Your problem is that you did not do a nuget restore operation on TFS build to make the missing nuget packages under the packages folder so that build process will find those nuget packages and make them work.
You should add a nuget restore xxx\sln command line or task.
Please check one,two,three.
I am working in an ASP.NET website (Website-A) code base which consumes an in-house NuGet package dependency.
Website-A consumes a pre-release of a NuGet dependency (Dependency-A). Opening Website-A and looking at "NuGet packages for solution" shows that Dependency-A is currently installed. Running "Restore NuGet packages" runs normally with no errors.
Rebuilding this .NET solution should result in a directory being created in one of the projects. (This directory will not be "included" in the project of Website-A, but the folder should be visible. I have clicked the "show all files" button.)
The issue is that this directory does not appear after rebuilding, nor after re-installing the dependency in NuGet package manager and then rebuilding.
We have discovered that if we manually delete the "packages" folder in the solution, and then "Restore NuGet packages", then rebuild the solution, the dependency will now create the directory like it should. It seems to need the "packages" folder to not exist in order to work like it should.
My question is: Is there something I am missing as far as a setting to automatically delete the packages folder? I would like to avoid having to manually delete this folder every time I need to update to a new pre-release of a NuGet package (we do a lot of this). I am using Visual Studio Enterprise 2017.
My question is: Is there something I am missing as far as a setting to
automatically delete the packages folder?
I'm afraid the answer is negative. AFAIK, VS doesn't have the option to delete the packages folder in Solution directory since it's not a normal way to do package update or package restore.
In addition: Do the pre-release packages have different names like packageName.1.2.0-beta1.nupkg,packageName.1.2.0-beta2.nupkg?
If your pre-release packages have different versions, and you update them using Update button in VS Package Manager UI, I think this strange issue you shouldn't encounter this issue. And if you have both projects in your local machine, it's not a good choice to develop locally with nuget packages...
In the limited amount of time I've worked with NuGet, the packages.config files I've encountered have all been associated with a Visual Studio project. I've just found one that seems to not be associated with a project (in this case a C# project). Rather, it's purpose appears to be to gather tools that are required to successfully complete a build of the solution the project is a component of (i.e. the NuGet packages in the packages.config file are never referenced directly in a .cs file).
I know I can open the packages.config in a text editor and add a new package to it. However, that seems to run contrary to the idea of NuGet as I understand it, and I'm not sure if adding an entry into packages.config manually won't create problems down the road.
What is the best way to add a new NuGet package to a packages.config file that's not associated with a Visual Studio project like this? The Microsoft docs I've found so far all seem to mention a corresponding VS project ( see https://learn.microsoft.com/en-us/nuget/consume-packages/ways-to-install-a-package)
Using Visual Studio to manage NuGet references for .NET projects that use packages.config is useful/important because of all the extra things that need to happen on "install". But for .NET projects that use PackageReference, using Visual Studio is just a minor convenience because it will restore the packages at the same time as changing the XML. There is no Visual Studio UI for isolated packages.config files
So, there's no problems editing your packages.config file with a text editor. You'll just need to run nuget.exe restore yourself (or more likely it's part of a build script). In fact, the NuGet team have one themselves as part of their build.
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.
I am writing a Windows Phone app, at the beggining using VS 2010 Express for windows phone. Then I installed VS 2012 and i made a desktop app which consumed JSON/REST service using RestSharp. Due to lack of support for plugins in Express version, i got full VS 2010 Ultimate and installed Nuget. When I create a win phone library project, and i add a RestSharp package, it shows in References, but i cannot access any of it's classes (and using RestSharp is underlined in red color). Also, when i Remove it and add again from Add Reference i get an Incompatible reference error window:
RestSharp.WindowsPhone, Version=103.2.0.0, Culture=neutral, PublicKeyToken=null" is incompatible with
Windows Phone 7.1
In order to add it yourself you should to change the project's terget to a compatible framework first.
It also appears if i change the target to WP 7.0.
Has anyone solved similar problem?
In my case this was because there was a packages.config file in the project folder but not in the solution. This was why I could not add the reference again properly. Delete this file from the physical disk, and re-run your Install-Package command. It should add this correctly now.
Are you using source control?
The it might be possible that you have not yet set the solution to enable package restore (NuGet documentation).
Right click on the Solution node in Solution Explorer and select
Enable NuGet Package Restore.
After that Solution Explorer will contain a few items more and there will be a new folder packages that was automatically added to your solution folder. You will need this folder to add to your version control because it will contain your installed NuGet packages.
That's it.
If you want to know more, here's more details on what it (automatically) does for you:
It added a solution folder named .nuget containing NuGet.exe and a
NuGet.targets MsBuild file. It also changed every project in the
solution to import the NuGet.targets MsBuild task.
With this in place, any time a project is compiled, the build task
will look at each project's packages.config file and for each package
in that file, ensure that the corresponding package exists within the
packages folder. For any missing package, the build task will download
and unpack the package.
In the restore scenario, NuGet will grab the exact version when
restoring a package. It will not perform any upgrades.
Additionally, if you have the latest NuGet version installed, will now find a new option unter Tools -> Options... -> Package Manager -> General -> Allow NuGet to download missing packages during build that I would also suggest to use.
The name says it all. If the solution is configured to use a certain NuGet package but the package is not yet installed on your development machine, NuGet will download it automatically for you when you do your next build.