search

NuGet / Home

Repo for NuGet Client issues
Other
1.5k stars 252 forks source link

Uninstall packages tries to install old version first #2050

Closed brgrz closed 7 years ago

brgrz commented 8 years ago

Uninstalling packages with -force still tries to install (or at least find, don't know) the old version first, which makes a little or no sense at all.

uninstall-package : Some NuGet packages are missing from the solution. The packages need to be restored in order to build the dependency graph. Restore the packages before performing any operations.

emgarten commented 8 years ago

Uninstall needs the contents of the package to uninstall to find the assembly references, content files, XML transforms, and uninstall.ps1 files contained in the package.

Skipping these steps is equivalent to removing the entry from packages.config without cleaning up the project.

brgrz commented 8 years ago

Makes sense but it seems it tries to find the package on the feed instead of on the disk? The old package (the one we're trying to remove) was installed to /packages folder and everything needed was added to the referencing .csproj so all the information needed is there. Yet the tooling wants to find it on the feed (which for us is a problem since we regulary clean/delete old .nupkgs).

emgarten commented 8 years ago

That sounds like a bug if it was already restored and in the packages folder.

emgarten commented 8 years ago

Which version of NuGet are you using?

yishaigalatzer commented 8 years ago

@brgrz can you let us know which version of NuGet are you using?

brgrz commented 8 years ago

it's 3.3.0.167

I'm constantly running into issue

"Some Nuget packages are missing from this solution. Click to restore from your online package sources."

This happens a lot when checking out projects from Git, merging branches etc. Nuget really isn't too happy with most changes, in fact it goes crazy the moment something is missing.

The problem gets even worse when the old version of the package is no longer available.

For instance, Nuget is missing package version 3.0.16 which is not available neither locally nor on the feed. But there is version 3.0.22 available on the feed. Still, all hell breaks loose, Nuget trying to restore the 3.0.16 both for update or uninstall - which is crazy and totally doesn't make sense.

Okay, it makes sense for normal workflows but we should still have an option to forcefully remove the package or forcefully update to new version.

I don't know who invented this dependency graph mechanism but it sucks. Obviously not very change resilient mechanism.

PM> uninstall-package mypackage -removedependencies -force
uninstall-package : Some NuGet packages are missing from the solution. The packages need to be restored in order to build the dependency graph. Restore the packages before performing any operations.

Doesn't work without the -removedependencies option either..

Oh, and btw, I did deleted those old packages from packages.config but when I try to reinstall them from scratch (the new version, that is) it is still searching for the old ones - have no idea why.

yishaigalatzer commented 8 years ago

We agree with you and that is why project.json based projects was invented. Packages no longer affect your project directly and thus uninstall doesn't require the original version, and so does update.

If you removed the package from packages.config, you might just have to reload the solution OR there is a reference in your project left behind from the old package (e.g. DLL name changed).

rrelyea commented 7 years ago

Closing in favor of recommendation to move to project files with PackageReferences inside of them. See https://blog.nuget.org/20170316/NuGet-now-fully-integrated-into-MSBuild.html

As such, references and imports don't need to be maintained in csproj, which causes problems like the above.

brgrz commented 7 years ago

As such, references and imports don't need to be maintained in csproj, which causes problems like the above.

As the blog post states the references are still in ItemGroup within the csproj?

brgrz commented 7 years ago

Also, this requires us to switch to Nuget 4, if I understand this correctly. We are still on 2.8 due to packaging features which are missing from Nuget 3 and 4.

emgarten commented 7 years ago

@brgrz what packaging features are missing, could you elaborate?

brgrz commented 7 years ago

@emgarten Source code and config transformations. Do you know of an alternative method/process with NuGet 4 to achieve that same feature?

emgarten commented 7 years ago

Those features exist in packages.config which is also in NuGet 4.x.

Config transforms are not supported in PackageReference, but you can get similar functionality from writing custom build targets/props to modify your files as needed during build.

brgrz commented 7 years ago

Those features exist in packages.config which is also in NuGet 4.x.

I see but if I move my projects to NuGet 4 I don't want to use an 'obsolete' method of referencing packages.

Config transforms are not supported in PackageReference, but you can get similar functionality from writing custom build targets/props to modify your files as needed during build.

Modifying my files during build (with build targets) is not the same as modifying the source (.pp)/config files when the package is installed in another project. I'm used to changing namespaces, wire up some stuff, etc. as a part of .pp transformation.

emgarten commented 7 years ago

.pp files are supported with PackageReference, there are a few scenarios where it is broken today but they will be fixed.

XDT transforms are not supported with PackageReference.

I see but if I move my projects to NuGet 4 I don't want to use an 'obsolete' method of referencing packages.

I'm not sure I follow your logic here. NuGet 2.x was obsolete years ago.

brgrz commented 7 years ago

I'm not sure I follow your logic here. NuGet 2.x was obsolete years ago.

Yes, I know and I want to move on but until I know most features I use with 2.8 are supported on v4 I cannot. PP transforms are crucial for me, XDT less so.

.pp files are supported with PackageReference, there are a few scenarios where it is broken today but they will be fixed.

Why isn't this documented somewhere? Docs say it's not supported, so I didn't even bother to test it out.

brgrz commented 7 years ago

From https://docs.microsoft.com/en-us/nuget/create-packages/source-and-config-file-transformations

Note Source and configuration file transformations are not applied when a package is installed in a project using Package References in project files.

emgarten commented 7 years ago

Well that is confusing, the docs are incorrect there. .pp files are supported and they can be put in the contentFiles/ folder now. Example contentFiles/cs/net46/code.cs.pp

brgrz commented 7 years ago

@emgarten I understand it takes time and effort to keep the docs in sync with new features. Maybe the Nuget team can use the blog on nuget.org more often, for shorter posts regarding new features, what's coming etc. ? I can see you already do that for bigger releases but maybe it'd be easier if there were more shorter posts discussing new functionality you just added/enabled, especially because the product changes are happening so fast.