The extension is broken for Nuget version 2.2, because the InstallCommand constructor arguments have changed.

[serra]

When running the nuget.copy.extension under Nuget 2.2.40207.9053, I get the following error:

Method not found: 'Void NuGet.Commands.InstallCommand..ctor(NuGet.IPackageRepositoryFactory, NuGet.IPackageSourceProvider)'.

Inspection shows that in commit e2504 this constructor was removed from InstallCommand. I'm sure not since which release this is, but from the git tags I'd expect NuGet version 2.2 and up.

Notes

1. This also affects the AddConsoleExtension extension; so if you're a new user and you're using NuGet 2.2, you won't succeed installing this extension; I manually copied it.I'm clueless as to where the NuGet Extend project is, so unfortunately I can't file an issues there.

2. The InstallCommand on the current head at codeplex only has an empty public constructor and a protected one that takes an IPackageRepoistory

[ferventcoder]

I believe this last worked at nuget 1.4. If you want to figure out how to
get it to work again, I'd be down for that. This was an experiment and a
learning opportunity at the time. It was coupled probably a little too
closely to the install and push commands, so that would need to be
refactored out.

Xavier DeCoster wrote another nuget extension mechanism, which I believe
works better than the one I used (written by a softie). I don't know where
their source is either or whether they've kept up with the library. I would
definitely say this should be converted to whatever Xavier is using.

On Wednesday, April 24, 2013, Marijn van der Zee wrote:

When running the nuget.copy.extension under Nuget 2.2.40207.9053, I get
the following error:

Method not found: 'Void NuGet.Commands.InstallCommand..ctor(NuGet.IPackageRepositoryFactory, NuGet.IPackageSourceProvider)'.

Inspection shows that in commit e2504http://nuget.codeplex.com/SourceControl/changeset/view/e250429fb16400194b56d951586dde29a75a5209#src/CommandLine/Commands/InstallCommand.csthis constructor was removed from
InstallCommand. I'm not since which release this is, but from the git
tags i'd expect NuGet version 2.2 and up.
Notes

1. This also affects the AddConsoleExtension extension; so if you're a
   new user and you're using NuGet 2.2, you won't succeed installing this
   extension; I manually copied it.I'm clueless as to where the NuGet Extend
   project is, so unfortunately I can't file an issues there.

2. The InstallCommand on the current head at codeplex only has an empty
   public constructor and a protected one that takes an IPackageRepoistory

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4
.

---

Rob
"Be passionate in all you do"

http://devlicio.us/blogs/rob_reynolds
http://ferventcoder.com
http://twitter.com/ferventcoder

[serra]

Thanks for the reply.

I was looking for a clean solution for promoting packages from a dev feed to a production feed and this extension command seemed to do the trick.

From my inspections earlier today it seems that the code indeed is coupled a bit too tightly to nuget internals making it difficult to maintain as nuget changes. The changes I made to support the current version of nuget would break against the current head of the nuget project already and that's not the kind of contribution I'd like to make.

Btw do you mean http://nuget.org/packages/NuGet.InstallCommandLineExtension/ by Xavier? Iirc this uses the same nuget extend package to add nuget.commandline support for adding commands.

I'll investigate some more and post back here later.

[ferventcoder]

I thought so with Xavier's tool. I'm adding him to this discussion.

On Wednesday, April 24, 2013, Marijn van der Zee wrote:

Thanks for the reply.

I was looking for a clean solution for promoting packages from a dev feed
to a production feed and this extension command seemed to do the trick.

From my inspections earlier today it seems that the code indeed is coupled
a bit too tightly to nuget internals making it difficult to maintain as
nuget changes. The changes I made to support the current version of nuget
would break against the current head of the nuget project already and
that's not the kind of contribution I'd like to make.

Btw do you mean
http://nuget.org/packages/NuGet.InstallCommandLineExtension/ by Xavier?
Iirc this uses the same nuget extend package to add nuget.commandline
support for adding commands.

I'll investigate some more and post back here later.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4#issuecomment-16940447
.

---

Rob
"Be passionate in all you do"

http://devlicio.us/blogs/rob_reynolds
http://ferventcoder.com
http://twitter.com/ferventcoder

[xavierdecoster]

Hey guys,

the last nuget extension I wrote (3 months ago, against NuGet.exe 2.2.31210.9045) simply got published as a downloadable DLL with the instruction to download it under %localappdata%\nuget\commands. Guess I was a bit lazy back then :)

I do however have a powershell script NuGet.InstallCommandLineExtension.psm1 which should do the trick: it downloads the latest nuget.exe, it calls nuget.exe install on the package containing the extension you want to install, and uses the %localappdata%\nuget\commands as -outdir for this command.

