In the VS solution, I have as dependencies (in the packages.config file)
a package A, version 2.0.0 which has dependency on package B version >= 5.0.0.0. The latest version of A is 2.1.0 and has the same dependencies as in 2.0.0
a package B, version 10.0.0.0. The latest version is 10.0.5.2
I want to update the package A to 2.1.0 so I tried the command
update-package A
in 'package manager console'. But strangely, Nuget updates also the package B to 10.0.5.2.
Someone told me that by default, Nuget will update to the 'bug fix' version, but I haven't found the link about that.
Does anyone know how to tell Nuget to not update other packages automatically ?
For info, I'm using Nuget 2.5, so according to http://docs.nuget.org/docs/reference/versioning, the dependencies are no longer updated during package installation
Thanks.
As far as I'm aware, this cannot be done, and is the main reason we created the ProGet Client Tools.
You might be able to get away with specifying the explicit version by surrounding it in brackets (e.g. [10.0.0.0]) in the packages.config file but that still seemed to grab the bug fix version when I tried it - though I haven't tested it on the latest version yet.
For reference, the NuGet dependency version selection algorithm is described in detail here: http://blog.davidebbo.com/2011/01/nuget-versioning-part-2-core-algorithm.html
Related
I want to pre-release a formula to homebrew so that even the new version is released as part of pre-release when user installs brew install package we should get the non pre-release package.
For example I have a package test-pre-release and versions are
x.y.z+1-rc -> latest pre-release
x.y.z -> previous
and when user wants to install brew install test-pre-release it should get the non pre-release versio i.e., x.y.z. Is it possible to do that in brew?
Thanks in advance.
Similar to what I answered in here, you can create duplicate your current formula.rb as formula-rc.rb and Then rename class Formula into class FormulaRc, and commit the changes to do the pre-release testing.
I have just updated my Typescript version through npm to V3.2.2 after I discovered that VS is using 2.6 and I need something from V2.9 at least.
I verified this with the tsc --version command, which gives me "Version 3.2.2" as output.
Now, however, when I want to update the Version for my project through the project properties in VS2017, I am still only able to use the old 2.6 version.
I tried this through the following guide: https://github.com/Microsoft/TypeScript/wiki/Updating-TypeScript-in-Visual-Studio-2017
With this help, I went to the csproj and manually updated the version number to the desired one. After restarting VS, I get a message stating that the (now) V3.2.2 is unavailable, and whether I want to downgrade to 2.6 again.
What am I doing wrong here?
I am using VS2017, V15.6.1
I'm attempting to install the Microsoft.Extensions.DependencyInjection and Microsoft.Extensions.DependencyInjection.Abstractions 2.0.0 nuget packages into a .NET Framework 4.7.1 project (Microsoft.AspNet.OData), however I'm getting the error:
Could not install package 'Microsoft.Extensions.DependencyInjection
2.0.0'. You are trying to install this package into a project that targets '.NETFramework,Version=v4.7.1', 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 dependency for these packages is .NETStandard,Version=v2.0. I understand that .NET Standard isn't .NET Framework, however I thought that .NET Framework 4.6 and greater projects could install .NET Standard projects? If this isn't possible, then are there other equivalent versions of these nuget packages for .NET Framework?
The whole reason that I'm going through this exercise is because many developers are completely blocked by Microsoft.AspNet.OData only supporting DI 1.0, not 2.0. This means that we cannot upgrade our nuget packages in our OData web api, as other packages require DI 2.0 but OData is stuck on 1.0. The rest of our applications are using the latest and greatest, so really it means that our OData web api solution can't leverage ANY of our shared code, and is completely quarantined until this compatibility block is resolved.
Installing Microsoft.Extensions.DependencyInjection in .NET Framework 4.7.1 project
I think the error message is not accurate. When I install the nuget package Microsoft.Extensions.DependencyInjection 2.0.0 to the project (Microsoft.AspNet.OData), I got the following error message:
Unable to resolve dependencies.
'Microsoft.Extensions.DependencyInjection 2.0.0' is not compatible
with 'Microsoft.AspNet.OData 7.0.0-beta2 constraint:
Microsoft.Extensions.DependencyInjection (>= 1.0.0 && < 2.0.0)'.
That is exactly what you said "because many developers are completely blocked by Microsoft.AspNet.OData only supporting DI 1.0, not 2.0."
Check the dependencies of package Microsoft.AspNet.OData, we could know there are strict restrictions for the dependencies Microsoft.Extensions.DependencyInjection and Microsoft.Extensions.DependencyInjection.Abstractions ((>= 1.0.0 && < 2.0.0))
So, this is really a issue that the package Microsoft.AspNet.OData don't support DI 2.0. Many other communities also report this issue on Github, but there is still no any workaround and solution.
My current workaround is:
Create a new project without installing package Microsoft.AspNet.OData.
Install the other dependencies of package Microsoft.AspNet.OData: Microsoft.OData.Core (>= 7.2.0 && < 8.0.0), Microsoft.AspNet.WebApi.Core (>= 5.2.2 && < 5.3.0) and Microsoft.AspNet.WebApi.Client (>= 5.2.2 && < 5.3.0) (The latter two packages should be included in the template by default).
Install the nuget package Microsoft.Extensions.DependencyInjection 2.0.0
Install the nuget package Microsoft.AspNet.OData with option -IgnoreDependencies in the Package Manager Console:
update-package Microsoft.AspNet.OData -IgnoreDependencies -IncludePrerelease
With this workaround, we could use Microsoft.AspNet.OData and DI 2.0, but I could fully confirm whether breaking the dependency limition will cause any problem for the Microsoft.AspNet.OData package. Simple tests are not problematic.
Hope this helps.
I am making a multi-platform app in VS 2013 (iOS, WinPhone and Android). I want to add into the iOS reference folder a Nuget Packages named Microsoft Http Clients Libraries and I cannot do it because I get the following error:
Could not install package 'Microsoft.Bcl.Build 1.0.14'. You are trying
to install this package into a project that targets
'Xamarin.iOS,Version=v1.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.
Can anybody help me with that?
I faced the same problem and apparently the Bcl.Build 1.0.14 can not be installed, but you probably you don't need that old version.
I faced this issue when I tried adding WindowsAzure.MobileService to the iOS Xamarin project. And it failed, because the minimal supported Bcl.Build is required to be 1.0.14, but if you have a newer version, which installs quite fine, you will be able to add other packages that depend on it.
So
1. Install Microsoft.Bcl.Build package separately (the latest)
2. Install your package that depends on it.
Go to -> Solution -> Manage Packages For Solution -> In the tab "Browse" -> Select the two options follow below:
First:
Install package "Microsoft.Bcl.Build" your version more latest 1.0.21
Second:
After this step, now install package "Microsoft.Net.Http" your version mor latest 2.2.29
Result:
For me was solved!
Microsoft.Bcl.Build 1.0.14 can be installed into Xamarin.iOS projects.
It may fail if:
Your NuGet Package manager is not up to date.
You do not have the Xamarin Portable Class Library profiles for Xamarin.iOS installed.
If you have the latest Xamarin version installed it is probably the NuGet Package Manager not being up to date. You can update it from Tools - Extensions and Updates - Updates - Visual Studio Gallery.
In Visual Studio 2017 I encountered above error, and I solved the issue by installing Microsoft.Bcl.Build first on the Xamarin.Android, then installed Microsoft.Net.Http and System.Net.Http, but Xamarin.IOS and Xamarin.UWP there were no issues.
I found the solution and put it here in case some one may face the same problem.
Install "Microsoft.Bcl.Build.1.0.21" first for all your projects.
Now you can install "PortableRest", all dependency that depends on Microsoft.Bcl.Build will be installed correctly.
I was trying to install Microsoft.Net.Http in my Xamarin.Forms project when i faced this issue. Here is what you must try to get rid of this error:
1- Update Xamarin.Forms to latest version in each project of solution.
2- As my primary intention was to install Microsoft.Net.Http, and this package had dependencies on Microsoft.BCL and Microsoft.BCL.Build. I tried installing these packages (Microsoft.Bcl and Microsoft.Bcl.Build) individually and it worked for me. First install latest version of Microsoft.Bcl.Build 1.0.21 (If 1.0.14 did not install, try latest version). Then, install Microsoft.Bcl which should be installed successfully and this solution worked for me and I hope would work for you too. After installing these packages indivisually, I was able to install Microsoft.Net.Http successfully.
NOTE: While installing Packages (Microsoft.Bcl and Microsoft.Bcl.Build) into your projects, check which version you are installing. Try installing another version, if one does not work and let me know If problem does not solve.
Have a great day :)
I recently tried to upgrade my log4net to the new 2.0.0 version.
but I wasn't able to do so, cause I have another library (combres.mvc) that has a dependency for log4net 1.2.11
Install failed. Rolling back...
Updating 'log4net 1.2.11' to 'log4net 2.0.0' failed. Unable to find a version of 'combres' that is compatible with 'log4net 2.0.0'.
Now the combres is an open source which I can download here http://combres.codeplex.com/
Does any one know how can I fix this, that the combres library will support log4net 2.0.0 or any other future version that may come out?
I did tried to contact the publisher with no help, It seems that he is not supporting this library any more...