[One .NET] Initial workload support #5195

pjcollins · 2020-10-09T16:50:10Z

Context: https://github.com/dotnet/designs/blob/main/accepted/2020/workloads/workloads.md

A new Microsoft.NET.Workload.Android NuGet package has been added which
contains the WorkloadManifest.json and WorkloadManifest.targets files
required for the workload resolver.

The Microsoft.Android.Sdk NuGet package has been convered from an
MSBuild project SDK to an SDK workload pack. The most noticeable
difference in this change is that the Sdk.props import hook has been
replaced by an AutoImport.props file. The AutoImport.props file
should not set any MSBuild properties, and should only contain ItemGroup
glob behavior that can be modified by the main project file. The
AutoImport.props file included in Microsoft.Android.Sdk will be
imported by all project using Microsoft.NET.Sdk once workloads are
enabled by default. As a result, it is crucial that all of the content
in this file is conditionally included based on some Android specific
property value.

All other .props files from this repo which are included in the
Microsoft.Android.Sdk pack have been renamed to .targets files. This
was done to follow the convention that .props files are loaded before
the main project file, and .targets files are loaded after. The only
file that is loaded before the project file is AutoImport.props.

All One .NET tests have been updated to use the Microsoft.NET.Sdk
project SDK, rather than Microsoft.Android.Sdk. In order to support
this, a new /t:ExtractWorkloadPacks target has been added. This target
can be used with any .proj file in build-tools/create-packs/, and it is
responsible for extracting Microsoft.NET.Workload.Android,
Microsoft.Android.Sdk, and Microsoft.Android.Ref into our sandbox .NET
preview installation location. This target will also clean up any stale
Microsoft.Android.* packs that were previously installed.

The Xamarin.Android.Sdk.Lite package has been removed, as it continues
to be a bit of a headache to maintain moving forward. Old versions of
this package will continue to be available on the internal NuGet feed as
needed, however teams should soon be able to switch over to our workload
for their own dev/test efforts.

Finally, I've bumped the .NET Preview version to 5.0.100-rtm.20509.5.

build-tools/create-packs/Directory.Build.targets

build-tools/create-packs/Microsoft.Android.Workload.proj

...n.Android.Build.Tasks/Microsoft.Android.Sdk/targets/Microsoft.Android.Sdk.DefaultItems.props

dsplaisted · 2020-10-13T18:57:10Z

src/Xamarin.Android.Build.Tasks/Microsoft.Android.Sdk/targets/Microsoft.Android.Sdk.targets

+  <Import Project="Microsoft.Android.Sdk.BundledVersions.props" Condition=" Exists('Microsoft.Android.Sdk.BundledVersions.props') " />
+  <Import Project="Microsoft.Android.Sdk.SupportedPlatforms.props" />
  <Import Project="Microsoft.Android.Sdk.DefaultProperties.props" />
  <Import Project="$(MSBuildThisFileDirectory)..\tools\Xamarin.Android.Common.Debugging.props"
      Condition="Exists('$(MSBuildThisFileDirectory)..\tools\Xamarin.Android.Common.Debugging.props')"/>


Generally the pattern I expect is that .props files are imported before the body of a project file and .targets are imported afterwards. Importing .props files from a .targets file breaks this, and makes it harder to reason about which files will be included when the workload isn't active.

@dsplaisted Am I correct to assume that AutoImport.props is the only pre-project file import hook that workloads have access to? It probably makes sense for us to rename these to .targets files now since we no longer have an Sdk.props import hook, and we shouldn't be setting properties in AutoImport.props.

Is there a way a workload has a chance to set properties after the .csproj? We were setting $(ProduceReferenceAssembly) to false by default for "application" projects, as the reference assembly is somewhat useless. It needs to be set before Microsoft.NET.Sdk/Sdk.targets but depends on $(OutputType) set to Exe in the .csproj.

Likewise, I think we should set $(GenerateDependencyFile) to false? We don't need to generate a .deps.json file?

Is there a way a workload has a chance to set properties after the .csproj? We were setting $(ProduceReferenceAssembly) to false by default for "application" projects, as the reference assembly is somewhat useless. It needs to be set before Microsoft.NET.Sdk/Sdk.targets but depends on $(OutputType) set to Exe in the .csproj.

Likewise, I think we should set $(GenerateDependencyFile) to false? We don't need to generate a .deps.json file?

