dotnet pack does not support title in .csproj #4150

Closed
joelverhagen opened this Issue Dec 26, 2016 · 17 comments

Comments

Projects
None yet
10 participants
@joelverhagen
Member

joelverhagen commented Dec 26, 2016

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?

@rrelyea rrelyea added this to the 4.0 RC3 milestone Dec 27, 2016

@rrelyea rrelyea modified the milestones: 4.0.1, 4.0 RC3 Jan 6, 2017

@rohit21agrawal

This comment has been minimized.

Show comment
Hide comment
@rohit21agrawal

rohit21agrawal Jan 14, 2017

Contributor

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

Contributor

rohit21agrawal commented Jan 14, 2017

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

@joelverhagen

This comment has been minimized.

Show comment
Hide comment
@joelverhagen

joelverhagen Jan 14, 2017

Member

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

Member

joelverhagen commented Jan 14, 2017

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 rohit21agrawal self-assigned this Jan 20, 2017

@rohit21agrawal

This comment has been minimized.

Show comment
Hide comment
@rohit21agrawal

rohit21agrawal Jan 20, 2017

Contributor

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

Contributor

rohit21agrawal commented Jan 20, 2017

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

@rohit21agrawal

This comment has been minimized.

Show comment
Hide comment
@rohit21agrawal

rohit21agrawal Jan 20, 2017

Contributor

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

Contributor

rohit21agrawal commented Jan 20, 2017

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

@rohit21agrawal rohit21agrawal modified the milestones: 4.0 RTM, 4.0.1 Jan 20, 2017

@joelverhagen

This comment has been minimized.

Show comment
Hide comment
@joelverhagen

joelverhagen Jan 20, 2017

Member

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.

Member

joelverhagen commented Jan 20, 2017

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

This comment has been minimized.

Show comment
Hide comment
@rohit21agrawal

rohit21agrawal Jan 20, 2017

Contributor

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.

Contributor

rohit21agrawal commented Jan 20, 2017

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

This comment has been minimized.

Show comment
Hide comment
@joelverhagen

joelverhagen Jan 20, 2017

Member

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.
Member

joelverhagen commented Jan 20, 2017

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.

@rohit21agrawal rohit21agrawal changed the title from dotnet pack does not support title attribute in .csproj to dotnet pack does not support title and summary attribute in .csproj Jan 23, 2017

@onovotny

This comment has been minimized.

Show comment
Hide comment
@onovotny

onovotny Jan 23, 2017

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.

onovotny commented Jan 23, 2017

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

This comment has been minimized.

Show comment
Hide comment
@Mpdreamz

Mpdreamz Jan 23, 2017

@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.

@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

This comment has been minimized.

Show comment
Hide comment
@jamesmontemagno

jamesmontemagno Jan 23, 2017

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.

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.

@onovotny

This comment has been minimized.

Show comment
Hide comment
@onovotny

onovotny Jan 23, 2017

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

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

@stefandevo

This comment has been minimized.

Show comment
Hide comment
@stefandevo

stefandevo Jan 23, 2017

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

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

@ghuntley

This comment has been minimized.

Show comment
Hide comment
@ghuntley

ghuntley Jan 24, 2017

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

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

@rrelyea

This comment has been minimized.

Show comment
Hide comment
@rrelyea

rrelyea Jan 24, 2017

Contributor

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.

Contributor

rrelyea commented Jan 24, 2017

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

This comment has been minimized.

Show comment
Hide comment
Contributor

rohit21agrawal commented Jan 24, 2017

CC: @onovotny

@rrelyea rrelyea changed the title from dotnet pack does not support title and summary attribute in .csproj to dotnet pack does not support title in .csproj Jan 26, 2017

@natemcmaster natemcmaster referenced this issue in dotnet/docs Feb 22, 2017

Merged

pj to csproj mapping #1581

@axelheer

This comment has been minimized.

Show comment
Hide comment
@axelheer

axelheer Feb 28, 2017

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?

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

This comment has been minimized.

Show comment
Hide comment
@delphyne

delphyne May 9, 2018

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

delphyne commented May 9, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment