AssemblyInfo: Determine which properties will be generated and their msbuild mappings

[brthor]

In dotnet cli AssemblyInfo is generated during each build from properties present in the project.json file. MSBuild currently relies on a template generated or user created AssemblyInfo to be present.

For certain options which need to be present in the csproj for pack (or other mechanisms) to function, it doesn't make sense to require putting these in both the project and AssemblyInfo.cs. (e.g. language )

For this reason it makes sense to generate a subset of the assemblyinfo from the project during build, and leave the rest to be manually entered.

To do this we need to determine what the subset of AssemblyInfo is that we're generating and how they map to msbuild options.

[davkean]

See this gist: https://gist.github.com/harikmenon/ee72194925985ed7f4eb80b517972369

[davkean]

@brthor, I and the NuGet team sat down together and came up with the following maps:

Attribute/NuSpec value	Type	MSBuild Property	Default	Notes
AssemblyTitle	Attribute	AssemblyTitle	AssemblyName
AssemblyDescription	Attribute	N/A	Description
AssemblyConfiguration	Attribute	Configuration	Debug	Existing property
AssemblyCompany	Attribute	AssemblyCompany	Authors
AssemblyProduct	Attribute	Product	AssemblyName
AssemblyCopyright	Attribute	N/A	Copyright
AssemblyTrademark	Attribute	N/A	Not present	Developers can define attribute if they want to set it
AssemblyCulture	Attribute	N/A	Not present	Developers can define attribute if they want to set it
ComVisible	Attribute	N/A	Not present
Guid	Attribute	N/A	Not present	Developers can define attribute if they want to set it
NeutralResourcesLanguage	Attribute	NeutralLanguage
AssemblyInformationalVersion	Attribute	Version	1.0.0	Make note this is SemVer version (ie 1.0.0-beta1 is valid)
AssemblyVersion	Attribute	AssemblyVersion	Version (major.minor.patch components only)
AssemblyFileVersion	Attribute	FileVersion	major.minor.patch components only of Version
PackageId	NuSpec	PackageId	AssemblyName
PackageVersion	NuSpec	PackageVersion	Version
Authors	NuSpec	Authors	AssemblyName
Owners	NuSpec	N/A	Not present in NuSpec
Description	NuSpec	Description	empty
Copyright	NuSpec	Copyright	empty
Summary	NuSpec	N/A	Not present in NuSpec
RequireLicenseAcceptance	NuSpec	PackageRequireLicenseAcceptance	false
LicenseUrl	NuSpec	PackageLicenseUrl	empty
ProjectUrl	NuSpec	PackageProjectUrl	empty
IconUrl	NuSpec	PackageIconUrl	empty
Tags	NuSpec	PackageTags	empty
ReleaseNotes	NuSpec	PackageReleaseNotes	empty
RepositoryUrl	NuSpec	RepositoryUrl	empty
RepositoryType	NuSpec	RepositoryType	empty
PackageType	NuSpec	?		NuGet will go offline and figure out this design

EDIT: 10/17/2016 by eerhardt - Add $(AssemblyCompany) as the MSBuild property for AssemblyCompany.  There are plenty of cases where users want to define AssemblyCompany differently from their nupkg Authors.  CoreFX is the first place I've found: AssemblyCompany = "Microsoft Corporation", but Authors = "microsoft;aspnet;dotnetframework".
Also added Authors to be defaulted to "AssemblyName" so `dotnet pack` works by default.

[brthor]

Language is already used by the nuget.build.task to determine appropriate analyzers.

https://github.com/NuGet/NuGet.BuildTasks/blob/dev/src/Microsoft.NuGet.Build.Tasks/Microsoft.NuGet.targets#L145

https://github.com/Microsoft/msbuild/blob/master/src/XMakeTasks/Microsoft.CSharp.CurrentVersion.targets#L40

Perhaps NeutralLanguage?

[davkean]

Ah yes, Language is programming language. Let's pick NeutralLanguage for now.

[nguerrera]

@davkean, @brthor, @srivatsn: I'm going to look at generating the AssemblyInfo.cs. Should we morph this issue to track the task and targets changes, or should I create a new tracking issue? Seems like the original issue to come up with the set of mappings is done with the table above, right?

[brthor]

I think it makes sense to leave this issue independent from the tracking of generating the assembly info.

My reasoning is that I expect as you dig in to generating these things, you might find that some of the properties need to change and update this issue. I'll need to react to these changes in the migration tool. It'll be easier to recognize this with less noise on the issue.

[nguerrera]

@brthor OK. Opened #57

[mrward]

Are summary and owners no longer supported?

Summary is displayed by the NuGet UI in the package list if the NuGet package defines it instead of the description which can be a large amount of text.

[srivatsn]

Is there any work left here? @brthor @nguerrera

[brthor]

@rohit21agrawal Has there been a decision on the PackageType mapping?

[rohit21agrawal]

<PackageType>DotNetCliTool, 1.0.0.0;Dependency, 2.0.0.0</PackageType>

[brthor]

How can PackageType to be inferred from a migrated project? Is it even possible? or should it always be Dependency

[rohit21agrawal]

the default is to not have a package type, which the client deduces to be of type dependency. on the more finer details, @joelverhagen will have an answer

[rohit21agrawal]

@brthor @davkean @nguerrera what msbuild property should we default to for $(Authors) ? since it is a required property I don't think its good to keep it empty.

[joelverhagen]

Concerning package type:
Package type was never supported in dotnet pack. The story for producing it before was nuget.exe pack. Details here:
https://github.com/NuGet/Home/wiki/Package-Type-%5BPacking%5D#tool-creation

The bottom line is that it should only be mentioned anywhere (.nuspec or .csproj) if it's not the default (Dependency package type). Since it was never supported in dotnet pack, it shouldn't have to be supported in dotnet migrate.

Concerning defaulting authors to empty:
This is should be reconsidered since a) pack3 needs an author and b) dotnet migrate does not put a <Authors> in the resulting .csproj. From the user's perspective, this is a delta from dotnet pack (preview 2 tooling) since the <authors> baked into the produced package seems to have defaulted to the package ID.

[rrelyea]

authors question is both for migration and new projects.
we have a few options...including what "nuget spec" then "nuget pack" give...you get some default values, but pack warns that you have default values.

[brthor]

Ideally the $(Authors) property would be defaulted somewhere in the nuget targets so that migration or anything else only overrides the default rather than setting it.

Or is the thinking that it should be defaulted in the User's project file?

[eerhardt]

since the baked into the produced package seems to have defaulted to the package ID.

Correct. For project.json-based projects, the default author would be the name of the project:

https://github.com/dotnet/cli/blob/1278e9d6bf35500e9672fe3f53125df1d08717d8/src/dotnet/commands/dotnet-pack/PackageGenerator.cs#L381

@brthor is correct as well. The SDK targets should default $(Authors) if it isn't set.

[rohit21agrawal]

@eerhardt is there a bug tracking this in SDK?

[eerhardt]

is there a bug tracking this in SDK?

Outside of this one: no.

[srivatsn]

Is there any work left here?

[nguerrera]

I don't think so. Closing.