I discussed this a bit with @pjcollins, we may need to add another targets hook for this scenario.

I'm running into a similar scenario for Xamarin.iOS: we have to set the DebuggerSupport property before Microsoft.NET.Sdk is imported, but we need to know other properties in the user's csproj to know which value to set DebuggerSupport to.

...n.Android.Build.Tasks/Microsoft.Android.Sdk/targets/Microsoft.Android.Sdk.DefaultItems.props

Depends on: dotnet#5195 For .NET 6 Preview 1, we will need to provide our own installers for the Android workload. This will also unblock the Xamarin.Forms / MAUI team as they build on top of the iOS and Android workloads for .NET 6. We will eventually do some kind of "insertion" process to provide our `.nupkg` files to the dotnet/installer repo, so these installers will go away completely at some point. For now, this creates two new installers: * Microsoft.Android.Workload.msi - installs to `C:\Program Files\dotnet\` * Microsoft.Android.Workload.pkg - installs to `/usr/local/share/dotnet/` Both installers have the following file structure underneath the root directory: * sdk\5.0.100-rtm.20509.5\EnableWorkloadResolver.sentinel * sdk-manifests\5.0.100\Microsoft.Android.Workload\** * packs\Microsoft.Android.Ref\** * packs\Microsoft.Android.Sdk\** The installers will have a hard dependency on .NET 5.0.100-rtm.20509.5, so we will need to have clear instructions for installing the correct version of .NET for the Android workload. The Windows installer is made using WIX, to mirror what dotnet/installer is using: * https://wixtoolset.org/ * https://github.com/dotnet/installer/blob/861a1dd12cb80bd834d0e51442d46ee7d1a4023f/src/redist/targets/GenerateMSIs.targets For now, the `.msi` will need to be built on Windows and the `.pkg` will need to be built on macOS. `create-dotnet-msi.csproj` will download the WIX toolset to `~\android-toolchain\wix` and call `candle.exe` and `light.exe` appropriately. `create-dotnet-pkg.csproj` is based on `create-pkg.csproj`, and no additional tooling is needed.

dellis1972 · 2020-10-14T10:23:11Z