This means that if you have a package MyExtension.nupkg containing MyExtension.dll, you'll end up with %localappdata%\nuget\commands\MyExtension\MyExtension.dll.

I haven't used the script lately, but I believe it should still do the trick. Let me know if it doesn't.
Hope that answers the question? :)

Cheers!
Xavier

[serra]

@xavierdecoster - thanks for your reply, that's helpful.

In your book (Pro Nuget, chapter 6 Cont Pck Int / promoting packages) you suggest to use this extension for promoting (or phasing out) packages from one feed to another.

1. Do you still recommend this?
2. What would you consider to be the added value of this extension over a small script (install in temp dir, push to target feed)?

ATM I'm estimating if it's worth the effort to update and maintain this nuget.copy.extension extension. The alternative I'm considering is to add the copy command as a feature request to the the nuget project (so that when it's adopted it gets maintained) and until then use a short dedicated script in my deploy pipeline.

[ferventcoder]

Let me give you an idea of something that is on the burner. We are looking
at starting to phase out nuget as a default feed for chocolatey, and
mirroring packages on chocolatey instead. The reason is that nuget isn't as
discoverable and I've had a lot of folks ask where certain tools are (I'm
like, on nuget.org, just cinst it). In the long run it will help to speed
up the query time as well. The work done here can be a major player into
what we'll roll into chocolatey.

---

Rob
"Be passionate in all you do"

http://devlicio.us/blogs/rob_reynolds
http://ferventcoder.com
http://twitter.com/ferventcoder

On Thu, Apr 25, 2013 at 8:51 AM, Marijn van der Zee <
[email protected]> wrote:

@xavierdecoster https://github.com/xavierdecoster - thanks for your
reply, that's helpful.

In your book (Pro Nuget, chapter 6 Cont Pck Int / promoting packages)http://my.safaribooksonline.com/9781430241911/navpoint-52you suggest to use this extension for promoting (or phasing out) packages
from one feed to another.

1. Do you still recommend this?
2. What would you consider to be the added value of this extension
   over a small script (install in temp dir, push to target feed)?

ATM I'm estimating if it's worth the effort to update and maintain this
nuget.copy.extension extension. The alternative I'm considering is to add
the copy command as a feature request to the the nuget project (so that
when it's adopted it gets maintained) and until then use a short dedicated
script in my deploy pipeline.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4#issuecomment-17008082
.

[xavierdecoster]

@serra the extension is useful for those who are not aware of MyGet :-) We have the concept of upstream package sources and allow you to create a hierarchy of feeds, allowing you to push packages up the chain. So yes, I definitely still recommend this scenario, we've made it a core feature of MyGet.

I personally believe this functionality should be offered by a decent NuGet server, as it allows you to define and control the flow of packages (the feed hierarchy is defined server side for all clients, and the package moves from feed to feed server-side). This NuGet CLI extension actually makes it easier to define an alternative flow client-side and copy the package between random feeds (on the other hand, the push command is all you need if you 'd want to script this).

Would it be a big effort to update this extension (you're talking about a changed constructor for the InstallCommand)?

The added value of this extension?
Not all NuGet users are able to script these things. A simple commandline extension makes it more accessible to implement this workflow with the default NuGet.Server or NuGet Gallery implementations they might have in their company. It is an enabler for what I would call a good practice.

[xavierdecoster]

@ferventcoder Just thinking out loud here: I think the main issue you're having with Chocolatey packages on NuGet is that you have no common way to identify them. Maybe a virtual package dependency could do the trick? you could even specify which version of chocolatey is required to install the package (if for instance the package is using some new feature of choco). Could be a default convention when creating a chocolatey package?

[ferventcoder]

The ones on the nuget feed are not chocolatey packages, they are nuget packages with executables in them. So they work for both nuget and chocolatey.

[serra]

@ferventcoder what would be the advantage of physically hosting the packages on the chocolatey package server (I guess that's what this extension would be useful for - physically copy the packages from nuget.org to the chocolatey package server) instead of only mirroring them (which should be a oneliner using nuget mirror)?

[serra]

I don't think the effort is to make this extension up-to-date, but the effort is (better: will be) in:

• keeping this extension up-to-date (although a thorough refactoring might improve this)
• making the changes without breaking backwards compatibility

My point of view right now:

• only maintain this if we can refactor it to be more resilient to upstream changes to nuget (should be possible)
• break backwards compatibility for nuget < 2.2

[ferventcoder]

I agree here.

[serra]

Just for reference, I have filed issue nuget.3297 on nuget.codeplex, requesting for a copy command to be included into nuget.

Best way to get that issue resolved probably is to fix this extension in such a way that it could be easily changed into a pull request for nuget.3297.