Package renamed and instalation error

Mar 19, 2011 at 4:30 PM
I followed the suggested guidelines on renaming packages, by creating a new one and taking a dependency on that from the old one.

When I update, now I get this error:

'netfx-Reflector (≥ 1.0.0.0)' not installed. Attempting to retrieve dependency from source...
Done.
External packages cannot depend on packages that target projects.

/kzu

--
Daniel Cazzulino | Developer Lead | MS MVP | Clarius Consulting | +1 425.329.3471
Mar 19, 2011 at 5:03 PM

Yes, there is some quirky behavior in there. The simplest thing to do is to add a readme.txt (or named after the old package) under content that explains the rename. The presence of that content file will avoid the issue you're seeing.

Mar 19, 2011 at 6:21 PM
Here's an approach that seems to work way better for me (and my users I guess).
I just add an install.ps1 to the last version of the old package I'm going to provide, with the following:

param($installPath, $toolsPath, $package, $project)
write-host This package ID is obsolete. Replacing with netfx-Reflector
uninstall-package netfx-System.Reflection.Reflect -ProjectName $project.Name
install-package netfx-Reflector -ProjectName $project.Name


So that uninstalls the deprecated package right after installing it, tells the user, and installs the new one. Done. No dependency to the new package, etc. Clean way to get them forward IMO.

Thoughts?
Mar 19, 2011 at 8:29 PM

Brilliant, I love it! We should do that for EFCodeFirst. Did you test it when installing from the dialog?

Mar 19, 2011 at 9:13 PM
Let's document this in our conventions page as well!
____
Rob
"Be passionate in all you do"

http://devlicio.us/blogs/rob_reynolds
http://ferventcoder.com
http://twitter.com/ferventcoder
Mar 19, 2011 at 10:21 PM
Works great from the dialog too :))

But given that after the install, the user still doesn't have the package installed ('cause we installed another one), the "Install" button is still enabled, so I think the guidance should mention that the package author should explain that in the package description.

You can try out the experience with the package netfx-System.Reflection.Reflect which has been renamed to netfx-Reflector

Mar 20, 2011 at 6:29 AM

Seems to work well! It's probably the best technique yet, so I agree we should document it.

Developer
Mar 20, 2011 at 7:22 PM
dcazzulino wrote:
Here's an approach that seems to work way better for me (and my users I guess).
I just add an install.ps1 to the last version of the old package I'm going to provide, with the following:
param($installPath, $toolsPath, $package, $project)
 write-host This package ID is obsolete. Replacing with netfx-Reflector
 uninstall-package netfx-System.Reflection.Reflect -ProjectName $project.Name
 install-package netfx-Reflector -ProjectName $project.Name
So that uninstalls the deprecated package right after installing it, tells the user, and installs the new one. Done. No dependency to the new package, etc. Clean way to get them forward IMO.
Thoughts?

I'd change Write-Host to Write-Warning

Mar 20, 2011 at 7:25 PM

Tried that, but there was a bug iirc that prevented that from working

El mar 20, 2011 4:23 p.m., "dfowler" <notifications@codeplex.com> escribió:

From: dfowler


>
> dcazzulino wrote:
> Here's an approach that seems to work way better for me (and my users I gue...

I'd change Write-Host to Write-Warning



Read the full discussion online.

To add a post to this discussion, reply to this email (nuget@dis...

Developer
Mar 20, 2011 at 7:31 PM

I think it's Write-Error that doesn't work.

Jun 12, 2011 at 10:54 PM

This trick is not working anymore. Seems like something changed in nuget, because even through the uninstal-package succeeds, I never see the install-package run to add the renamed package.