src/Xamarin.Android.Build.Tasks/Tests/Xamarin.ProjectTools/Android/XASdkProject.cs

 		public string PackageName { get; set; }
 		public string JavaPackageName { get; set; }

 		public XASdkProject (string outputType = "Exe")
 		{
-			Sdk = $"Microsoft.Android.Sdk/{SdkVersion}";


This might be a silly question. With the "old" system this {SdkVersion} was used to allow Nuget/MSbuild to find the SDK files in our local Nuget cache. How will this work with the new workload system, can it still look in the local cache? Or will it try to download things from nuget.org. What is going to happen on the bots when it's trying to install a new workload because our tests are requesting it. (I should probably read the spec for the workload stuff).

Do we need to be able to support both types of sdk? I'm thinking from a local development point of view.

Workloads won't automatically be downloaded from NuGet.org. They need to be installed. The version that is used is determined by the workload manifest, which the workload installation process should install or update.

For testing, you would want to "install" the workload you want to test. For now this basically means copying some files into the dotnet folder.

@dellis1972 I think we can migrate entirely away from the old MSBuild project SDK package. For local development, we are now installing a .NET 5 preview build into $(AndroidToolchainDirectory )/dotnet. This PR adds a new ExtractWorkloadPacks msbuild target to extract the relevant workload .nupkg files into this new .NET 5 installation path for tests running both locally and in CI to use.

For local dev/test efforts the following steps will prepare, build, pack .nupkgs, and install our workload components into the .NET 5 preview sandbox:

msbuild /t:Prepare Xamarin.Android.sln
msbuild /t:PackDotNet Xamarin.Android.sln
or
make jenkins
msbuild /t:CreateAllPacks,ExtractWorkloadPacks build-tools/create-packs/Microsoft.Android.Sdk.proj

This works for everything aside from runtime packs at the moment, those will still need to be pulled from some NuGet source. Our tests use this local source by default: https://github.com/xamarin/xamarin-android/blob/a7bda88d05b58efd26c17be3956c7140d05868e1/src/Xamarin.Android.Build.Tasks/Tests/Xamarin.ProjectTools/Common/XamarinProject.cs#L94

Eventually the work described in dotnet/sdk#14044 will allow us to install runtime packs into our .NET 5 sandbox and we shouldn't have to use NuGet feeds for anything.

@pjcollins wrote:

This PR adds a new ExtractWorkloadPacks msbuild target to extract the relevant workload .nupkg files into this new .NET 5 installation path for tests running both locally and in CI to use.

Does this mean that $(AndroidToolchainDirectory)\dotnet will be updated to include a copy of in-tree build artifacts as part of msbuild /t:PackDotNet?

If so, is there anything we should to to prevent "non-clean" environments in which $(AndroidToolchainDirectory)\dotnet contains "possibly corrupt" or "out-of-sync" file contents due to repeated invocations of msbuild /t:PackDotNet over time?

Then there's presumably the unit test scenario: won't msbuild /t:PackDotNet and an update of $(AndroidToolchainDirectory)\dotnet be required to run dotnet build-based unit tests?

I'm slightly concerned about the prospect of "corrupting" local dotnet installs which will necessitate nuking the $(AndroidToolchainDirectory)\dotnet directory, but I don't really have an alternative idea either. 😞

For the dotnet/sdk repo, we keep our testing environment separate. We have a "stage 0" copy of the .NET SDK which is installed under <REPO ROOT>\.dotnet. When we build the repo it creates a "stage 2" version of the .NET SDK in the output folder. That's what the tests run against.

We may be able to add some hooks which would allow you to set environment variables to point to local workloads without having to copy them into a dotnet install.

Does this mean that $(AndroidToolchainDirectory)\dotnet will be updated to include a copy of in-tree build artifacts as part of msbuild /t:PackDotNet?

Yes it does. /t:PackDotNet is a convenience target for the Windows build + smoke job, and for local dev. It effectively wraps Build, CreateAllPacks, and ExtractWorkloadPacks. The /t:CreateAllPacks target can still be used to create all of our .NET .nupkg files without also installing them into $(AndroidToolchainDirectory)\dotnet\packs. The macOS build job uses this target and will never try to install build artifacts into $(AndroidToolchainDirectory)\dotnet\packs.

We have a couple of steps which will clean out $(AndroidToolchainDirectory)\dotnet\packs to ensure that there are no stale workloads left behind whenever we try to "install" a new one.

/t:ExtractWorkloadPacks will delete all Microsoft.Android.* content in $(AndroidToolchainDirectory)\dotnet\packs, and

xaprepare deletes Android packs when ensuring that the correct version of .NET Preview is installed:
https://github.com/xamarin/xamarin-android/blob/master/build-tools/xaprepare/xaprepare/Steps/Step_InstallDotNetPreview.cs#L26

Then there's presumably the unit test scenario: won't msbuild /t:PackDotNet and an update of $(AndroidToolchainDirectory)\dotnet be required to run dotnet build-based unit tests?

For unit tests in CI, we download the .nupkgs artifact produced by the build job and then call the /t:ExtractWorkloadPacks to "install" them for our tests. We ensure a clean test state through both of the clean up mechanisms described above.

Depends on: dotnet#5195 For .NET 6 Preview 1, we will need to provide our own installers for the Android workload. This will also unblock the Xamarin.Forms / MAUI team as they build on top of the iOS and Android workloads for .NET 6. We will eventually do some kind of "insertion" process to provide our `.nupkg` files to the dotnet/installer repo, so these installers will go away completely at some point. For now, this creates two new installers: * Microsoft.Android.Workload.msi - installs to `C:\Program Files\dotnet\` * Microsoft.Android.Workload.pkg - installs to `/usr/local/share/dotnet/` Both installers have the following file structure underneath the root directory: * sdk\5.0.100-rtm.20509.5\EnableWorkloadResolver.sentinel * sdk-manifests\5.0.100\Microsoft.Android.Workload\** * packs\Microsoft.Android.Ref\** * packs\Microsoft.Android.Sdk\** The installers will have a hard dependency on .NET 5.0.100-rtm.20509.5, so we will need to have clear instructions for installing the correct version of .NET for the Android workload. The Windows installer is made using WIX, to mirror what dotnet/installer is using: * https://wixtoolset.org/ * https://github.com/dotnet/installer/blob/861a1dd12cb80bd834d0e51442d46ee7d1a4023f/src/redist/targets/GenerateMSIs.targets For now, the `.msi` will need to be built on Windows and the `.pkg` will need to be built on macOS. `create-dotnet-msi.csproj` will download the WIX toolset to `~\android-toolchain\wix` and call `candle.exe` and `light.exe` appropriately. `create-dotnet-pkg.csproj` is based on `create-pkg.csproj`, and no additional tooling is needed.

The ProjectCapability item group has been moved into `Microsoft.Android.Sdk.targets`. Certain `$(TargetPlatformIdentifier)` checks have also been removed as they are redundant. `Microsoft.Android.Sdk.targets` will only be imported when `'$(TargetPlatformIdentifier)' == 'Android'` is true.

We no longer have an `Sdk.props` import hook, and our .props files that are imported by Microsoft.Android.Sdk.targets should be renamed.

build-tools/create-packs/Directory.Build.targets

…tforms.targets

Depends on: dotnet#5195 For .NET 6 Preview 1, we will need to provide our own installers for the Android workload. This will also unblock the Xamarin.Forms / MAUI team as they build on top of the iOS and Android workloads for .NET 6. We will eventually do some kind of "insertion" process to provide our `.nupkg` files to the dotnet/installer repo, so these installers will go away completely at some point. For now, this creates two new installers: * Microsoft.Android.Workload.msi - installs to `C:\Program Files\dotnet\` * Microsoft.Android.Workload.pkg - installs to `/usr/local/share/dotnet/` Both installers have the following file structure underneath the root directory: * sdk\5.0.100-rtm.20509.5\EnableWorkloadResolver.sentinel * sdk-manifests\5.0.100\Microsoft.Android.Workload\** * packs\Microsoft.Android.Ref\** * packs\Microsoft.Android.Sdk\** The installers will have a hard dependency on .NET 5.0.100-rtm.20509.5, so we will need to have clear instructions for installing the correct version of .NET for the Android workload. The Windows installer is made using WIX, to mirror what dotnet/installer is using: * https://wixtoolset.org/ * https://github.com/dotnet/installer/blob/861a1dd12cb80bd834d0e51442d46ee7d1a4023f/src/redist/targets/GenerateMSIs.targets For now, the `.msi` will need to be built on Windows and the `.pkg` will need to be built on macOS. `create-dotnet-msi.csproj` will download the WIX toolset to `~\android-toolchain\wix` and call `candle.exe` and `light.exe` appropriately. `create-dotnet-pkg.csproj` is based on `create-pkg.csproj`, and no additional tooling is needed.

Context: dotnet/android#5195 Due to the way `<Import/>` ordering has changed with .NET 6 workloads, `$(AndroidApplication)` is not set until after NuGet packages have had their MSBuild targets evaluated. The result is `$(_AndroidXShouldRunMigration)` is blank, and AndroidX.Migration doesn't do any work. We noticed this happening in MSBuild tests using Xamarin.Forms.Maps. To solve this issue, we can check for `$(OutputType)` set to `Exe`, as this is what developers will set in their `.csproj` file. We may eventually get another MSBuild extension point from dotnet/sdk to make this possible to fix on the `xamarin-android`-side, but I think we can simply check both properties for now.

Depends on: dotnet#5195 For .NET 6 Preview 1, we will need to provide our own installers for the Android workload. This will also unblock the Xamarin.Forms / MAUI team as they build on top of the iOS and Android workloads for .NET 6. We will eventually do some kind of "insertion" process to provide our `.nupkg` files to the dotnet/installer repo, so these installers will go away completely at some point. For now, this creates two new installers: * Microsoft.Android.Workload.msi - installs to `C:\Program Files\dotnet\` * Microsoft.Android.Workload.pkg - installs to `/usr/local/share/dotnet/` Both installers have the following file structure underneath the root directory: * sdk\5.0.100-rtm.20509.5\EnableWorkloadResolver.sentinel * sdk-manifests\5.0.100\Microsoft.Android.Workload\** * packs\Microsoft.Android.Ref\** * packs\Microsoft.Android.Sdk\** The installers will have a hard dependency on .NET 5.0.100-rtm.20509.5, so we will need to have clear instructions for installing the correct version of .NET for the Android workload. The Windows installer is made using WIX, to mirror what dotnet/installer is using: * https://wixtoolset.org/ * https://github.com/dotnet/installer/blob/861a1dd12cb80bd834d0e51442d46ee7d1a4023f/src/redist/targets/GenerateMSIs.targets For now, the `.msi` will need to be built on Windows and the `.pkg` will need to be built on macOS. `create-dotnet-msi.csproj` will download the WIX toolset to `~\android-toolchain\wix` and call `candle.exe` and `light.exe` appropriately. `create-dotnet-pkg.csproj` is based on `create-pkg.csproj`, and no additional tooling is needed.

jonpryor · 2020-10-21T01:11:44Z

For review:

Context: https://github.com/dotnet/designs/blob/main/accepted/2020/workloads/workloads.md

Add a new Microsoft.NET.Workload.Android NuGet package which contains
the `WorkloadManifest.json` and `WorkloadManifest.targets` files
required for the [workload resolver][1].

The Microsoft.Android.Sdk NuGet package has been converted from an
[MSBuild project SDK][2] to an SDK workload pack.  The most noticeable
difference in this change is that the `Sdk.props` import hook has been
replaced by an `AutoImport.props` file.  The `AutoImport.props` file
should not set any MSBuild properties, and should only contain
ItemGroup glob behavior that can be modified by the main project file.
The `AutoImport.props` file included in Microsoft.Android.Sdk will be
imported by all project using Microsoft.NET.Sdk once workloads are
enabled by default.  As a result, it is crucial that all of the content
in this file be conditionally included based on some Android specific
property value; in this case, when `$(EnableDefaultAndroidItems)`=True.

All other `.props` files from this repo which are included in the
Microsoft.Android.Sdk pack have been renamed to `.targets` files.
This was done to follow the convention that `.props` files are loaded
before the main project file, and `.targets` files are loaded after.

The only file that is loaded before the project file is
`AutoImport.props`.

All One .NET tests have been updated to use the Microsoft.NET.Sdk
project SDK, rather than Microsoft.Android.Sdk.  In order to support
this, a new `/t:ExtractWorkloadPacks` target has been added.
This target can be used `build-tools/create-packs/*.proj`, and is
responsible for extracting Microsoft.NET.Workload.Android,
Microsoft.Android.Sdk, and Microsoft.Android.Ref into our sandbox .NET
preview installation location (cdc35b60).  This target will also clean
up any stale Microsoft.Android.* packs that were previously installed.

The Xamarin.Android.Sdk.Lite package has been removed, as it continues
to be a bit of a headache to maintain moving forward.  Old versions of
this package will continue to be available on the internal NuGet feed as
needed, however teams should soon be able to switch over to our workload
for their own dev/test efforts.

Finally, I've bumped the .NET Preview version to 5.0.100-rtm.20509.5.

[1]: https://github.com/dotnet/designs/blob/main/accepted/2020/workloads/workload-resolvers.md
[2]: https://docs.microsoft.com/en-us/visualstudio/msbuild/how-to-use-project-sdk

dsplaisted · 2020-10-21T02:05:22Z

🎉 🎉 🎉

Depends on: dotnet#5195 For .NET 6 Preview 1, we will need to provide our own installers for the Android workload. This will also unblock the Xamarin.Forms / MAUI team as they build on top of the iOS and Android workloads for .NET 6. We will eventually do some kind of "insertion" process to provide our `.nupkg` files to the dotnet/installer repo, so these installers will go away completely at some point. For now, this creates two new installers: * Microsoft.Android.Workload.msi - installs to `C:\Program Files\dotnet\` * Microsoft.Android.Workload.pkg - installs to `/usr/local/share/dotnet/` Both installers have the following file structure underneath the root directory: * sdk\5.0.100-rtm.20509.5\EnableWorkloadResolver.sentinel * sdk-manifests\5.0.100\Microsoft.Android.Workload\** * packs\Microsoft.Android.Ref\** * packs\Microsoft.Android.Sdk\** The installers will have a hard dependency on .NET 5.0.100-rtm.20509.5, so we will need to have clear instructions for installing the correct version of .NET for the Android workload. The Windows installer is made using WIX, to mirror what dotnet/installer is using: * https://wixtoolset.org/ * https://github.com/dotnet/installer/blob/861a1dd12cb80bd834d0e51442d46ee7d1a4023f/src/redist/targets/GenerateMSIs.targets For now, the `.msi` will need to be built on Windows and the `.pkg` will need to be built on macOS. `create-dotnet-msi.csproj` will download the WIX toolset to `~\android-toolchain\wix` and call `candle.exe` and `light.exe` appropriately. `create-dotnet-pkg.csproj` is based on `create-pkg.csproj`, and no additional tooling is needed.

Depends on: dotnet#5195 For .NET 6 Preview 1, we will need to provide our own installers for the Android workload. This will also unblock the Xamarin.Forms / MAUI team as they build on top of the iOS and Android workloads for .NET 6. We will eventually do some kind of "insertion" process to provide our `.nupkg` files to the dotnet/installer repo, so these installers will go away completely at some point. For now, this creates two new installers: * Microsoft.Android.Workload.msi - installs to `C:\Program Files\dotnet\` * Microsoft.Android.Workload.pkg - installs to `/usr/local/share/dotnet/` Both installers have the following file structure underneath the root directory: * sdk\5.0.100-rtm.20509.5\EnableWorkloadResolver.sentinel * sdk-manifests\5.0.100\Microsoft.Android.Workload\** * packs\Microsoft.Android.Ref\** * packs\Microsoft.Android.Sdk\** The installers will have a hard dependency on .NET 5.0.100-rtm.20509.5, so we will need to have clear instructions for installing the correct version of .NET for the Android workload. The Windows installer is made using WIX, to mirror what dotnet/installer is using: * https://wixtoolset.org/ * https://github.com/dotnet/installer/blob/861a1dd12cb80bd834d0e51442d46ee7d1a4023f/src/redist/targets/GenerateMSIs.targets The `.msi` will need to be built on Windows and the `.pkg` will need to be built on macOS. `create-dotnet-msi.csproj` will download the WIX toolset to `~\android-toolchain\wix` and call `candle.exe` and `light.exe` appropriately. `create-dotnet-pkg.csproj` is based on `create-pkg.csproj`, and no additional tooling is needed.

Depends on: dotnet#5195 For .NET 6 Preview 1, we will need to provide our own installers for the Android workload. This will also unblock the Xamarin.Forms / MAUI team as they build on top of the iOS and Android workloads for .NET 6. We will eventually do some kind of "insertion" process to provide our `.nupkg` files to the dotnet/installer repo, so these installers will go away completely at some point. For now, this creates two new installers: * Microsoft.Android.Workload.msi - installs to `C:\Program Files\dotnet\` * Microsoft.Android.Workload.pkg - installs to `/usr/local/share/dotnet/` Both installers have the following file structure underneath the root directory: * sdk\5.0.100-rtm.20509.5\EnableWorkloadResolver.sentinel * sdk-manifests\5.0.100\Microsoft.Android.Workload\** * packs\Microsoft.Android.Ref\** * packs\Microsoft.Android.Sdk\** The installers will have a hard dependency on .NET 5.0.100-rtm.20509.5, so we will need to have clear instructions for installing the correct version of .NET for the Android workload. The Windows installer is made using WIX, to mirror what dotnet/installer is using: * https://wixtoolset.org/ * https://github.com/dotnet/installer/blob/861a1dd12cb80bd834d0e51442d46ee7d1a4023f/src/redist/targets/GenerateMSIs.targets The `.msi` will need to be built on Windows and the `.pkg` will need to be built on macOS. `create-dotnet-msi.csproj` will download the WIX toolset to `~\android-toolchain\wix` and call `candle.exe` and `light.exe` appropriately. `create-dotnet-pkg.csproj` is based on `create-pkg.csproj`, and no additional tooling is needed. Changes to CI: * The `create-installers` make target now creates the .NET 6 `.pkg` installer. The `mac_build` stage creates one additional installer. * Any subsequent stages that download the `installers` artifact, now use a wildcard for the installer they need. This will improve some of the test stages that were downloading both the `.vsix` and `.pkg` installers before. * A `.NET 6 Preview Installers` Github status will appear that contains public download links for the new installers. * A `Build Results - .NET 6 Preview Installers` artifact will contain additional build logs.

pjcollins force-pushed the workload-playground branch from c8f1142 to dbda332 Compare October 9, 2020 21:44

jonathanpeppers reviewed Oct 12, 2020

View reviewed changes

build-tools/create-packs/Directory.Build.targets Show resolved Hide resolved

jonathanpeppers reviewed Oct 12, 2020

View reviewed changes

build-tools/create-packs/Directory.Build.targets Outdated Show resolved Hide resolved

pjcollins added 6 commits October 12, 2020 21:35

Initial workload drop

9effc6e

Update test project SDK import

3399ea5

Remove Xamarin.Android.Sdk.Lite

523f64b

Install workloads in CI

d2abf96

Update common properties and tests for new import ordering

746b4cd

Apply feedback and fix macOS executable extraction

67656d5

pjcollins force-pushed the workload-playground branch from ebfb6f9 to 67656d5 Compare October 13, 2020 01:35

rolfbjarne reviewed Oct 13, 2020

View reviewed changes

build-tools/create-packs/Microsoft.Android.Workload.proj Outdated Show resolved Hide resolved

Fix casing typo

42f6946

pjcollins marked this pull request as ready for review October 13, 2020 15:28

pjcollins requested review from dellis1972, grendello and jonpryor as code owners October 13, 2020 15:28

pjcollins changed the title ~~[WIP] Initial workload support~~ [One .NET] Initial workload support Oct 13, 2020

pjcollins commented Oct 13, 2020

View reviewed changes

...n.Android.Build.Tasks/Microsoft.Android.Sdk/targets/Microsoft.Android.Sdk.DefaultItems.props Outdated Show resolved Hide resolved

grendello approved these changes Oct 13, 2020

View reviewed changes

dsplaisted approved these changes Oct 13, 2020

View reviewed changes

dellis1972 reviewed Oct 14, 2020

View reviewed changes

pjcollins added 3 commits October 14, 2020 16:17

Rename .props files imported by Microsoft.Android.Sdk.targets

8324592

We no longer have an `Sdk.props` import hook, and our .props files that are imported by Microsoft.Android.Sdk.targets should be renamed.

Separate out workload cleanup target

c7fbffe

jonpryor reviewed Oct 14, 2020

View reviewed changes

build-tools/create-packs/Directory.Build.targets Outdated Show resolved Hide resolved

pjcollins added 2 commits October 14, 2020 16:55

Move $(TargetPlatformSupported) to Microsoft.Android.Sdk.SupportedPla…

6f1a0e4

…tforms.targets

Ensure relevant darwin _and_ linux workload files are executable

8ec2c0c

jonathanpeppers mentioned this pull request Oct 19, 2020

[One .NET] temporary Windows & macOS installers for .NET 6 #5225

Merged

jonathanpeppers approved these changes Oct 20, 2020

View reviewed changes

Rename workload to Microsoft.NET.Workload.Android

809ebf5

dellis1972 approved these changes Oct 20, 2020

View reviewed changes

pjcollins added 3 commits October 20, 2020 13:39

Clean up old workload pack name

052862a

Merge remote-tracking branch 'upstream/master' into workload-playground

545e524

Fix version miscalculation that can occur in PR builds

b2076e0

jonpryor merged commit 91498d5 into dotnet:master Oct 21, 2020

github-actions bot locked and limited conversation to collaborators Jan 24, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[One .NET] Initial workload support #5195

[One .NET] Initial workload support #5195

pjcollins commented Oct 9, 2020 •

edited

Loading

dsplaisted Oct 13, 2020

pjcollins Oct 13, 2020

jonathanpeppers Oct 13, 2020

dsplaisted Oct 13, 2020

rolfbjarne Oct 14, 2020

dellis1972 Oct 14, 2020

dsplaisted Oct 14, 2020

pjcollins Oct 14, 2020 •

edited

Loading

jonpryor Oct 14, 2020

dsplaisted Oct 14, 2020

pjcollins Oct 14, 2020 •

edited

Loading

jonpryor commented Oct 21, 2020

dsplaisted commented Oct 21, 2020

[One .NET] Initial workload support #5195

[One .NET] Initial workload support #5195

Conversation

pjcollins commented Oct 9, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pjcollins Oct 14, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pjcollins Oct 14, 2020 • edited Loading

Choose a reason for hiding this comment

jonpryor commented Oct 21, 2020

dsplaisted commented Oct 21, 2020

pjcollins commented Oct 9, 2020 •

edited

Loading

pjcollins Oct 14, 2020 •

edited

Loading

pjcollins Oct 14, 2020 •

edited

Loading