Automatic calculate the assembly and package version in servicing#57158
Automatic calculate the assembly and package version in servicing#57158Anipik merged 8 commits intodotnet:mainfrom Anipik:servicing2
Conversation
|
Tagging subscribers to this area: @Anipik, @safern, @ViktorHofer Issue DetailsFixes #46178
|
…ilding the package in servicing
Co-authored-by: Viktor Hofer <viktor.hofer@microsoft.com>
| <IsWindowsDesktop Condition="$(WindowsDesktopCoreAppLibrary.Contains('$(AssemblyName);'))">true</IsWindowsDesktop> | ||
| <_AssemblyInTargetingPack Condition="'$(IsNETCoreAppSrc)' == 'true' or '$(IsAspNetCoreApp)' == 'true' or '$(IsWindowsDesktop)' == 'true'">true</_AssemblyInTargetingPack> | ||
| <!-- Assembly version do not get updated in non-netfx ref pack assemblies. --> | ||
| <AssemblyVersion Condition="'$(_AssemblyInTargetingPack)' != 'true' or '$(TargetFrameworkIdentifier)' == '.NETFramework'">$(MajorVersion).$(MinorVersion).0.$(ServicingVersion)</AssemblyVersion> |
There was a problem hiding this comment.
Shouldn't AssemblyVersion be set outside of this file so that it also applies to reference assemblies and source generators assemblies (the latter doesn't import this file as they aren't packable)?
There was a problem hiding this comment.
Shouldn't AssemblyVersion be set outside of this file so that it also applies to reference assemblies and source generators assemblies (the latter doesn't import this file as they aren't packable)?
we don`t need to update the reference assemblies as we never change them in servicing and anyway we are not shipping them in 6.0.
For generators assemblies, we will have to decide if we want to always increment with the package or only when we make a change in generator.
Shouldn't AssemblyVersion be set outside of this files
Instead i will suggest to add the packaging.targets file to analyzers as well. (using IsNETCoreAppAnalyzer property)
are any of the analyzers part of the shared framework ?
There was a problem hiding this comment.
are any of the analyzers part of the shared framework ?
Yes, the System.Text.Json one is part of the shared framework.
Instead i will suggest to add the packaging.targets file to analyzers as well. (using IsNETCoreAppAnalyzer property)
Analyzers aren't packable themselves so it doesn't make sense for them to import packaging.targets. The code in that file is specific to projects which pack. I would keep the PackageVersion property in packaging.props and move the AssemblyVersion sectionout and make sure that it applies to both source projects and analyzers.
For generators assemblies, we will have to decide if we want to always increment with the package or only when we make a change in generator.
My gut feeling says that we should keep the AssemblyVersion of source assemblies in sync with their source generators. For that we might need two more properties in NetCoreAppLibrary.props (btw we should change that file's name at some point): AspNetCoreAppAnalyzer and NetCoreAppAnalyzer.
There was a problem hiding this comment.
Putting more thought into this, I don't think that introducing properties for analyzers in NetCoreAppLibrary.props is necessary. It is probably easier to apply the same assembly version to both the source assembly and the analyzer assembly.
If the project is a generator project you would need to check if the "corresponding" source assembly is part of any shared framework.
There was a problem hiding this comment.
For now all existing source generators are shipping as part of a shared framework (either netcoreapp or aspnetcoreapp) so if this becomes to complicated to implement you might just ignore them for 6.0 and never increment their assembly version.
If you want to go down that path then your PR in its current state is probably sufficient.
|
Hello @ViktorHofer! Because this pull request has the p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (
|
Fixes #46178