I'm creating an app to automatically update nuget packages in a solution and build it to be sure they are still compatible.
Scenario:
<PackageReference Include="Dapper" Version="1.50.5" />
Clean/Build package with correct package version. It Succeeds.
Then I edit the version in the .csproj with garbage text.
<PackageReference Include="Dapper" Version="dasdasdasdqw3" />
It still succeeds. However it does log the error:
Error occurred while restoring NuGet packages: Invalid restore input. Missing required property 'Name'.
My understanding is that it is using the previous successful version from the \.nuget\packages folder.
Is there a way to have the build fail if the package could not be restored that does not involve deleting it from \.nuget\packages?
Assume that you used a net core project.
First, make sure that you have enabled these two options under Tools-->Options-->Nuget Package Manager-->General:
Actually, when you change the version, vs will detect the change and use the current version and will not used the latest valid package under \.nuget\packages. In my side, it failed.
Right-click on your project Properties-->Unload project-->Edit Project File and then change from 1.50.5 to adadd. And then reload your project, you will find that the project has an invalid nuget version called asda.
It fails build process successfully. You should click Rebuild rather than Build button.
========
If you did not see the nuget package version displayed UI under solution explorer, you could unload the project and then reload your project. And wait for a moment to get the change.
Besides, you could add dotnet restore command under Project Properties-->Build Events-->Pre-Build event command line to make it more accurately.
To use the latest updated version automatically, you could use Floating Versions.
Try this:
<PackageReference Include="Dapper" Version="*" />
It will update the nuget package to use the latest version under nuget package source feed rather than the latest version from cache \.nuget\packages. When you reload your project, wait for a moment, and you will see the change to use the latest nuget version automatically.
Related
Trying to have the latest version of ChromeDriver without having to always update the Nuget: Selenium.WebDriver.ChromeDriver in drop folder.
For this we used the floating variable: "*" for version as below in my project .csproj file:
<PackageReference Include="Selenium.WebDriver.ChromeDriver" Version="*"/>
or
<PackageReference Include="Selenium.WebDriver.ChromeDriver">
<Version>*</Version>
</PackageReference>
This works in local wherein on build, the latest version of available chromedriver ( currently: 99.0.4844.5100 ) is installed into local machine in bin/debug (or whichever)
but using a floating variable doesn't copy the latest ChromeDriver.exe (or any version of ChromeDriver.exe) into the build drop when checked-in (whereas when the version is hardcoded or anything other than *, its copied to build drop upon check-in).
Any other way of using floating variable works: For example:
using 99* works (but this will always fix it to any version starting with 99, and will not get the next highest version when the next version 100 will release
using []/(]/()/[) works but again will not get the highest acceptable stable version
hardcoding the version like 99.0.4844.5100 works
Note: My goal is to
Not manually keep updating Selenium.WebDriver.ChromeDriver in my projects
Have latest publish to build drop folder upon checkin
Copy build files to a remote VM X
Use the latest ChromeDriver.exe copied onto the machine X to run Selenium Test Cases using latest Nuget without manually and continuously checking and updating Nuget SeleniumWebDriver.ChromeDriver for a new version.
How can we move latest highest version of chromedriver.exe to build drop upon check-in without having to manually regularly updating the Nuget package: Selenium.WebDriver.ChromeDriver ? (preferebly by using * in version of csproj) ?
You may not reference Selenium.WebDriver.ChromeDriver directly.
You may reference
<PackageReference Include="Selenium.WebDriver" Version="4.1.0" />
<PackageReference Include="Selenium.Support" Version="4.1.0" />
and any version of chrome driver will be available for you without the need to update the Selenium.WebDriver.ChromeDriver package version.
To update the driver binary on your machine to the latest version - you may use https://github.com/rosolko/WebDriverManager.Net
Using MSBuild, the following builds and works fine:
<PackageReference Include="Publicise.MSBuild.Task" Version="1.3.0"/>
<Target Name="Publicise" BeforeTargets="BeforeBuild">
<Publicise
AssemblyPath="..."
OutputPath="../"/>
</Target>
However, when I add another Package Reference (changing nothing else), it encounters errors on build:
<PackageReference Include="Publicise.MSBuild.Task" Version="1.3.0"/>
<PackageReference Include="ILRepack.MSBuild.Task" Version="2.0.13"/>
This results in error MSB4062:
The "Publicise" task could not be loaded from the assembly ...\ILRepack.MSBuild.Task.dll. Confirm that the declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.
Why is something completely separate preventing the task from being properly found, and how can I fix this?
The issue is caused by these two msbuild task nuget packages accidentally.
And since you have installed the ILRepack.MSBuild.Task nuget package at the end. And the PackageReference node of ILRepack.MSBuild.Task is akways at the end. So $(TaskAssembly) is always loads from ILRepack.MSBuild.Task nuget package and the value from publicise.msbuild.task is being covered. And the issue The "Publicise" task could not be loaded from the assembly ILRepack.MSBuild.Task.dll makes sense.
C:\Users\xxx\.nuget\packages\publicise.msbuild.task\1.3.0\build\Publicise.MSBuild.Task.props
C:\Users\xxx\.nuget\packages\ilrepack.msbuild.task\2.0.13\build\ILRepack.MSBuild.Task.props
Also, when you project loads the nuget package, you can check under C:\xxx\source\repos\xxx(project_name)\xxx(project_name)\obj\xxx.csproj.nuget.g.props:
Loading the ILRepack.MSBuild.Task.props is always at the end and $(TaskAssembly) is always from ilrepack.msbuild.task due to being overwritten by the later installed package.
The error Publicise task(should be from publicise.msbuild.task) from ilrepack.msbuild.task could be understood.
Solution
So you should make publicise.msbuild.task at the end.
Solution 1)
open C:\xxx\source\repos\xxx(project_name)\xxx(project_name)\obj\xxx.csproj.nuget.g.props file,
modify like this:
<ImportGroup Condition=" '$(ExcludeRestorePackageImports)' != 'true' ">
<Import Project="$(NuGetPackageRoot)ilrepack.msbuild.task\2.0.13\build\ILRepack.MSBuild.Task.props" Condition="Exists('$(NuGetPackageRoot)ilrepack.msbuild.task\2.0.13\build\ILRepack.MSBuild.Task.props')" />
<Import Project="$(NuGetPackageRoot)publicise.msbuild.task\1.3.0\build\Publicise.MSBuild.Task.props" Condition="Exists('$(NuGetPackageRoot)publicise.msbuild.task\1.3.0\build\Publicise.MSBuild.Task.props')" />
</ImportGroup>
make Publicise.MSBuild.Task.props at the buttom.
Then, save the changes and then click Build button rather than Rebuild button to test again.
Solution 2)
downgrade ILRepack.MSBuild.Task nuget package to version 2.0.0.
===============================
Update 1
Thanks for sharing your opinion about the workaround. Since these two nuget packages have to be used in your project, so these two solutions might not be very useful.
The error, conflict is caused by the author of the nuget packages and incidentally, you're using the same TaskAssembly property from these two nuget packages at the same time.
TreatAsLocalProperty="TaskAssembly" will not solve the issue. <packages_id>.props files from the nuget packages are still embedded in the project's CSPROj file. Whether the fields are the same as TaskAssembly or will conflict.
The better solution is that you should rename one of the TaskAssembly of the nuget packages to another, which would not cause conflict.
1) Open C:\Users\xxx\.nuget\packages\ilrepack.msbuild.task\2.0.13\build\ILRepack.MSBuild.Task.props file:
change TaskAssembly property to another like TaskAssembly_copy:
Is there a way to disable updates of specific nuget packages installed in a project?
I have made some local modifications to a couple of javascript library packages and do not want to run the risk of someone updating over the top of my changes in the future.
I've never created my own nuget package, I'm guessing one option might be to fork the existing packages?
You could try constraining the package so it your project will only allow a particular version to be used. Then all updates to any newer version will be prevented.
You can do this by editing your project's package.config file. For example, the line below should only allow version 2.1.0 to be used.
<package id="SomePackage" version="2.1.0" allowedVersions="[2.1.0]" />
I don't have a package.config. (VS 2019, .NET Core 3.1) What I did instead was changing the .csproj of the project which had the package which I needed to stop showing up for updates.
In my case it was EPPlus, and I wrapped the version number within square brackets.
<ItemGroup>
<PackageReference Include="EPPlus" Version="[4.5.3.3]" />
</ItemGroup>
After that, it stopped showing up on the Updates tab in Nuget Package Manager.
And it doesn't give any option to update from anywhere else too. (Installed tab, Nuget for the solution, etc)
You'll need to restart VS to get rid of the yellow triangles next to the packages.
EDIT:
WARNING: Please note that this work only for "Manage nuget packages for [project]" (which is rarelly used), not "Manage nuget packages for Solution" (which is the one you use every other day). See comments.
So this is no solution at all. I will keep it here for some random googlers who will try this, but it is almost useless.
For PackageReference you can block update on single version like this:
<PackageReference Include="IdentityServer4.AspNetIdentity">`
<Version>[3.1.1]</Version>
</PackageReference>
For some reason it have to be in own element and not in attribute, so you are stuck with editing your .csproj by hand.
VS2019 will look funny (some yellow triangles) but just restart it and it will take effect.
It is not the same as allowedVersions= becouse AFAIK you can lock to exactly one version only (for example, [3.1.0, 3.1.1] or (3.0.0, 3.1.1] or whatever else does NOT work!)
(i know i am necromanting this question - accepted answer is about older <Package />, my answer is about newer <PackageReference />)
I have the following warning
Severity Code Description Project File Line Suppression State
Warning NETSDK1071 A PackageReference to 'Microsoft.AspNetCore.App' specified a Version of `2.1.6`. Specifying the version of this package is not recommended. For more information, see https://aka.ms/sdkimplicitrefs MyApi C:\Program Files\dotnet\sdk\2.2.102\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.DefaultItems.targets 153
I tried removing the reference by editing the project file and then adding the nuget package, however when I did this a lot of references no longer worked correctly.
I note the error is mentioning sdk\2.2 which I did install recently on my computer but there is no reference to it in the project file.
I am using VS2017 15.9.5
There's a few ways around this.
If you include the PackageReference but remove the Version attribute, it should make the warning go away. This is because it is a metapackage, which (simply put) is a type of package that gets the version based on your framework version, more here: https://learn.microsoft.com/en-us/dotnet/core/packages#metapackages
To disable the warnings, add AllowExplicitVersion:
<PackageReference Include="Microsoft.AspNetCore.App" Version="2.1.11" >
<AllowExplicitVersion>true</AllowExplicitVersion>
</PackageReference>
More here: https://github.com/dotnet/sdk/issues/2602
I ran into a similar situation creating a new xUnit Test Project (.NET Core). When I added a reference to an existing ASP.NET Core Web App project, I got:
Microsoft.Common.CurrentVersion.targets(2106,5): warning MSB3277: Found conflicts between different versions of:
Microsoft.AspNetCore.Authorization
Microsoft.AspNetCore.Cors
Microsoft.AspNetCore.Diagnostics.Abstractions
Microsoft.AspNetCore.Mvc
Microsoft.AspNetCore.Mvc.Abstractions
Microsoft.AspNetCore.Mvc.Core
Microsoft.AspNetCore.Mvc.Formatters.Json
Microsoft.AspNetCore.Mvc.RazorPages
Microsoft.AspNetCore.Mvc.ViewFeatures
Microsoft.AspNetCore.Razor.Runtime
Microsoft.AspNetCore.Routing
I did not understand how there could be conflicts when I did not find any references to Microsoft.AspNetCore.App NuGet package in my xUnit project.
I eliminated these version conflicts by adding the Microsoft.AspNetCore.App to my xUnit Test project.
At this point, I started getting the explicit version reference warning (NETSDK1071).
NuGet Package Manager and Package Manager Console within Visual Studio
will both add the version attribute to Microsoft.AspNetCore.App when
installing the package. You may remove the version attribute by
editing your .csproj file. This should eliminate the NETSDK1071
warning.
Note that if you do remove the version attribute, then NuGet Package Manager will disable the [Uninstall] + [Update] buttons and state: "- implicitly referenced by an SDK...".
At this point, I am not getting any warnings.
There is a lot of chatter and some tldr; documentation related to this issue. FWIW, here are a couple of succinct resources that I think warrant highlighting:
Microsoft.AspNetCore.App metapackage for ASP.NET Core 2.1 or later
#nguerrera summarized the the situation very well:
It is for all tests, or even all non-web projects that have a reference to a web project. It is not really a workaround in that the web reference did not flow transitively in .NET Core 2.x. You need to add it, and you should add it without the version so that the SDK can pick the correct version to avoid conflicts.
Better news: starting with .NET Core 3.0, the web reference will flow transitively and you can reference a web project from a test project without any other steps. So I am closing this. The design of 2.x cannot be changed, but we specifically designed things in 3.0 to have transitive Framework References, and this was a motivating scenario for that.
And here are a couple of tldr; conversations:
Does not cover Microsoft.AspNet.Core.All #8691
Version conflicts in test project depending on a Microsoft.AspNetCore.App project #2253
I had a similar issue with the error code MB2322. Fixed this by removing the version from the tag and adding the version to my Packages.props file in the src folder for the project.
So to translate here in terms of your project, the PackageReference portion you already have would simply have the version removed:
<PackageReference Include="Microsoft.AspNetCore.App" />
And in your Packages.props file, you'd add:
<PackageReference Update="Microsoft.AspNetCore.App" Version="[whichever version you are using here]"/>
For Developers working on Nopcommerce.
I was having the issue with Nopcommerce Project v(2.2).
To resolve, you have to make an edit inside Nop.Core.csproj file.
change :
<PackageReference Include="Microsoft.AspNetCore.App" Version="2.2.5" />
with :
<PackageReference Include="Microsoft.AspNetCore.App" Version="2.2.5">
<AllowExplicitVersion>true</AllowExplicitVersion>
</PackageReference>
I am trying to restore the missing nuget packages and it keeps giving me this Error:
An error occurred while trying to restore packages. Please try again.
Any experience solving this?
How can I find out what exactly is causing the error?
This is how I fix my issue:
First, I clear my Package Cache:
Second, I make sure I have the right path source and click the available package source:
Make sure you upgrade to the latest NuGet (http://docs.nuget.org/docs/start-here/installing-nuget).
Make sure you're doing package restore "The Right Way" http://blog.davidebbo.com/2014/01/the-right-way-to-restore-nuget-packages.html
That should resolve the issue.
If you don't want the package, just double-click your packages.config, find the line which refers to the package you want to get rid of, and delete that line.
Then, if you do want the package you could probably just redownload it using nuget and it'd probably resolve itself.
I had a similar issue with the Microsoft.Bcl.Build.1.0.14 NuGet package. My solution to this was to
Close Visual Studio
Remove the package folder with Explorer (or better only move it to another location)
Start Visual Studio
Go to the NuGet package manager and click Restore
I resolved the same issue by downloading the latest version of NuGet (really easy install, quick download): http://docs.nuget.org/docs/start-here/installing-nuget
(Definitely a beginner's answer here, but I'll leave it since I didn't find this anywhere else.) Make sure that nuget.org hasn't been unchecked from your package sources.
Tools. Options. Nuget package manager. Package sources. Ensure "nuget.org" is checked.
The problem in my case
In my case, we have developed our own NuGet packages. For some indescribable reason when I opened the solution, When I open solution, that has a previous version of NuGet packages that is deleted from origin or removed or unreachable for any reason. This make it unable to build the projects containing specific NuGet packages. I tried to install/reinstall/upgrade the NuGet package with out luck getting following error (see the image below), I did also try all possible answers here, and ensured the package was there, but no luck.
An error occurred while trying to restore packages: Unable to find version xxx..etc.
The solution for my case
Close your solution and find the path of the solution
Open all your projects .csproj files with notepad editor, that contain the packages that have the issue and remove all references that is shown in the error message, looks like this and save:
<Reference Include="Xxx, Version=30.0.0.16927, Culture=neutral, processorArchitecture=MSIL">
<HintPath>..\packages\Xxx.35.1.122605\lib\net461\Xxx.dll</HintPath>
</Reference>
In each folder where your .csproj is located, you find packages.config file, open it with notepad editor and remove all packages that is shown in the error message, looks like this and save:
<package id="Xxx" version="35.1.122605" targetFramework="net461" />
Start your solution, the error now should disappear, but you can not build because we have removed references and packages. So now you should be able to install your missing packages in fresh. When done build and all should work. Enjoy :)
I had similar issue, i found out it was due to my nuget cache.
Command to clear cache: dotnet nuget locals all --clear
After cache is cleared try restoring.
i fix this problem by moving the project folder to another one with less characters (local path was to long) i hope it helps some one
For me I cloned a solution (vs2015/NuGet3.4) that had a nuget dependency on a pre-release package that had been superceded. Nuget failed to restore the pre-release and wouldn't let me either uninstall or upgrade it. I frigged it by manually editting packages.config to target an older non-pre-release of the package, which I could then upgrade to the version I wanted. HTH
Just in case it helps someone else, I had this issue in a .NET Standard project where I had defined the target frameworks incorrectly:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard1.3;netstandard2.0;net45</TargetFramework>
</PropertyGroup>
...
When it should have been the plural TargetFrameworks (not TargetFramework):
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFrameworks>netstandard1.3;netstandard2.0;net45</TargetFrameworks>
</PropertyGroup>
...
For me non of those things mentioned above work.
I solved this issue by deleting packages.config in each project of my solution and then reinstalling all Nuget packages
In my case, I had another package source added which was like this.
I just removed this source from the NuGet package manager and rebuild the solution, it started working for me.
Go to TOOLS under OPTIONS select NuGet Package Manager
General, Select Everything
Package Source, Select all required Source
Hit OK. Done you must be good to go.