I have a dependency on specific nuget package. When I update my solution to use new package version and commit/push solution to remote GIT repository, other contributors to solution, after pull, are still using old DLL version of nuget package, even though package-restore is activated. However, when they open CSPROJ file, it shows that reference should be to the new version. Basically Visual Studio is not generating any warning/error if there is a mismatch between used DLL from bin/obj folder and referenced DLL in csproj file. To be more concise:
Solution uses DLL version 0.5
I upgrade via Nuget to DLL version 0.6
My Visual Studio shows that version 0.6 is used
I commit/push solution to GIT
Another colleague pulls solution from GIT
His Visual Studio shows DLL version 0.5, there is no error/warning
His CSPROJ file references DLL version 0.6
Solution fails on runtime as there is change in internal implementation
How do we fix this:
Colleague deletes his bin/obj
Visual Studio notices that DLL's are missing
He uses Manage Nuget Packages on solution level and just clicks OK, nothing else
Nuget downloads DLL's and issue is solved
Now this is really stupid workaround and in my opinion this should be automated. Is there anything that we might be doing wrong that is causing this to happen?
GIT for VS doesn't take into consideration nugget packages (neither build generated files in \obj and \bin folders).
For Git to manage packages for versioning edit .gitignore file by commenting (#) line below :
# Enable "build/" folder in the NuGet Packages folder since NuGet packages use it for MSBuild targets
#!packages/*/build/
(nb : if you want to backup and rename .gitignore file, go there)
Related
In Visual Studio 2019 I added a Nuget package, Microsoft.AspNetCore.Authentication.Google version 3.14. The only visible change I can find is an extra line in <ItemGroup> in the .csproj file.
Where is the code of the package located?
How is version control impacted if my project is checked into TFS?
Nugets are saved under :
{project-root}\bin\{debug-release}\{target-framework}
{project-root}\obj\{debug-release}\{target-framework}
Additionally all nugets are cashed under below folder for future use :
%UserProfile%/.nuget/packages
The packages are in your build folder ie. bin/debug or bin/release
NuGet packages are typically omitted from source control repositories and are restored with project dependencies before a build.
Omitting NuGet packages in source control systems
I have a nightly process running on TeamCity that will loop through my packages on a locally hosted NuGet repo and update all packages in all solutions to the latest prerelease version.
When I pull the latest code the morning after. The solution builds fine, but my project references are not loaded.
Unresolved project references: https://imgur.com/a/v7Klbkm
Unresolved code: https://imgur.com/a/EEzWgUe
I'm using packages.config to manage my NuGet packages.
In order to continue working I have to "reload" my Visual Studio projects by either manually asking the properties of the missing reference, or by changing something in the .csproj file.
That is my little workaround, but for some solutions with 10+ projects this becomes quite cumbersome.
Other means of updating packages work fine, if I try to update the packages through Visual Studio I have no issues. It only fails when using the NuGet.exe command line utility.
Here's the command we use to update the packages through NuGet.exe on TeamCity during a nightly build:
NuGet.exe update <path_to_packages.config> -Id <current_package_to_update> -pre -NonInteractive
This is the version of NuGet we're using:
NuGet Version: 4.8.1.5435
Here's an excerpt of the logging:
found PFW.Utilities with version 2019.9.0-build0009 in file C:\Sources\Xmp\ModXmp\packages.config
http://srvppratonexus.prato.be:8888/nexus/service/rest/repository/browse/nuget-prato-prereleases/PFW.Utilities/2019.9.0-build0009
MSBuild auto-detection: using msbuild version '16.1.76.45076' from 'C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Current\bin'.
Feeds used:
http://srvppratonexus:8888/nexus/service/local/nuget/nuget-group/
https://api.nuget.org/v3/index.json
C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\
Attempting to gather dependency information for multiple packages with respect to project `C:\Sources\Xmp\ModXmp\ModXmp.csproj`, targeting `.NETFramework,Version=v4.6.1`
Gathering dependency information took 10.79 sec
Attempting to resolve dependencies for multiple packages.
Resolving dependency information took 0 ms
Resolving actions install multiple packages
Found package 'PFW.Utilities 2019.9.0-build0019' in 'C:\Sources\Xmp\packages'.
Removed package 'PFW.Utilities 2019.9.0-build0009' from 'packages.config'
Successfully uninstalled 'PFW.Utilities 2019.9.0-build0009' from ModXmp
Package 'PFW.Utilities.2019.9.0-build0019' already exists in folder 'C:\Sources\Xmp\packages'
Added package 'PFW.Utilities.2019.9.0-build0019' to 'packages.config'
Successfully installed 'PFW.Utilities 2019.9.0-build0019' to ModXmp
Executing nuget actions took 192.26 ms
When I pull the latest code the morning after. The solution builds
fine, but my project references are not loaded.
When you call nuget.exe to update nuget packages for the project using packages.config format outside the VS IDE, it not only modified the packages.config file, but also modified the project file(.csproj). So VS IDE can't load them well unless a reload.
Not sure what's the real solution you have, you can Go Tools => option => Environment => Documents, make sure you've enabled the Detect when file is changed outside the environment. Then you can get reload all dialog when you modify the project file outside VS IDE.
Reload all dialog looks like this:
That is my little workaround, but for some solutions with 10+ projects
this becomes quite cumbersome.
If for some reason that dialog didn't occur, you can manually open one .csproj using notepad, then add one empty line into it and save. VS will detect the change and show the dialog, then click reload all to reload all projects in the solution.(For the solution with many projects)
I am using mspec (machine specification) unit test framework for .NET project.
I used nuget to get all required packages.
There is a specific package, that is not part of the code. It is the "Console" application for the mspec that I used to run my unit tests from outside VS, from the command line.
(It is located here):
When I use Nuget to install it, Nuget doesn't add it to the normal "packages.config" file inside of the Test project.
It is adding it to a "packages.config" folder that exists in ".nuget" folder.
But when my colleague open the project and build, his VS doesn't get that package.
How to change that, to force VS to get the package automatically?
Nuget doesn't add it to the normal "packages.config" file inside of the Test project. It is adding it to a "packages.config" folder that exists in ".nuget" folder.
That is because you are using NuGet 2.7 or later and have a solution that is still configured by old package restore method "MSBuild-integrated restore". This will cause builds to fail with an error stating that you have not given consent to restore packages. Visual Studio will skip automatic package restore.
How to change that, to force VS to get the package automatically?
To resolve this question, you can follow below steps:
Close Visual Studio to avoid file potential file locks and conflicts.
If using TFS: a. Remove nuget.exe and nuget.targets from the solution's .nuget folder and remove those files from the solution workspace. a. Retain nuget.config with the disableSourceControlIntegration setting as explained in Omitting packages with Team Foundation Version Control.
If not using TFS: a. Remove the .nuget folder from the solution and the solution workspace.
Edit each project file in the solution, remove the <RestorePackages> element, and remove any references to the nuget.targets file. For more detail information, you can refer to Migrating to automatic restore.
I have been trying to figure out why automatic package restore in Visual Studio 2015 doesn't work.
As I understand it there is nothing to do but check a couple of settings. When you build, it looks for missing packages and downloads them automatically.
I have a solution that has 15 individual projects. The majority of them will not compile because of "missing packages".
I do not have any of the legacy NuGet (.nuget folder etc.) in any of these projects and I have the latest and greatest version of NuGet.
Visual Studio simply will not download the missing files. I deleted the solution package folder and it does re-create and download all of the packages when I build, but each individual project still shows missing references.
If I go to the package manager console and issue a
Update-Package -reinstall
then the packages download and everything works. I'm just wonder why it doesn't do this automatically.
It's supposed to right?
NuGet Restore only restores files in the packages directory, but does not restore files inside your project or modify your project.
For example, if there has a package will add some reference dlls or add some content files into your project. After deleting these reference dlls and content files from your project, it will not be added when restoring this package. This will cause the your project could not find the missing pacakges when compile.
So we need use "Update-Package -reinstall" command to force reinstall the package references and content files into project.
Update the example for sharing projects in a team:
Following is my solution structure, the CommDLL project installed some NuGet packages and entire solution is managed by a source control.
I download this solution on another machine from source control use another user account and install another NuGet packages into the CommDLL project. Then use some content from the new installed package and build the project successful. Please make sure the package dlls has been added into your project and it has been set the correct HintPath in .csproj file.
<Reference Include="Newtonsoft.Json, Version=9.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed, processorArchitecture=MSIL">
<HintPath>..\packages\Newtonsoft.Json.9.0.1\lib\net45\Newtonsoft.Json.dll</HintPath>
<Private>True</Private>
</Reference>
Next, I check in this modified project into the source control. Please make sure you the .csproj file and packages.config file are checked in.
Now I get the latest version on another machine to get the modified content. After check out the latest version from source control, the package references are shown with a warning because the project is not compiled, which means the packages are not restored. Please rebuild this project, it will restore the packages for your project (make sure your Visual Studio 2015 has enable "Allow NuGet to download missing packages" and "Automatically check for missing packages during build in Visual Studio" before rebuild this project).
I updated to VS2015 this week and along with that updated all NuGet packages in my website solution.
The site builds and run fine locally, however when doing my gated check in to my build server, I get the following when the build fails
As you can see the packages are complaining about the NuGet version, but I'm unsure how to update the NuGet version on the build server. I do have admin privileges to the server, but following the guild described at: http://blog.stangroome.com/2014/02/04/update-nuget-exe-version-used-by-team-build-2013-package-restore/ did not help. For one, my folder was actually C:\Program Files\Microsoft Team Foundation Server 11.0\Tools unlike the C:\Program Files\Microsoft Team Foundation Server 12.0\Tools described in the guide, but additionally I did not have a NuGet.exe within the folder.
I've done a full hard drive search of NuGet.exe, but could not locate it in any directories aside from the directories that are directly related to project source code (.nuget\NuGet.exe).
I have opened visual studio on the server and updated the NuGet version within "Extension and Updates" hoping that would fix the issue, unfortunately it did not.
Any ideas on how to fix the issue/errors presented in the screenshot?
The problem is that you're using the old-style, deprecated-since-NuGet 2.7-style "package restore" that's based on modifying your CSProj files to include references to a NuGet.targets file and a copy of NuGet.exe that gets put into a .nuget folder and ends up source controlled.
Basically, the version of nuget.exe that's on the build server is irrelevant right now -- your CSProj files are pointing to the file in your .nuget folder.
TFS 2013 and beyond has support for automatic package restore without using the NuGet.targets method. You can migrate off of it pretty easily: https://docs.nuget.org/consume/package-restore/migrating-to-automatic-package-restore