Change to how nuget commands accept ProjectName parameter

Feb 20, 2011 at 6:18 AM
Edited Feb 20, 2011 at 6:19 AM

Hi all,

I'm making a small change in v1.2 in how nuget commands intepret the ProjectName parameter. This is to fix this bug (

First of all, a new concept. Every VS project will have a simple name and unique name.

  • Simple name: the project name as displayed in the Solution explorer. This is how we specify a project today in 1.1. As explained in the bug description, using simple names will fail in case two projects beloging to different solution folders share the same name.
  • Unique name (a.k.a fully-qualified name): this is the full path from solution root to the project including solution folders.

For example, for a solution with this structure:


The first ProjectA: simple name is ProjectA, unique name is Folder1\Folder2\ProjectA

ProjectB: simple name is ProjectB, unique name is Folder1\ProjectB

The second ProjectA: simple name is ProjectA, unique name is ProjectA.  In this case, simple name and unique name are the same.

So, in any case, you can always use the unique name to specify a project. That will always work.

On the other hand, if there is no ambiguity (i.e. no two projects with the same simple name), you can use simple name. Otherwise, you have to specify the unique name.

In the example above, you can refer to ProjectB either with simple name or unique name. Both of these will work:

install-package elmah -projectName 'ProjectB'

install-package elmah -projectName 'Folder1\ProjectB'

For the ProjectA inside Folder2, you have to use the unique name:

install-package elmah -projectName 'Folder1\Folder2\ProjectA'

And finllay for the ProjectA at the solution root, since both names are the same, you only have one choice:

install-package elmah -projectName 'ProjectA'

Questions or suggestions?

Feb 20, 2011 at 6:21 AM

Sounds good to me!

Feb 20, 2011 at 6:24 AM
Edited Feb 20, 2011 at 7:22 AM

One thing I should add is that the Default Project dropdown box on the console toolbar will be smart enough to show unconflicting names. It will try to show simple names if possible. If there are conflicts, it will fallback to unique names.

Feb 20, 2011 at 8:36 AM

Another thing is that for WebSite projects, unique name is always the same as simple name, even if it's nested inside solution folders. This is because WebSite projects use the full solution folder as the Name property, which is always unique.

Feb 20, 2011 at 5:08 PM

Can you give an example of names for web sites?

Feb 20, 2011 at 6:13 PM

Names of web sites are the full path to the folder containing its files. If you create a website in VS, you'll see the full path in the Solution explorer. That's the name.

Feb 20, 2011 at 6:27 PM

Don't forget about piping. i.e.

Get-Project -All | Install-Package elmah

Feb 20, 2011 at 7:07 PM

If we want piping to work, we have to make change so that it pipe on unique name, or pipe on the whole Project object.

Feb 20, 2011 at 7:16 PM
Your really ought to be able to pass along whole Project objects. This is the way a lot of the file I/O operations work in PowerShell: they accept both string filenames as well as FileInfo/DirectoryInfo objects.
Feb 20, 2011 at 7:44 PM

Totally agree with brad. I commented on the review for this.

Feb 21, 2011 at 4:25 PM

I assume we are keeping the -ProjectName and just changing the form of the name string it accepts?

Feb 21, 2011 at 5:44 PM

Yes, we'll keep the -ProjectName parameter and in the Types.ps1xml, I'll change the ProjectName property to a CodeProperty which returns a safe name. It is currently aliased to Name.

In the end, we're not introducing breaking change and still keep the pipelining work.

Note that pipeline on object is a different feature and I'm not addressing that in this change.

Feb 21, 2011 at 7:07 PM

I guess the only thing that changes now is how you need to wildcard a project name with get-project. Previously, get-project foo* would find a\b\foobar. Am I right in saying that now you'd need: get-project *foo*  ?