Create a new Microsoft.DotNet.SharedFramework.Sdk for creating shared frameworks #5714

jkoritzinsky · 2020-06-26T17:44:42Z

Create a new shared framework SDK + 2 NuGet packages that can fully replace the Microsoft.DotNet.Build.Tasks.SharedFramework SDK as well as ASP.NET Core's custom shared framework construction tooling.

The Microsoft.DotNet.SharedFramework.Sdk can produce the following:

Runtime pack NuGet packages
Targeting pack NuGet packages
AppHost pack NuGet packages
"Tool" packs to enable custom pack-based packaging scenarios

The Microsoft.DotNet.Build.Tasks.Archives package can produce the following:

Zip/Tar archives for the above that binplace files into the correct locations from the root of a dotnet installation.

The Microsoft.DotNet.Build.Tasks.Installers package can produce the following:

MSI installers for the above
Deb and Rpm installers for the above
Pkg installers for the above
Exe and Pkg bundle installers for bundling multiple MSIs and Pkgs respectively into a single installer.

Example usages of this SDK and related packages are in dotnet/windowsdesktop#909 and dotnet/runtime#38457.

TODO:

SDK documentation
FileVersion validation for files in a runtime pack.
Type closure validation

Fixes #2704

Start working on a new SharedFramework SDK tooling story to unify between the dotnet/runtime, dotnet/windowsdesktop, and dotnet/aspnetcore shared framework authoring stories. After ReadyToRun, filter the itemgroup down to the files to bundle in the shared framework. Produce deps.json file for the shared framework. Various fixes found through local testing. Add support for resource assemblies. Fix multi-rid build. Fix typo Produce runtimeconfig.json. Copy over the CreateFrameworkListFile task to enable writing a FrameworkList.xml or RuntimeList.xml for their respective shared framework packs. Require the consumer to provide a package overrides file since all known customers already have their own mechanism to supply one. Implement templated platform manifest generation. Remove unused static. Re-enable publishing R2R symbols. Use GetFilesToPackage classifications for AppHost packs as well. Ensure that we don't include our generated files in the platform manifest check. Clean up error handling in GeneratePlatformManifestEntriesFromTemplate. Implement harvesting platform manifest support so shared frameworks that can use it don't need to use the templating approach. Implement dumping the completed shared framework to disk. Add back acquiring NuGet since we're going to need that when producing packages. Implement creating a compressed archive of the shared framework based on the on-disk layout. Output archive to packages. Implement packing a shared framework using the .NET SDKs packing infra. Package symbol files in the symbol package. Implement conditionally creating a symbols archive. Copy over targets from the old shared framework SDK and enable opt-in generation of .msi installers. Additional cleanup and validation TBD. Update deb, rpm, pkg paths to depend on the correct variables. Update cross-arch msi builds to work in the new system. Convert installer targets to be a recursive setup to enable building multiple types of packages from one build. Wire up installer generation to the build. Set GenerateInstallers to true to generate installers for the platform. Add ability to pass scripts to the macOS pkgbuild invocation. Fix shared framework name. Update creating the VS insertion packages. Batch up the installer build project calls instead of serially calling MSBuild. Fix RPM targets enough to get to the rpmbuild invocation. Make some progress on producing deb packages with dotnet-deb-tool to validate the targets flow. Fix typo. Also, building .deb packages works! (WSL->Windows drives apparently can have issues) Move the underlying scripts of dotnet-deb-tool into the shared framework SDK. Include RPM template files in the SDK. Remove the package testing files. Fix packing. Fix installer versioning and naming. Change many of the private installer properties to be prefixed with an underscore to make it easier to understand which properties are private. Fix light command package drop location. Enable adding dependencies for debs and rpms created with the built-in infra. Allow a different name for installers vs the archive. Make Wix exe bundles buildable. Fix product band version wix variable. Implement MacOS bundle proj. Various fixes to get to the point of building packages in dotnet/windowsdesktop. Fix building installers for targeting packs. Fix VS insertion package generation. Fix wix acquisition Filter symbol files out of the implementation package. Fix binplacing of resource files when publishing to disk. Fix Wix installer branding. Remove outdated todo Enable servicing and rid-based skipping in the same (for servicing) or similar (for RIDs) mechanism as the old shared framework sdk. Avoid re-evaluating when calling into the PublishSharedFrameworkToDisk target to avoid parallel copy issues and reduce the amount of work MSBuild has to do. Hook in package label versioning with the Arcade versioning story. Remove completed TODO Pass through RepoRoot so Arcade doesn't try to find it from the package cache. Various fixes around templated manifests and symbol file discovery/packaging. Fix issues found when packaging the .NET runtime shared framework. Use MSBuild to automatically determine the relative path for symbols instead of requiring it to be manually updated. Implement changes needed to support the shared host installer. Enable features for building the hostfxr and host installers. Update branding. Preliminary fixes for the bundle installer. Detect perfmap files as symbol files. Make sure we publish to disk before building our deb/rpms. Enhance build invocation caching to also cache R2R and auxiliary file generation so each build only runs each target once. This removes instabiility with attempts to ready-to-run the shared framework simultaneously by enabling the MSBuild scheduler to only execute the targets once. Fix typos in macos bundle creation. Actually write the distribution file to disk. Pass brand name instead of shared framework friendly name.

