Aspnetcore: Emit ANCM version information as part of the build

[shirhatti]

In 2.2, we can modify the version of the produced internal ANCM package- https://github.com/dotnet/versions/blob/master/build-info/dotnet/product/cli/release/2.2/build.xml#L20
We'll need a new approach for 3.0 which @natemcmaster will help define.

[muratg]

@shirhatti What's the new approach you were thinking about?

@natemcmaster any thoughts on this?

[natemcmaster]

If it were me, I would just update the nuget package version on Microsoft.AspNetCore.AspNetCoreModuleV2 to match its actual version.

[shirhatti]

@leecow @vivmishra How should we emit ANCM version as part of the build?

[leecow]

I don't quite understand the question. From the release side, we need a way to know when an ANCM update is released to Antares (and VS?) and what that version will be. For every other component, the version is readily visible in the installer file names (eg aspnetcore-runtime-2.2.2-win-x86.exe).

[anurse]

I'm going to add value off the critical path by giving this a look ;).

[anurse]

@shirhatti wants this number: '12.2.19048.0' (not the literal number ;)) to flow through the build somehow.

[natemcmaster]

How is this number supposed to be used and where should it appear? Is this just for the sake of being able to find it in the future when we write ANCM security bulletins? Or is should this end up on https://dot.net or something? We don't have the equivalent of the unified build.xml anymore, and we also killed off a bunch of internal nuget packages, so there isn't an obious place to stuff this data.

[anurse]

@shirhatti can clarify where he wants the number to appear. The main thing he mentioned to me was having it clearly visible in the build output from our official CI.

One thought I have is that all our MSIs tend to have version numbers in them (for example aspnetcore-runtime-2.2.4-win-x64.msi) except ANCM (aspnetcoremodule_x64_en.msi). We'd have to change our setup authoring (the hosting bundle, etc.), but could we start by renaming our MSI to aspnetcoremodule-12.2.19048.0-x64.msi or something similar?

[shirhatti]

Here's where I want the version to appear- https://github.com/dotnet/core/blob/master/release-notes/3.0/releases.json#L200-L202

[shirhatti]

Based on @leecow's comment above I'm assuming @anurse's suggestion to have it in the msi name might suffice

[natemcmaster]

From the release side, we need a way to know when an ANCM update is released to Antares (and VS?) and what that version will be.

As long as the "way to know" doesn't need to be automated, sure, let's go with putting the version in the filename. Sounds like a simple, effective solution.

[anurse]

Ok, let's explore that option then. I may still look in to this myself in the preview 5 timeline, depending on if I get any free time ;P. Not going to schedule it based on that though :D

[anurse]

I want to walk this back a little bit, because the ANCM MSIs are only shipped via the Hosting Bundle, so renaming them may not actually resolve @shirhatti 's problem. If you're looking to make sure the releases.json file is updated, I think we need to know from @leecow how this file is updated.

[leecow]

Currently, versions in the releases.json begin life in a manually built config file used as input for the generator. This works fine for all other assets as the version is part of the on-disk file name. The ancm package is a bit inscrutable so something that brings the information closer to the surface would be a help.

[anurse]

Ok, so maybe the best option here (since the MSI is always hidden behind the hosting bundle) is to write a text file with the version and get that to "flow" through the build process as an artifact. I'll explore that option further.

[anurse]

Re-opening to track making sure this flows through all build phases and is backported (in some form) to 2.x

[anurse]

TODO:

• [x] 3.0: Produce aspnetcoremodule.version file in build output.
• [ ] 3.0: Flow this file to the final drop (https://github.com/aspnet/AspNetCore-Internal/issues/2439)
• [ ] 2.2: Produce aspnetcoremodule.version file in build output.
• [ ] 2.2: Flow this file to the final drop
• [ ] 2.1: Produce aspnetcoremodule.version file in build output.
• [ ] 2.1: Flow this file to the final drop

[anurse]

I've got some scripts to extract the version from the EXE coming together. Closing this issue now as it's not really work that needs to happen in this repo.