Produce non-stable version of targeting pack #22372
Conversation
Pilchie
added
the
feature-platform
| <GenerateDocumentationFile>false</GenerateDocumentationFile> | ||
| <IncludeBuildOutput>false</IncludeBuildOutput> | ||
| <IncludeSymbols>false</IncludeSymbols> | ||
| <NoPackageAnalysis>true</NoPackageAnalysis> |
There was a problem hiding this comment.
Side question: Should this and the main Microsoft.AspNetCore.App.Ref project also set <IsReferenceAssemblyProject>false</IsReferenceAssemblyProject>❔ No urgency here and I'm not asking for a change in this PR but most of the special cases for $(IsReferenceAssemblyProject) projects are not necessary here (all but referencing reference assemblies). Probably better to put these in the $(IsImplementationProject) category (unless of course some of those special cases break things 😈).
There was a problem hiding this comment.
As far as I can tell, it shouldn't change how these projects build either way. Mostly it affects AssemblyVersions and compilation items, which don't apply here. There's a condition in versions.props that ensures that we use the .0 versions of CoreFx dependencies in ref projects, but it also checks for if the project is named Microsoft.AspNetCore.App.Ref, so either setting should be fine.
|
@dougbu I'm still going to separate the new proj into another folder, I just pushed my local changes to save them before I started doing branding. Returning to this now |
|
@dougbu this is now more "interesting" to review |
There was a problem hiding this comment.
Still approved but please run the updated layout by a few other people. I'm not sure which layout others would prefer and let's avoid shuffling things around a couple of weeks down the line. (My preference is to avoid special-cased ref/ projects that don't actually produce reference assemblies.)
|
@dougbu I reorganized the projects as you suggested. New internal build: https://dev.azure.com/dnceng/internal/_build/results?buildId=667319&view=results |
|
Something broke, the ref pack is missing lots of AspNetCore .dll's now (though it has the .xml files still). looking |
|
The build of the ref pack project now gives all AspNetCore ref assemblies the metadata |
|
Oh, got it - it's due to |
Those don't exist in this branch yet - @pranavkm after you merge the wasm -> 3.1 PR next week, I'll fix this guy up |
|
Alright, everything looks copacetic now |
Resolves #21850
Now that the targeting pack .msi has non-stable branding, we need to produce a package that identifies the version of that .msi so that dotnet/installer can know what to download. Note that we can't use some arbitrary nonshipping package from AspNetCore, since the targeting pack doesn't always build. Should be ported forwards to master also (and will require reaction in dotnet/installer's master branch)