…d-sharedfx-sdk

…Installer and bundle generation docs still TBD.

jkoritzinsky · 2020-07-02T18:15:42Z

cc: @NikolaMilosavljevic for review

src/Microsoft.DotNet.SharedFramework.Sdk/Microsoft.DotNet.SharedFramework.Sdk.csproj

src/Microsoft.DotNet.SharedFramework.Sdk/README.md

ericstj · 2020-07-03T06:04:53Z

src/Microsoft.DotNet.SharedFramework.Sdk/README.md

+    or have an easily calculatable assembly version and file version.
+- All native files have an easily calculatable file version.
+
+To use, set `UseTemplatedPlatformManifes`t to true and define a set of `PlatformManifestFileEntry` items


Would it be possible for a hybrid where we only list the items which are unique and let common items be harvested? If we did this and validated it it, that might eliminate the need for explicit selection of modes.

I'm not sure what you mean here. Do you mean that we harvest the files from the targeting pack and then template the rest? Or that we harvest from whatever platform we're on and use the template as a baseline for the missing files?

I'm slightly concerned about both of those options. I prefer the design of either being fully implicit (harvest the runtime packs) or fully explicit (templating). I fear allowing a mix of the two might cause some of the data to be generated inconsistently depending on which platform you build the ref pack on (in particular with file versions).

Basically I'm thinking how we might allow harvesting without needing every single runtime available while minimizing the checked in template (which presumably needs to define versions and some way to calculate them). I'm not worried about inconsistency since anything with the template must be an accurate representation of the actual content.

So there's a process to defining versions for files:

By default, if a file is in the ref pack, we assume that the runtime pack will have the same version.

The developer can specify a fallback assembly or file version if any items don't have versions and need to have assembly or file versions.

The developer can specify versions for specific files if they aren't present in the ref pack.

The other reason to avoid harvesting is that harvesting more than just the current target platform is not compatible with source-build to my knowledge. And since we don't need file versions or assembly versions for native files on non-Windows, harvesting on non-Windows only isn't worth it IMO.

ericstj

only about 1/3 through this. but need to take a break

ericstj · 2020-07-03T06:10:41Z

src/Microsoft.DotNet.SharedFramework.Sdk/src/CreateFrameworkListFile.cs

+        /// %(ReferencedByDefault): Empty (default) or "true"/"false". Indicates whether this file
+        ///   should be referenced by default when the SDK uses this framework.
+        /// </summary>
+        public ITaskItem[] FileClassifications { get; set; }


Is it more natural to express this as metatdata on the Files or using a separate item that needs to be mapped to those files?

