We have a bunch of fast moving internal nuget packages.
We want the consumers of these packages to always be on the latest version. We currently do this on our CI system by running nuget update on the command line before build.
However we now are moving to .net standard/core. When we run nuget update on a .net standard csproj we get the following error:
Unable to update. The project does not contain a packages.config file.
Nuget still seems to be expecting a packages.config even though this has been dropped for .net core/standard csproj files.
How do we update PackageReferences to the latest version using the commandline for .net core/standard csproj projects?
UPDATE:
I've created a bug report incase this is a bug here: https://github.com/NuGet/Home/issues/4945
As a workaround, you should be able to run dotnet remove package followed by dotnet add package to update to the latest version of some package.
Related
Visual Studio 2022
I recently created an automation framework "prototype" project for my work. I created a nuget package for this framework following these instructions. I then created a new, separate project to try and install this nuget package with and I'm getting the following error:
I've looked through a lot of posts about this error and checked multiple things but nothing seems to be working. I've double checked that both my framework project and the target project are both the same output type / target framework:
Framework project:
Target project:
I've also checked both the csproj files for these projects and they both reference v4.7.2 as well.
I feel like I should be able to install this nuget package based on all this and the posts I've been reading that have fixes.
UPDATE
Nuspec file for the framework project
Karl's comment above seemed to do the trick. Somewhere I seemed to have missed a nuget pack. Once I did that it looks like the nuget package is able to be installed successfully.
I was trying to build a react app using Dotnet. I have installed dotnet but still getting this error. I have installed dotnet 5 and dotnet core 3.5. I have given the necessary images regarding the error.
First Image
Second Image
D:\dotnet project\Try\Try.csproj : error NU1100: Unable to resolve 'Microsoft.AspNetCore.SpaServices.Extensions (>= 5.0.9)' for 'net5.0'.
Oddly for my project, the user's computer couldn't find restorable packages because it didn't have a mapping for (the real) nuget. We had to add (or run from powershell):
dotnet nuget add source --name nuget.org https://api.nuget.org/v3/index.json
Then nuget restore worked and the error went away.
Try installing the version 5.0.1, Link. I faced the same issue a while back and it was fixed by installing a lower version. If it doesn't work, then try installing version 4.8
Between older version of .NET 5.0 there has been an rename of the targetFramework.
.net 5.0 vs netcoreapp5.0 Github
If your nuget package version doesn't contain your target framework,
please update or align the targetframework in your csproj file
with the contents of the nuget package or choose a more recent package.
Now it should be net5.0
All .NET framework projects that use Nuget have a packages.config per project. When I run something like:
nuget update MySolution.sln -Id PackageName -Version 1.2.3
It will update all projects in my solution that use this package to the specified version (1.2.3 in this case)
However, I'm finding that this does NOT work for UWP projects. UWP does not use packages.config and instead put the package references directly into the csproj file. As a result, this is literally what nuget update says when I run it:
Found 2 projects with a packages.config file. (A.csproj, B.csproj)
where A and B are my .NET Framework projects that still have a packages.config file. But this list doesn't include my new UWP projects.
Is there another command for nuget update that will work with UWP projects?
How do I update UWP projects' nuget packages via the CLI?
This is a known issue for the packagereference. 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 details:
support for updating references into csproj from commandline(s)
Besides, as test, the workaround using following command line does not work with UWP project
dotnet add package <PackageName> --version <version>
Indeed, currently it is very inconvenient to manage packages outside of Visual Studio for UWP with packagereference.
Hope this helps.
I've got a class library that till today was for .NET 4.5, now I've been asked to port it to .NET 40 but I've got some difficulies. I've followed this approach
and it works for the nuget packages that
but using this approach I get an error when going to Manage Nuget Packages telling
What's the most clean way to target different .NET framework version without loosing nuget package manager?
UPDATE #1
I've this version of nuget package manager
The error message caused by the duplicate packages listed in packages.config file. Because the Manager NuGet Packages window will read the packages.config file to list installed packages in your project and manage them.
For your situation, please check whether the packages in your project could compatible with both of .NET 4.5 and .NET 4.0. If yes, you need not to use two version packages in one project. You just need to change the project .NET Framework through Project -> Properties -> Application -> Target Framework.
If the installed packages version could not compatible with .NET 4.5 and .NET 4.0 at the same time, and you still want to use the Manager NuGet Packages, I suggest you do with below manual operation: Comment out one version of the packages in packages.config file and then open Manager NuGet Packages. After using Manager NuGet Packages, please uncomment the version that commented before.
We are using git as source control and we follow the git flow workflow.
We are using Visual Studio 2013
We are using Teamcity v8.1
We have 2 C# solutions. Solution A and solution B. Solution B uses a nuget package that solution A creates.
We are using teamcity as a build server. We have 2 build configurations that creates the Project A nuget package. One build configuration creates a prerelease version of the nuget package, the other one creates the stable version of the nuget package.
The build configuration for creating the prerelease nuget listens on the develop branch. The build configuration for the stable version listens on the master/release/hotfix branches
When we work in the develop branch we use the prerelease version of the nuget package.
But when we create a release branch we want to use the stable version of the nuget package.
What we have tried so far is:
In project B csproj file, we have added an element in the BeforeBuild target that executes nuget.exe to update the prerelease version of the nuget package. That works well, since every time we build project B we will get the latest prerelease version of the nuget package.
But when we are in the release/master/hotfix branch we don't want the prerelease version, we want the stable one.
I've created a powershell script that is executed from project B csproj file in the BeforeBuild target
In the powershell script I can find which git branch we are in, but I haven't found a way to update the nuget package to the latest stable version using nuget.exe. If I could use the nuget cmdlets in the powershell script I could run the update-package with the version flag, but that is not supportered when using nuget.exe
Do you do something similar and how have you solved this?
I while back I also tried to automate updating and installing packages with Powershell. As far as I know there is no way to use the Visual Studio cmdlets outside Visual Studio.
You could do everything yourself. Update packages.config, run nuget update, update csproj file.
It is possible your package has an install.ps1 file. This also uses the Visual Studio cmdlets. For example, the install.ps1 can add a config file to the Visual Studio project and set Copy to Output Directory to Copy if newer.
This means you would have to add these changes to the csproj as well.