I want to install OPCFoundation.NetStandard.Opc.Ua version 1.4.355.26 (and all of its dependencies) to an offline machine. My online and offline machines are running Visual Studio 2019 16.1.3.
When I install OPCFoundation.NetStandard.Opc.Ua version 1.4.355.26 using the NuGet Package Manager, it installs many dependencies, including Libuv.1.10.0. See screenshot:
When I download the same package for offline installation, nuget.exe fetches Libuv.1.9.2. See screenshot:
C:\Users\cstankevitz\Downloads>nuget.exe install OPCFoundation.NetStandard.Opc.Ua
Feeds used:
https://api.nuget.org/v3/index.json
C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\
Installing package 'OPCFoundation.NetStandard.Opc.Ua' to 'C:\Users\cstankevitz\Downloads'.
GET https://api.nuget.org/v3/registration3-gz-semver2/opcfoundation.netstandard.opc.ua/index.json
OK https://api.nuget.org/v3/registration3-gz-semver2/opcfoundation.netstandard.opc.ua/index.json 558ms
Attempting to gather dependency information for package 'OPCFoundation.NetStandard.Opc.Ua.1.4.355.26' with respect to project 'C:\Users\cstankevitz\Downloads', targeting 'Any,Version=v0.0'
Gathering dependency information took 16.89 sec
Attempting to resolve dependencies for package 'OPCFoundation.NetStandard.Opc.Ua.1.4.355.26' with DependencyBehavior 'Lowest'
Resolving dependency information took 0 ms
Resolving actions to install package 'OPCFoundation.NetStandard.Opc.Ua.1.4.355.26'
Resolved actions to install package 'OPCFoundation.NetStandard.Opc.Ua.1.4.355.26'
Retrieving package 'Libuv 1.9.2' from 'nuget.org'.
...
Of course, when I bring the downloaded packages to my offline machine and install them using Visual Studio 2019 NuGet Package Manager, the install fails because the Libuv.1.10.0 is not available.
How can I get nuget.exe (or any other tool) to download the correct packages needed by NuGet Package Manager for offline installation?
Here is how I installed the correct dependencies to my offline system:
On the online system
Fetch the source of https://github.com/StuffOfInterest/NuGetDependencyDownloader
Edit PackageTools.cs and modify the function GetRangedPackageVersion so that it contains the code below. This is needed to fix a "bug" in which older packages are not downloaded when newer packages are available -- but the older packages will be needed in Step 9 below.
Compile and run NuGetDependencyDownloader to download the package and its dependencies
Copy the packages to an external drive
On the offline system
Copy the packages to your offline system (c:\Work\2019-07018 Nuget Offline\ in my example)
Edit options for Nuget Package Manager | Package Sources. Add a source that points to the directory used in step 5. Specify Local Package Source Screenshot
Run Nuget Package Manager.
Specify the Package source that you created in step 6. Specify package source screenshot
Install your package
Notice that it appears to install but nothing is actually happening. It is trying to contact something online (which will fail after a long timeout). This is repeated for every dependency. Speed up the failure by disconnecting all of your interfaces (unplug cables, etc).
private IPackage GetRangedPackageVersion(IQueryable<IPackage> packages, IVersionSpec versionSpec)
{
packages = packages.Where(o => o.Version == versionSpec.MinVersion);
IPackage package = packages
.OrderByDescending(o => o.Version)
.FirstOrDefault();
return package;
}
If you look at the output of the Preview Changes dialog in VS, all the Microsoft.AspNetCore packages are version 2.0.1, whereas running nuget.exe, it got versions 1.1.x. If you look at OPCFoundation.NetStandard.Opc.Ua on nuget.org and expand the dependencies, you see it has dependencies on the 1.1 packages for net46 and netstandard2.0, but 2.0 dependencies for netstandard2.0.
From this I can deduce that your project is using netcoreapp2.0, netstandard2.0, or above, whereas nuget.exe is probably using some .NET Framework for dependencies.
As for ways to get the same packages that your project actually uses, I've answered this question several times in the past and I usually link to the first time I answered it
Related
I have a Blazor Server app (Visual Studio 2019), where I have to install sometimes some nuget packages. I have often the case that when I try to install the nuget, I get an error that several packages are missing. (For example three packages)
So I am downloading also the nugets to the missing packages but I get also on some of them the same case, that again some packages are missing for installing them. I have to download again and again new packages and install them. Sometimes it takes me more then half an hour until I have installed all the missing packages and can install the first nuget package without Error.
Isn't there an easier way to manage that?
Background:
I have created a class library for .net core (targetting v2.2), and I have a .net core application as well (targetting v2.2).
I am trying to export the library as nuget package and install it in my application.
Here is the dependencies for my library
I am able to export it as nuget package and for now I am storing it in local nuget repo.
But when I try to install this library package in my application it's not getting installed due to package version conflict for Microsoft.Extensions.Logging. Here's package manager console output.
Issue:
I have specified the exact version for Microsoft.Extensions.Logging i.e. [2.2.0] as we could confirm that in the screenshot showing dependency for my library, then why it's getting resolved to version 3.0.0?
How could I resolve this issue?
Details about the environment:
NuGet product used (Package Manager Console): Package Manager Console Host Version 5.3.1.6268
VS version (if appropriate): Microsoft Visual Studio Community 2019 Version 16.3.8
OS version (i.e. win10 v1607 (14393.321)): Windows 10 Enterprise Version: 1809
How could I resolve this issue?
To resolve the strange behavior in your side, you should clean the nuget cache before installing that package in your current project.
(To make sure the cache is cleaned up, I suggest you go %userprofile%\.nuget\packages to check if there exists Com.lib folder within the Packages folder)
I have specified the exact version for Microsoft.Extensions.Logging
i.e. [2.2.0] as we could confirm that in the screenshot showing
dependency for my library, then why it's getting resolved to version
3.0.0?
I think the one(Com.Mylib) you want to install is not the first one you pack. I mean that you may actually build and pack several different Com.Mylib package with different content. And all of their names is Com.lib.1.0.0.nupkg.
Nuget stores all nuget cache in %userprofile%\.nuget\packages. So if I once install one PackageA in any project. The cache of PackageA is stored there. And if I open a new project trying to install the PackageA with same version(1.0.0), it actually installs the one from cache. So we will meet this strange behavior:
Nuget can recognize the Com.lib package depends on other 2.2.0 packages. But when it tries to install that package, it finds the package has existed in cache. Then he tries to install the one from cache, and I guess content of the one in cache is different from your latest one, then the issue occurs.
Suggestions:
1.When developing locally, use project reference instead of Nuget packages.
2.If you need to test the nuget package every time after packing, please make sure the package version has increased.(1.0.0=>1.0.1=>1.0.3... or beta-1.0.12, preview-xxx)
3.If you have special reason do use same version 1.0.0, please clean the cache to avoid previous cache affects current project.
Hope all above helps :)
I'm getting this error when using maps in Android:
System.MissingMethodEsception: Method
'Xamarin.Forms.maps.Android.MapRenderer.OnCameraChange' not found.
And I've read that you can update the nugetpackage to fix the issue. However, I cannot install it due to this:
Could not install package 'TK.CustomMap 2.0.1'. You are trying to install this package into a project that targets '.NETPortable,Version=v4.5,Profile=Profile78', 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.
The updates of packages installs just find in iOS and Android but not for PCL. I've tried to remove all the packages and then tried to add TK.Customs nuget package but this same issue.
Also tried to install it on a fresh project and that installed just fine. Just cant get it to install on my old project.
Here is the whole error message when trying to update package:
Attempting to gather dependency information for package 'TK.CustomMap.2.0.1' with respect to project 'Vernamo', targeting '.NETPortable,Version=v4.5,Profile=Profile78'
GET https://api.nuget.org/v3/registration3-gz-semver2/tk.custommap/index.json
OK https://api.nuget.org/v3/registration3-gz-semver2/tk.custommap/index.json 175ms
Total number of results gathered : 29
Gathering dependency information took 232 ms
Summary of time taken to gather dependencies per source :
https://api.nuget.org/v3/index.json - 204.03 ms
Attempting to resolve dependencies for package 'TK.CustomMap.2.0.1' with DependencyBehavior 'Lowest'
Resolving dependency information took 0 ms
Resolving actions to install package 'TK.CustomMap.2.0.1'
Resolved actions to install package 'TK.CustomMap.2.0.1'
Found package 'TK.CustomMap 2.0.1' in '/Users/holger/Downloads/Vernamo/packages'.
For adding package 'TK.CustomMap.2.0.1' to project 'Vernamo' that targets 'portable45-net45+win8+wp8'.
Install failed. Rolling back...
Package 'TK.CustomMap.2.0.1' does not exist in project 'Vernamo'
Executing nuget actions took 52 ms
Could not install package 'TK.CustomMap 2.0.1'. You are trying to install this package into a project that targets '.NETPortable,Version=v4.5,Profile=Profile78', 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.
The pre-release version (at least pre2) of TK.CustomMap supported all platforms (see here), anyway, as of pre3 (see here), obviously the support for all platforms was dropped in favor of .NET Standard (1.1 in this case).
The profile you are using in your PCL does not seem to be compatible with .NET Standard 1.1, hence NuGet fails to add the reference. You may try to switch to another profile (.NET 4.5.1 for example), but I don't know if that would help. Another option would be to migrate your projects to .NET Standard. It's kind of a stupid, repetetive task, but it's possible.
I cannot install the NuGet package System.IdentityModel.Tokens.Jwt (.Net JWT Handler) into my project. If i try to install the package with NuGet, it will install into the root of the solution only (a .nuget folder is created in the root of the solution). I need to install the package in my project, not the solution.
Why would this happen? I tried passing in the project name to the Install-Package command in the Package Manager Console, and that looks like it installs correctly but no references are added to my project and the packages.config file is not updated.
My project is currently referencing .Net 4.5.1 and I have also tried with .Net 4.5.
The package I am trying to install is here:
System.IdentityModel.Tokens.Jwt
I'm having the same issue. I was trying to install the package as said in this article http://msdn.microsoft.com/en-us/library/dn205064(v=vs.110).aspx
So, I look into the package history and finally I installed the previous package
http://www.nuget.org/packages/System.IdentityModel.Tokens.Jwt/3.0.0
It works fine for me.
With NuGet, you can now specify the directory the packages are installed in.
http://docs.nuget.org/docs/release-notes/nuget-2.1
Specify ‘packages’ Folder Location
In the past, NuGet has managed a solution’s packages from a known ‘packages’ folder found beneath the solution root directory. For development teams that have many different solutions which have NuGet packages installed, this can result in the same package being installed in many different places on the file system. NuGet 2.1 provides more granular control over the location of the packages folder via the ‘repositoryPath’ element in the NuGet.config file. Building on the previous example of hierarchical nuget.config support, assume that we wish to have all projects under C:\myteam\ share the same packages folder. To accomplish this, simply add the following entry to C:\myteam\nuget.config.
The package System.IdentityModel.Tokens.Jwt 3.0.1 has some problems: the file System.IdentityModel.Tokens.Jwt.dll and System.IdentityModel.Tokens.Jwt.Xml should be put in directory lib\net45, but they are put in the root directory instead. This causes NuGet to think the package is a solution level package, and will not install the package into a project.
This problem was fixed in System.IdentityModel.Tokens.Jwt 3.0.2
When I try and build my project in Teamcity (or in a clean repository on my machine), it fails with the error message
The schema version of 'Microsoft.Bcl' is incompatible with version 1.7.30402.9028 of NuGet. Please upgrade NuGet to the latest version from <nuget url>...
I've set my NuGet.Targets to restore packages, and not require user interactions to accept licenses. In addition both my local machine and the build server have the restore packages setting enabled (in the project/env variable as appropriate).
I'm aware of this issue http://blogs.msdn.com/b/dotnet/archive/2013/06/12/nuget-package-restore-issues.aspx. I've tried the second and third options suggested here, but without success.
Does anyone have any suggestions how to resolve this error?
Turns out the version of NuGet that is held in the .nuget folder of my solution was out of date. The version that Visual Studio uses had updated correctly, but the command line version didn't.
I followed the instructions described here Nuget versioning issue with package restore to resolve the problem.
In the solution directory run these commands:
cd .nuget
nuget.exe update -Self
Try updating the nuget that teamcity is using
If you are using version 8.x.x
Administration -> Nuget Settings -> Nuget Commandline -> (click fetch nuget) -> then choose the latest version and install it. Make sure "Set as Default" is checked.