It's more natural to specify this in a separate set of items. The FilesToPackage item group can be generated from Reference, PackageReference, ProjectReference, or any other mechanism to reference assemblies that are not part of a framework dependency. As a result, there's no good way to modify those items after resolution and before this target. We could use a <JoinItems /> task to join the lists together into a single list of items, but I don't think that gives much in addition to just passing the two lists into CreateFrameworkListFile directly.

I see, Reference and Project reference should preserve metadata on the original item, but PackageReference does not. I'm mainly thinking about how we minimize the duplication in checked in projects. The more times we require devs to duplicate file lists, the more chance there is that folks get it wrong or out of sync.

src/Microsoft.DotNet.SharedFramework.Sdk/src/FileUtilities.cs

src/Microsoft.DotNet.SharedFramework.Sdk/src/CreateFrameworkListFile.cs

src/Microsoft.DotNet.SharedFramework.Sdk/src/CreateLightCommandPackageDrop.cs

src/Microsoft.DotNet.SharedFramework.Sdk/src/ExecWithRetries.cs

dagood · 2020-07-06T17:01:53Z

I don't think I can spend the time to do a full review, but a couple things:

It's hard to tell what's new in this SDK vs. the old one. The usage PRs are interesting but it's not clear what the high-impact changes are.
It's hard to tell which bits of the new SDK are actually new vs. copied code, in this particular PR.
How much asset validation have you done with this? Diffing extracted artifacts, decompiled WiX files, RPM/Deb metadata, nupkg content, etc.?

NikolaMilosavljevic · 2020-07-06T17:08:17Z

I don't think I can spend the time to do a full review, but a couple things:

It's hard to tell what's new in this SDK vs. the old one. The usage PRs are interesting but it's not clear what the high-impact changes are.

It's hard to tell which bits of the new SDK are actually new vs. copied code, in this particular PR.

How much asset validation have you done with this? Diffing extracted artifacts, decompiled WiX files, RPM/Deb metadata, nupkg content, etc.?

I echo Davis' comment. I have cloned the source repo to do some diffing locally.

I think a better approach would have been to first commit the copy of the old SDK, and then send a new PR with actual changes.

dagood · 2020-07-06T17:12:11Z

3. How much asset validation have you done with this? Diffing extracted artifacts, decompiled WiX files, RPM/Deb metadata, nupkg content, etc.?

I have some rudimentary tooling at https://devdiv.visualstudio.com/Personal/_git/dagood?path=%2FVstsTools%2FCompareBuildOutputs%2FProgram.cs that might be able to help with nupkg and WiX compares--it has some fiddling to remove some "unstable" strings to make diffs a bit cleaner. (And it runs in parallel--I had a powershell script earlier but it was agonizingly slow.) Note that the source code has been in flux depending on what I was comparing at the time, so it might not be directly useful.

jkoritzinsky · 2020-07-06T17:17:18Z

I don't think I can spend the time to do a full review, but a couple things:

It's hard to tell what's new in this SDK vs. the old one. The usage PRs are interesting but it's not clear what the high-impact changes are.

It's hard to tell which bits of the new SDK are actually new vs. copied code, in this particular PR.

The sharefx.props/targets files are completely new and encompass archive creation as well as . Any tasks with the same name as in the old SDK are identical. The installer.targets file is a stripped down version of the old SDK's installer.targets file. The Windows path of bundle.targets is pulled from the old SDK's installer.targets. The macOS path of bundle.targets is completely new. The wix.targets and the acquisition folder are copied from the old SDK with some minor changes around which properties are public and which are "private".

The installer targets workflow has changed to fan out for installer builds and call into the PublishSharedFrameworkToDirectory target instead of using a single invocation to make it clear which type of package is being built when.

How much asset validation have you done with this? Diffing extracted artifacts, decompiled WiX files, RPM/Deb metadata, nupkg content, etc.?

