Repository navigation
AssemblyInfo: Determine which properties will be generated and their msbuild mappings #2
Description
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.
Activity
[-]AssemblyInfo: Determine which properties will be generated and their msbuild mappins[/-][+]AssemblyInfo: Determine which properties will be generated and their msbuild mappings[/+]davkean commentedon Aug 1, 2016
See this gist: https://gist.github.com/harikmenon/ee72194925985ed7f4eb80b517972369
davkean commentedon Aug 8, 2016
@brthor, I and the NuGet team sat down together and came up with the following maps:
brthor commentedon Aug 9, 2016
Languageis 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 commentedon Aug 9, 2016
Ah yes, Language is programming language. Let's pick NeutralLanguage for now.
nguerrera commentedon Aug 16, 2016
@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 commentedon Aug 16, 2016
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 commentedon Aug 16, 2016
@brthor OK. Opened #57
mrward commentedon Sep 9, 2016
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 commentedon Sep 19, 2016
Is there any work left here? @brthor @nguerrera
brthor commentedon Sep 19, 2016
@rohit21agrawal Has there been a decision on the
PackageTypemapping?rohit21agrawal commentedon Sep 19, 2016
<PackageType>DotNetCliTool, 1.0.0.0;Dependency, 2.0.0.0</PackageType>brthor commentedon Sep 19, 2016
How can
PackageTypeto be inferred from a migrated project? Is it even possible? or should it always beDependencyrohit21agrawal commentedon Sep 19, 2016
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
15 remaining items
srivatsn commentedon Nov 21, 2016
Is there any work left here?
nguerrera commentedon Nov 21, 2016
I don't think so. Closing.
Merge pull request dotnet#2 from aspnet/targets
Adjust tests #2
# This is a combination of 3 commits.
Copilot implementation of new logic for stage 2 bundled versions
Apply code review feedback: shared workflows, runtime commands, globa…
Apply Round 3 code review feedback
Address PR review feedback on build duty skill
Trigger CI build #2 - streak: 1/25
Address review: fix ZeroTests, stream stdout, and unique wasm TRX name
[test] Fix duplicate runtime pack in `dotnet test` device deployment (#…