I have a private NuGet 2.8.5 feed in my internal network, which I use as part of my environment.
I just found that it does not work with some new packages.
Particularly, this package reference the same assembly for two different evironments - DNX 4.5.1 and DNXCore 5.0
That causes following error:
'xunit.runner.dnx' already has a dependency defined for
'Microsoft.Framework.Runtime.Abstractions'.
It looks like NuGet v.2 problem.
NuGet Package Explorer UI tool has exactly the same problem...
So, how can I create a local NuGet v.3 feed, which could serve such packages?
This NuGet.Server package looks abandoned, and I'm not able to find its source code anymore...
A 2.8.6 version of Nuget.Server package got posted yesterday, probably after your post. Perhaps this will fix the problem?
https://www.nuget.org/packages/nuget.server
Related
I have a Xamarin Forms Project, and I do use ShinyLib.net Package https://github.com/shinyorg/shiny.
I do have some bugs with Shiny, which I would like to track down and Fix.
How can I make my project use the Source Code from Git instead of the Nuget Packages so I can Debug and Make changes and try to fix some bugs? Shiny already is using .Net MUAI, but it is still compatible with Xamarin.
I tried to Download the Shiny Source Code, and in my Project, I use Add Existing Project, but it shows me that is Incompatible, and it fails when compiling :
Shiny.BluetoothLE is not compatible with netstandard2.1.
Can someone please explain the correct way for me to compile using source code instead of Nuget Package?
I am trying to build a VSIX extension that is using some NuGet packages.
When running the project I get an exception "Could not load file or assembly or its dependencies". I've included the package dlls themselves and they get copied over, but I suspect they're missing one of the numerous dependencies. But I don't know which ones.
I've found many old links here with similar issue and tried everything, but nothing seems to work.
Specifically I am trying to use MdXaml nuget package. It looks like it's relying on AvalonTextEdit, and that itself is relying on bunch of other stuff.
If I understand Scott Hanselman's post here correctly then I should be able to reference a .net standard library from a framework 4.7.2 solution.
I want to use Nuget to install such a reference.
I am using Azure DevOps Artifacts for the Nuget package. When I push my .net standard solution I can see that the package does create and that the Nuget install command is
Install-Package SBD.Standard -version 2.0.0-CI-etc
However when I try this at the PM console for my framework 4.7.2 project I get
Could not install package 'SBD.Standard 2.0.0-etc'. You are trying to install this package into a project that targets
'.NETFramework,Version=v4.7.2', but the package does not contain any assembly references or content files that are compatible with that
framework
moreover I do not see SBD.Standard as an avialable package in the relevant feed from within VS2019 -> Manage nuget packages for solution.
I think I need packages.config
I was able to create a new 4.7.2 project and add the nuget package that used .net standard 2.0 (but not 2.1)
When I tried to add the nuget package I got a dialog asking me to select the Nuget package manager format
so I chose Packages.config and that worked.
I am not sure I have it right. I solved my problem but am not sure whether this was it after all. SInce PackageReference is more recent it should work.
Some additional explanations for this issue.
There is an issue for NuGet restore when you using new SDK-based project type or PackageReference in the .net framework:
https://github.com/NuGet/Home/issues/5461
https://github.com/dotnet/sdk/issues/1755
When we use packages.config projects or non-SDK based project type, NuGet do not check compatibility during install/restore.
So, to resolve this issue, we need make sure the referenced project is an old style csproj or use packages.config.
That the reason why the packages.config works for you.
Hope this helps.
I know, you should not change the Package ID of a NuGet Package. But I did, because of a big refactoring.
Now I want to know if there is a proper way to define a successor NuGet package.
Old ID in Nuspec: OldLibrary1
New ID in Nuspec/csproj file: Library1
If a user opens the NuGet Package Management window for a Visual Studio Solution and the old package (ID OldLibrary1-1.0.0) is installed, he should see an update/upgrade to package Library1-2.0.0.
Is there a possible way to define this in some way?
By the way I use ProGet as NuGet server.
NuGet recently added deprecation information to it's HTTP protocol, however, as far as I know, only nuget.org has implemented it (it's very new, NuGet 5.3, Visual Studio 16.3). If your private nuget server (Proget) hasn't implemented it yet, you can try contacting the developers and ask them to implement it.
Otherwise the best option I've heard about is to create a new version of your old library, do not include any assemblies in it, just have a NuGet dependency on your new package id.
The issue with this is if your package consumer is using PackageReference, Visual Studio's upgrade experience isn't yet great, because when you release a new version of your new package, people getting it as a transitive dependency of your old package won't be notified about the available upgrade. An option to work around this is to include a MSBuild targets file which displays a build warning on every build, telling them to install the new package and uninstall the old package. People who ignore warnings won't see it, so if you want to be extreme, make it an error instead, but it helps get the message out.
I'm trying to install protobuf-net (2.0.0.602) in a portable class library, I just can't seem to get this to work. I get this error:
PM> install-package protobuf-net
'protobuf-net 2.0.0.602' already installed.
install-package : Could not install package 'protobuf-net 2.0.0.602'. You are trying to install this package into a project that targets '.NETPortable,Version=v4.0,Profile=Profile4', 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.
Inspecting the package it appears to target portable-sl4+wp71+windows8, however when i create a vinalla project targeting these frameworks I can't get it to work (profile4 is listed above, but I've tried a few different ones to see what sticks). I've just updated nuget in studio. Running 'nuget' from the package manager console shows the nuget version as 2.1.31022.9038.
If I browse to the protobuf-net.dll within the package (under lib\portable-sl4+wp71+windows8) it will allow me to reference it and all is good.
I can just manually add it, but am I missing something obvious.
Any help appreciated.
This appears to be just a slight tweak needed to the nuget config; I had specified portable-sl4+wp71+windows8, when actually I needed to specify portable-sl4+net4+wp7+windows8, to include regular .NET.
This is fixed in 2.0.0.611, which has been pushed to NuGet.