I've validated the NuGet package metadata, NuGet file list and location in the package, and archive layout. I've also checked the RPM/Deb metadata and file lists to ensure they match the packages currently produced in CI. I've also manually installed a few of the Wix MSIs to validate their install/uninstall experience and their entries in the Add/Remove Programs view. I've started the exe bundle installers to validate that they are correctly branded. I've validated that all inputs to pkgbuild and productbuild on macOS are identical to the invocations currently on dotnet/runtime's master branch CI.

I think a better approach would have been to first commit the copy of the old SDK, and then send a new PR with actual changes.

The original approach I took with this SDK was to start from scratch until I realized I needed to also copy over all of the installer generation, so the old SDK kind of came over piecemeal.

jkoritzinsky · 2020-07-06T17:29:26Z

The sharedfx.targets are designed to do the following steps:

ReadyToRun the managed assemblies.
- Done via the built-in R2R targets.
Generate the .deps.json file.
- Done via a new custom target and task.
Generate the FrameworkList.xml, RuntimeList.xml
- This reuses the old shared framework SDK task to do the work.
Generate the PlatformManifest.txt
- This is new and has two options.
  - Harvesting based on a runtime pack project
  - Templating based on a set of MSBuild items
Generate PackageOverrides.txt
- The SDK allows the user to provide it since every repo does it differently.
Generate the NuGet package
- The SDK uses the built-in targets to generate the package.
Generate the Shared framework archive and the shared framework symbols archive
- The SDK uses targets copied from the old SDK, but updates the .zip path to use the built-in ZipDirectory target instead of a custom target.

…only projects can also generate archives.

Add PackageTargetOS property for the dotnet-runtime-deps packages to hook in to.

…argeting files).

dougbu

I don't have a solid idea how dotnet/aspnetcore would use this other than to read all the docs, add the packages, and iterate. Are there any repos where you've got branches using the new stuff❔

We also have many more urgent infrastructure issues than changing how we create shared Fx and targeting pack assets. It'll be a few months before we have resources available to really think about this.

dougbu · 2020-08-22T01:23:21Z

src/Microsoft.DotNet.Build.Tasks.Archives/README.md

+
+## Build Skip Support for Unsupported Platforms and Servicing
+
+This SDK also supports automatically skipping builds on unsupported platforms or in servicing releases. If a project with a list of provided RIDs in `RuntimeIdentifiers` is built with the `RuntimeIdentifier` property set to a RID that is not in the `RuntimeIdentifiers` list, the build will be skipped. This enables cleanly skipping optional packs, installers, or bundles that only exist on specific platforms. 


If aspnetcore was going to use this, the "or in servicing releases" bit must be something we could override. We Zip both our shared Fx contributions and our targeting packs. The shared Fx Zips are produced unconditionally. And, we've had multiple 3.1.x releases that had to include updated targeting pack content.

It is implemented this way--that targeting pack vs. sharedfx behavior is universal. I think what I landed with in dotnet/runtime etc. is pretty nice if I may say so myself 😄:

https://github.com/dotnet/runtime/blob/e535e10f7ff66960ef3552794fdfb81e028e8b5e/eng/Versions.props#L34-L51

 <ItemGroup>  <ProjectServicingConfiguration Include="Microsoft.NETCore.App.Ref" PatchVersion="0" /> </ItemGroup>

dougbu · 2020-08-22T01:28:09Z

src/Microsoft.DotNet.Build.Tasks.Archives/build/Microsoft.DotNet.Build.Tasks.Archives.targets

+  </Target>
+
+  <!--
+    The Microsoft build's per-package servicing policy conflicts with the source-build restrictions.


Sorry, what's "the Microsoft build"❔

If it matters, different repos have different incremental servicing policies e.g. dotnet/runtime services many packages individually while dotnet/aspnetcore only disables the targeting packs in most (wish it were all ☹️) servicing releases.

The Microsoft build is the one that Microsoft builds--the one that ends up on dot.net, NuGet.org, blob storage (dailies), etc.

