Skip to content

Automatic calculate the assembly and package version in servicing#57158

Merged
Anipik merged 8 commits intodotnet:mainfrom
Anipik:servicing2
Aug 12, 2021
Merged

Automatic calculate the assembly and package version in servicing#57158
Anipik merged 8 commits intodotnet:mainfrom
Anipik:servicing2

Conversation

@Anipik
Copy link
Contributor

@Anipik Anipik commented Aug 10, 2021

Fixes #46178

@ghost
Copy link

ghost commented Aug 10, 2021

Tagging subscribers to this area: @Anipik, @safern, @ViktorHofer
See info in area-owners.md if you want to be subscribed.

Issue Details

Fixes #46178

Author: Anipik
Assignees: -
Labels:

area-Infrastructure-libraries

Milestone: -

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>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 ?

Copy link
Member

@ViktorHofer ViktorHofer Aug 12, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@ghost
Copy link

ghost commented Aug 11, 2021

Hello @ViktorHofer!

Because this pull request has the auto-merge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

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 (@msftbot) and give me an instruction to get started! Learn more here.

@Anipik Anipik merged commit 4684a1d into dotnet:main Aug 12, 2021
@ghost ghost locked as resolved and limited conversation to collaborators Sep 11, 2021
@Anipik Anipik deleted the servicing2 branch November 10, 2021 18:58
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Automate the servicing process of packages

3 participants