I've following structure for a .NET Framework project:
-->ProjectSoln -------->ClassLibProj1 -------->ClassLibProj2 -------->ConsumerLibProj3
I've defined GlobalAssemblyInfo.cs file at solution level and added the reference to this file in all
the 3 projects. ConsumerLibraryProj3 has project reference to ClassLibraryProj1 and ClassLibraryProj2.
I've added nuspec file in the ConsumerLibProj3 that contains $version$.
I'm generating Nuget Package for the ConsumerLibraryProj3 using following command
nuget pack ConsumerLibProj3.csproj -includereferencedprojects -verbosity detailed
The package gets generated successfully, but the version of the ClassLibProj1 and ClassLibProj2 dlls
in the package is not the latest. e.g. in the package ConsumerLibProj3.dll has version 1.0.0.2
whereas the ClassLibProj1.dll and ClassLibProj2.dll has version 1.0.0.1. The expectation is that all
the three dll's should have same version because the the version is coming from the
GlobalAssemblyInfo.cs file. The solution is using .NET Framework type project. Any help will be appreciated.
At last I was able to resolve this issue by forcing the nuget to use release configuration while packing. Surprisingly, I was building the solution with Release profile but still nuget was getting confused somehow. I used following command
nuget pack ConsumerLibProj3.csproj -includereferencedprojects -build -properties configuration=release -verbosity detailed
Thanks for the help.
Related
I am working on referencing another set of .dlls in another project and have bundled it up via Nuget:
I get this error:
Severity Code Description Project File Line Suppression State
Error NU1701 Package 'MyPackageImTryingToInstall' was restored using '.NETFramework,Version=v4.6.1, .NETFramework,Version=v4.6.2, .NETFramework,Version=v4.7, .NETFramework,Version=v4.7.1, .NETFramework,Version=v4.7.2, .NETFramework,Version=v4.8' instead of the project target framework '.NETCoreApp,Version=v2.1'. This package may not be fully compatible with your project. 1
I understand the error, but how do I make .Nuget restore with .Net standard?
Just found that if I reference the Nuget in a .Net Framework 4.6.1 project - it works fine.
It has something to do with making a nuget from .net standard to .net standard.
I had to add lib folders for the target frameworks I wanted to add the nuget package to:
For the files section in the nuspec I needed to make a \netstandard2.0 folder and \461 folder
I have used visual studio 2019, I have added some NuGet packages but it's show error like..
Error Could not install package 'Microsoft.Build.Framework 14.3.0'. You are trying to install this package into a project that targets 'MonoAndroid,Version=v9.0', but the package does not contain any assembly references or content files that are compatible with that framework. For more information, contact the package author.
Note: My Xamarin Binding library(Android) solution target version9.0.
please help me to resolve this issue.
Try by updating your Microsoft.Build.Framework package to the latest version (at the moment it is 16.0.461).
You can check it also here: https://www.nuget.org/packages/Microsoft.Build.Framework/
Once I copied the build task property section from my iOS csproj to my Android csproj.. I got a slightly different message. It asked me to add Microsoft.Build.Utilities.Core.
I then had to add the Microsoft.Win32.Registry 5 nuget then as it tried to install 4.3.0 which my Android project didn't like.
I'm using the PackageReference package management format available in VS2017 rather than packages.config.
The Nuget restore command works fine, however, the Nuget update seems to be searching from projects that have a packages.config even though I'm explicitly providing the .sln file
The command I'm using is
\NuGet\4.0.0\x64\nuget.exe update "Test.sln"
The output I get is
Scanning for projects...
MSBuild auto-detection: using msbuild version '15.3.409.57025' from 'C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\bin'.
Found 0 projects with a packages.config file.
Does anyone know if this should work or some other way of forcing my packages to update?
Does anyone know if this should work or some other way of forcing my packages to update?
At the moment, NuGet CLI does not support automatic package updates to the the new .NET Core .csproj format, you can refer to the below GitHub issue for detail:
https://github.com/NuGet/Home/issues/4358
If you want to force your packages to update, you can use the command line:
dotnet add package PackageName --version <version>
to update the package to the version that you specify. See the Github issue 4361 for detail.
Update to the Comment:
If you want to update to the latest version (without having to specify a specific version) of your nuget packages, you could use above command line without the option "--version":
dotnet add package PackageName
Besides, you can also use the command line update-package from the package manager console to update the package.
Is it possible to add a NuGet reference to an existing VS project (csproj or jsprox) using some command line tool?
I would need a functionality like package manager console offers using Install-Package command:
PM>Install-Package
This is not supported with NuGet.exe. With NuGet.exe you can download the NuGet packages based on what is in the packages.config file. You can also update NuGet packages and have their references updated in the project file by using NuGet.exe update. However you cannot use NuGet.exe to install the NuGet package so it adds the required references to the project file.
It is supported with Paket however if you use Paket then you would need to switch to using Paket for all NuGet packages since it has its own way of referencing the NuGet packages which does not include using the packages.config file. It also does not support PowerShell scripts.
I looked at installing NuGet Packages from the command line outside of Visual Studio using SharpDevelop and a set of PowerShell commands. This was a proof of concept but is not supported and requires most of SharpDevelop to be available.
If you are using .NET Core there is now a way to achieve this using the dotnet CLI.
dotnet add package EntityFramework
See Steve Smith's blog post for more information.
I'm configuring a TFS 2015 build using the new scriptable system. During the build, when NuGet is retoring some packages, it fails with the following error:
The 'System.Collections 4.0.10' package requires NuGet client version
'3.0' or above, but the current NuGet version is '2.8.60318.667'.
The 'System.Diagnostics.Debug 4.0.10' package requires NuGet client
version '3.0' or above, but the current NuGet version is
'2.8.60318.667'.
The 'System.Globalization 4.0.10' package requires NuGet client
version '3.0' or above, but the current NuGet version is
'2.8.60318.667'.
The 'System.Linq 4.0.0' package requires NuGet client version '3.0' or
above, but the current NuGet version is '2.8.60318.667'.
The 'System.Resources.ResourceManager 4.0.0' package requires NuGet
client version '3.0' or above, but the current NuGet version is
'2.8.60318.667'.
The 'System.Runtime 4.0.20' package requires NuGet client version
'3.0' or above, but the current NuGet version is '2.8.60318.667'.
The 'System.Runtime.Extensions 4.0.10' package requires NuGet client
version '3.0' or above, but the current NuGet version is
'2.8.60318.667'.
The 'System.Threading 4.0.10' package requires NuGet client version
'3.0' or above, but the current NuGet version is '2.8.60318.667'.
BTW, I've installed Visual Studio 2015 in the whole build machine and I've checked that NuGet 3.1 is present in the extensions manager menu.
I guess TFS Build is using a different NuGet installation location, but I can't figure out where's looking for it and how do I update it from 2.8.x to 3.x.
There's a workaround to this problem.
By default, if you use VSBuild/MSBuild tasks, you can only choose whether to run nuget restore or not via the appropriate checkbox. But there is a separate task called NuGet Installer (it lives in the Package section). It exposes an optional field for the custom path to the NuGet.exe:
So, here is the idea:
Schedule NuGet Installer step before the appropriate VSBuild/MSBuild step
Specify correct custom path to NuGet.exe
Make sure Restore NuGet packages flag is off for the VSBuild/MSBuild step
NOTE: Your solution with replacing the physical executable directly in the build agent internals might work well up until the agent is updated (either on purpose, or somehow automatically) and overwrites NuGet.exe with newer, but still outdated version.
It was easier than I thought...
After checking the TFS build log I found the following string:
X:\TfsBuild\Agents\project\agent\worker\tools\NuGet.exe
restore
"X:\TfsBuild\Agents\project\c57207ab\path\to\solution\whatever.sln"
-NonInteractive
That is, when TFS build agent ZIP is downloaded from the TFS Web Access, it includes an outdated NuGet executable.
The worst part that there's no publicly available NuGet Command-Line 3.x executable, and I needed to use Google once I've found a post in the official NuGet blog pointing to a NuGet Command-Line 3.1 beta version executable I've replaced the one in the build agent tools location with the beta one, and the error got fixed.
The issue also affects XAML builds
If you want to work with XAML builds, you'll need to download the same NuGet Command-Line executable and copy it to C:\Program Files\Microsoft Team Foundation Server 14.0\Tools\nuget.exe and replace existing one...
I had the same problem. You need to use more recent version of nuget.exe. Version 3.5.0 soved my problem.
You can download Nuget distributions here: https://dist.nuget.org/index.html
There should be a .NuGet folder at the top of your solution. TFS will use the nuget.exe in this folder for package restore operations.
Visit this URL: https://dist.nuget.org/index.html
Download the latest nuget.exe
Delete the existing nuget.exe from the .nuget folder.
Use add/existing item to add the new nuget.exe to this folder.
Check in the change.
You should now be able to queue a build and have it restore packages successfully.