Non-Microsoft builds would be the ones that Red Hat and Fedora do for their distros, based on source-build. And any other builds from source that we might not even know about.

Servicing differences are a known, significant issue. I wrote up a summary doc on the problem at https://github.com/dotnet/source-build/tree/release/3.1/Documentation/planning/nongranular-servicing-readiness with a proposal to add tests to validate that the Microsoft servicing behavior won't wreck the source-built product. (Not implemented.)

dougbu · 2020-08-22T01:35:28Z

src/Microsoft.DotNet.Build.Tasks.Archives/build/Microsoft.DotNet.Build.Tasks.Archives.targets

+    <Exec Command="tar -C '$(_OutputPathRoot)' -czf $(PackageOutputPath)/$(_ArchiveFileName).tar.gz ."
+          IgnoreExitCode="true"
+          IgnoreStandardErrorWarningFormat="true"
+          Condition="!$([MSBuild]::IsOSPlatform(Windows))"/>


dotnet/aspnetcore creates aspnetcore-targeting-pack-6.0.0-dev.tar.gz on Windows. We execute ./eng/scripts/InstallTar.ps1 on the CI to cover older versions of Windows (some don't include tar).

dagood

Do you have builds, in particular mock official builds, that you can link to? I think artifacts and binlogs would help a lot with review. (I only looked at superficial stuff with this review.)

dagood · 2020-08-24T15:08:14Z

src/Microsoft.DotNet.Build.Tasks.Archives/build/Microsoft.DotNet.Build.Tasks.Archives.targets

@@ -0,0 +1,121 @@
+<Project>
+  <Target Name="_GetCurrentProjectServicingConfiguration">


Why is this target and SetLastReleasedVersionForSourceBuild copied three times?

Since the Archives, Installer, and SharedFramework packages can all be used independently (and in dotnet/runtime they will be for the host installers and archives), they all need an implementation of the project servicing configuration check. I'd also be ok adding these targets to the Arcade SDK so they're shared there and defined only once.

src/Microsoft.DotNet.Build.Tasks.Installers/build/Microsoft.DotNet.Build.Tasks.Installers.props

src/Microsoft.DotNet.Build.Tasks.Installers/build/installer.targets

src/Microsoft.DotNet.SharedFramework.Sdk/README.md

src/Microsoft.DotNet.SharedFramework.Sdk/src/GenerateSharedFrameworkDepsFile.cs

src/Microsoft.DotNet.SharedFramework.Sdk/src/Packaging/Extensions.cs

jkoritzinsky · 2020-08-24T18:14:26Z

I'll spin another mock official build. It's been a bit since I've run one and I'm pretty sure the last one I did got deleted.

jkoritzinsky · 2020-08-24T18:34:26Z

Official build running at:

~~https://dev.azure.com/dnceng/internal/_build/results?buildId=785257&view=results~~

New build with updates in the platform manifest for WebAssembly:

https://dev.azure.com/dnceng/internal/_build/results?buildId=785601&view=results

…ed on the referenced framework packs. Exclude culture assemblies from closure validation (otherwise we get duplicate assembly names).

…it (like the installers and archives packages) Signed-off-by: Jeremy Koritzinsky <[email protected]>

…TFX compat. Use more efficient publicKeyToken-to-string algorithm.

… into pr/jkoritzinsky/5714

ericstj

I skimmed most of the relevant tasks / targets that impact packaging. I can't really provide a full sign-off here, but I've left most of my feedback. Thank you for addressing my concerns.

src/Microsoft.DotNet.Build.Tasks.Archives/Microsoft.DotNet.Build.Tasks.Archives.csproj

src/Microsoft.DotNet.Build.Tasks.Installers/Microsoft.DotNet.Build.Tasks.Installers.csproj

src/Microsoft.DotNet.SharedFramework.Sdk/src/FileUtilities.cs

Signed-off-by: Jeremy Koritzinsky <[email protected]>

…ritzinsky/5714

SDK version 5.0.0-dev.20465.2

SDK version 5.0.0-dev.20465.3

jkoritzinsky · 2020-09-15T23:53:47Z

Per @NikolaMilosavljevic's suggestion, I've compared the MSIs produced in dotnet/runtime master against the MSIs produced in dotnet/runtime#38457 (which is the PR that uses this SDK) using Orca.

I've validated that the Directory and Registry tables match completely and that the Component and File tables match to the expected level (some slight differences in the list of included files for the runtime pack since the current infra includes some .h files that were accidentally included). I've also checked the other tables and they all look identical to the level I can tell (some entries in Orca just say [Binary Data] so it's hard to tell if there are any diffs there).

…s packages like the old system for Microsoft.DotNet.Build.Tasks.SharedFramework.

NikolaMilosavljevic

The amount of changes is huge, with lots of files moved to new locations and quite a bit of refactoring. Based on extensive discussions about design and various implementation details, and your validations of produced packages, I am signing off on this work.

ViktorHofer · 2020-10-09T17:09:39Z

Merging as Arcade branched-off for 5.0.

jkoritzinsky force-pushed the unified-sharedfx-sdk branch from 5bc7da4 to 72181d3 Compare June 29, 2020 16:29

jkoritzinsky added 3 commits June 29, 2020 09:29

Merge branch 'master' of https://github.com/dotnet/arcade into unifie…

444612d

…d-sharedfx-sdk

Port dotnet#5688 to the new SDK.

6399975

Update readme with documentation of the shared framework generation. …

452628d

…Installer and bundle generation docs still TBD.

ericstj requested review from Anipik and ericstj July 1, 2020 16:51

jkoritzinsky added 3 commits July 1, 2020 10:47

Add back feature that was somehow lost in the rebase.

564617d

Add basic docs for the installer builds.

97dd8ab

Finish documentation.

4f6c956

jkoritzinsky mentioned this pull request Jul 2, 2020

Create targets and tasks for authoring a shared framework #2704

Closed

ericstj reviewed Jul 3, 2020

View reviewed changes

src/Microsoft.DotNet.SharedFramework.Sdk/Microsoft.DotNet.SharedFramework.Sdk.csproj Outdated Show resolved Hide resolved

ericstj reviewed Jul 3, 2020

View reviewed changes

src/Microsoft.DotNet.SharedFramework.Sdk/README.md Show resolved Hide resolved

ericstj reviewed Jul 3, 2020

View reviewed changes

NikolaMilosavljevic requested review from dagood and NikolaMilosavljevic July 6, 2020 16:44

dagood removed their request for review July 6, 2020 17:06

jkoritzinsky added 6 commits July 15, 2020 11:12

Update host file names to be overridable to support the crossgen2 pack.

a20bef3

Fix GeneratedBuildFile check in GenerateSharedFrameworkDepsFile

346b896

Split out the archive targets from the sharedfx targets so installer-…

18ab7fd

…only projects can also generate archives.

Fix error condition.

30bd1c8

Version 5.0.0-dev.20365.8

8ace30a

Add PackageTargetOS property for the dotnet-runtime-deps packages to hook in to.

Only include runtime files in the deps file (not tool files or crosst…

81bd869

…argeting files).

dougbu reviewed Aug 22, 2020

View reviewed changes

dagood reviewed Aug 24, 2020

View reviewed changes

jkoritzinsky added 2 commits August 24, 2020 11:20

PR feedback.

bd6a7e3

Comments and var clarification.

304f667

jkoritzinsky mentioned this pull request Aug 26, 2020

[Signing][LC] Refactor WixToolsDir usage to explicitly set the directory from upstream projects #6038

Closed

jkoritzinsky added 3 commits August 26, 2020 17:29

Automatically calculate ignored references for closure validation bas…

840626f

…ed on the referenced framework packs. Exclude culture assemblies from closure validation (otherwise we get duplicate assembly names).

Set SelfContained to true when processing framework references.

80aee3c

Don't set BuildDependsOn to empty. It breaks packages that hook into …

a5c17c4

…it (like the installers and archives packages) Signed-off-by: Jeremy Koritzinsky <[email protected]>

This was referenced Aug 27, 2020

Switch to new Microsoft.DotNet.SharedFramework.Sdk dotnet/windowsdesktop#909

Merged

Enable VerifyClosure target to run independently of other validations #6101

Merged

ericstj requested a review from ViktorHofer September 11, 2020 19:21

jkoritzinsky added 3 commits September 11, 2020 14:00

Merge branch 'master' into unified-sharedfx-sdk

4165ccc

Use System.Reflection.Metadata to get the assembly name to ensure .NE…

93e0577

…TFX compat. Use more efficient publicKeyToken-to-string algorithm.

Merge branch 'unified-sharedfx-sdk' of github.com:jkoritzinsky/arcade…

b31c01f

… into pr/jkoritzinsky/5714

ericstj reviewed Sep 15, 2020

View reviewed changes

jkoritzinsky added 5 commits September 15, 2020 10:57

Rename folder to avoid warning

47b10a6

Remove unneeded NoWarn

a46fcaf

Signed-off-by: Jeremy Koritzinsky <[email protected]>

Merge branch 'master' of https://github.com/dotnet/arcade into pr/jko…

4543285

…ritzinsky/5714

React to changes in PrepareForReadyToRunCompilation.

6ece972

SDK version 5.0.0-dev.20465.2

Fix packaging non RuntimePack shared framework packs in msi installers.

9701071

SDK version 5.0.0-dev.20465.3

Enable overriding the targets and tasks for the installer and archive…

70819f2

…s packages like the old system for Microsoft.DotNet.Build.Tasks.SharedFramework.

NikolaMilosavljevic approved these changes Oct 2, 2020

View reviewed changes

ViktorHofer merged commit d1a58bc into dotnet:master Oct 9, 2020

jkoritzinsky deleted the unified-sharedfx-sdk branch October 9, 2020 17:06

jkoritzinsky mentioned this pull request Dec 7, 2020

Use file version instead of assembly version when setting file version. #6654

Merged

dagood mentioned this pull request Sep 14, 2021

Adding x64 emulation support for pkg installers #7893

Merged


		## Build Skip Support for Unsupported Platforms and Servicing

		This SDK also supports automatically skipping builds on unsupported platforms or in servicing releases. If a project with a list of provided RIDs in `RuntimeIdentifiers` is built with the `RuntimeIdentifier` property set to a RID that is not in the `RuntimeIdentifiers` list, the build will be skipped. This enables cleanly skipping optional packs, installers, or bundles that only exist on specific platforms.

		@@ -0,0 +1,121 @@
		<Project>
		<Target Name="_GetCurrentProjectServicingConfiguration">

Create a new Microsoft.DotNet.SharedFramework.Sdk for creating shared frameworks #5714

Create a new Microsoft.DotNet.SharedFramework.Sdk for creating shared frameworks #5714

Uh oh!

Conversation

jkoritzinsky commented Jun 26, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jkoritzinsky commented Jul 2, 2020

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ericstj left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

dagood commented Jul 6, 2020

Uh oh!

NikolaMilosavljevic commented Jul 6, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dagood commented Jul 6, 2020

Uh oh!

jkoritzinsky commented Jul 6, 2020

Uh oh!

jkoritzinsky commented Jul 6, 2020

Uh oh!

dougbu left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dagood Aug 24, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dagood left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jkoritzinsky commented Aug 24, 2020

Uh oh!

jkoritzinsky commented Aug 24, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ericstj left a comment

jkoritzinsky commented Jun 26, 2020 •

edited

Loading

NikolaMilosavljevic commented Jul 6, 2020 •

edited

Loading

dagood Aug 24, 2020 •

edited

Loading

dagood left a comment •

edited

Loading

jkoritzinsky commented Aug 24, 2020 •

edited

Loading