Home: dotnet pack does not support title in .csproj

[joelverhagen]

Using VS 2017 RC obtained from web, I am specify all of the .nuspec metadata I care about except <title>. Are there plans to support this in dotnet pack of a .csproj?

[rohit21agrawal]

@joelverhagen we decided not to support title in csproj. is there a reason you need it ?

[joelverhagen]

It's a first class property in NuGet.

I have a package with a title that is different than the ID. This is a pretty common scenario.

Newtonsoft.Json
Json.Net

[rohit21agrawal]

@rrelyea if we want to fix this, we should fix this in 4.0 itself.

[rohit21agrawal]

moving this to 4.0 RTM milestone to make it more visible for discussion.

[joelverhagen]

I think we should only phase this out after we have phased it out of all user experiences. In particular, nuget.org shows title in search results, so this is a very visible field. I did some analysis of the top 100 packages on nuget.org.

. | Exact match | Difference casing | Different
----------|-----------------|------------------------|----------------------------------------------
Count | 43 | 1 | 56
1st | EntityFramework | angularjs
AngularJS | Newtonsoft.Json
Json.NET
2nd | NUnit | | bootstrap
Bootstrap CSS
3rd | jQuery | | Microsoft.AspNet.Mvc
Microsoft ASP.NET MVC

Exact match means the ID and title are exactly the same.
Difference casing means the ID and title only different on casing.
Different means the ID is different than the title.

If more than half of our top packages are using title, we shouldn't eliminate it from tooling.

[rohit21agrawal]

i feel like what we are doing is a good first step..we continue to support title (and summary) in the following sccenarios :
1) nuget.exe pack legacy csproj
2) nuget.exe pack nuspec
3) dotnet.exe pack /p:NuspecFile="nuspec file"
4) msbuild /t:pack /p:NuspecFile="nuspec file"

The scenario for which we are eliminating it is:
1) dotnet.exe pack "package ref based csproj"
2) msbuild /t:pack "package ref based csproj"

People who want a mix of both worlds can use the intermediate generated nuspec file from their package referenced based projects and pack the nuspec with the title added to get the desired result.

This way we discourage people from using Title and make them follow the recommended convention of having ID the same as Title, but not essentially blocking anyone.

[joelverhagen]

The problem is that we have no telemetry or idea of how frequently users are packing .nuspec vs packing .csproj today. If we found that more than half of our users are using a feature, aren't we inadvertently discouraging users from moving to the new world if it doesn't have that feature?

Suppose we are designing the migration flow from packages.config to package reference. How would that migration work if the client has a package title?

People who want a mix of both worlds can use the intermediate generated nuspec file from their package referenced based projects and pack the nuspec with the title added to get the desired result.

Is this a well documented or polished experience? Are there basic knobs and switches that can be used so that customers don't have to make XML munging code on the intermediate .nuspec? If you are used to packing a legacy .csproj, is the "new world" going to be a lot more painful if you just want to set your package title?

I guess it seems strange to me to eliminate commonly used field when we a) have no documented high level design to phase out package title and b) the cost of implementing package title in package reference is very low.

Just spit-balling here, but the phase-out plan could be:

1. Warn during any pack when ID does not equal title.
2. Show ID on nuget.org instead of title.
3. Blog about the phase out and receive customer feedback.

[clairernovotny]

I'm not sure Title should be phased out at all. There needs to be something other than package id that shows what the package is and give it a friendly name. This is a regression from project.json support too.

All of Rx.NET does this.

Package Id: System.Reactive, Title: Reactive Extensions (Rx) - Main Library
Package Id: System.Reactive.Core, Title: Reactive Extensions - Core Library
etc.

Another:
Portable.BouncyCastle, Title= Bouncy Castle PCL

Title needs to be a first-class experience and cannot be phased out. Package Id is simply not enough.

[Mpdreamz]

@rohit21agrawal in the interest of learning why is having the same title and id a recommended convention? I use title for friendly human readable names and agree with @onovotny id alone is not enough.

[jamesmontemagno]

Ever since Title stopped being the main result in the NuGet Package manager things have gotten really confusing. Often my package IDs are short or legacy such as "Xam.Plugin.Connectivity" when the Title is "Connectivity Plugin for Xamarin", which is what makes sense. The UI should simply just show the title and the package name under it. Seems like an extremely easy improvement.

[clairernovotny]

@jamesmontemagno I agree. The title needs to be added to the results on the GUI, not removed.

[stefandevo]

This is a no brainer. Don't understand that it's even considered...

[ghuntley]

I'm with @onovotny. Please don't drop title.

[rrelyea]

plan is to bring back title...leaving summary and owners out.
and then communicate the long term plan for id/title, etc...and get feedback on that plan.

[rohit21agrawal]

CC: @onovotny

[axelheer]

If my description is tool long, I get build warnings, which tell me to add a (shorter) summary. But I cannot add a summary, because there seems to be no plans to support that any more.

That doesn't make any sense. Does it?

[delphyne]

which version of dotnet will include the changes? 2.0.7 released 2 days ago doesn't seem to include the fix.