xamarin
/
xamarin-macios
зеркало из
1
0
Форкнуть 0
Код Задачи Пакеты Проекты Релизы Вики Активность
xamarin-macios/dotnet/Makefile

428 строки
24 KiB
Makefile
Исходник Обычный вид История

Create and publish .NET NuGet packages. (#8576) Create the various NuGet packages to support .NET 5+. The packages are currently empty (and not very useful), but the actual content will come later. The current set of NuGet packages are (this list is duplicated for each platform: iOS, tvOS, watchOS and macOS): * Microsoft.iOS.Sdk: currently contains the basic MSBuild targets files for an MSBuild Project SDK. Will eventually contain all the build logic. Might also eventually contain other tools (mlaunch, bgen, etc.), but these might also end up in a different package. * Microsoft.iOS.Ref: will contain the Xamarin.iOS.dll reference assembly. * Microsoft.iOS.Runtime.[RID]: will contain architecture-specific files (libxamarin*.dylib, the Xamarin.iOS.dll implementation assembly, etc.): The NuGets built on CI are automatically published to a NuGet feed. The versioning for the NuGet packages required a few changes: OS bumps are now changed in Make.versions instead of Make.config (this is explained in the files themselves as well).
2020-05-13 16:23:29 +03:00
TOP = ..
include $(TOP)/Make.config
include $(TOP)/mk/rules.mk
[.NET] Rename several DOTNET6_* variables to to DOTNET_*. (#14463) Also rename DOTNET_VERSION to SYSTEM_DOTNET_VERSION to make it clear what it's referring to (and to not clash with DOTNET6_VERSION which has now been renamed to DOTNET_VERSION). .NET 7 is right around the corner.
2022-03-23 10:07:34 +03:00
DOTNET_MANIFESTS_PATH=$(DOTNET_DIR)/sdk-manifests/$(DOTNET_MANIFEST_VERSION_BAND)
DOTNET_PACKS_PATH=$(DOTNET_DIR)/packs
DOTNET_TEMPLATE_PACKS_PATH=$(DOTNET_DIR)/template-packs
[dotnet] Create Microsoft.<platform>.Bundle.pkg packages for installing workloads manually.
2020-10-15 12:45:36 +03:00
TMP_PKG_DIR=_pkg
[dotnet] Install our workloads into the dotnet directory (as symlinks).
2020-10-15 12:38:29 +03:00
[dotnet] Build & publish MacCatalyst packs. (#10624) * [dotnet] Build & publish MacCatalyst packs. * Add runtime support.
2021-02-12 09:38:43 +03:00
DOTNET_PLATFORMS_UPPERCASE:=$(shell echo $(DOTNET_PLATFORMS) | tr a-z A-Z)
[dotnet] Create a WorkloadManifest.json for each platform.
2020-10-15 12:35:03 +03:00
# Create variables prefixed with the correctly cased platform name from the upper-cased platform name. This makes some of the next sections somewhat simpler.
$(foreach platform,$(DOTNET_PLATFORMS),$(eval $(platform)_NUGET_VERSION_NO_METADATA:=$($(shell echo $(platform) | tr a-z A-Z)_NUGET_VERSION_NO_METADATA)))
[dotnet] Improve incremental builds in make. (#8754) * Be more exact when specifying dependencies for nuget packages: instead of making every package depend on every file within this directory, only make the specific package the files go into depend on those files. This means that if any of these files change, only the package that contains that file will be rebuilt. * Have each package depend on all the files that are to be included in that package. This means that if any other directory adds or updates a file for a nuget, we'll rebuild that nuget here. * Removes packages from the local feed before trying to (re-)add them. This makes them actually install locally, instead of nuget just skipping them, when the version hasn't changed. This was easier to express with make templates than pattern rules, so some of the logic was re-implemented as make templates.
2020-06-04 17:39:19 +03:00
define DefineTargets
$(1)_NUGET_TARGETS = \
[dotnet] Add a data/UnixFilePermissions.xml file to the sdk packs. Fixes #11860. (#11869) NuGet doesn't support preserving the executable bit for files in *.nupkgs (which are just zip files), so .NET implemented a [temporary workaround](https://github.com/dotnet/sdk/pull/17299) for workload installs, where they hardcoded files that should be executable. This isn't really sustainable, and they'll remove their workaround, so we need to use their supported method of specifying the file permissions: a data/UnixFilePermissions.xml file. Fixes https://github.com/xamarin/xamarin-macios/issues/11860.
2021-06-09 08:54:18 +03:00
$(DOTNET_DESTDIR)/Microsoft.$(1).Sdk/data/UnixFilePermissions.xml \
[dotnet] Add AutoImport.props.
2020-10-15 12:46:16 +03:00
$(DOTNET_DESTDIR)/Microsoft.$(1).Sdk/Sdk/AutoImport.props \
[dotnet] Reorder imports to account for that our targets are imported earlier in the build process. In the latest .NET 6, our Workloads.targets is imported earlier in the build. This requires a few changes, because we still need to run most of our logic later in the process, which we do by adding targets files we want imported later to the AfterMicrosoftNETSdkTargets property. What we're loading as soon as possible: * Our version information (Xamarin.Shared.Sdk.Versions.targets) * The supported OS versions (Microsoft.<platform>.Sdk.SupportedTargetPlatforms.targets) * The default OS version (Xamarin.Shared.Sdk.TargetFrameworkInference.targets). This is all information that the .NET build require early on. Changes: * Rename all files that are loaded early to *.props. * Updated documentations to reflect these changes. * Remove Microsoft.<platform>.TargetFrameworkInference.targets, these files aren't used and don't contain anything useful. * Move the logic to calculate _ComputedTargetFrameworkMoniker has been delayed to later, because it needs TargetFrameworkMoniker set.
2020-11-05 12:06:45 +03:00
$(DOTNET_DESTDIR)/Microsoft.$(1).Sdk/Sdk/Sdk.props \
[dotnet] Add support for implicit namespace imports. Fixes #12084. (#12173) * [dotnet] Add support for implicit namespace imports. Fixes #12084. Also update our templates to remove any using statements for implicitly imported namespaces. Fixes https://github.com/xamarin/xamarin-macios/issues/12084. * [monotouch-test] Fix compilation error due to implicit namespace causing type conflict. Fixes these errors: xamarin-macios/tests/monotouch-test/ImageIO/MutableImageMetadataTest.cs(54,54): error CS0104: 'CGImageProperties' is an ambiguous reference between 'CoreGraphics.CGImageProperties' and 'ImageIO.CGImageProperties' xamarin-macios/tests/monotouch-test/ImageIO/MutableImageMetadataTest.cs(54,88): error CS0104: 'CGImageProperties' is an ambiguous reference between 'CoreGraphics.CGImageProperties' and 'ImageIO.CGImageProperties' xamarin-macios/tests/monotouch-test/ImageIO/ImageMetadataTest.cs(40,54): error CS0104: 'CGImageProperties' is an ambiguous reference between 'CoreGraphics.CGImageProperties' and 'ImageIO.CGImageProperties' xamarin-macios/tests/monotouch-test/ImageIO/ImageMetadataTest.cs(40,88): error CS0104: 'CGImageProperties' is an ambiguous reference between 'CoreGraphics.CGImageProperties' and 'ImageIO.CGImageProperties'
2021-07-23 16:07:03 +03:00
$(DOTNET_DESTDIR)/Microsoft.$(1).Sdk/targets/Microsoft.$(1).Sdk.ImplicitNamespaceImports.props \
[dotnet] Reorder imports to account for that our targets are imported earlier in the build process. In the latest .NET 6, our Workloads.targets is imported earlier in the build. This requires a few changes, because we still need to run most of our logic later in the process, which we do by adding targets files we want imported later to the AfterMicrosoftNETSdkTargets property. What we're loading as soon as possible: * Our version information (Xamarin.Shared.Sdk.Versions.targets) * The supported OS versions (Microsoft.<platform>.Sdk.SupportedTargetPlatforms.targets) * The default OS version (Xamarin.Shared.Sdk.TargetFrameworkInference.targets). This is all information that the .NET build require early on. Changes: * Rename all files that are loaded early to *.props. * Updated documentations to reflect these changes. * Remove Microsoft.<platform>.TargetFrameworkInference.targets, these files aren't used and don't contain anything useful. * Move the logic to calculate _ComputedTargetFrameworkMoniker has been delayed to later, because it needs TargetFrameworkMoniker set.
2020-11-05 12:06:45 +03:00
$(DOTNET_DESTDIR)/Microsoft.$(1).Sdk/targets/Microsoft.$(1).Sdk.SupportedTargetPlatforms.props \
[dotnet] Improve incremental builds in make. (#8754) * Be more exact when specifying dependencies for nuget packages: instead of making every package depend on every file within this directory, only make the specific package the files go into depend on those files. This means that if any of these files change, only the package that contains that file will be rebuilt. * Have each package depend on all the files that are to be included in that package. This means that if any other directory adds or updates a file for a nuget, we'll rebuild that nuget here. * Removes packages from the local feed before trying to (re-)add them. This makes them actually install locally, instead of nuget just skipping them, when the version hasn't changed. This was easier to express with make templates than pattern rules, so some of the logic was re-implemented as make templates.
2020-06-04 17:39:19 +03:00
$(DOTNET_DESTDIR)/Microsoft.$(1).Sdk/targets/Microsoft.$(1).Sdk.DefaultItems.props \
[dotnet] Reorder imports to account for that our targets are imported earlier in the build process. In the latest .NET 6, our Workloads.targets is imported earlier in the build. This requires a few changes, because we still need to run most of our logic later in the process, which we do by adding targets files we want imported later to the AfterMicrosoftNETSdkTargets property. What we're loading as soon as possible: * Our version information (Xamarin.Shared.Sdk.Versions.targets) * The supported OS versions (Microsoft.<platform>.Sdk.SupportedTargetPlatforms.targets) * The default OS version (Xamarin.Shared.Sdk.TargetFrameworkInference.targets). This is all information that the .NET build require early on. Changes: * Rename all files that are loaded early to *.props. * Updated documentations to reflect these changes. * Remove Microsoft.<platform>.TargetFrameworkInference.targets, these files aren't used and don't contain anything useful. * Move the logic to calculate _ComputedTargetFrameworkMoniker has been delayed to later, because it needs TargetFrameworkMoniker set.
2020-11-05 12:06:45 +03:00
$(DOTNET_DESTDIR)/Microsoft.$(1).Sdk/targets/Microsoft.$(1).Sdk.props \
[dotnet] Templateify some build logic. (#10618) * [dotnet-linker] Templateify the install logic. * [builds] Templateify the Versions.plist install logic. * [dotnet] Create a per-platform Versions.props file with only the values applicable to that platform. Also move the definition of the default TargetPlatformVersion to Make.versions, where we have other versions. * [dotnet] Templateify some build code.
2021-02-11 22:17:12 +03:00
$(DOTNET_DESTDIR)/Microsoft.$(1).Sdk/targets/Microsoft.$(1).Sdk.Versions.props \
[dotnet] Improve incremental builds in make. (#8754) * Be more exact when specifying dependencies for nuget packages: instead of making every package depend on every file within this directory, only make the specific package the files go into depend on those files. This means that if any of these files change, only the package that contains that file will be rebuilt. * Have each package depend on all the files that are to be included in that package. This means that if any other directory adds or updates a file for a nuget, we'll rebuild that nuget here. * Removes packages from the local feed before trying to (re-)add them. This makes them actually install locally, instead of nuget just skipping them, when the version hasn't changed. This was easier to express with make templates than pattern rules, so some of the logic was re-implemented as make templates.
2020-06-04 17:39:19 +03:00
$(DOTNET_DESTDIR)/Microsoft.$(1).Sdk/targets/Microsoft.$(1).Sdk.targets \
$(DOTNET_DESTDIR)/Microsoft.$(1).Sdk/targets/Xamarin.Shared.Sdk.DefaultItems.targets \
[dotnet] Add support for 'dotnet publish'. Fixes #11807. (#12397) * Add support for 'dotnet publish'. * Add support for a 'PkgPackagePath' for macOS and Mac Catalyst, an MSBuild property to specify the resulting .pkg path, to reflect the existing 'IpaPackagePath' (for iOS and tvOS). * Fix MSBuild logic that uses 'IpaPackagePath'. Looks like nobody has ever used this... * Add tests. Fixes https://github.com/xamarin/xamarin-macios/issues/11807.
2021-08-11 11:01:16 +03:00
$(DOTNET_DESTDIR)/Microsoft.$(1).Sdk/targets/Xamarin.Shared.Sdk.Publish.targets \
[dotnet] Reorder imports to account for that our targets are imported earlier in the build process. In the latest .NET 6, our Workloads.targets is imported earlier in the build. This requires a few changes, because we still need to run most of our logic later in the process, which we do by adding targets files we want imported later to the AfterMicrosoftNETSdkTargets property. What we're loading as soon as possible: * Our version information (Xamarin.Shared.Sdk.Versions.targets) * The supported OS versions (Microsoft.<platform>.Sdk.SupportedTargetPlatforms.targets) * The default OS version (Xamarin.Shared.Sdk.TargetFrameworkInference.targets). This is all information that the .NET build require early on. Changes: * Rename all files that are loaded early to *.props. * Updated documentations to reflect these changes. * Remove Microsoft.<platform>.TargetFrameworkInference.targets, these files aren't used and don't contain anything useful. * Move the logic to calculate _ComputedTargetFrameworkMoniker has been delayed to later, because it needs TargetFrameworkMoniker set.
2020-11-05 12:06:45 +03:00
$(DOTNET_DESTDIR)/Microsoft.$(1).Sdk/targets/Xamarin.Shared.Sdk.TargetFrameworkInference.props \
$(DOTNET_DESTDIR)/Microsoft.$(1).Sdk/targets/Xamarin.Shared.Sdk.props \
[dotnet] Improve incremental builds in make. (#8754) * Be more exact when specifying dependencies for nuget packages: instead of making every package depend on every file within this directory, only make the specific package the files go into depend on those files. This means that if any of these files change, only the package that contains that file will be rebuilt. * Have each package depend on all the files that are to be included in that package. This means that if any other directory adds or updates a file for a nuget, we'll rebuild that nuget here. * Removes packages from the local feed before trying to (re-)add them. This makes them actually install locally, instead of nuget just skipping them, when the version hasn't changed. This was easier to express with make templates than pattern rules, so some of the logic was re-implemented as make templates.
2020-06-04 17:39:19 +03:00
$(DOTNET_DESTDIR)/Microsoft.$(1).Sdk/targets/Xamarin.Shared.Sdk.targets \
[dotnet] Templateify some build logic. (#10618) * [dotnet-linker] Templateify the install logic. * [builds] Templateify the Versions.plist install logic. * [dotnet] Create a per-platform Versions.props file with only the values applicable to that platform. Also move the definition of the default TargetPlatformVersion to Make.versions, where we have other versions. * [dotnet] Templateify some build code.
2021-02-11 22:17:12 +03:00
[dotnet] Improve incremental builds in make. (#8754) * Be more exact when specifying dependencies for nuget packages: instead of making every package depend on every file within this directory, only make the specific package the files go into depend on those files. This means that if any of these files change, only the package that contains that file will be rebuilt. * Have each package depend on all the files that are to be included in that package. This means that if any other directory adds or updates a file for a nuget, we'll rebuild that nuget here. * Removes packages from the local feed before trying to (re-)add them. This makes them actually install locally, instead of nuget just skipping them, when the version hasn't changed. This was easier to express with make templates than pattern rules, so some of the logic was re-implemented as make templates.
2020-06-04 17:39:19 +03:00
endef
[dotnet] Ship libxamarin.dylib and friends. (#8830) * [dotnet] Ship libxamarin.dylib and friends. Add libxamarin[-debug].[a|dylib] to the NuGets. * [dotnet] Create a DOTNET_PLATFORMS variable in Make.config. Create a DOTNET_PLATFORMS variable in Make.config and use it everywhere instead of the PLATFORMS variable we were defining in multiple Makefiles. Also move the creation of the DOTNET_<platform>_RUNTIME_IDENTIFIERS variables from dotnet/Makefile to Make.config, it'll soon be needed elsewhere as well. * [runtime] Conditionally include bits. * Make the contents of the DOTNET_[PLATFORMS|RUNTIME_IDENTIFIERS] variables depend on the INCLUDE_[IOS|TVOS|WATCH] variables.
2020-06-15 18:47:18 +03:00
$(foreach platform,$(DOTNET_PLATFORMS),$(eval $(call DefineTargets,$(platform))))
Create and publish .NET NuGet packages. (#8576) Create the various NuGet packages to support .NET 5+. The packages are currently empty (and not very useful), but the actual content will come later. The current set of NuGet packages are (this list is duplicated for each platform: iOS, tvOS, watchOS and macOS): * Microsoft.iOS.Sdk: currently contains the basic MSBuild targets files for an MSBuild Project SDK. Will eventually contain all the build logic. Might also eventually contain other tools (mlaunch, bgen, etc.), but these might also end up in a different package. * Microsoft.iOS.Ref: will contain the Xamarin.iOS.dll reference assembly. * Microsoft.iOS.Runtime.[RID]: will contain architecture-specific files (libxamarin*.dylib, the Xamarin.iOS.dll implementation assembly, etc.): The NuGets built on CI are automatically published to a NuGet feed. The versioning for the NuGet packages required a few changes: OS bumps are now changed in Make.versions instead of Make.config (this is explained in the files themselves as well).
2020-05-13 16:23:29 +03:00
[dotnet] Fixes -t:Run and illink.dll path for Windows (#10744) * [dotnet] Adds support for dotnet build -t:Run from Windows What was essentially needed was to execute the command remotely, using the right mlaunch path on the Mac * [dotnet] Fixes illink.dll location when building from Windows The property `_ILLinkTasksDirectoryRoot` does not exist anymore so we need to get the path in a different way. Essentially it is located in the same directory as the ILLink Task, so we can get it from `ILLinkTasksAssembly`.
2021-03-03 09:43:34 +03:00
define DefineWindowsTargets
$(1)_WINDOWS_NUGET_TARGETS = \
[build] Create Microsoft.iOS.Windows.Sdk workload pack (#11251) Converts the Microsoft.iOS.Windows.Sdk NuGet package into a proper [workload SDK pack][0]. The entry point for this pack has been changed, and it is now imported through the `WorkloadManifest.targets` file included in `Microsoft.NET.Workload.iOS`, rather than being imported directly from `Microsoft.iOS.Sdk`. Import ordering has otherwise changed slightly. The following files are now imported before the majority of the `Microsoft.iOS.Sdk` (and the majority of the .NET SDK targets): * Xamarin.iOS.Common.Before.props * Xamarin.iOS.Common.Before.targets After this the majority of the .NET SDK targets will load, followed by the `Microsoft.iOS.Sdk` targets. Finally, everything declared in the `<AfterMicrosoftNETSdkTargets/>` hook loads, which consists of: * Microsoft.iOS.Windows.Sdk.targets * tools/msbuild/* [0]: https://github.com/dotnet/designs/blob/main/accepted/2020/workloads/workload-manifest.md#sdk-packs Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
2021-04-27 08:44:51 +03:00
$(DOTNET_DESTDIR)/Microsoft.$(1).Windows.Sdk/Sdk/Sdk.props \
$(DOTNET_DESTDIR)/Microsoft.$(1).Windows.Sdk/targets/Microsoft.$(1).Windows.Sdk.props \
$(DOTNET_DESTDIR)/Microsoft.$(1).Windows.Sdk/targets/Microsoft.$(1).Windows.Sdk.targets \
[dotnet] Fixes -t:Run and illink.dll path for Windows (#10744) * [dotnet] Adds support for dotnet build -t:Run from Windows What was essentially needed was to execute the command remotely, using the right mlaunch path on the Mac * [dotnet] Fixes illink.dll location when building from Windows The property `_ILLinkTasksDirectoryRoot` does not exist anymore so we need to get the path in a different way. Essentially it is located in the same directory as the ILLink Task, so we can get it from `ILLinkTasksAssembly`.
2021-03-03 09:43:34 +03:00
endef
$(foreach platform,$(DOTNET_WINDOWS_PLATFORMS),$(eval $(call DefineWindowsTargets,$(platform))))
[Build] Allow to skip the build of Hotrestart. (#15380)
2022-06-30 16:18:42 +03:00
ifdef INCLUDE_HOTRESTART
[msbuild/dotnet] Build the Xamarin.PreBuilt.iOS app bundle. Fixes #12945. (#13342) Build the Xamarin.PreBuilt.iOS app bundle instead of using a prebuilt bundle. This makes sure that we're always using the latest BCL. Some accurate build massaging was needed, because: * To build the prebuilt app we need the iOS workload installed (into our build-local .NET installation). * The iOS workload contains the Microsoft.iOS.Windows.Sdk pack. * The Microsoft.iOS.Windows.Sdk pack contains the prebuilt app. Thus we had a circular reference. Fortunately, the Microsoft.iOS.Windows.Sdk pack is only required on Windows, which means we can break this circular reference by: * Mark Microsoft.iOS.Windows.Sdk pack as only to be installed on Windows (unfortunately it seems we have to list the exact runtime identifiers for the platforms where to install the pack, so we can't do something like "win-*", but new variations of the "win-*" runtime identifier shouldn't show up all that often). * Build the prebuilt app on macOS. This way we don't need the Microsoft.iOS.Windows.Sdk pack when installing the iOS workload locally. The .NET build order is now: * Build general sdk, runtime and ref packs for .NET. * Build the prebuilt app. * Build the Microsoft.iOS.Windows.Sdk pack. Fixes https://github.com/xamarin/xamarin-macios/issues/12945.
2021-11-12 09:38:07 +03:00
iOS_WINDOWS_NUGET_TARGETS += \
$(DOTNET_DESTDIR)/Microsoft.iOS.Windows.Sdk/tools/msbuild/iOS/Xamarin.PreBuilt.iOS.app.zip \
[Build] Allow to skip the build of Hotrestart. (#15380)
2022-06-30 16:18:42 +03:00
endif
Create and publish .NET NuGet packages. (#8576) Create the various NuGet packages to support .NET 5+. The packages are currently empty (and not very useful), but the actual content will come later. The current set of NuGet packages are (this list is duplicated for each platform: iOS, tvOS, watchOS and macOS): * Microsoft.iOS.Sdk: currently contains the basic MSBuild targets files for an MSBuild Project SDK. Will eventually contain all the build logic. Might also eventually contain other tools (mlaunch, bgen, etc.), but these might also end up in a different package. * Microsoft.iOS.Ref: will contain the Xamarin.iOS.dll reference assembly. * Microsoft.iOS.Runtime.[RID]: will contain architecture-specific files (libxamarin*.dylib, the Xamarin.iOS.dll implementation assembly, etc.): The NuGets built on CI are automatically published to a NuGet feed. The versioning for the NuGet packages required a few changes: OS bumps are now changed in Make.versions instead of Make.config (this is explained in the files themselves as well).
2020-05-13 16:23:29 +03:00
DIRECTORIES += \
$(DOTNET_NUPKG_DIR) \
[dotnet] Create Microsoft.<platform>.Bundle.pkg packages for installing workloads manually.
2020-10-15 12:45:36 +03:00
$(DOTNET_PKG_DIR) \
[dotnet] Add a data/UnixFilePermissions.xml file to the sdk packs. Fixes #11860. (#11869) NuGet doesn't support preserving the executable bit for files in *.nupkgs (which are just zip files), so .NET implemented a [temporary workaround](https://github.com/dotnet/sdk/pull/17299) for workload installs, where they hardcoded files that should be executable. This isn't really sustainable, and they'll remove their workaround, so we need to use their supported method of specifying the file permissions: a data/UnixFilePermissions.xml file. Fixes https://github.com/xamarin/xamarin-macios/issues/11860.
2021-06-09 08:54:18 +03:00
$(foreach platform,$(DOTNET_PLATFORMS),$(DOTNET_DESTDIR)/Microsoft.$(platform).Sdk/data) \
[dotnet] Ship libxamarin.dylib and friends. (#8830) * [dotnet] Ship libxamarin.dylib and friends. Add libxamarin[-debug].[a|dylib] to the NuGets. * [dotnet] Create a DOTNET_PLATFORMS variable in Make.config. Create a DOTNET_PLATFORMS variable in Make.config and use it everywhere instead of the PLATFORMS variable we were defining in multiple Makefiles. Also move the creation of the DOTNET_<platform>_RUNTIME_IDENTIFIERS variables from dotnet/Makefile to Make.config, it'll soon be needed elsewhere as well. * [runtime] Conditionally include bits. * Make the contents of the DOTNET_[PLATFORMS|RUNTIME_IDENTIFIERS] variables depend on the INCLUDE_[IOS|TVOS|WATCH] variables.
2020-06-15 18:47:18 +03:00
$(foreach platform,$(DOTNET_PLATFORMS),$(DOTNET_DESTDIR)/Microsoft.$(platform).Sdk/Sdk) \
$(foreach platform,$(DOTNET_PLATFORMS),$(DOTNET_DESTDIR)/Microsoft.$(platform).Sdk/targets) \
.NET 6 templates for iOS, macOS, tvOS, & MacCatalyst (#10741) Context: https://docs.microsoft.com/dotnet/core/tutorials/cli-templates-create-template-pack Context: https://github.com/dotnet/templating/wiki Context: https://github.com/dotnet/designs/pull/120 Fixes: https://github.com/xamarin/xamarin-macios/issues/10252 To implement templates in a .NET workload: 1. Make `.nupkg` files that follow the structure of the `dotnet new` templating system, using `$(PackageType)` of `Template`. 2. Install the `.nupkg` files in in `dotnet/template-packs/` 3. Update `WorkloadManifest.json`, to be part of the workload: "Microsoft.@PLATFORM@.Templates": { "kind": "template", "version": "@VERSION@" } These are a starting point, for what I would consider the minimum for the xamarin-macios repo to provide for now: Template Name Short Name Language Tags -------------------------------------------- -------------- ---------- ---------------------- iOS Controller template ios-controller [C#] iOS iOS Application ios [C#] iOS iOS Class library ioslib [C#] iOS macOS Application macos [C#] macOS MacCatalyst Application maccatalyst [C#] macOS/Catalyst tvOS Application tvos [C#] tvOS We will probably need PM input on what the final templates will be. To use these, you might do: $ mkdir MyApp && cd MyApp $ dotnet new ios $ dotnet new ios-controller --name LoginController --namespace MyApp Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
2021-03-02 18:23:05 +03:00
$(foreach platform,$(DOTNET_PLATFORMS),$(DOTNET_DESTDIR)/Microsoft.$(platform).Templates) \
[dotnet] rename workload to Microsoft.NET.Sdk._platform_.Manifest-6.0.100 (#11436) * [dotnet] rename workload to Microsoft.NET.Sdk._platform_.Manifest-6.0.100 Context: https://github.com/dotnet/designs/pull/188/files#diff-8fcaa29d8e6f00b34b3cb1830d93f33e75f04424780a66a3c658c7021048e74fR125 Context: https://github.com/xamarin/xamarin-android/pull/5898 The `$(PackageId)` of our workload `.nupkg` needs to be: Microsoft.NET.Sdk._platform_.Manifest-6.0.100 While the `$(PackageVersion)` remains the same as before. The layout on disk will change to: dotnet\sdk-manifests\6.0.100\Microsoft.NET.Sdk._platform_\ WorkloadManifest.json WorkloadManifest.targets Note that `.Manifest` and `-6.0.100` are not in the folder name on disk. At the same time, let's also update the `version` in `WorkloadManifest.json` so it contains the proper version for our workload. This used to not be possible because `version` was a `long`, but it now is a `string` where we can put our version. * Use $(DOTNET6_VERSION_BAND) * Pass in -p:VersionBand to 'dotnet pack'
2021-05-06 08:46:01 +03:00
$(foreach platform,$(DOTNET_PLATFORMS),$(DOTNET_DESTDIR)/Microsoft.NET.Sdk.$(platform)) \
[dotnet] Install our workloads into the dotnet directory (as symlinks).
2020-10-15 12:38:29 +03:00
$(DOTNET_MANIFESTS_PATH) \
[dotnet] Install the Sdk and Ref packages too into the dotnet directory (as symlinks).
2020-10-15 12:39:20 +03:00
$(DOTNET_PACKS_PATH) \
.NET 6 templates for iOS, macOS, tvOS, & MacCatalyst (#10741) Context: https://docs.microsoft.com/dotnet/core/tutorials/cli-templates-create-template-pack Context: https://github.com/dotnet/templating/wiki Context: https://github.com/dotnet/designs/pull/120 Fixes: https://github.com/xamarin/xamarin-macios/issues/10252 To implement templates in a .NET workload: 1. Make `.nupkg` files that follow the structure of the `dotnet new` templating system, using `$(PackageType)` of `Template`. 2. Install the `.nupkg` files in in `dotnet/template-packs/` 3. Update `WorkloadManifest.json`, to be part of the workload: "Microsoft.@PLATFORM@.Templates": { "kind": "template", "version": "@VERSION@" } These are a starting point, for what I would consider the minimum for the xamarin-macios repo to provide for now: Template Name Short Name Language Tags -------------------------------------------- -------------- ---------- ---------------------- iOS Controller template ios-controller [C#] iOS iOS Application ios [C#] iOS iOS Class library ioslib [C#] iOS macOS Application macos [C#] macOS MacCatalyst Application maccatalyst [C#] macOS/Catalyst tvOS Application tvos [C#] tvOS We will probably need PM input on what the final templates will be. To use these, you might do: $ mkdir MyApp && cd MyApp $ dotnet new ios $ dotnet new ios-controller --name LoginController --namespace MyApp Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
2021-03-02 18:23:05 +03:00
$(DOTNET_TEMPLATE_PACKS_PATH) \
[dotnet] Install the Sdk and Ref packages too into the dotnet directory (as symlinks).
2020-10-15 12:39:20 +03:00
$(foreach platform,$(DOTNET_PLATFORMS),$(DOTNET_PACKS_PATH)/Microsoft.$(platform).Sdk) \
$(foreach platform,$(DOTNET_PLATFORMS),$(DOTNET_PACKS_PATH)/Microsoft.$(platform).Ref) \
[dotnet] Install the runtime packs too, now they can be resolved from the packs folder.
2021-08-23 15:40:40 +03:00
$(foreach platform,$(DOTNET_PLATFORMS),$(foreach rid,$(DOTNET_$(platform)_RUNTIME_IDENTIFIERS),$(DOTNET_PACKS_PATH)/Microsoft.$(platform).Runtime.$(rid))) \
.NET 6 templates for iOS, macOS, tvOS, & MacCatalyst (#10741) Context: https://docs.microsoft.com/dotnet/core/tutorials/cli-templates-create-template-pack Context: https://github.com/dotnet/templating/wiki Context: https://github.com/dotnet/designs/pull/120 Fixes: https://github.com/xamarin/xamarin-macios/issues/10252 To implement templates in a .NET workload: 1. Make `.nupkg` files that follow the structure of the `dotnet new` templating system, using `$(PackageType)` of `Template`. 2. Install the `.nupkg` files in in `dotnet/template-packs/` 3. Update `WorkloadManifest.json`, to be part of the workload: "Microsoft.@PLATFORM@.Templates": { "kind": "template", "version": "@VERSION@" } These are a starting point, for what I would consider the minimum for the xamarin-macios repo to provide for now: Template Name Short Name Language Tags -------------------------------------------- -------------- ---------- ---------------------- iOS Controller template ios-controller [C#] iOS iOS Application ios [C#] iOS iOS Class library ioslib [C#] iOS macOS Application macos [C#] macOS MacCatalyst Application maccatalyst [C#] macOS/Catalyst tvOS Application tvos [C#] tvOS We will probably need PM input on what the final templates will be. To use these, you might do: $ mkdir MyApp && cd MyApp $ dotnet new ios $ dotnet new ios-controller --name LoginController --namespace MyApp Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
2021-03-02 18:23:05 +03:00
$(foreach platform,$(DOTNET_PLATFORMS),$(DOTNET_TEMPLATE_PACKS_PATH)/Microsoft.$(platform).Templates) \
[dotnet] Create Microsoft.<platform>.Bundle.pkg packages for installing workloads manually.
2020-10-15 12:45:36 +03:00
$(TMP_PKG_DIR) \
[build] Create Microsoft.iOS.Windows.Sdk workload pack (#11251) Converts the Microsoft.iOS.Windows.Sdk NuGet package into a proper [workload SDK pack][0]. The entry point for this pack has been changed, and it is now imported through the `WorkloadManifest.targets` file included in `Microsoft.NET.Workload.iOS`, rather than being imported directly from `Microsoft.iOS.Sdk`. Import ordering has otherwise changed slightly. The following files are now imported before the majority of the `Microsoft.iOS.Sdk` (and the majority of the .NET SDK targets): * Xamarin.iOS.Common.Before.props * Xamarin.iOS.Common.Before.targets After this the majority of the .NET SDK targets will load, followed by the `Microsoft.iOS.Sdk` targets. Finally, everything declared in the `<AfterMicrosoftNETSdkTargets/>` hook loads, which consists of: * Microsoft.iOS.Windows.Sdk.targets * tools/msbuild/* [0]: https://github.com/dotnet/designs/blob/main/accepted/2020/workloads/workload-manifest.md#sdk-packs Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
2021-04-27 08:44:51 +03:00
$(foreach platform,$(DOTNET_WINDOWS_PLATFORMS),$(DOTNET_DESTDIR)/Microsoft.$(platform).Windows.Sdk/Sdk) \
[dotnet] Fixes -t:Run and illink.dll path for Windows (#10744) * [dotnet] Adds support for dotnet build -t:Run from Windows What was essentially needed was to execute the command remotely, using the right mlaunch path on the Mac * [dotnet] Fixes illink.dll location when building from Windows The property `_ILLinkTasksDirectoryRoot` does not exist anymore so we need to get the path in a different way. Essentially it is located in the same directory as the ILLink Task, so we can get it from `ILLinkTasksAssembly`.
2021-03-03 09:43:34 +03:00
$(foreach platform,$(DOTNET_WINDOWS_PLATFORMS),$(DOTNET_DESTDIR)/Microsoft.$(platform).Windows.Sdk/targets) \
Create and publish .NET NuGet packages. (#8576) Create the various NuGet packages to support .NET 5+. The packages are currently empty (and not very useful), but the actual content will come later. The current set of NuGet packages are (this list is duplicated for each platform: iOS, tvOS, watchOS and macOS): * Microsoft.iOS.Sdk: currently contains the basic MSBuild targets files for an MSBuild Project SDK. Will eventually contain all the build logic. Might also eventually contain other tools (mlaunch, bgen, etc.), but these might also end up in a different package. * Microsoft.iOS.Ref: will contain the Xamarin.iOS.dll reference assembly. * Microsoft.iOS.Runtime.[RID]: will contain architecture-specific files (libxamarin*.dylib, the Xamarin.iOS.dll implementation assembly, etc.): The NuGets built on CI are automatically published to a NuGet feed. The versioning for the NuGet packages required a few changes: OS bumps are now changed in Make.versions instead of Make.config (this is explained in the files themselves as well).
2020-05-13 16:23:29 +03:00
$(DIRECTORIES):
$(Q) mkdir -p $@
CURRENT_HASH_LONG:=$(shell git log -1 --pretty=%H)
[dotnet] Add a data/UnixFilePermissions.xml file to the sdk packs. Fixes #11860. (#11869) NuGet doesn't support preserving the executable bit for files in *.nupkgs (which are just zip files), so .NET implemented a [temporary workaround](https://github.com/dotnet/sdk/pull/17299) for workload installs, where they hardcoded files that should be executable. This isn't really sustainable, and they'll remove their workaround, so we need to use their supported method of specifying the file permissions: a data/UnixFilePermissions.xml file. Fixes https://github.com/xamarin/xamarin-macios/issues/11860.
2021-06-09 08:54:18 +03:00
$(DOTNET_DESTDIR)/Microsoft.%: Microsoft.% | $(foreach platform,$(DOTNET_PLATFORMS),$(DOTNET_DESTDIR)/Microsoft.$(platform).Sdk/data $(DOTNET_DESTDIR)/Microsoft.$(platform).Sdk/Sdk $(DOTNET_DESTDIR)/Microsoft.$(platform).Sdk/targets $(DOTNET_DESTDIR)/Microsoft.$(platform).Templates) \
[build] Create Microsoft.iOS.Windows.Sdk workload pack (#11251) Converts the Microsoft.iOS.Windows.Sdk NuGet package into a proper [workload SDK pack][0]. The entry point for this pack has been changed, and it is now imported through the `WorkloadManifest.targets` file included in `Microsoft.NET.Workload.iOS`, rather than being imported directly from `Microsoft.iOS.Sdk`. Import ordering has otherwise changed slightly. The following files are now imported before the majority of the `Microsoft.iOS.Sdk` (and the majority of the .NET SDK targets): * Xamarin.iOS.Common.Before.props * Xamarin.iOS.Common.Before.targets After this the majority of the .NET SDK targets will load, followed by the `Microsoft.iOS.Sdk` targets. Finally, everything declared in the `<AfterMicrosoftNETSdkTargets/>` hook loads, which consists of: * Microsoft.iOS.Windows.Sdk.targets * tools/msbuild/* [0]: https://github.com/dotnet/designs/blob/main/accepted/2020/workloads/workload-manifest.md#sdk-packs Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
2021-04-27 08:44:51 +03:00
$(foreach platform,$(DOTNET_WINDOWS_PLATFORMS),$(DOTNET_DESTDIR)/Microsoft.$(platform).Windows.Sdk/Sdk $(DOTNET_DESTDIR)/Microsoft.$(platform).Windows.Sdk/targets)
[dotnet] Add the Sdk build files to the Sdk NuGet. (#8644) Also add a very simple net5 test app (which doesn't build yet). Current (expected) build result: > xamarin-macios/tests/dotnet/MySingleView $ dotnet build Microsoft (R) Build Engine version 16.7.0-preview-20258-02+26f6d1d87 for .NET Copyright (C) Microsoft Corporation. All rights reserved. Determining projects to restore... xamarin-macios/tests/dotnet/MySingleView/MySingleView.csproj : error NU1102: Unable to find package Microsoft.NETCore.App.Runtime.ios-x64 with version (= 5.0.0-preview.6.20264.1) xamarin-macios/tests/dotnet/MySingleView/MySingleView.csproj : error NU1102: - Found 1 version(s) in nuget.org [ Nearest version: 5.0.0-preview.4.20251.6 ] xamarin-macios/tests/dotnet/MySingleView/MySingleView.csproj : error NU1102: - Found 1 version(s) in Nuget Official [ Nearest version: 5.0.0-preview.4.20251.6 ] xamarin-macios/tests/dotnet/MySingleView/MySingleView.csproj : error NU1102: - Found 0 version(s) in local-dotnet-feed xamarin-macios/tests/dotnet/MySingleView/MySingleView.csproj : error NU1102: - Found 0 version(s) in Dotnet arcade Failed to restore xamarin-macios/tests/dotnet/MySingleView/MySingleView.csproj (in 951 ms). This fails because the .NET build logic isn't being told that it should look for the mono runtime packs instead of the .NET Core runtime packs.
2020-05-25 16:22:29 +03:00
$(Q) $(CP) $< $@
[dotnet] Templateify some build logic. (#10618) * [dotnet-linker] Templateify the install logic. * [builds] Templateify the Versions.plist install logic. * [dotnet] Create a per-platform Versions.props file with only the values applicable to that platform. Also move the definition of the default TargetPlatformVersion to Make.versions, where we have other versions. * [dotnet] Templateify some build code.
2021-02-11 22:17:12 +03:00
define CopyTargets
$$(DOTNET_DESTDIR)/Microsoft.$(1).Sdk/targets/%: targets/% | $$(DOTNET_DESTDIR)/Microsoft.$(1).Sdk/targets
$$(Q) $$(CP) $$< $$@
endef
$(foreach platform,$(DOTNET_PLATFORMS),$(eval $(call CopyTargets,$(platform))))
[dotnet] Add the Sdk build files to the Sdk NuGet. (#8644) Also add a very simple net5 test app (which doesn't build yet). Current (expected) build result: > xamarin-macios/tests/dotnet/MySingleView $ dotnet build Microsoft (R) Build Engine version 16.7.0-preview-20258-02+26f6d1d87 for .NET Copyright (C) Microsoft Corporation. All rights reserved. Determining projects to restore... xamarin-macios/tests/dotnet/MySingleView/MySingleView.csproj : error NU1102: Unable to find package Microsoft.NETCore.App.Runtime.ios-x64 with version (= 5.0.0-preview.6.20264.1) xamarin-macios/tests/dotnet/MySingleView/MySingleView.csproj : error NU1102: - Found 1 version(s) in nuget.org [ Nearest version: 5.0.0-preview.4.20251.6 ] xamarin-macios/tests/dotnet/MySingleView/MySingleView.csproj : error NU1102: - Found 1 version(s) in Nuget Official [ Nearest version: 5.0.0-preview.4.20251.6 ] xamarin-macios/tests/dotnet/MySingleView/MySingleView.csproj : error NU1102: - Found 0 version(s) in local-dotnet-feed xamarin-macios/tests/dotnet/MySingleView/MySingleView.csproj : error NU1102: - Found 0 version(s) in Dotnet arcade Failed to restore xamarin-macios/tests/dotnet/MySingleView/MySingleView.csproj (in 951 ms). This fails because the .NET build logic isn't being told that it should look for the mono runtime packs instead of the .NET Core runtime packs.
2020-05-25 16:22:29 +03:00
[dotnet] Templateify some build logic. (#10618) * [dotnet-linker] Templateify the install logic. * [builds] Templateify the Versions.plist install logic. * [dotnet] Create a per-platform Versions.props file with only the values applicable to that platform. Also move the definition of the default TargetPlatformVersion to Make.versions, where we have other versions. * [dotnet] Templateify some build code.
2021-02-11 22:17:12 +03:00
define VersionsTemplate
targets/Microsoft.$(1).Sdk.Versions.props: targets/Microsoft.Sdk.Versions.template.props Makefile $(TOP)/Make.config.inc $(TOP)/.git/HEAD $(TOP)/.git/index
$$(Q_GEN) sed \
-e "s/@PLATFORM@/$(1)/g" \
-e "s/@NUGET_VERSION_NO_METADATA@/$$($(2)_NUGET_VERSION_NO_METADATA)/g" \
-e "s/@NUGET_VERSION_FULL@/$$($(2)_NUGET_VERSION_FULL)/g" \
-e "s/@DEFAULT_TARGET_PLATFORM_VERSION@/$$(DEFAULT_TARGET_PLATFORM_VERSION_$(2))/g" \
-e "s/@CURRENT_BRANCH@/$$(CURRENT_BRANCH_SED_ESCAPED)/g" \
-e "s/@CURRENT_HASH_LONG@/$$(CURRENT_HASH_LONG)/g" \
[dotnet] Generate an itemgroup with the valid runtime identifiers and use it to detect invalid runtime identifiers. (#13484) This way we don't have to update the runtime identifier validation when we add support for new runtime identifiers. We'll also have an item group that lists the valid runtime identifiers, which is making it possible (although the item group is currently private) to query the valid runtime identifiers (which is something the IDEs have expressed interest in).
2021-12-03 09:57:08 +03:00
-e 's*@VALID_RUNTIME_IDENTIFIERS@*$(foreach rid,$(3),\n\t\t<_XamarinValidRuntimeIdentifier Include="$(rid)" Platform="$(1)" />)*' \
[dotnet] Templateify some build logic. (#10618) * [dotnet-linker] Templateify the install logic. * [builds] Templateify the Versions.plist install logic. * [dotnet] Create a per-platform Versions.props file with only the values applicable to that platform. Also move the definition of the default TargetPlatformVersion to Make.versions, where we have other versions. * [dotnet] Templateify some build code.
2021-02-11 22:17:12 +03:00
$$< > $$@.tmp
$$(Q) mv $$@.tmp $$@
[dotnet] Add the Sdk build files to the Sdk NuGet. (#8644) Also add a very simple net5 test app (which doesn't build yet). Current (expected) build result: > xamarin-macios/tests/dotnet/MySingleView $ dotnet build Microsoft (R) Build Engine version 16.7.0-preview-20258-02+26f6d1d87 for .NET Copyright (C) Microsoft Corporation. All rights reserved. Determining projects to restore... xamarin-macios/tests/dotnet/MySingleView/MySingleView.csproj : error NU1102: Unable to find package Microsoft.NETCore.App.Runtime.ios-x64 with version (= 5.0.0-preview.6.20264.1) xamarin-macios/tests/dotnet/MySingleView/MySingleView.csproj : error NU1102: - Found 1 version(s) in nuget.org [ Nearest version: 5.0.0-preview.4.20251.6 ] xamarin-macios/tests/dotnet/MySingleView/MySingleView.csproj : error NU1102: - Found 1 version(s) in Nuget Official [ Nearest version: 5.0.0-preview.4.20251.6 ] xamarin-macios/tests/dotnet/MySingleView/MySingleView.csproj : error NU1102: - Found 0 version(s) in local-dotnet-feed xamarin-macios/tests/dotnet/MySingleView/MySingleView.csproj : error NU1102: - Found 0 version(s) in Dotnet arcade Failed to restore xamarin-macios/tests/dotnet/MySingleView/MySingleView.csproj (in 951 ms). This fails because the .NET build logic isn't being told that it should look for the mono runtime packs instead of the .NET Core runtime packs.
2020-05-25 16:22:29 +03:00
[dotnet] Templateify some build logic. (#10618) * [dotnet-linker] Templateify the install logic. * [builds] Templateify the Versions.plist install logic. * [dotnet] Create a per-platform Versions.props file with only the values applicable to that platform. Also move the definition of the default TargetPlatformVersion to Make.versions, where we have other versions. * [dotnet] Templateify some build code.
2021-02-11 22:17:12 +03:00
Microsoft.$1.Sdk/targets/Microsoft.$1.Sdk.Versions.props: targets/Microsoft.$1.Sdk.Versions.props
$$(Q) $$(CP) $$< $$@
endef
[dotnet] Generate an itemgroup with the valid runtime identifiers and use it to detect invalid runtime identifiers. (#13484) This way we don't have to update the runtime identifier validation when we add support for new runtime identifiers. We'll also have an item group that lists the valid runtime identifiers, which is making it possible (although the item group is currently private) to query the valid runtime identifiers (which is something the IDEs have expressed interest in).
2021-12-03 09:57:08 +03:00
$(foreach platform,$(DOTNET_PLATFORMS),$(eval $(call VersionsTemplate,$(platform),$(shell echo $(platform) | tr a-z A-Z),$(DOTNET_$(shell echo $(platform) | tr a-z A-Z)_RUNTIME_IDENTIFIERS))))
Create and publish .NET NuGet packages. (#8576) Create the various NuGet packages to support .NET 5+. The packages are currently empty (and not very useful), but the actual content will come later. The current set of NuGet packages are (this list is duplicated for each platform: iOS, tvOS, watchOS and macOS): * Microsoft.iOS.Sdk: currently contains the basic MSBuild targets files for an MSBuild Project SDK. Will eventually contain all the build logic. Might also eventually contain other tools (mlaunch, bgen, etc.), but these might also end up in a different package. * Microsoft.iOS.Ref: will contain the Xamarin.iOS.dll reference assembly. * Microsoft.iOS.Runtime.[RID]: will contain architecture-specific files (libxamarin*.dylib, the Xamarin.iOS.dll implementation assembly, etc.): The NuGets built on CI are automatically published to a NuGet feed. The versioning for the NuGet packages required a few changes: OS bumps are now changed in Make.versions instead of Make.config (this is explained in the files themselves as well).
2020-05-13 16:23:29 +03:00
[dotnet] Make default items file templated to make it platform-specific. The template takes each platform as input, and adds a TargetPlatformIdentifier condition to the item groups. This also means removing Xamarin.Shared.Sdk.DefaultItems.props, and put all the generated logic into Microsoft.<platform>.Sdk.DefaultItems.props. We can't use an identical default items file for all four platforms, because the file is loaded once for each platform, and if the file is identical it means it'll get repeated four times (and everything included by default will be included four times, ending up with build errors).
2020-10-15 19:48:29 +03:00
define DefaultItems
Microsoft.$1.Sdk/targets/Microsoft.$1.Sdk.DefaultItems.props: targets/Microsoft.Sdk.DefaultItems.template.props Makefile
$$(Q_GEN) sed \
-e "s/@PLATFORM@/$1/g" \
$$< > $$@
endef
$(foreach platform,$(DOTNET_PLATFORMS),$(eval $(call DefaultItems,$(platform))))
[dotnet] Use net5.0-[ios|tvos|watchos|macos] TargetFrameworks. (#9532) * [dotnet] Set TargetPlatformSupported when the right TargetPlatformIdentifier is used. * [dotnet] Generate a list of valid OS versions for each platform, and add it to the SupportedTargetPlatform item group. The generated files: https://gist.github.com/rolfbjarne/765c4e4b38b1b017380c9378d9666317 * [dotnet] Define and set the default platform version if it's not set in the TargetFramework variable. * [dotnet] Switch to using the new-style TargetFramework values. This includes bumping spouliot/Touch.Unit to get new-style TargetFramework values for Touch.Client. * spouliot/Touch.Unit@89afaf7 [Touch.Client] Use the right TargetFrameworks for watchOS and macOS as well. (#92) * spouliot/Touch.Unit@fd0e576 [Touch.Client] Use the right TargetFrameworks. (#91) * spouliot/Touch.Unit@40f47db [Touch.Client] Add a macOS and watchOS version for .NET. (#90) * spouliot/Touch.Unit@1d4b8c0 Add .gitignore for NuGet.config and global.json. (#89) * spouliot/Touch.Unit@49441f3 Call `mlaunch` instead of `mtouch` (#88) * spouliot/Touch.Unit@b157cf4 Fix a few markdown issues found by markdownlint. (#87) Diff: https://github.com/spouliot/Touch.Unit/compare/d7f55a61673e18ae5a8f9628600081a54b4e074c..89afaf7e05a942c87231cf5601b3a5b59640e218 * [dotnet] Document the script that generates the lists of the target platform versions a little bit better. * [dotnet] Make the [Platform]SupportedTargetPlatform variables public. This matches how Android and Windows do it: * https://github.com/xamarin/xamarin-android/pull/5007 * https://github.com/dotnet/sdk/blob/18ee4eac8b3abe6d554d2e0c39d8952da0f23ce5/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.WindowsSupportedTargetPlatforms.props * [xharness] Update the TargetFramework value when creating project variations.
2020-08-31 10:27:19 +03:00
define SupportedTargetPlatforms
[dotnet] Reorder imports to account for that our targets are imported earlier in the build process. In the latest .NET 6, our Workloads.targets is imported earlier in the build. This requires a few changes, because we still need to run most of our logic later in the process, which we do by adding targets files we want imported later to the AfterMicrosoftNETSdkTargets property. What we're loading as soon as possible: * Our version information (Xamarin.Shared.Sdk.Versions.targets) * The supported OS versions (Microsoft.<platform>.Sdk.SupportedTargetPlatforms.targets) * The default OS version (Xamarin.Shared.Sdk.TargetFrameworkInference.targets). This is all information that the .NET build require early on. Changes: * Rename all files that are loaded early to *.props. * Updated documentations to reflect these changes. * Remove Microsoft.<platform>.TargetFrameworkInference.targets, these files aren't used and don't contain anything useful. * Move the logic to calculate _ComputedTargetFrameworkMoniker has been delayed to later, because it needs TargetFrameworkMoniker set.
2020-11-05 12:06:45 +03:00
Microsoft.$(1).Sdk/targets/Microsoft.$(1).Sdk.SupportedTargetPlatforms.props: $(TOP)/Versions-ios.plist.in $(TOP)/Versions-mac.plist.in Makefile ./generate-target-platforms.csharp Makefile
[dotnet] Use net5.0-[ios|tvos|watchos|macos] TargetFrameworks. (#9532) * [dotnet] Set TargetPlatformSupported when the right TargetPlatformIdentifier is used. * [dotnet] Generate a list of valid OS versions for each platform, and add it to the SupportedTargetPlatform item group. The generated files: https://gist.github.com/rolfbjarne/765c4e4b38b1b017380c9378d9666317 * [dotnet] Define and set the default platform version if it's not set in the TargetFramework variable. * [dotnet] Switch to using the new-style TargetFramework values. This includes bumping spouliot/Touch.Unit to get new-style TargetFramework values for Touch.Client. * spouliot/Touch.Unit@89afaf7 [Touch.Client] Use the right TargetFrameworks for watchOS and macOS as well. (#92) * spouliot/Touch.Unit@fd0e576 [Touch.Client] Use the right TargetFrameworks. (#91) * spouliot/Touch.Unit@40f47db [Touch.Client] Add a macOS and watchOS version for .NET. (#90) * spouliot/Touch.Unit@1d4b8c0 Add .gitignore for NuGet.config and global.json. (#89) * spouliot/Touch.Unit@49441f3 Call `mlaunch` instead of `mtouch` (#88) * spouliot/Touch.Unit@b157cf4 Fix a few markdown issues found by markdownlint. (#87) Diff: https://github.com/spouliot/Touch.Unit/compare/d7f55a61673e18ae5a8f9628600081a54b4e074c..89afaf7e05a942c87231cf5601b3a5b59640e218 * [dotnet] Document the script that generates the lists of the target platform versions a little bit better. * [dotnet] Make the [Platform]SupportedTargetPlatform variables public. This matches how Android and Windows do it: * https://github.com/xamarin/xamarin-android/pull/5007 * https://github.com/dotnet/sdk/blob/18ee4eac8b3abe6d554d2e0c39d8952da0f23ce5/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.WindowsSupportedTargetPlatforms.props * [xharness] Update the TargetFramework value when creating project variations.
2020-08-31 10:27:19 +03:00
$(Q) rm -f $$@.tmp
$(Q) ./generate-target-platforms.csharp $(1) $$@.tmp
$(Q) mv $$@.tmp $$@
endef
$(foreach platform,$(DOTNET_PLATFORMS),$(eval $(call SupportedTargetPlatforms,$(platform))))
[dotnet] Create a WorkloadManifest.json for each platform.
2020-10-15 12:35:03 +03:00
define WorkloadTargets
[dotnet] Add support for generating a binary version of runtimeconfig.json. Fixes #11745. (#11887) Use Mono's RuntimeConfigParserTask to parse the *.runtimeconfig.json file and produce a binary version of it. This also means implementing support for finding the on-disk location of the file at runtime, and passing it to mono. Ref: https://github.com/dotnet/runtime/blob/01b7e73cd378145264a7cb7a09365b41ed42b240/docs/design/mono/mobile-runtimeconfig-json.md Fixes https://github.com/xamarin/xamarin-macios/issues/11745.
2021-06-16 16:22:02 +03:00
Workloads/Microsoft.NET.Sdk.$(1)/WorkloadManifest.json: targets/WorkloadManifest.$(1).template.json Makefile $(TOP)/Make.config.inc $(TOP)/.git/HEAD $(TOP)/.git/index Makefile
[dotnet] Create a WorkloadManifest.json for each platform.
2020-10-15 12:35:03 +03:00
$$(Q) rm -f $$@.tmp
$$(Q_GEN) sed \
-e "s/@VERSION@/$3/g" \
[dotnet] Add support for generating a binary version of runtimeconfig.json. Fixes #11745. (#11887) Use Mono's RuntimeConfigParserTask to parse the *.runtimeconfig.json file and produce a binary version of it. This also means implementing support for finding the on-disk location of the file at runtime, and passing it to mono. Ref: https://github.com/dotnet/runtime/blob/01b7e73cd378145264a7cb7a09365b41ed42b240/docs/design/mono/mobile-runtimeconfig-json.md Fixes https://github.com/xamarin/xamarin-macios/issues/11745.
2021-06-16 16:22:02 +03:00
-e "s/@BUNDLED_NETCORE_PLATFORMS_PACKAGE_VERSION@/$(BUNDLED_NETCORE_PLATFORMS_PACKAGE_VERSION)/g" \
[dotnet] Create a WorkloadManifest.json for each platform.
2020-10-15 12:35:03 +03:00
-e "s/@PLATFORM_LOWERCASE@/$2/g" \
-e "s/@PLATFORM@/$1/g" \
$$< > $$@.tmp
$$(Q) mv $$@.tmp $$@
Ship a LICENSE file with the workload. (#9978)
2020-10-28 00:46:59 +03:00
Mono changed the location of the AOT compiler, so we have to update our code accordingly. (#11789) * [tests] Augment the .NET unit tests to verify that more runtime identifiers build. * [dotnet] Show a better error if the AOT compiler doesn't exist. * [dotnet] Use the official path for the AOT compiler. * [dotnet] Use platform-specific templates for WorkloadManifest.json. * [dotnet] Generate the workload targets before the nupkgs. This avoids a random build failure when doing parallel make. * [builds] Install the runtime workloads for iOS and tvOS so that we have the AOT compilers downloaded for our local tests. * [dotnet] Make the iOS and tvOS workloads load the AOT compiler packages from Mono. * [dotnet] Move the workloads into a common subdirectory. Also delete the watchOS workload, we're not shipping it for now. * [dotnet] Set DOTNETSDK_WORKLOAD_MANIFEST_ROOTS when install workloads to get our local ones. * Set DOTNETSDK_WORKLOAD_MANIFEST_ROOTS to where our local workloads are to use them when installing our locally built workloads into .NET (the local one). * Stop installing workloads from builds/ * Get NuGet.config with local feed, and make sure those feed contain local build before running 'workload install'. * Fix makefile logic. * Another tweak.
2021-06-04 09:34:32 +03:00
Workloads/Microsoft.NET.Sdk.$(1)/LICENSE: $(TOP)/LICENSE
Ship a LICENSE file with the workload. (#9978)
2020-10-28 00:46:59 +03:00
$$(Q) $(CP) $$< $$@
Mono changed the location of the AOT compiler, so we have to update our code accordingly. (#11789) * [tests] Augment the .NET unit tests to verify that more runtime identifiers build. * [dotnet] Show a better error if the AOT compiler doesn't exist. * [dotnet] Use the official path for the AOT compiler. * [dotnet] Use platform-specific templates for WorkloadManifest.json. * [dotnet] Generate the workload targets before the nupkgs. This avoids a random build failure when doing parallel make. * [builds] Install the runtime workloads for iOS and tvOS so that we have the AOT compilers downloaded for our local tests. * [dotnet] Make the iOS and tvOS workloads load the AOT compiler packages from Mono. * [dotnet] Move the workloads into a common subdirectory. Also delete the watchOS workload, we're not shipping it for now. * [dotnet] Set DOTNETSDK_WORKLOAD_MANIFEST_ROOTS when install workloads to get our local ones. * Set DOTNETSDK_WORKLOAD_MANIFEST_ROOTS to where our local workloads are to use them when installing our locally built workloads into .NET (the local one). * Stop installing workloads from builds/ * Get NuGet.config with local feed, and make sure those feed contain local build before running 'workload install'. * Fix makefile logic. * Another tweak.
2021-06-04 09:34:32 +03:00
WORKLOAD_TARGETS += Workloads/Microsoft.NET.Sdk.$(1)/WorkloadManifest.json
WORKLOAD_TARGETS += Workloads/Microsoft.NET.Sdk.$(1)/LICENSE
[dotnet] Try to implement a workaround for xamarin/maccore#2427. (#11897) We randomly run into a NuGet restore failure, which breaks the build, and is quite annoying. This might be due to a problem with multiple simultaneous restores, so this is an attempt to first restore the packages we need, in a single serialized restore, and once that's done we can process everything else in parallel. Ref: https://github.com/xamarin/maccore/issues/2427 Ref: https://github.com/NuGet/Home/issues/10935
2021-06-11 16:22:31 +03:00
LOCAL_WORKLOAD_TARGETS += Workloads/Microsoft.NET.Sdk.$(1)/WorkloadManifest.json
LOCAL_WORKLOAD_TARGETS += Workloads/Microsoft.NET.Sdk.$(1)/LICENSE
[dotnet] Create a WorkloadManifest.json for each platform.
2020-10-15 12:35:03 +03:00
endef
Mono changed the location of the AOT compiler, so we have to update our code accordingly. (#11789) * [tests] Augment the .NET unit tests to verify that more runtime identifiers build. * [dotnet] Show a better error if the AOT compiler doesn't exist. * [dotnet] Use the official path for the AOT compiler. * [dotnet] Use platform-specific templates for WorkloadManifest.json. * [dotnet] Generate the workload targets before the nupkgs. This avoids a random build failure when doing parallel make. * [builds] Install the runtime workloads for iOS and tvOS so that we have the AOT compilers downloaded for our local tests. * [dotnet] Make the iOS and tvOS workloads load the AOT compiler packages from Mono. * [dotnet] Move the workloads into a common subdirectory. Also delete the watchOS workload, we're not shipping it for now. * [dotnet] Set DOTNETSDK_WORKLOAD_MANIFEST_ROOTS when install workloads to get our local ones. * Set DOTNETSDK_WORKLOAD_MANIFEST_ROOTS to where our local workloads are to use them when installing our locally built workloads into .NET (the local one). * Stop installing workloads from builds/ * Get NuGet.config with local feed, and make sure those feed contain local build before running 'workload install'. * Fix makefile logic. * Another tweak.
2021-06-04 09:34:32 +03:00
$(foreach platform,$(DOTNET_PLATFORMS),$(eval $(call WorkloadTargets,$(platform),$(shell echo $(platform) | tr A-Z a-z),$($(platform)_NUGET_VERSION_NO_METADATA))))
[dotnet] Create a WorkloadManifest.json for each platform.
2020-10-15 12:35:03 +03:00
[CI] Add Prepare Release and VS Insertion stages (again) (#12157) Context: xamarin/yaml-templates#117 Updates the .NET 6 NuGet packaging steps to exclude package metadata, as the .msi conversion tooling does not process .nupkg file names with the +sha.commit metadata. Two new stages have been added to facilitate the Visual Studio setup authoring process. The first stage named "Prepare Release" will sign the .NET 6 NuGet package content (inside and out), convert relevant packages to .msi installers, generate Visual Studio manifests for the .msi installers, and push the signed packages to the xamarin-impl feed. The new SignList.xml file is required for our NuGet signing templates. The new xamarin-workload.props file contains version information and other metadata required to generate a Visual Studio manifest. The second stage starts with a manual validation task. This task will pause and wait for someone to click a "Resume" or "Reject" button that will appear on the pipeline UI. This task is configured to be rejected after waiting for two days, but it can be manually re-ran at a later date if we want to trigger VS insertion for an older build. If the manual validation task is approved, a VS Drop will be created containing all .NET 6 .msi files. This Drop URL can then be used to update our component versions in Visual Studio. This last piece is currently manual as we will initially be introducing new components, however we should be able to automate VS PR creation in the future. Commit 09f911b missed adding the PR build check condition to a step in sign-and-notarized.yml, causing PR builds from forks to fail. We can fix this by adding in the missing condition.
2021-07-21 20:09:29 +03:00
$(DOTNET_NUPKG_DIR)/vs-workload.props: Workloads/vs-workload.template.props
$(Q) rm -f $@.tmp
$(Q_GEN) sed \
$(foreach platform,$(DOTNET_PLATFORMS_UPPERCASE),-e "s/@$(platform)_WORKLOAD_VERSION@/$($(platform)_NUGET_VERSION).$($(platform)_NUGET_COMMIT_DISTANCE)/g") \
-e "s/@PACK_VERSION_LONG@/$(IOS_NUGET_VERSION_NO_METADATA)/g" \
-e "s/@PACK_VERSION_SHORT@/$(IOS_NUGET_VERSION).$(IOS_NUGET_COMMIT_DISTANCE)/g" \
Generate msi files and VS setup authoring for all .NET 6 platforms (#12581) * Update vs-insertion-prep.yml * Remove filters from symbol package download as well * [temp] Changes for testing * Shorten manifest name * Shorten manifest name take 2 * Add ComponentResources and WorkloadPackages for tvOS and macOS * Don't shorten MacCatalyst name, version string replacement should suffice * Revert "Don't shorten MacCatalyst name, version string replacement should suffice" This reverts commit d1c1d1d89db51154160bdc568f90c31934b87490. * Replace long macOS versions in .msi files * Shorten tvossimulator msi names * Test with real signing * Revert testing changes * Enable tests Co-authored-by: Peter Collins <pecolli@microsoft.com>
2021-09-01 20:55:08 +03:00
-e "s/@MACOS_PACK_VERSION_LONG@/$(MACOS_NUGET_VERSION_NO_METADATA)/g" \
-e "s/@MACOS_PACK_VERSION_SHORT@/$(MACOS_NUGET_VERSION).$(MACOS_NUGET_COMMIT_DISTANCE)/g" \
[CI] Add Prepare Release and VS Insertion stages (again) (#12157) Context: xamarin/yaml-templates#117 Updates the .NET 6 NuGet packaging steps to exclude package metadata, as the .msi conversion tooling does not process .nupkg file names with the +sha.commit metadata. Two new stages have been added to facilitate the Visual Studio setup authoring process. The first stage named "Prepare Release" will sign the .NET 6 NuGet package content (inside and out), convert relevant packages to .msi installers, generate Visual Studio manifests for the .msi installers, and push the signed packages to the xamarin-impl feed. The new SignList.xml file is required for our NuGet signing templates. The new xamarin-workload.props file contains version information and other metadata required to generate a Visual Studio manifest. The second stage starts with a manual validation task. This task will pause and wait for someone to click a "Resume" or "Reject" button that will appear on the pipeline UI. This task is configured to be rejected after waiting for two days, but it can be manually re-ran at a later date if we want to trigger VS insertion for an older build. If the manual validation task is approved, a VS Drop will be created containing all .NET 6 .msi files. This Drop URL can then be used to update our component versions in Visual Studio. This last piece is currently manual as we will initially be introducing new components, however we should be able to automate VS PR creation in the future. Commit 09f911b missed adding the PR build check condition to a step in sign-and-notarized.yml, causing PR builds from forks to fail. We can fix this by adding in the missing condition.
2021-07-21 20:09:29 +03:00
$< > $@.tmp
$(Q) mv $@.tmp $@
$(DOTNET_NUPKG_DIR)/SignList.xml: Workloads/SignList.xml
$(Q) $(CP) $< $@
[ci] Sign .NET 6 VS Hot Restart content (#12400) Context: https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=5074495&view=logs&j=f8a716f9-5318-5935-19a4-149a64409b96&t=773a1aad-99f2-5f0b-eafa-0deb88171543 Context: https://dev.azure.com/devdiv/DevDiv/_workitems/edit/1366309 Context: https://dev.azure.com/devdiv/DevDiv/_workitems/edit/1366310 Commit 9dbf451d added files required to support Hot Restart in .NET 6 packages, however it did not update SignList.xml to also include these new file additions. This caused .nupkg signing issues: C:\a\_temp\artifact-signing\SignFiles.proj(66,5): error : Unknown assemblies: C:\a\_temp\artifact-signing\SignFiles.proj(66,5): error : C:\a\_temp\artifact-signing\extracted\Microsoft.iOS.Windows.Sdk.15.0.100-ci.main.446\tools\msbuild\iOS\BouncyCastle.Crypto.dll; C:\a\_temp\artifact-signing\SignFiles.proj(66,5): error : C:\a\_temp\artifact-signing\extracted\Microsoft.iOS.Windows.Sdk.15.0.100-ci.main.446\tools\msbuild\iOS\imobiledevice-x64\bz2.dll; C:\a\_temp\artifact-signing\SignFiles.proj(66,5): error : C:\a\_temp\artifact-signing\extracted\Microsoft.iOS.Windows.Sdk.15.0.100-ci.main.446\tools\msbuild\iOS\imobiledevice-x64\getopt.dll; C:\a\_temp\artifact-signing\SignFiles.proj(66,5): error : C:\a\_temp\artifact-signing\extracted\Microsoft.iOS.Windows.Sdk.15.0.100-ci.main.446\tools\msbuild\iOS\imobiledevice-x64\ideviceactivation.dll; ... Fix signing by listing all new content that should be skipped or signed with first/third party certs. Additionally, content in nested .zip files also needs to be signed. I've added a couple of targets to SignList.targets to unzip and rezip these files before and after individual file signing runs.
2021-08-12 17:40:10 +03:00
$(DOTNET_NUPKG_DIR)/SignList.targets: Workloads/SignList.targets
$(Q) $(CP) $< $@
Create and publish .NET NuGet packages. (#8576) Create the various NuGet packages to support .NET 5+. The packages are currently empty (and not very useful), but the actual content will come later. The current set of NuGet packages are (this list is duplicated for each platform: iOS, tvOS, watchOS and macOS): * Microsoft.iOS.Sdk: currently contains the basic MSBuild targets files for an MSBuild Project SDK. Will eventually contain all the build logic. Might also eventually contain other tools (mlaunch, bgen, etc.), but these might also end up in a different package. * Microsoft.iOS.Ref: will contain the Xamarin.iOS.dll reference assembly. * Microsoft.iOS.Runtime.[RID]: will contain architecture-specific files (libxamarin*.dylib, the Xamarin.iOS.dll implementation assembly, etc.): The NuGets built on CI are automatically published to a NuGet feed. The versioning for the NuGet packages required a few changes: OS bumps are now changed in Make.versions instead of Make.config (this is explained in the files themselves as well).
2020-05-13 16:23:29 +03:00
TEMPLATED_FILES = \
[dotnet] Templateify some build logic. (#10618) * [dotnet-linker] Templateify the install logic. * [builds] Templateify the Versions.plist install logic. * [dotnet] Create a per-platform Versions.props file with only the values applicable to that platform. Also move the definition of the default TargetPlatformVersion to Make.versions, where we have other versions. * [dotnet] Templateify some build code.
2021-02-11 22:17:12 +03:00
$(foreach platform,$(DOTNET_PLATFORMS),Microsoft.$(platform).Sdk/targets/Microsoft.$(platform).Sdk.Versions.props) \
[dotnet] Reorder imports to account for that our targets are imported earlier in the build process. In the latest .NET 6, our Workloads.targets is imported earlier in the build. This requires a few changes, because we still need to run most of our logic later in the process, which we do by adding targets files we want imported later to the AfterMicrosoftNETSdkTargets property. What we're loading as soon as possible: * Our version information (Xamarin.Shared.Sdk.Versions.targets) * The supported OS versions (Microsoft.<platform>.Sdk.SupportedTargetPlatforms.targets) * The default OS version (Xamarin.Shared.Sdk.TargetFrameworkInference.targets). This is all information that the .NET build require early on. Changes: * Rename all files that are loaded early to *.props. * Updated documentations to reflect these changes. * Remove Microsoft.<platform>.TargetFrameworkInference.targets, these files aren't used and don't contain anything useful. * Move the logic to calculate _ComputedTargetFrameworkMoniker has been delayed to later, because it needs TargetFrameworkMoniker set.
2020-11-05 12:06:45 +03:00
$(foreach platform,$(DOTNET_PLATFORMS),Microsoft.$(platform).Sdk/targets/Microsoft.$(platform).Sdk.SupportedTargetPlatforms.props) \
Create and publish .NET NuGet packages. (#8576) Create the various NuGet packages to support .NET 5+. The packages are currently empty (and not very useful), but the actual content will come later. The current set of NuGet packages are (this list is duplicated for each platform: iOS, tvOS, watchOS and macOS): * Microsoft.iOS.Sdk: currently contains the basic MSBuild targets files for an MSBuild Project SDK. Will eventually contain all the build logic. Might also eventually contain other tools (mlaunch, bgen, etc.), but these might also end up in a different package. * Microsoft.iOS.Ref: will contain the Xamarin.iOS.dll reference assembly. * Microsoft.iOS.Runtime.[RID]: will contain architecture-specific files (libxamarin*.dylib, the Xamarin.iOS.dll implementation assembly, etc.): The NuGets built on CI are automatically published to a NuGet feed. The versioning for the NuGet packages required a few changes: OS bumps are now changed in Make.versions instead of Make.config (this is explained in the files themselves as well).
2020-05-13 16:23:29 +03:00
[dotnet] Initial support for .NET6 from Windows (#10590) These changes add support for executing iOS and MacDev tasks remotely (on a Mac) when running a build from Windows, and creates a specific .NET6 pack for Windows that's only included in the MSI. For now this only enables builds for the iOS Simulator, physical devices are not yet supported. - Each task decides if it should run locally or remotely depending on the SessionId property, which will only have a value on Windows. - The XMA Build agent is now part of this repo and will be included in the iOS .NET6 Windows pack. - On this first version we're including some Windows specific tasks and references into the Xamarin.iOS.Tasks project for simplicity, but those will be moved to the Windows specific project. ------------ * [msbuild] Adds support for executing Xamarin.iOS tasks from Windows * [msbuild] Adds support for executing Xamarin.MacDev tasks from Windows * Added XMA Build Agent to Xamarin.MacDev.Tasks.sln * Fixes some MSBuild versioning problems * Makes the XMA Build agent load Xamarin.iOS tasks We need to load a type from the iOS tasks assembly so we can run the tasks requested by MSBuild from Windows. We only need to load Xamarin.iOS.Tasks.dll since MacDev.tasks is already embedded in that one. There's a little trick on the csproj, we can't directly use the Xamarin.iOS.Tasks project ref assemblies because that includes both Xamarin.iOS.Tasks.dll and Xamarin.MacDev.Tasks.dll, so the MacDev tasks will collide. We use the project ref only for build dependency purposes but we add an assembly reference to Xamarin.iOS.Tasks.dll. * Added Xamarin.iOS.Tasks.Windows project * Removed unnecessary references on Xamarin.iOS.Tasks.Windows.csproj * Adds Messaging assemblies when ILRepacking Xamarin Tasks The Xamarin Task assemblies now depend on Messaging, so we need the Messaging assemblies to be packed into Xamarin.Mac.Tasks and Xamarin.iOS.Tasks. Also had to remove the direct Messaging dependencies from the build agent since those are already contained in Xamarin.iOS.Tasks * Adds a reference to Messaging.Core targets to the Agent's project * [msbuild] Adds Xamarin iOS Windows targets * [msbuild] Adds missing dependencies to Xamarin.iOS.Tasks This should fix build errors because of missing dependencies. Had to move System.Net.Mqtt.Server from the Build agent project to the tasks one to avoid conflicts with System.Diagnostics.Tracer. * [dotnet] Creates iOS Windows pack Creates a new pack for Windows specific (targets, build agent, etc.) files that shouldn't be installed on the Mac. We have a separate package for this to avoid increasing the core pack size with things that are not needed when using it from macOS. * Fixes type in dotnet makefile * [dotnet] Fixes the iOS Windows pack generation - The windows pack should not include the Sdk and Targets folders - For now we'll just create an iOS pack - Fixes the path to the files to include on the Windows Sdk pack * Added reference to the Windows iOS SDK from the Xamarin.iOS.Common.targets Added a property to navigate to the Windows iOS SDK folder, based on a naming convention that assumes that both packs will always have the same version * Added reference to the core iOS SDK from the Windows iOS SDK Added a property to navigate to the core iOS SDK folder, based on a naming convention that assumes that both packs will always have the same version * Updated Messaging version * Override MessagingBuildClientAssemblyFile property and correctly imported props from targets * [dotnet] Make Windows pack using target files from the output dir We need to take the target files from the output dir to include targets that are part of nuget packages, otherwise we will only include targets from our source * [dotnet] Adds the Windows Sdk pack to the workload manifest * [msbuild] Fixes the Windows Sdk pack name * [dotnet] Merge Mqtt instead of Mqtt.Server We only need System.Net.Mqtt to be merged into Xamarin.iOS.Tasks * Updated Messaging version * [dotnet] Several fixes for the Windows Sdk - Adds missing task CollectMonotouchReferences - Merges more dependencies into Xamarin.iOS.Tasks.dll needed by XMA - Updates the msbuild/Makefile to include files from both the output dir and the source dir - Overrides the agents directory to look for them on the Windows pack * [dotnet] Fixes the XMA Build agent - The build agent is an app so it cannot target ns2.0 - The MSBuild dependencies should be copied into the agent zip file - Avoids copying all the Xamarin iOS SDK core targets into the build agent, since those are not needed - Ensures the broker zip file is copied into the Xamarin.iOS.Windows.Tasks output dir so its included in the Windows pack * Bumps Xamarin.Messaging to 1.2.102 * Adds net6-win branch to trigger builds * Adds Messaging.Client missing dependency to Xamarin.Mac.Tasks * Added Xamarin.Messaging.Apple.Tasks project and VerifyXcodeVersion Task * Fix unloaded Xamarin.Messaging.Build project * Added Build contracts project and unified Xamarin.Messaigng.Apple.Tasks in Xamarin.iOS.Tasks.Windows Also added missing tasks and changes .After.targets * Updated Xamarin.Messaging version * Build agent - reference MSBuild assemblies from the framework Since the assemblies will be included in the build agent we need those to be the ones that come from the framework to be compatible with macOS * [msbuild] Fixes _UpdateDynamicLibraryId target The tasks con this target need to be executed remotely (when building from Windows). * Updates resources * Bump Xamarin.Messaging Fixes problems when executing Exec task remotely * [dotnet] Overrides Publish targets to execute them remotely from Windows The `_CopyResolvedFilesToPublishPreserveNewest` and `_CopyResolvedFilesToPublishAlways` targets essentially copy files into the app bundle. Since those are part of the .NET SDK we need to override those so we can pass to the Copy task the SessionId parameter and then it will be executed remotely when building from Windows. This is done in a Windows.After.targets file so it won't affect builds on macOS. * Added ILMerge to Xamarin.iOS.Tasks.Windows Also modified ILMerge.targets to not include System assemblies because we don't need them on the Windows package * Bumps Messaging This new version of messaging fixes a problem when copying task inputs from Windows to the Mac * [dotnet] Fixes copying files to the Mac when building from Windows When building from Windows there are .NET SDK targets that copy dynamic libraries from the SDK to the intermediate output directory or other files to the publish directory, since we can't control those we can't run them remotely so we need to copy those files to the Mac to ensure other targets will find those. * [dotnet] Fixes how files are copied to the output dir - Before executing `_CopyResolvedFilesToPublishPreserveNewest` and `_CopyResolvedFilesToPublishAlways` we copy the input files for those targets to the Mac - Then we override the original targets to execute the same copy task as the original ones but on the Mac, so the output files are placed in the right location for the following targets to pick them up. * Fixes typo on Xamarin.iOS.Common.After.targets * Bumps Xamarin.Messaging * [msbuild] Fixes VerifyXcodeVersion and ResolveUTIs tasks Both tasks were not being able to connect to the Mac mostly because of ILRepack, there were kind of 2 versions of Xamarin.Messaging, one merged into Xamarin.iOS.Tasks and another one merged into Xamarin.iOS.Windows.Tasks. Because of this the build connection object registered on the task could not be casted to the build connection type. This essentially moves both tasks into the Xamarin.iOS.Tasks assembly to avoid this issue, and as part of that also includes the Messaging contracts into that same project. * [msbuild] Fixes warnings when building from Windows * [dotnet] Adds missing assemblies to merge into Xamarin.iOS.Tasks Those 2 new assemblies will only be used from Windows and we need their implementation instead of the ref assemblies. In the future we will need to find a way of doing this on the Windows only pack insted of doing it on the core Xamarin.iOS.Tasks assembly. * [dotnet] Compute PublishTrimmed on a target We need to do this so the property is evaluated after VS on Windows connects to the Mac, otherwise by default IsMacEnabled is false from Windows. * Bumps Messaging to 1.2.111 * [dotnet] Execute ILLink remotely when building from Windows - Overrides the ILLink task and _RunILLink target to add the hability to execute it remotely, adding input and output properties so files are copied to the server and output files are created on Windows. - This "custom" ILLink task will only be executed from the Windows targets so when building from a Mac it will execute the core SDK task. * [dotnet] Fixes intput/output files creation for linker tasks - Custom Linker options file should be created on the Mac so we need to execute WriteLinesToFile remotely - All the *.items files from the linker are created on the Mac so we need to execute ReadItemsFromFile remotely - CompileNativeCode: fixes the OutputFile metadata path, otherwise the execution fails; also copies all the files in the declared "IncludeDirectories" to the Mac - Avoids copying input files from Windows to the Mac when running LinkNativeCode since the real input files already exist on the Mac, and Windows contains only empty files just to make MSBuild inputs/outputs check work. If we copy those empty files to the Mac we brake the build. * [msbuild] Minor fixes after merging from main * [dotnet] Adds missing output files to the Xamarin.iOS.Tasks.Windows project The output of this project was missing Messaging build targets and the build agent zip file that are needed to create the dotnet Windows specific pack * [dotnet] Fixes dotnet Windows specific pack generation Ensures the Windows projects are built and the files are copied to the dotnet pack directory before creating the package. It also adds a variable to enable building this pack. * [dotnet] Adds iOS Windows specific pack to iOS only MSI There's only a Windows specific pack for iOS available for now, so we should only add it to the iOS SDK MSI * [dotnet] Create a separate bundle for the iOS Windows MSI We need to do this to avoid including the Windows specific pack in the pkg. Also for now we'll only create an MSI for iOS since it's the only supported platform from Windows. * Fixes spacing issues in Xamarin.iOS.Tasks.csproj * Bumps Touch.Unit back to 05db76 * Fixes formatting problems * [msbuild] Replaces error E0176 by E0186 Because there's a warning W0176 that will overlap with the error * [msbuild] Fixes CompileEntitlements task There were 2 problems: 1- The if statement on the DefaultEntitlementsPath was wrong, because we should return the base value if there's no SessionId (which means the task is running on a Mac) 2- We should copy to the Mac the default entitlements file if no custom file was specified * Several fixes to cleanup the code to support iOS from Windows * Apply suggestions from code review Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com> * Formatting fixes in Xamarin.Messaging.Build * Reverted formatting changes in CompileEntitlements.cs * More formatting fixes * Update msbuild/Messaging/Xamarin.Messaging.Build/Handlers/ExecuteTaskMessageHandler.cs Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com> * Fixes order of MSBuild errors in the resource file * Add newly added localizable strings to canary test of translated strings. * Delete tests that ensure theres code only on the abstract tasks These were needed to ensure all the code was in the base tasks so we could have tasks implementations on Windows to remote those. Now that code is part of this repo (and that is why these tests are failing now) so we do not need them anymore. * [dotnet] Don't build the Windows SDK pack if not configured to do so. Co-authored-by: mag <mauro.agnoletti@gmail.com> Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
2021-02-12 09:43:17 +03:00
nupkgs/$(IOS_WINDOWS_NUGET).%.nupkg: CURRENT_VERSION_NO_METADATA=$(IOS_WINDOWS_NUGET_VERSION_NO_METADATA)
nupkgs/$(IOS_WINDOWS_NUGET).%.nupkg: CURRENT_VERSION_FULL=$(IOS_WINDOWS_NUGET_VERSION_FULL)
Create and publish .NET NuGet packages. (#8576) Create the various NuGet packages to support .NET 5+. The packages are currently empty (and not very useful), but the actual content will come later. The current set of NuGet packages are (this list is duplicated for each platform: iOS, tvOS, watchOS and macOS): * Microsoft.iOS.Sdk: currently contains the basic MSBuild targets files for an MSBuild Project SDK. Will eventually contain all the build logic. Might also eventually contain other tools (mlaunch, bgen, etc.), but these might also end up in a different package. * Microsoft.iOS.Ref: will contain the Xamarin.iOS.dll reference assembly. * Microsoft.iOS.Runtime.[RID]: will contain architecture-specific files (libxamarin*.dylib, the Xamarin.iOS.dll implementation assembly, etc.): The NuGets built on CI are automatically published to a NuGet feed. The versioning for the NuGet packages required a few changes: OS bumps are now changed in Make.versions instead of Make.config (this is explained in the files themselves as well).
2020-05-13 16:23:29 +03:00
[dotnet] Templateify some build logic. (#10618) * [dotnet-linker] Templateify the install logic. * [builds] Templateify the Versions.plist install logic. * [dotnet] Create a per-platform Versions.props file with only the values applicable to that platform. Also move the definition of the default TargetPlatformVersion to Make.versions, where we have other versions. * [dotnet] Templateify some build code.
2021-02-11 22:17:12 +03:00
define NupkgDefinition
nupkgs/$($(1)_NUGET).%.nupkg: CURRENT_VERSION_NO_METADATA=$($(1)_NUGET_VERSION_NO_METADATA)
nupkgs/$($(1)_NUGET).%.nupkg: CURRENT_VERSION_FULL=$($(1)_NUGET_VERSION_FULL)
endef
$(foreach platform,$(DOTNET_PLATFORMS),$(eval $(call NupkgDefinition,$(platform))))
Create and publish .NET NuGet packages. (#8576) Create the various NuGet packages to support .NET 5+. The packages are currently empty (and not very useful), but the actual content will come later. The current set of NuGet packages are (this list is duplicated for each platform: iOS, tvOS, watchOS and macOS): * Microsoft.iOS.Sdk: currently contains the basic MSBuild targets files for an MSBuild Project SDK. Will eventually contain all the build logic. Might also eventually contain other tools (mlaunch, bgen, etc.), but these might also end up in a different package. * Microsoft.iOS.Ref: will contain the Xamarin.iOS.dll reference assembly. * Microsoft.iOS.Runtime.[RID]: will contain architecture-specific files (libxamarin*.dylib, the Xamarin.iOS.dll implementation assembly, etc.): The NuGets built on CI are automatically published to a NuGet feed. The versioning for the NuGet packages required a few changes: OS bumps are now changed in Make.versions instead of Make.config (this is explained in the files themselves as well).
2020-05-13 16:23:29 +03:00
# Create the nuget in a temporary directory (nupkgs/)
[dotnet] Improve incremental builds in make. (#8754) * Be more exact when specifying dependencies for nuget packages: instead of making every package depend on every file within this directory, only make the specific package the files go into depend on those files. This means that if any of these files change, only the package that contains that file will be rebuilt. * Have each package depend on all the files that are to be included in that package. This means that if any other directory adds or updates a file for a nuget, we'll rebuild that nuget here. * Removes packages from the local feed before trying to (re-)add them. This makes them actually install locally, instead of nuget just skipping them, when the version hasn't changed. This was easier to express with make templates than pattern rules, so some of the logic was re-implemented as make templates.
2020-06-04 17:39:19 +03:00
define CreateNuGetTemplate
Make our local .NET the default .NET for the build. (#15086) Make our local .NET the default .NET (in the root's global.json), and then if a directory wants to use the system .NET, then that directory would have to opt-in (using its own global.json). This way we don't have to copy global.json/NuGet.config files around to run tests with the correct .NET setup.
2022-06-07 11:11:02 +03:00
nupkgs/$(1)$(4).$(2).nupkg: $(TEMPLATED_FILES) $(WORKLOAD_TARGETS) $(3) package/$(1)/package.csproj $(wildcard package/*.csproj) $(wildcard $(DOTNET_DESTDIR)/$(1)/* $(DOTNET_DESTDIR)/$(1)/*/* $(DOTNET_DESTDIR)/$(1)/*/*/* $(DOTNET_DESTDIR)/$(1)/*/*/*/*) .stamp-workaround-for-maccore-issue-2427
[dotnet] Improve incremental builds in make. (#8754) * Be more exact when specifying dependencies for nuget packages: instead of making every package depend on every file within this directory, only make the specific package the files go into depend on those files. This means that if any of these files change, only the package that contains that file will be rebuilt. * Have each package depend on all the files that are to be included in that package. This means that if any other directory adds or updates a file for a nuget, we'll rebuild that nuget here. * Removes packages from the local feed before trying to (re-)add them. This makes them actually install locally, instead of nuget just skipping them, when the version hasn't changed. This was easier to express with make templates than pattern rules, so some of the logic was re-implemented as make templates.
2020-06-04 17:39:19 +03:00
@# Delete any versions of the nuget we're building
$$(Q) rm -f nupkgs/$(1).*.nupkg
[dotnet] Rename the DOTNET6 make variable to DOTNET. (#14441) This is the follow-up to where the DOTNET variable was renamed SYSTEM_DOTNET.
2022-03-21 17:56:57 +03:00
$$(Q_PACK) $(DOTNET) pack package/$(1)/package.csproj -p:VersionBand=$(5) --output "$$(dir $$@)" $(DOTNET_PACK_VERBOSITY) "/bl:$$@.binlog"
[dotnet] Improve incremental builds in make. (#8754) * Be more exact when specifying dependencies for nuget packages: instead of making every package depend on every file within this directory, only make the specific package the files go into depend on those files. This means that if any of these files change, only the package that contains that file will be rebuilt. * Have each package depend on all the files that are to be included in that package. This means that if any other directory adds or updates a file for a nuget, we'll rebuild that nuget here. * Removes packages from the local feed before trying to (re-)add them. This makes them actually install locally, instead of nuget just skipping them, when the version hasn't changed. This was easier to express with make templates than pattern rules, so some of the logic was re-implemented as make templates.
2020-06-04 17:39:19 +03:00
endef
[dotnet] Initial support for .NET6 from Windows (#10590) These changes add support for executing iOS and MacDev tasks remotely (on a Mac) when running a build from Windows, and creates a specific .NET6 pack for Windows that's only included in the MSI. For now this only enables builds for the iOS Simulator, physical devices are not yet supported. - Each task decides if it should run locally or remotely depending on the SessionId property, which will only have a value on Windows. - The XMA Build agent is now part of this repo and will be included in the iOS .NET6 Windows pack. - On this first version we're including some Windows specific tasks and references into the Xamarin.iOS.Tasks project for simplicity, but those will be moved to the Windows specific project. ------------ * [msbuild] Adds support for executing Xamarin.iOS tasks from Windows * [msbuild] Adds support for executing Xamarin.MacDev tasks from Windows * Added XMA Build Agent to Xamarin.MacDev.Tasks.sln * Fixes some MSBuild versioning problems * Makes the XMA Build agent load Xamarin.iOS tasks We need to load a type from the iOS tasks assembly so we can run the tasks requested by MSBuild from Windows. We only need to load Xamarin.iOS.Tasks.dll since MacDev.tasks is already embedded in that one. There's a little trick on the csproj, we can't directly use the Xamarin.iOS.Tasks project ref assemblies because that includes both Xamarin.iOS.Tasks.dll and Xamarin.MacDev.Tasks.dll, so the MacDev tasks will collide. We use the project ref only for build dependency purposes but we add an assembly reference to Xamarin.iOS.Tasks.dll. * Added Xamarin.iOS.Tasks.Windows project * Removed unnecessary references on Xamarin.iOS.Tasks.Windows.csproj * Adds Messaging assemblies when ILRepacking Xamarin Tasks The Xamarin Task assemblies now depend on Messaging, so we need the Messaging assemblies to be packed into Xamarin.Mac.Tasks and Xamarin.iOS.Tasks. Also had to remove the direct Messaging dependencies from the build agent since those are already contained in Xamarin.iOS.Tasks * Adds a reference to Messaging.Core targets to the Agent's project * [msbuild] Adds Xamarin iOS Windows targets * [msbuild] Adds missing dependencies to Xamarin.iOS.Tasks This should fix build errors because of missing dependencies. Had to move System.Net.Mqtt.Server from the Build agent project to the tasks one to avoid conflicts with System.Diagnostics.Tracer. * [dotnet] Creates iOS Windows pack Creates a new pack for Windows specific (targets, build agent, etc.) files that shouldn't be installed on the Mac. We have a separate package for this to avoid increasing the core pack size with things that are not needed when using it from macOS. * Fixes type in dotnet makefile * [dotnet] Fixes the iOS Windows pack generation - The windows pack should not include the Sdk and Targets folders - For now we'll just create an iOS pack - Fixes the path to the files to include on the Windows Sdk pack * Added reference to the Windows iOS SDK from the Xamarin.iOS.Common.targets Added a property to navigate to the Windows iOS SDK folder, based on a naming convention that assumes that both packs will always have the same version * Added reference to the core iOS SDK from the Windows iOS SDK Added a property to navigate to the core iOS SDK folder, based on a naming convention that assumes that both packs will always have the same version * Updated Messaging version * Override MessagingBuildClientAssemblyFile property and correctly imported props from targets * [dotnet] Make Windows pack using target files from the output dir We need to take the target files from the output dir to include targets that are part of nuget packages, otherwise we will only include targets from our source * [dotnet] Adds the Windows Sdk pack to the workload manifest * [msbuild] Fixes the Windows Sdk pack name * [dotnet] Merge Mqtt instead of Mqtt.Server We only need System.Net.Mqtt to be merged into Xamarin.iOS.Tasks * Updated Messaging version * [dotnet] Several fixes for the Windows Sdk - Adds missing task CollectMonotouchReferences - Merges more dependencies into Xamarin.iOS.Tasks.dll needed by XMA - Updates the msbuild/Makefile to include files from both the output dir and the source dir - Overrides the agents directory to look for them on the Windows pack * [dotnet] Fixes the XMA Build agent - The build agent is an app so it cannot target ns2.0 - The MSBuild dependencies should be copied into the agent zip file - Avoids copying all the Xamarin iOS SDK core targets into the build agent, since those are not needed - Ensures the broker zip file is copied into the Xamarin.iOS.Windows.Tasks output dir so its included in the Windows pack * Bumps Xamarin.Messaging to 1.2.102 * Adds net6-win branch to trigger builds * Adds Messaging.Client missing dependency to Xamarin.Mac.Tasks * Added Xamarin.Messaging.Apple.Tasks project and VerifyXcodeVersion Task * Fix unloaded Xamarin.Messaging.Build project * Added Build contracts project and unified Xamarin.Messaigng.Apple.Tasks in Xamarin.iOS.Tasks.Windows Also added missing tasks and changes .After.targets * Updated Xamarin.Messaging version * Build agent - reference MSBuild assemblies from the framework Since the assemblies will be included in the build agent we need those to be the ones that come from the framework to be compatible with macOS * [msbuild] Fixes _UpdateDynamicLibraryId target The tasks con this target need to be executed remotely (when building from Windows). * Updates resources * Bump Xamarin.Messaging Fixes problems when executing Exec task remotely * [dotnet] Overrides Publish targets to execute them remotely from Windows The `_CopyResolvedFilesToPublishPreserveNewest` and `_CopyResolvedFilesToPublishAlways` targets essentially copy files into the app bundle. Since those are part of the .NET SDK we need to override those so we can pass to the Copy task the SessionId parameter and then it will be executed remotely when building from Windows. This is done in a Windows.After.targets file so it won't affect builds on macOS. * Added ILMerge to Xamarin.iOS.Tasks.Windows Also modified ILMerge.targets to not include System assemblies because we don't need them on the Windows package * Bumps Messaging This new version of messaging fixes a problem when copying task inputs from Windows to the Mac * [dotnet] Fixes copying files to the Mac when building from Windows When building from Windows there are .NET SDK targets that copy dynamic libraries from the SDK to the intermediate output directory or other files to the publish directory, since we can't control those we can't run them remotely so we need to copy those files to the Mac to ensure other targets will find those. * [dotnet] Fixes how files are copied to the output dir - Before executing `_CopyResolvedFilesToPublishPreserveNewest` and `_CopyResolvedFilesToPublishAlways` we copy the input files for those targets to the Mac - Then we override the original targets to execute the same copy task as the original ones but on the Mac, so the output files are placed in the right location for the following targets to pick them up. * Fixes typo on Xamarin.iOS.Common.After.targets * Bumps Xamarin.Messaging * [msbuild] Fixes VerifyXcodeVersion and ResolveUTIs tasks Both tasks were not being able to connect to the Mac mostly because of ILRepack, there were kind of 2 versions of Xamarin.Messaging, one merged into Xamarin.iOS.Tasks and another one merged into Xamarin.iOS.Windows.Tasks. Because of this the build connection object registered on the task could not be casted to the build connection type. This essentially moves both tasks into the Xamarin.iOS.Tasks assembly to avoid this issue, and as part of that also includes the Messaging contracts into that same project. * [msbuild] Fixes warnings when building from Windows * [dotnet] Adds missing assemblies to merge into Xamarin.iOS.Tasks Those 2 new assemblies will only be used from Windows and we need their implementation instead of the ref assemblies. In the future we will need to find a way of doing this on the Windows only pack insted of doing it on the core Xamarin.iOS.Tasks assembly. * [dotnet] Compute PublishTrimmed on a target We need to do this so the property is evaluated after VS on Windows connects to the Mac, otherwise by default IsMacEnabled is false from Windows. * Bumps Messaging to 1.2.111 * [dotnet] Execute ILLink remotely when building from Windows - Overrides the ILLink task and _RunILLink target to add the hability to execute it remotely, adding input and output properties so files are copied to the server and output files are created on Windows. - This "custom" ILLink task will only be executed from the Windows targets so when building from a Mac it will execute the core SDK task. * [dotnet] Fixes intput/output files creation for linker tasks - Custom Linker options file should be created on the Mac so we need to execute WriteLinesToFile remotely - All the *.items files from the linker are created on the Mac so we need to execute ReadItemsFromFile remotely - CompileNativeCode: fixes the OutputFile metadata path, otherwise the execution fails; also copies all the files in the declared "IncludeDirectories" to the Mac - Avoids copying input files from Windows to the Mac when running LinkNativeCode since the real input files already exist on the Mac, and Windows contains only empty files just to make MSBuild inputs/outputs check work. If we copy those empty files to the Mac we brake the build. * [msbuild] Minor fixes after merging from main * [dotnet] Adds missing output files to the Xamarin.iOS.Tasks.Windows project The output of this project was missing Messaging build targets and the build agent zip file that are needed to create the dotnet Windows specific pack * [dotnet] Fixes dotnet Windows specific pack generation Ensures the Windows projects are built and the files are copied to the dotnet pack directory before creating the package. It also adds a variable to enable building this pack. * [dotnet] Adds iOS Windows specific pack to iOS only MSI There's only a Windows specific pack for iOS available for now, so we should only add it to the iOS SDK MSI * [dotnet] Create a separate bundle for the iOS Windows MSI We need to do this to avoid including the Windows specific pack in the pkg. Also for now we'll only create an MSI for iOS since it's the only supported platform from Windows. * Fixes spacing issues in Xamarin.iOS.Tasks.csproj * Bumps Touch.Unit back to 05db76 * Fixes formatting problems * [msbuild] Replaces error E0176 by E0186 Because there's a warning W0176 that will overlap with the error * [msbuild] Fixes CompileEntitlements task There were 2 problems: 1- The if statement on the DefaultEntitlementsPath was wrong, because we should return the base value if there's no SessionId (which means the task is running on a Mac) 2- We should copy to the Mac the default entitlements file if no custom file was specified * Several fixes to cleanup the code to support iOS from Windows * Apply suggestions from code review Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com> * Formatting fixes in Xamarin.Messaging.Build * Reverted formatting changes in CompileEntitlements.cs * More formatting fixes * Update msbuild/Messaging/Xamarin.Messaging.Build/Handlers/ExecuteTaskMessageHandler.cs Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com> * Fixes order of MSBuild errors in the resource file * Add newly added localizable strings to canary test of translated strings. * Delete tests that ensure theres code only on the abstract tasks These were needed to ensure all the code was in the base tasks so we could have tasks implementations on Windows to remote those. Now that code is part of this repo (and that is why these tests are failing now) so we do not need them anymore. * [dotnet] Don't build the Windows SDK pack if not configured to do so. Co-authored-by: mag <mauro.agnoletti@gmail.com> Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
2021-02-12 09:43:17 +03:00
define CreateWindowsNuGetTemplate
Make our local .NET the default .NET for the build. (#15086) Make our local .NET the default .NET (in the root's global.json), and then if a directory wants to use the system .NET, then that directory would have to opt-in (using its own global.json). This way we don't have to copy global.json/NuGet.config files around to run tests with the correct .NET setup.
2022-06-07 11:11:02 +03:00
nupkgs/$(1).$(2).nupkg: $(3) $(WORKLOAD_TARGETS) package/$(1)/package.csproj $(wildcard package/*.csproj) $(wildcard $(DOTNET_DESTDIR)/$(1)/* $(DOTNET_DESTDIR)/$(1)/*/* $(DOTNET_DESTDIR)/$(1)/*/*/* $(DOTNET_DESTDIR)/$(1)/*/*/*/*) .stamp-workaround-for-maccore-issue-2427
[dotnet] Initial support for .NET6 from Windows (#10590) These changes add support for executing iOS and MacDev tasks remotely (on a Mac) when running a build from Windows, and creates a specific .NET6 pack for Windows that's only included in the MSI. For now this only enables builds for the iOS Simulator, physical devices are not yet supported. - Each task decides if it should run locally or remotely depending on the SessionId property, which will only have a value on Windows. - The XMA Build agent is now part of this repo and will be included in the iOS .NET6 Windows pack. - On this first version we're including some Windows specific tasks and references into the Xamarin.iOS.Tasks project for simplicity, but those will be moved to the Windows specific project. ------------ * [msbuild] Adds support for executing Xamarin.iOS tasks from Windows * [msbuild] Adds support for executing Xamarin.MacDev tasks from Windows * Added XMA Build Agent to Xamarin.MacDev.Tasks.sln * Fixes some MSBuild versioning problems * Makes the XMA Build agent load Xamarin.iOS tasks We need to load a type from the iOS tasks assembly so we can run the tasks requested by MSBuild from Windows. We only need to load Xamarin.iOS.Tasks.dll since MacDev.tasks is already embedded in that one. There's a little trick on the csproj, we can't directly use the Xamarin.iOS.Tasks project ref assemblies because that includes both Xamarin.iOS.Tasks.dll and Xamarin.MacDev.Tasks.dll, so the MacDev tasks will collide. We use the project ref only for build dependency purposes but we add an assembly reference to Xamarin.iOS.Tasks.dll. * Added Xamarin.iOS.Tasks.Windows project * Removed unnecessary references on Xamarin.iOS.Tasks.Windows.csproj * Adds Messaging assemblies when ILRepacking Xamarin Tasks The Xamarin Task assemblies now depend on Messaging, so we need the Messaging assemblies to be packed into Xamarin.Mac.Tasks and Xamarin.iOS.Tasks. Also had to remove the direct Messaging dependencies from the build agent since those are already contained in Xamarin.iOS.Tasks * Adds a reference to Messaging.Core targets to the Agent's project * [msbuild] Adds Xamarin iOS Windows targets * [msbuild] Adds missing dependencies to Xamarin.iOS.Tasks This should fix build errors because of missing dependencies. Had to move System.Net.Mqtt.Server from the Build agent project to the tasks one to avoid conflicts with System.Diagnostics.Tracer. * [dotnet] Creates iOS Windows pack Creates a new pack for Windows specific (targets, build agent, etc.) files that shouldn't be installed on the Mac. We have a separate package for this to avoid increasing the core pack size with things that are not needed when using it from macOS. * Fixes type in dotnet makefile * [dotnet] Fixes the iOS Windows pack generation - The windows pack should not include the Sdk and Targets folders - For now we'll just create an iOS pack - Fixes the path to the files to include on the Windows Sdk pack * Added reference to the Windows iOS SDK from the Xamarin.iOS.Common.targets Added a property to navigate to the Windows iOS SDK folder, based on a naming convention that assumes that both packs will always have the same version * Added reference to the core iOS SDK from the Windows iOS SDK Added a property to navigate to the core iOS SDK folder, based on a naming convention that assumes that both packs will always have the same version * Updated Messaging version * Override MessagingBuildClientAssemblyFile property and correctly imported props from targets * [dotnet] Make Windows pack using target files from the output dir We need to take the target files from the output dir to include targets that are part of nuget packages, otherwise we will only include targets from our source * [dotnet] Adds the Windows Sdk pack to the workload manifest * [msbuild] Fixes the Windows Sdk pack name * [dotnet] Merge Mqtt instead of Mqtt.Server We only need System.Net.Mqtt to be merged into Xamarin.iOS.Tasks * Updated Messaging version * [dotnet] Several fixes for the Windows Sdk - Adds missing task CollectMonotouchReferences - Merges more dependencies into Xamarin.iOS.Tasks.dll needed by XMA - Updates the msbuild/Makefile to include files from both the output dir and the source dir - Overrides the agents directory to look for them on the Windows pack * [dotnet] Fixes the XMA Build agent - The build agent is an app so it cannot target ns2.0 - The MSBuild dependencies should be copied into the agent zip file - Avoids copying all the Xamarin iOS SDK core targets into the build agent, since those are not needed - Ensures the broker zip file is copied into the Xamarin.iOS.Windows.Tasks output dir so its included in the Windows pack * Bumps Xamarin.Messaging to 1.2.102 * Adds net6-win branch to trigger builds * Adds Messaging.Client missing dependency to Xamarin.Mac.Tasks * Added Xamarin.Messaging.Apple.Tasks project and VerifyXcodeVersion Task * Fix unloaded Xamarin.Messaging.Build project * Added Build contracts project and unified Xamarin.Messaigng.Apple.Tasks in Xamarin.iOS.Tasks.Windows Also added missing tasks and changes .After.targets * Updated Xamarin.Messaging version * Build agent - reference MSBuild assemblies from the framework Since the assemblies will be included in the build agent we need those to be the ones that come from the framework to be compatible with macOS * [msbuild] Fixes _UpdateDynamicLibraryId target The tasks con this target need to be executed remotely (when building from Windows). * Updates resources * Bump Xamarin.Messaging Fixes problems when executing Exec task remotely * [dotnet] Overrides Publish targets to execute them remotely from Windows The `_CopyResolvedFilesToPublishPreserveNewest` and `_CopyResolvedFilesToPublishAlways` targets essentially copy files into the app bundle. Since those are part of the .NET SDK we need to override those so we can pass to the Copy task the SessionId parameter and then it will be executed remotely when building from Windows. This is done in a Windows.After.targets file so it won't affect builds on macOS. * Added ILMerge to Xamarin.iOS.Tasks.Windows Also modified ILMerge.targets to not include System assemblies because we don't need them on the Windows package * Bumps Messaging This new version of messaging fixes a problem when copying task inputs from Windows to the Mac * [dotnet] Fixes copying files to the Mac when building from Windows When building from Windows there are .NET SDK targets that copy dynamic libraries from the SDK to the intermediate output directory or other files to the publish directory, since we can't control those we can't run them remotely so we need to copy those files to the Mac to ensure other targets will find those. * [dotnet] Fixes how files are copied to the output dir - Before executing `_CopyResolvedFilesToPublishPreserveNewest` and `_CopyResolvedFilesToPublishAlways` we copy the input files for those targets to the Mac - Then we override the original targets to execute the same copy task as the original ones but on the Mac, so the output files are placed in the right location for the following targets to pick them up. * Fixes typo on Xamarin.iOS.Common.After.targets * Bumps Xamarin.Messaging * [msbuild] Fixes VerifyXcodeVersion and ResolveUTIs tasks Both tasks were not being able to connect to the Mac mostly because of ILRepack, there were kind of 2 versions of Xamarin.Messaging, one merged into Xamarin.iOS.Tasks and another one merged into Xamarin.iOS.Windows.Tasks. Because of this the build connection object registered on the task could not be casted to the build connection type. This essentially moves both tasks into the Xamarin.iOS.Tasks assembly to avoid this issue, and as part of that also includes the Messaging contracts into that same project. * [msbuild] Fixes warnings when building from Windows * [dotnet] Adds missing assemblies to merge into Xamarin.iOS.Tasks Those 2 new assemblies will only be used from Windows and we need their implementation instead of the ref assemblies. In the future we will need to find a way of doing this on the Windows only pack insted of doing it on the core Xamarin.iOS.Tasks assembly. * [dotnet] Compute PublishTrimmed on a target We need to do this so the property is evaluated after VS on Windows connects to the Mac, otherwise by default IsMacEnabled is false from Windows. * Bumps Messaging to 1.2.111 * [dotnet] Execute ILLink remotely when building from Windows - Overrides the ILLink task and _RunILLink target to add the hability to execute it remotely, adding input and output properties so files are copied to the server and output files are created on Windows. - This "custom" ILLink task will only be executed from the Windows targets so when building from a Mac it will execute the core SDK task. * [dotnet] Fixes intput/output files creation for linker tasks - Custom Linker options file should be created on the Mac so we need to execute WriteLinesToFile remotely - All the *.items files from the linker are created on the Mac so we need to execute ReadItemsFromFile remotely - CompileNativeCode: fixes the OutputFile metadata path, otherwise the execution fails; also copies all the files in the declared "IncludeDirectories" to the Mac - Avoids copying input files from Windows to the Mac when running LinkNativeCode since the real input files already exist on the Mac, and Windows contains only empty files just to make MSBuild inputs/outputs check work. If we copy those empty files to the Mac we brake the build. * [msbuild] Minor fixes after merging from main * [dotnet] Adds missing output files to the Xamarin.iOS.Tasks.Windows project The output of this project was missing Messaging build targets and the build agent zip file that are needed to create the dotnet Windows specific pack * [dotnet] Fixes dotnet Windows specific pack generation Ensures the Windows projects are built and the files are copied to the dotnet pack directory before creating the package. It also adds a variable to enable building this pack. * [dotnet] Adds iOS Windows specific pack to iOS only MSI There's only a Windows specific pack for iOS available for now, so we should only add it to the iOS SDK MSI * [dotnet] Create a separate bundle for the iOS Windows MSI We need to do this to avoid including the Windows specific pack in the pkg. Also for now we'll only create an MSI for iOS since it's the only supported platform from Windows. * Fixes spacing issues in Xamarin.iOS.Tasks.csproj * Bumps Touch.Unit back to 05db76 * Fixes formatting problems * [msbuild] Replaces error E0176 by E0186 Because there's a warning W0176 that will overlap with the error * [msbuild] Fixes CompileEntitlements task There were 2 problems: 1- The if statement on the DefaultEntitlementsPath was wrong, because we should return the base value if there's no SessionId (which means the task is running on a Mac) 2- We should copy to the Mac the default entitlements file if no custom file was specified * Several fixes to cleanup the code to support iOS from Windows * Apply suggestions from code review Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com> * Formatting fixes in Xamarin.Messaging.Build * Reverted formatting changes in CompileEntitlements.cs * More formatting fixes * Update msbuild/Messaging/Xamarin.Messaging.Build/Handlers/ExecuteTaskMessageHandler.cs Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com> * Fixes order of MSBuild errors in the resource file * Add newly added localizable strings to canary test of translated strings. * Delete tests that ensure theres code only on the abstract tasks These were needed to ensure all the code was in the base tasks so we could have tasks implementations on Windows to remote those. Now that code is part of this repo (and that is why these tests are failing now) so we do not need them anymore. * [dotnet] Don't build the Windows SDK pack if not configured to do so. Co-authored-by: mag <mauro.agnoletti@gmail.com> Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
2021-02-12 09:43:17 +03:00
@# Delete any versions of the nuget we're building
$$(Q) rm -f nupkgs/$(1).*.nupkg
[dotnet] Rename the DOTNET6 make variable to DOTNET. (#14441) This is the follow-up to where the DOTNET variable was renamed SYSTEM_DOTNET.
2022-03-21 17:56:57 +03:00
$$(Q_PACK) $(DOTNET) pack package/$(1)/package.csproj --output "$$(dir $$@)" $(DOTNET_PACK_VERBOSITY) "/bl:$$@.binlog"
[dotnet] Initial support for .NET6 from Windows (#10590) These changes add support for executing iOS and MacDev tasks remotely (on a Mac) when running a build from Windows, and creates a specific .NET6 pack for Windows that's only included in the MSI. For now this only enables builds for the iOS Simulator, physical devices are not yet supported. - Each task decides if it should run locally or remotely depending on the SessionId property, which will only have a value on Windows. - The XMA Build agent is now part of this repo and will be included in the iOS .NET6 Windows pack. - On this first version we're including some Windows specific tasks and references into the Xamarin.iOS.Tasks project for simplicity, but those will be moved to the Windows specific project. ------------ * [msbuild] Adds support for executing Xamarin.iOS tasks from Windows * [msbuild] Adds support for executing Xamarin.MacDev tasks from Windows * Added XMA Build Agent to Xamarin.MacDev.Tasks.sln * Fixes some MSBuild versioning problems * Makes the XMA Build agent load Xamarin.iOS tasks We need to load a type from the iOS tasks assembly so we can run the tasks requested by MSBuild from Windows. We only need to load Xamarin.iOS.Tasks.dll since MacDev.tasks is already embedded in that one. There's a little trick on the csproj, we can't directly use the Xamarin.iOS.Tasks project ref assemblies because that includes both Xamarin.iOS.Tasks.dll and Xamarin.MacDev.Tasks.dll, so the MacDev tasks will collide. We use the project ref only for build dependency purposes but we add an assembly reference to Xamarin.iOS.Tasks.dll. * Added Xamarin.iOS.Tasks.Windows project * Removed unnecessary references on Xamarin.iOS.Tasks.Windows.csproj * Adds Messaging assemblies when ILRepacking Xamarin Tasks The Xamarin Task assemblies now depend on Messaging, so we need the Messaging assemblies to be packed into Xamarin.Mac.Tasks and Xamarin.iOS.Tasks. Also had to remove the direct Messaging dependencies from the build agent since those are already contained in Xamarin.iOS.Tasks * Adds a reference to Messaging.Core targets to the Agent's project * [msbuild] Adds Xamarin iOS Windows targets * [msbuild] Adds missing dependencies to Xamarin.iOS.Tasks This should fix build errors because of missing dependencies. Had to move System.Net.Mqtt.Server from the Build agent project to the tasks one to avoid conflicts with System.Diagnostics.Tracer. * [dotnet] Creates iOS Windows pack Creates a new pack for Windows specific (targets, build agent, etc.) files that shouldn't be installed on the Mac. We have a separate package for this to avoid increasing the core pack size with things that are not needed when using it from macOS. * Fixes type in dotnet makefile * [dotnet] Fixes the iOS Windows pack generation - The windows pack should not include the Sdk and Targets folders - For now we'll just create an iOS pack - Fixes the path to the files to include on the Windows Sdk pack * Added reference to the Windows iOS SDK from the Xamarin.iOS.Common.targets Added a property to navigate to the Windows iOS SDK folder, based on a naming convention that assumes that both packs will always have the same version * Added reference to the core iOS SDK from the Windows iOS SDK Added a property to navigate to the core iOS SDK folder, based on a naming convention that assumes that both packs will always have the same version * Updated Messaging version * Override MessagingBuildClientAssemblyFile property and correctly imported props from targets * [dotnet] Make Windows pack using target files from the output dir We need to take the target files from the output dir to include targets that are part of nuget packages, otherwise we will only include targets from our source * [dotnet] Adds the Windows Sdk pack to the workload manifest * [msbuild] Fixes the Windows Sdk pack name * [dotnet] Merge Mqtt instead of Mqtt.Server We only need System.Net.Mqtt to be merged into Xamarin.iOS.Tasks * Updated Messaging version * [dotnet] Several fixes for the Windows Sdk - Adds missing task CollectMonotouchReferences - Merges more dependencies into Xamarin.iOS.Tasks.dll needed by XMA - Updates the msbuild/Makefile to include files from both the output dir and the source dir - Overrides the agents directory to look for them on the Windows pack * [dotnet] Fixes the XMA Build agent - The build agent is an app so it cannot target ns2.0 - The MSBuild dependencies should be copied into the agent zip file - Avoids copying all the Xamarin iOS SDK core targets into the build agent, since those are not needed - Ensures the broker zip file is copied into the Xamarin.iOS.Windows.Tasks output dir so its included in the Windows pack * Bumps Xamarin.Messaging to 1.2.102 * Adds net6-win branch to trigger builds * Adds Messaging.Client missing dependency to Xamarin.Mac.Tasks * Added Xamarin.Messaging.Apple.Tasks project and VerifyXcodeVersion Task * Fix unloaded Xamarin.Messaging.Build project * Added Build contracts project and unified Xamarin.Messaigng.Apple.Tasks in Xamarin.iOS.Tasks.Windows Also added missing tasks and changes .After.targets * Updated Xamarin.Messaging version * Build agent - reference MSBuild assemblies from the framework Since the assemblies will be included in the build agent we need those to be the ones that come from the framework to be compatible with macOS * [msbuild] Fixes _UpdateDynamicLibraryId target The tasks con this target need to be executed remotely (when building from Windows). * Updates resources * Bump Xamarin.Messaging Fixes problems when executing Exec task remotely * [dotnet] Overrides Publish targets to execute them remotely from Windows The `_CopyResolvedFilesToPublishPreserveNewest` and `_CopyResolvedFilesToPublishAlways` targets essentially copy files into the app bundle. Since those are part of the .NET SDK we need to override those so we can pass to the Copy task the SessionId parameter and then it will be executed remotely when building from Windows. This is done in a Windows.After.targets file so it won't affect builds on macOS. * Added ILMerge to Xamarin.iOS.Tasks.Windows Also modified ILMerge.targets to not include System assemblies because we don't need them on the Windows package * Bumps Messaging This new version of messaging fixes a problem when copying task inputs from Windows to the Mac * [dotnet] Fixes copying files to the Mac when building from Windows When building from Windows there are .NET SDK targets that copy dynamic libraries from the SDK to the intermediate output directory or other files to the publish directory, since we can't control those we can't run them remotely so we need to copy those files to the Mac to ensure other targets will find those. * [dotnet] Fixes how files are copied to the output dir - Before executing `_CopyResolvedFilesToPublishPreserveNewest` and `_CopyResolvedFilesToPublishAlways` we copy the input files for those targets to the Mac - Then we override the original targets to execute the same copy task as the original ones but on the Mac, so the output files are placed in the right location for the following targets to pick them up. * Fixes typo on Xamarin.iOS.Common.After.targets * Bumps Xamarin.Messaging * [msbuild] Fixes VerifyXcodeVersion and ResolveUTIs tasks Both tasks were not being able to connect to the Mac mostly because of ILRepack, there were kind of 2 versions of Xamarin.Messaging, one merged into Xamarin.iOS.Tasks and another one merged into Xamarin.iOS.Windows.Tasks. Because of this the build connection object registered on the task could not be casted to the build connection type. This essentially moves both tasks into the Xamarin.iOS.Tasks assembly to avoid this issue, and as part of that also includes the Messaging contracts into that same project. * [msbuild] Fixes warnings when building from Windows * [dotnet] Adds missing assemblies to merge into Xamarin.iOS.Tasks Those 2 new assemblies will only be used from Windows and we need their implementation instead of the ref assemblies. In the future we will need to find a way of doing this on the Windows only pack insted of doing it on the core Xamarin.iOS.Tasks assembly. * [dotnet] Compute PublishTrimmed on a target We need to do this so the property is evaluated after VS on Windows connects to the Mac, otherwise by default IsMacEnabled is false from Windows. * Bumps Messaging to 1.2.111 * [dotnet] Execute ILLink remotely when building from Windows - Overrides the ILLink task and _RunILLink target to add the hability to execute it remotely, adding input and output properties so files are copied to the server and output files are created on Windows. - This "custom" ILLink task will only be executed from the Windows targets so when building from a Mac it will execute the core SDK task. * [dotnet] Fixes intput/output files creation for linker tasks - Custom Linker options file should be created on the Mac so we need to execute WriteLinesToFile remotely - All the *.items files from the linker are created on the Mac so we need to execute ReadItemsFromFile remotely - CompileNativeCode: fixes the OutputFile metadata path, otherwise the execution fails; also copies all the files in the declared "IncludeDirectories" to the Mac - Avoids copying input files from Windows to the Mac when running LinkNativeCode since the real input files already exist on the Mac, and Windows contains only empty files just to make MSBuild inputs/outputs check work. If we copy those empty files to the Mac we brake the build. * [msbuild] Minor fixes after merging from main * [dotnet] Adds missing output files to the Xamarin.iOS.Tasks.Windows project The output of this project was missing Messaging build targets and the build agent zip file that are needed to create the dotnet Windows specific pack * [dotnet] Fixes dotnet Windows specific pack generation Ensures the Windows projects are built and the files are copied to the dotnet pack directory before creating the package. It also adds a variable to enable building this pack. * [dotnet] Adds iOS Windows specific pack to iOS only MSI There's only a Windows specific pack for iOS available for now, so we should only add it to the iOS SDK MSI * [dotnet] Create a separate bundle for the iOS Windows MSI We need to do this to avoid including the Windows specific pack in the pkg. Also for now we'll only create an MSI for iOS since it's the only supported platform from Windows. * Fixes spacing issues in Xamarin.iOS.Tasks.csproj * Bumps Touch.Unit back to 05db76 * Fixes formatting problems * [msbuild] Replaces error E0176 by E0186 Because there's a warning W0176 that will overlap with the error * [msbuild] Fixes CompileEntitlements task There were 2 problems: 1- The if statement on the DefaultEntitlementsPath was wrong, because we should return the base value if there's no SessionId (which means the task is running on a Mac) 2- We should copy to the Mac the default entitlements file if no custom file was specified * Several fixes to cleanup the code to support iOS from Windows * Apply suggestions from code review Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com> * Formatting fixes in Xamarin.Messaging.Build * Reverted formatting changes in CompileEntitlements.cs * More formatting fixes * Update msbuild/Messaging/Xamarin.Messaging.Build/Handlers/ExecuteTaskMessageHandler.cs Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com> * Fixes order of MSBuild errors in the resource file * Add newly added localizable strings to canary test of translated strings. * Delete tests that ensure theres code only on the abstract tasks These were needed to ensure all the code was in the base tasks so we could have tasks implementations on Windows to remote those. Now that code is part of this repo (and that is why these tests are failing now) so we do not need them anymore. * [dotnet] Don't build the Windows SDK pack if not configured to do so. Co-authored-by: mag <mauro.agnoletti@gmail.com> Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
2021-02-12 09:43:17 +03:00
endef
[dotnet] Improve incremental builds in make. (#8754) * Be more exact when specifying dependencies for nuget packages: instead of making every package depend on every file within this directory, only make the specific package the files go into depend on those files. This means that if any of these files change, only the package that contains that file will be rebuilt. * Have each package depend on all the files that are to be included in that package. This means that if any other directory adds or updates a file for a nuget, we'll rebuild that nuget here. * Removes packages from the local feed before trying to (re-)add them. This makes them actually install locally, instead of nuget just skipping them, when the version hasn't changed. This was easier to express with make templates than pattern rules, so some of the logic was re-implemented as make templates.
2020-06-04 17:39:19 +03:00
# Create the NuGet packaging targets. It's amazing what make allows you to do...
[.NET] Rename several DOTNET6_* variables to to DOTNET_*. (#14463) Also rename DOTNET_VERSION to SYSTEM_DOTNET_VERSION to make it clear what it's referring to (and to not clash with DOTNET6_VERSION which has now been renamed to DOTNET_VERSION). .NET 7 is right around the corner.
2022-03-23 10:07:34 +03:00
$(foreach platform,$(DOTNET_PLATFORMS),$(eval $(call CreateNuGetTemplate,Microsoft.$(platform).Sdk,$($(platform)_NUGET_VERSION_NO_METADATA),$($(platform)_NUGET_TARGETS),,$(DOTNET_VERSION_BAND))))
$(foreach platform,$(DOTNET_WINDOWS_PLATFORMS),$(eval $(call CreateWindowsNuGetTemplate,Microsoft.$(platform).Windows.Sdk,$(IOS_WINDOWS_NUGET_VERSION_NO_METADATA),$($(platform)_WINDOWS_NUGET_TARGETS),,$(DOTNET_VERSION_BAND))))
$(foreach platform,$(DOTNET_PLATFORMS),$(eval $(call CreateNuGetTemplate,Microsoft.$(platform).Ref,$($(platform)_NUGET_VERSION_NO_METADATA),,,$(DOTNET_VERSION_BAND))))
$(foreach platform,$(DOTNET_PLATFORMS),$(eval $(call CreateNuGetTemplate,Microsoft.$(platform).Templates,$($(platform)_NUGET_VERSION_NO_METADATA),,,$(DOTNET_VERSION_BAND))))
Use the MANIFEST_VERSION_BAND for the manifests (#13386) It appears that the package IDs for the manifests retain the main .NET version band, such as 100 and 200, and the packs use the full version of 101 or 203. This PR just uses the version band for the manifest packages. Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
2021-11-19 11:24:30 +03:00
$(foreach platform,$(DOTNET_PLATFORMS),$(eval $(call CreateNuGetTemplate,Microsoft.NET.Sdk.$(platform),$($(platform)_NUGET_VERSION_NO_METADATA),,.Manifest-$(MANIFEST_VERSION_BAND),$(MANIFEST_VERSION_BAND))))
[.NET] Rename several DOTNET6_* variables to to DOTNET_*. (#14463) Also rename DOTNET_VERSION to SYSTEM_DOTNET_VERSION to make it clear what it's referring to (and to not clash with DOTNET6_VERSION which has now been renamed to DOTNET_VERSION). .NET 7 is right around the corner.
2022-03-23 10:07:34 +03:00
$(foreach platform,$(DOTNET_PLATFORMS),$(foreach rid,$(DOTNET_$(platform)_RUNTIME_IDENTIFIERS),$(eval $(call CreateNuGetTemplate,Microsoft.$(platform).Runtime.$(rid),$($(platform)_NUGET_VERSION_NO_METADATA),,,$(DOTNET_VERSION_BAND)))))
Create and publish .NET NuGet packages. (#8576) Create the various NuGet packages to support .NET 5+. The packages are currently empty (and not very useful), but the actual content will come later. The current set of NuGet packages are (this list is duplicated for each platform: iOS, tvOS, watchOS and macOS): * Microsoft.iOS.Sdk: currently contains the basic MSBuild targets files for an MSBuild Project SDK. Will eventually contain all the build logic. Might also eventually contain other tools (mlaunch, bgen, etc.), but these might also end up in a different package. * Microsoft.iOS.Ref: will contain the Xamarin.iOS.dll reference assembly. * Microsoft.iOS.Runtime.[RID]: will contain architecture-specific files (libxamarin*.dylib, the Xamarin.iOS.dll implementation assembly, etc.): The NuGets built on CI are automatically published to a NuGet feed. The versioning for the NuGet packages required a few changes: OS bumps are now changed in Make.versions instead of Make.config (this is explained in the files themselves as well).
2020-05-13 16:23:29 +03:00
# Copy the nuget from the temporary directory into the final directory
$(DOTNET_NUPKG_DIR)/%.nupkg: nupkgs/%.nupkg | $(DOTNET_NUPKG_DIR)
[dotnet] Improve incremental builds in make. (#8754) * Be more exact when specifying dependencies for nuget packages: instead of making every package depend on every file within this directory, only make the specific package the files go into depend on those files. This means that if any of these files change, only the package that contains that file will be rebuilt. * Have each package depend on all the files that are to be included in that package. This means that if any other directory adds or updates a file for a nuget, we'll rebuild that nuget here. * Removes packages from the local feed before trying to (re-)add them. This makes them actually install locally, instead of nuget just skipping them, when the version hasn't changed. This was easier to express with make templates than pattern rules, so some of the logic was re-implemented as make templates.
2020-06-04 17:39:19 +03:00
$(Q) $(CP) $< $@
Create and publish .NET NuGet packages. (#8576) Create the various NuGet packages to support .NET 5+. The packages are currently empty (and not very useful), but the actual content will come later. The current set of NuGet packages are (this list is duplicated for each platform: iOS, tvOS, watchOS and macOS): * Microsoft.iOS.Sdk: currently contains the basic MSBuild targets files for an MSBuild Project SDK. Will eventually contain all the build logic. Might also eventually contain other tools (mlaunch, bgen, etc.), but these might also end up in a different package. * Microsoft.iOS.Ref: will contain the Xamarin.iOS.dll reference assembly. * Microsoft.iOS.Runtime.[RID]: will contain architecture-specific files (libxamarin*.dylib, the Xamarin.iOS.dll implementation assembly, etc.): The NuGets built on CI are automatically published to a NuGet feed. The versioning for the NuGet packages required a few changes: OS bumps are now changed in Make.versions instead of Make.config (this is explained in the files themselves as well).
2020-05-13 16:23:29 +03:00
[build] Skip building stuff that isn't enabled. (#11385)
2021-04-30 08:51:58 +03:00
ifdef INCLUDE_IOS
[CI] Add Prepare Release and VS Insertion stages (again) (#12157) Context: xamarin/yaml-templates#117 Updates the .NET 6 NuGet packaging steps to exclude package metadata, as the .msi conversion tooling does not process .nupkg file names with the +sha.commit metadata. Two new stages have been added to facilitate the Visual Studio setup authoring process. The first stage named "Prepare Release" will sign the .NET 6 NuGet package content (inside and out), convert relevant packages to .msi installers, generate Visual Studio manifests for the .msi installers, and push the signed packages to the xamarin-impl feed. The new SignList.xml file is required for our NuGet signing templates. The new xamarin-workload.props file contains version information and other metadata required to generate a Visual Studio manifest. The second stage starts with a manual validation task. This task will pause and wait for someone to click a "Resume" or "Reject" button that will appear on the pipeline UI. This task is configured to be rejected after waiting for two days, but it can be manually re-ran at a later date if we want to trigger VS insertion for an older build. If the manual validation task is approved, a VS Drop will be created containing all .NET 6 .msi files. This Drop URL can then be used to update our component versions in Visual Studio. This last piece is currently manual as we will initially be introducing new components, however we should be able to automate VS PR creation in the future. Commit 09f911b missed adding the PR build check condition to a step in sign-and-notarized.yml, causing PR builds from forks to fail. We can fix this by adding in the missing condition.
2021-07-21 20:09:29 +03:00
SDK_PACK_IOS_WINDOWS = $(DOTNET_NUPKG_DIR)/$(IOS_WINDOWS_NUGET).Sdk.$(IOS_WINDOWS_NUGET_VERSION_NO_METADATA).nupkg
[msbuild/dotnet] Build the Xamarin.PreBuilt.iOS app bundle. Fixes #12945. (#13342) Build the Xamarin.PreBuilt.iOS app bundle instead of using a prebuilt bundle. This makes sure that we're always using the latest BCL. Some accurate build massaging was needed, because: * To build the prebuilt app we need the iOS workload installed (into our build-local .NET installation). * The iOS workload contains the Microsoft.iOS.Windows.Sdk pack. * The Microsoft.iOS.Windows.Sdk pack contains the prebuilt app. Thus we had a circular reference. Fortunately, the Microsoft.iOS.Windows.Sdk pack is only required on Windows, which means we can break this circular reference by: * Mark Microsoft.iOS.Windows.Sdk pack as only to be installed on Windows (unfortunately it seems we have to list the exact runtime identifiers for the platforms where to install the pack, so we can't do something like "win-*", but new variations of the "win-*" runtime identifier shouldn't show up all that often). * Build the prebuilt app on macOS. This way we don't need the Microsoft.iOS.Windows.Sdk pack when installing the iOS workload locally. The .NET build order is now: * Build general sdk, runtime and ref packs for .NET. * Build the prebuilt app. * Build the Microsoft.iOS.Windows.Sdk pack. Fixes https://github.com/xamarin/xamarin-macios/issues/12945.
2021-11-12 09:38:07 +03:00
SDK_PACKS_WINDOWS += $(SDK_PACK_IOS_WINDOWS)
[dotnet] Initial support for .NET6 from Windows (#10590) These changes add support for executing iOS and MacDev tasks remotely (on a Mac) when running a build from Windows, and creates a specific .NET6 pack for Windows that's only included in the MSI. For now this only enables builds for the iOS Simulator, physical devices are not yet supported. - Each task decides if it should run locally or remotely depending on the SessionId property, which will only have a value on Windows. - The XMA Build agent is now part of this repo and will be included in the iOS .NET6 Windows pack. - On this first version we're including some Windows specific tasks and references into the Xamarin.iOS.Tasks project for simplicity, but those will be moved to the Windows specific project. ------------ * [msbuild] Adds support for executing Xamarin.iOS tasks from Windows * [msbuild] Adds support for executing Xamarin.MacDev tasks from Windows * Added XMA Build Agent to Xamarin.MacDev.Tasks.sln * Fixes some MSBuild versioning problems * Makes the XMA Build agent load Xamarin.iOS tasks We need to load a type from the iOS tasks assembly so we can run the tasks requested by MSBuild from Windows. We only need to load Xamarin.iOS.Tasks.dll since MacDev.tasks is already embedded in that one. There's a little trick on the csproj, we can't directly use the Xamarin.iOS.Tasks project ref assemblies because that includes both Xamarin.iOS.Tasks.dll and Xamarin.MacDev.Tasks.dll, so the MacDev tasks will collide. We use the project ref only for build dependency purposes but we add an assembly reference to Xamarin.iOS.Tasks.dll. * Added Xamarin.iOS.Tasks.Windows project * Removed unnecessary references on Xamarin.iOS.Tasks.Windows.csproj * Adds Messaging assemblies when ILRepacking Xamarin Tasks The Xamarin Task assemblies now depend on Messaging, so we need the Messaging assemblies to be packed into Xamarin.Mac.Tasks and Xamarin.iOS.Tasks. Also had to remove the direct Messaging dependencies from the build agent since those are already contained in Xamarin.iOS.Tasks * Adds a reference to Messaging.Core targets to the Agent's project * [msbuild] Adds Xamarin iOS Windows targets * [msbuild] Adds missing dependencies to Xamarin.iOS.Tasks This should fix build errors because of missing dependencies. Had to move System.Net.Mqtt.Server from the Build agent project to the tasks one to avoid conflicts with System.Diagnostics.Tracer. * [dotnet] Creates iOS Windows pack Creates a new pack for Windows specific (targets, build agent, etc.) files that shouldn't be installed on the Mac. We have a separate package for this to avoid increasing the core pack size with things that are not needed when using it from macOS. * Fixes type in dotnet makefile * [dotnet] Fixes the iOS Windows pack generation - The windows pack should not include the Sdk and Targets folders - For now we'll just create an iOS pack - Fixes the path to the files to include on the Windows Sdk pack * Added reference to the Windows iOS SDK from the Xamarin.iOS.Common.targets Added a property to navigate to the Windows iOS SDK folder, based on a naming convention that assumes that both packs will always have the same version * Added reference to the core iOS SDK from the Windows iOS SDK Added a property to navigate to the core iOS SDK folder, based on a naming convention that assumes that both packs will always have the same version * Updated Messaging version * Override MessagingBuildClientAssemblyFile property and correctly imported props from targets * [dotnet] Make Windows pack using target files from the output dir We need to take the target files from the output dir to include targets that are part of nuget packages, otherwise we will only include targets from our source * [dotnet] Adds the Windows Sdk pack to the workload manifest * [msbuild] Fixes the Windows Sdk pack name * [dotnet] Merge Mqtt instead of Mqtt.Server We only need System.Net.Mqtt to be merged into Xamarin.iOS.Tasks * Updated Messaging version * [dotnet] Several fixes for the Windows Sdk - Adds missing task CollectMonotouchReferences - Merges more dependencies into Xamarin.iOS.Tasks.dll needed by XMA - Updates the msbuild/Makefile to include files from both the output dir and the source dir - Overrides the agents directory to look for them on the Windows pack * [dotnet] Fixes the XMA Build agent - The build agent is an app so it cannot target ns2.0 - The MSBuild dependencies should be copied into the agent zip file - Avoids copying all the Xamarin iOS SDK core targets into the build agent, since those are not needed - Ensures the broker zip file is copied into the Xamarin.iOS.Windows.Tasks output dir so its included in the Windows pack * Bumps Xamarin.Messaging to 1.2.102 * Adds net6-win branch to trigger builds * Adds Messaging.Client missing dependency to Xamarin.Mac.Tasks * Added Xamarin.Messaging.Apple.Tasks project and VerifyXcodeVersion Task * Fix unloaded Xamarin.Messaging.Build project * Added Build contracts project and unified Xamarin.Messaigng.Apple.Tasks in Xamarin.iOS.Tasks.Windows Also added missing tasks and changes .After.targets * Updated Xamarin.Messaging version * Build agent - reference MSBuild assemblies from the framework Since the assemblies will be included in the build agent we need those to be the ones that come from the framework to be compatible with macOS * [msbuild] Fixes _UpdateDynamicLibraryId target The tasks con this target need to be executed remotely (when building from Windows). * Updates resources * Bump Xamarin.Messaging Fixes problems when executing Exec task remotely * [dotnet] Overrides Publish targets to execute them remotely from Windows The `_CopyResolvedFilesToPublishPreserveNewest` and `_CopyResolvedFilesToPublishAlways` targets essentially copy files into the app bundle. Since those are part of the .NET SDK we need to override those so we can pass to the Copy task the SessionId parameter and then it will be executed remotely when building from Windows. This is done in a Windows.After.targets file so it won't affect builds on macOS. * Added ILMerge to Xamarin.iOS.Tasks.Windows Also modified ILMerge.targets to not include System assemblies because we don't need them on the Windows package * Bumps Messaging This new version of messaging fixes a problem when copying task inputs from Windows to the Mac * [dotnet] Fixes copying files to the Mac when building from Windows When building from Windows there are .NET SDK targets that copy dynamic libraries from the SDK to the intermediate output directory or other files to the publish directory, since we can't control those we can't run them remotely so we need to copy those files to the Mac to ensure other targets will find those. * [dotnet] Fixes how files are copied to the output dir - Before executing `_CopyResolvedFilesToPublishPreserveNewest` and `_CopyResolvedFilesToPublishAlways` we copy the input files for those targets to the Mac - Then we override the original targets to execute the same copy task as the original ones but on the Mac, so the output files are placed in the right location for the following targets to pick them up. * Fixes typo on Xamarin.iOS.Common.After.targets * Bumps Xamarin.Messaging * [msbuild] Fixes VerifyXcodeVersion and ResolveUTIs tasks Both tasks were not being able to connect to the Mac mostly because of ILRepack, there were kind of 2 versions of Xamarin.Messaging, one merged into Xamarin.iOS.Tasks and another one merged into Xamarin.iOS.Windows.Tasks. Because of this the build connection object registered on the task could not be casted to the build connection type. This essentially moves both tasks into the Xamarin.iOS.Tasks assembly to avoid this issue, and as part of that also includes the Messaging contracts into that same project. * [msbuild] Fixes warnings when building from Windows * [dotnet] Adds missing assemblies to merge into Xamarin.iOS.Tasks Those 2 new assemblies will only be used from Windows and we need their implementation instead of the ref assemblies. In the future we will need to find a way of doing this on the Windows only pack insted of doing it on the core Xamarin.iOS.Tasks assembly. * [dotnet] Compute PublishTrimmed on a target We need to do this so the property is evaluated after VS on Windows connects to the Mac, otherwise by default IsMacEnabled is false from Windows. * Bumps Messaging to 1.2.111 * [dotnet] Execute ILLink remotely when building from Windows - Overrides the ILLink task and _RunILLink target to add the hability to execute it remotely, adding input and output properties so files are copied to the server and output files are created on Windows. - This "custom" ILLink task will only be executed from the Windows targets so when building from a Mac it will execute the core SDK task. * [dotnet] Fixes intput/output files creation for linker tasks - Custom Linker options file should be created on the Mac so we need to execute WriteLinesToFile remotely - All the *.items files from the linker are created on the Mac so we need to execute ReadItemsFromFile remotely - CompileNativeCode: fixes the OutputFile metadata path, otherwise the execution fails; also copies all the files in the declared "IncludeDirectories" to the Mac - Avoids copying input files from Windows to the Mac when running LinkNativeCode since the real input files already exist on the Mac, and Windows contains only empty files just to make MSBuild inputs/outputs check work. If we copy those empty files to the Mac we brake the build. * [msbuild] Minor fixes after merging from main * [dotnet] Adds missing output files to the Xamarin.iOS.Tasks.Windows project The output of this project was missing Messaging build targets and the build agent zip file that are needed to create the dotnet Windows specific pack * [dotnet] Fixes dotnet Windows specific pack generation Ensures the Windows projects are built and the files are copied to the dotnet pack directory before creating the package. It also adds a variable to enable building this pack. * [dotnet] Adds iOS Windows specific pack to iOS only MSI There's only a Windows specific pack for iOS available for now, so we should only add it to the iOS SDK MSI * [dotnet] Create a separate bundle for the iOS Windows MSI We need to do this to avoid including the Windows specific pack in the pkg. Also for now we'll only create an MSI for iOS since it's the only supported platform from Windows. * Fixes spacing issues in Xamarin.iOS.Tasks.csproj * Bumps Touch.Unit back to 05db76 * Fixes formatting problems * [msbuild] Replaces error E0176 by E0186 Because there's a warning W0176 that will overlap with the error * [msbuild] Fixes CompileEntitlements task There were 2 problems: 1- The if statement on the DefaultEntitlementsPath was wrong, because we should return the base value if there's no SessionId (which means the task is running on a Mac) 2- We should copy to the Mac the default entitlements file if no custom file was specified * Several fixes to cleanup the code to support iOS from Windows * Apply suggestions from code review Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com> * Formatting fixes in Xamarin.Messaging.Build * Reverted formatting changes in CompileEntitlements.cs * More formatting fixes * Update msbuild/Messaging/Xamarin.Messaging.Build/Handlers/ExecuteTaskMessageHandler.cs Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com> * Fixes order of MSBuild errors in the resource file * Add newly added localizable strings to canary test of translated strings. * Delete tests that ensure theres code only on the abstract tasks These were needed to ensure all the code was in the base tasks so we could have tasks implementations on Windows to remote those. Now that code is part of this repo (and that is why these tests are failing now) so we do not need them anymore. * [dotnet] Don't build the Windows SDK pack if not configured to do so. Co-authored-by: mag <mauro.agnoletti@gmail.com> Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
2021-02-12 09:43:17 +03:00
endif
pack-ios-windows: $(SDK_PACK_IOS_WINDOWS)
[dotnet] Templateify some build logic. (#10618) * [dotnet-linker] Templateify the install logic. * [builds] Templateify the Versions.plist install logic. * [dotnet] Create a per-platform Versions.props file with only the values applicable to that platform. Also move the definition of the default TargetPlatformVersion to Make.versions, where we have other versions. * [dotnet] Templateify some build code.
2021-02-11 22:17:12 +03:00
define PacksDefinitions
[CI] Add Prepare Release and VS Insertion stages (again) (#12157) Context: xamarin/yaml-templates#117 Updates the .NET 6 NuGet packaging steps to exclude package metadata, as the .msi conversion tooling does not process .nupkg file names with the +sha.commit metadata. Two new stages have been added to facilitate the Visual Studio setup authoring process. The first stage named "Prepare Release" will sign the .NET 6 NuGet package content (inside and out), convert relevant packages to .msi installers, generate Visual Studio manifests for the .msi installers, and push the signed packages to the xamarin-impl feed. The new SignList.xml file is required for our NuGet signing templates. The new xamarin-workload.props file contains version information and other metadata required to generate a Visual Studio manifest. The second stage starts with a manual validation task. This task will pause and wait for someone to click a "Resume" or "Reject" button that will appear on the pipeline UI. This task is configured to be rejected after waiting for two days, but it can be manually re-ran at a later date if we want to trigger VS insertion for an older build. If the manual validation task is approved, a VS Drop will be created containing all .NET 6 .msi files. This Drop URL can then be used to update our component versions in Visual Studio. This last piece is currently manual as we will initially be introducing new components, however we should be able to automate VS PR creation in the future. Commit 09f911b missed adding the PR build check condition to a step in sign-and-notarized.yml, causing PR builds from forks to fail. We can fix this by adding in the missing condition.
2021-07-21 20:09:29 +03:00
RUNTIME_PACKS_$(1) = $$(foreach rid,$$(DOTNET_$(1)_RUNTIME_IDENTIFIERS),$(DOTNET_NUPKG_DIR)/$($(1)_NUGET).Runtime.$$(rid).$($(1)_NUGET_VERSION_NO_METADATA).nupkg)
[dotnet] Templateify some build logic. (#10618) * [dotnet-linker] Templateify the install logic. * [builds] Templateify the Versions.plist install logic. * [dotnet] Create a per-platform Versions.props file with only the values applicable to that platform. Also move the definition of the default TargetPlatformVersion to Make.versions, where we have other versions. * [dotnet] Templateify some build code.
2021-02-11 22:17:12 +03:00
RUNTIME_PACKS += $$(RUNTIME_PACKS_$(1))
[CI] Add Prepare Release and VS Insertion stages (again) (#12157) Context: xamarin/yaml-templates#117 Updates the .NET 6 NuGet packaging steps to exclude package metadata, as the .msi conversion tooling does not process .nupkg file names with the +sha.commit metadata. Two new stages have been added to facilitate the Visual Studio setup authoring process. The first stage named "Prepare Release" will sign the .NET 6 NuGet package content (inside and out), convert relevant packages to .msi installers, generate Visual Studio manifests for the .msi installers, and push the signed packages to the xamarin-impl feed. The new SignList.xml file is required for our NuGet signing templates. The new xamarin-workload.props file contains version information and other metadata required to generate a Visual Studio manifest. The second stage starts with a manual validation task. This task will pause and wait for someone to click a "Resume" or "Reject" button that will appear on the pipeline UI. This task is configured to be rejected after waiting for two days, but it can be manually re-ran at a later date if we want to trigger VS insertion for an older build. If the manual validation task is approved, a VS Drop will be created containing all .NET 6 .msi files. This Drop URL can then be used to update our component versions in Visual Studio. This last piece is currently manual as we will initially be introducing new components, however we should be able to automate VS PR creation in the future. Commit 09f911b missed adding the PR build check condition to a step in sign-and-notarized.yml, causing PR builds from forks to fail. We can fix this by adding in the missing condition.
2021-07-21 20:09:29 +03:00
REF_PACKS_$(1) = $(DOTNET_NUPKG_DIR)/$($(1)_NUGET).Ref.$($(1)_NUGET_VERSION_NO_METADATA).nupkg
[dotnet] Templateify some build logic. (#10618) * [dotnet-linker] Templateify the install logic. * [builds] Templateify the Versions.plist install logic. * [dotnet] Create a per-platform Versions.props file with only the values applicable to that platform. Also move the definition of the default TargetPlatformVersion to Make.versions, where we have other versions. * [dotnet] Templateify some build code.
2021-02-11 22:17:12 +03:00
REF_PACKS += $$(REF_PACKS_$(1))
[CI] Add Prepare Release and VS Insertion stages (again) (#12157) Context: xamarin/yaml-templates#117 Updates the .NET 6 NuGet packaging steps to exclude package metadata, as the .msi conversion tooling does not process .nupkg file names with the +sha.commit metadata. Two new stages have been added to facilitate the Visual Studio setup authoring process. The first stage named "Prepare Release" will sign the .NET 6 NuGet package content (inside and out), convert relevant packages to .msi installers, generate Visual Studio manifests for the .msi installers, and push the signed packages to the xamarin-impl feed. The new SignList.xml file is required for our NuGet signing templates. The new xamarin-workload.props file contains version information and other metadata required to generate a Visual Studio manifest. The second stage starts with a manual validation task. This task will pause and wait for someone to click a "Resume" or "Reject" button that will appear on the pipeline UI. This task is configured to be rejected after waiting for two days, but it can be manually re-ran at a later date if we want to trigger VS insertion for an older build. If the manual validation task is approved, a VS Drop will be created containing all .NET 6 .msi files. This Drop URL can then be used to update our component versions in Visual Studio. This last piece is currently manual as we will initially be introducing new components, however we should be able to automate VS PR creation in the future. Commit 09f911b missed adding the PR build check condition to a step in sign-and-notarized.yml, causing PR builds from forks to fail. We can fix this by adding in the missing condition.
2021-07-21 20:09:29 +03:00
SDK_PACKS_$(1) = $(DOTNET_NUPKG_DIR)/$($(1)_NUGET).Sdk.$($(1)_NUGET_VERSION_NO_METADATA).nupkg
[dotnet] Templateify some build logic. (#10618) * [dotnet-linker] Templateify the install logic. * [builds] Templateify the Versions.plist install logic. * [dotnet] Create a per-platform Versions.props file with only the values applicable to that platform. Also move the definition of the default TargetPlatformVersion to Make.versions, where we have other versions. * [dotnet] Templateify some build code.
2021-02-11 22:17:12 +03:00
SDK_PACKS += $$(SDK_PACKS_$(1))
[CI] Add Prepare Release and VS Insertion stages (again) (#12157) Context: xamarin/yaml-templates#117 Updates the .NET 6 NuGet packaging steps to exclude package metadata, as the .msi conversion tooling does not process .nupkg file names with the +sha.commit metadata. Two new stages have been added to facilitate the Visual Studio setup authoring process. The first stage named "Prepare Release" will sign the .NET 6 NuGet package content (inside and out), convert relevant packages to .msi installers, generate Visual Studio manifests for the .msi installers, and push the signed packages to the xamarin-impl feed. The new SignList.xml file is required for our NuGet signing templates. The new xamarin-workload.props file contains version information and other metadata required to generate a Visual Studio manifest. The second stage starts with a manual validation task. This task will pause and wait for someone to click a "Resume" or "Reject" button that will appear on the pipeline UI. This task is configured to be rejected after waiting for two days, but it can be manually re-ran at a later date if we want to trigger VS insertion for an older build. If the manual validation task is approved, a VS Drop will be created containing all .NET 6 .msi files. This Drop URL can then be used to update our component versions in Visual Studio. This last piece is currently manual as we will initially be introducing new components, however we should be able to automate VS PR creation in the future. Commit 09f911b missed adding the PR build check condition to a step in sign-and-notarized.yml, causing PR builds from forks to fail. We can fix this by adding in the missing condition.
2021-07-21 20:09:29 +03:00
TEMPLATE_PACKS_$(1) = $(DOTNET_NUPKG_DIR)/$($(1)_NUGET).Templates.$($(1)_NUGET_VERSION_NO_METADATA).nupkg
.NET 6 templates for iOS, macOS, tvOS, & MacCatalyst (#10741) Context: https://docs.microsoft.com/dotnet/core/tutorials/cli-templates-create-template-pack Context: https://github.com/dotnet/templating/wiki Context: https://github.com/dotnet/designs/pull/120 Fixes: https://github.com/xamarin/xamarin-macios/issues/10252 To implement templates in a .NET workload: 1. Make `.nupkg` files that follow the structure of the `dotnet new` templating system, using `$(PackageType)` of `Template`. 2. Install the `.nupkg` files in in `dotnet/template-packs/` 3. Update `WorkloadManifest.json`, to be part of the workload: "Microsoft.@PLATFORM@.Templates": { "kind": "template", "version": "@VERSION@" } These are a starting point, for what I would consider the minimum for the xamarin-macios repo to provide for now: Template Name Short Name Language Tags -------------------------------------------- -------------- ---------- ---------------------- iOS Controller template ios-controller [C#] iOS iOS Application ios [C#] iOS iOS Class library ioslib [C#] iOS macOS Application macos [C#] macOS MacCatalyst Application maccatalyst [C#] macOS/Catalyst tvOS Application tvos [C#] tvOS We will probably need PM input on what the final templates will be. To use these, you might do: $ mkdir MyApp && cd MyApp $ dotnet new ios $ dotnet new ios-controller --name LoginController --namespace MyApp Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
2021-03-02 18:23:05 +03:00
TEMPLATE_PACKS += $$(TEMPLATE_PACKS_$(1))
Use the MANIFEST_VERSION_BAND for the manifests (#13386) It appears that the package IDs for the manifests retain the main .NET version band, such as 100 and 200, and the packs use the full version of 101 or 203. This PR just uses the version band for the manifest packages. Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
2021-11-19 11:24:30 +03:00
WORKLOAD_PACKS_$(1) = $(DOTNET_NUPKG_DIR)/$(subst Microsoft.,Microsoft.NET.Sdk.,$($(1)_NUGET)).Manifest-$(MANIFEST_VERSION_BAND).$($(1)_NUGET_VERSION_NO_METADATA).nupkg
[dotnet] produce .nupkg files for Workload packs (#10786) Fixes: https://github.com/xamarin/xamarin-macios/issues/10620 I have a prototype where I figured out how Maui would consume the iOS & Android workloads: https://github.com/jonathanpeppers/maui-workload One issue I ran into was there isn't a `Microsoft.NET.Workload.iOS` package on the NuGet feed: <add key="xamarin" value="https://pkgs.dev.azure.com/azure-public/vside/_packaging/xamarin-impl/nuget/v3/index.json" /> We will also need these packages to insert them in the dotnet/installer repo, when they are ready for us to do "real" insertions for .NET 6. To make this work, I mostly had to create a `package.csproj` for the workload packs and fix up the `Makefile`. Now I get additional `.nupkg` files produced in: % ls _build/nupkgs | grep Microsoft.NET.Workload Microsoft.NET.Workload.MacCatalyst.14.3.100-ci.workload-nupkgs.299+sha.692087e74.nupkg Microsoft.NET.Workload.iOS.14.4.100-ci.workload-nupkgs.1154+sha.692087e74.nupkg Microsoft.NET.Workload.macOS.11.1.100-ci.workload-nupkgs.1207+sha.692087e74.nupkg Microsoft.NET.Workload.tvOS.14.3.100-ci.workload-nupkgs.1207+sha.692087e74.nupkg
2021-03-05 01:33:42 +03:00
WORKLOAD_PACKS += $$(WORKLOAD_PACKS_$(1))
pack-$(shell echo $(1) | tr A-Z a-z): $$(RUNTIME_PACKS_$(1)) $$(REF_PACKS_$(1)) $$(SDK_PACKS_$(1)) $$(TEMPLATE_PACKS_$(1)) $$(WORKLOAD_PACKS_$(1))
[dotnet] Templateify some build logic. (#10618) * [dotnet-linker] Templateify the install logic. * [builds] Templateify the Versions.plist install logic. * [dotnet] Create a per-platform Versions.props file with only the values applicable to that platform. Also move the definition of the default TargetPlatformVersion to Make.versions, where we have other versions. * [dotnet] Templateify some build code.
2021-02-11 22:17:12 +03:00
endef
$(foreach platform,$(DOTNET_PLATFORMS_UPPERCASE),$(eval $(call PacksDefinitions,$(platform))))
Create and publish .NET NuGet packages. (#8576) Create the various NuGet packages to support .NET 5+. The packages are currently empty (and not very useful), but the actual content will come later. The current set of NuGet packages are (this list is duplicated for each platform: iOS, tvOS, watchOS and macOS): * Microsoft.iOS.Sdk: currently contains the basic MSBuild targets files for an MSBuild Project SDK. Will eventually contain all the build logic. Might also eventually contain other tools (mlaunch, bgen, etc.), but these might also end up in a different package. * Microsoft.iOS.Ref: will contain the Xamarin.iOS.dll reference assembly. * Microsoft.iOS.Runtime.[RID]: will contain architecture-specific files (libxamarin*.dylib, the Xamarin.iOS.dll implementation assembly, etc.): The NuGets built on CI are automatically published to a NuGet feed. The versioning for the NuGet packages required a few changes: OS bumps are now changed in Make.versions instead of Make.config (this is explained in the files themselves as well).
2020-05-13 16:23:29 +03:00
[msbuild/dotnet] Build the Xamarin.PreBuilt.iOS app bundle. Fixes #12945. (#13342) Build the Xamarin.PreBuilt.iOS app bundle instead of using a prebuilt bundle. This makes sure that we're always using the latest BCL. Some accurate build massaging was needed, because: * To build the prebuilt app we need the iOS workload installed (into our build-local .NET installation). * The iOS workload contains the Microsoft.iOS.Windows.Sdk pack. * The Microsoft.iOS.Windows.Sdk pack contains the prebuilt app. Thus we had a circular reference. Fortunately, the Microsoft.iOS.Windows.Sdk pack is only required on Windows, which means we can break this circular reference by: * Mark Microsoft.iOS.Windows.Sdk pack as only to be installed on Windows (unfortunately it seems we have to list the exact runtime identifiers for the platforms where to install the pack, so we can't do something like "win-*", but new variations of the "win-*" runtime identifier shouldn't show up all that often). * Build the prebuilt app on macOS. This way we don't need the Microsoft.iOS.Windows.Sdk pack when installing the iOS workload locally. The .NET build order is now: * Build general sdk, runtime and ref packs for .NET. * Build the prebuilt app. * Build the Microsoft.iOS.Windows.Sdk pack. Fixes https://github.com/xamarin/xamarin-macios/issues/12945.
2021-11-12 09:38:07 +03:00
TARGETS += $(RUNTIME_PACKS) $(REF_PACKS) $(SDK_PACKS) $(TEMPLATE_PACKS) $(WORKLOAD_PACKS) $(DOTNET_NUPKG_DIR)/vs-workload.props $(DOTNET_NUPKG_DIR)/SignList.xml $(DOTNET_NUPKG_DIR)/SignList.targets $(SDK_PACKS_WINDOWS)
Create and publish .NET NuGet packages. (#8576) Create the various NuGet packages to support .NET 5+. The packages are currently empty (and not very useful), but the actual content will come later. The current set of NuGet packages are (this list is duplicated for each platform: iOS, tvOS, watchOS and macOS): * Microsoft.iOS.Sdk: currently contains the basic MSBuild targets files for an MSBuild Project SDK. Will eventually contain all the build logic. Might also eventually contain other tools (mlaunch, bgen, etc.), but these might also end up in a different package. * Microsoft.iOS.Ref: will contain the Xamarin.iOS.dll reference assembly. * Microsoft.iOS.Runtime.[RID]: will contain architecture-specific files (libxamarin*.dylib, the Xamarin.iOS.dll implementation assembly, etc.): The NuGets built on CI are automatically published to a NuGet feed. The versioning for the NuGet packages required a few changes: OS bumps are now changed in Make.versions instead of Make.config (this is explained in the files themselves as well).
2020-05-13 16:23:29 +03:00
[dotnet] Install our workloads into the dotnet directory (as symlinks).
2020-10-15 12:38:29 +03:00
define InstallWorkload
[build] Use arcade dependency management tooling (#10890) * [build] Use arcade dependency management tooling * Apply feedback * Apply second round of feedback * Always make dotnet.config before trying to read it * Debugging * Update dependencies, trim tabs and spaces * [dotnet] Remove the existing workload shipped with .NET and install our locally built ones. The new version of .NET ships with our workloads, but those aren't the workloads we want to use, so replace them with our own. * Update .gitignores. * Bump to 6.0.100-preview.3.21181.5 That required renaming simulator runtime packs... * More rename for simulator packages * moar (hopefully all) * Bump to 6.0.100-preview.3.21201.11 This fix the issue with `Wait` that failed several tests in monotouch-tests However it does not include the fix for AppConext.GetData on device (AOT) Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com> Co-authored-by: Sebastien Pouliot <sebastien@xamarin.com>
2021-04-02 07:02:27 +03:00
# .NET comes with a workload for us, but we don't want that, we want our own. So delete the workload that comes with .NET.
[.NET] Rename several DOTNET6_* variables to to DOTNET_*. (#14463) Also rename DOTNET_VERSION to SYSTEM_DOTNET_VERSION to make it clear what it's referring to (and to not clash with DOTNET6_VERSION which has now been renamed to DOTNET_VERSION). .NET 7 is right around the corner.
2022-03-23 10:07:34 +03:00
.stamp-workload-replace-$1-$(DOTNET_VERSION):
$(Q) echo "Removing existing workload shipped with .NET $(DOTNET_VERSION): $(DOTNET_MANIFESTS_PATH)/microsoft.net.sdk.$1"
[dotnet] Use lowercase in several places due to https://github.com/dotnet/sdk/issues/19994.
2021-08-19 12:22:06 +03:00
$(Q) rm -Rf $(DOTNET_MANIFESTS_PATH)/microsoft.net.sdk.$3
[build] Use arcade dependency management tooling (#10890) * [build] Use arcade dependency management tooling * Apply feedback * Apply second round of feedback * Always make dotnet.config before trying to read it * Debugging * Update dependencies, trim tabs and spaces * [dotnet] Remove the existing workload shipped with .NET and install our locally built ones. The new version of .NET ships with our workloads, but those aren't the workloads we want to use, so replace them with our own. * Update .gitignores. * Bump to 6.0.100-preview.3.21181.5 That required renaming simulator runtime packs... * More rename for simulator packages * moar (hopefully all) * Bump to 6.0.100-preview.3.21201.11 This fix the issue with `Wait` that failed several tests in monotouch-tests However it does not include the fix for AppConext.GetData on device (AOT) Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com> Co-authored-by: Sebastien Pouliot <sebastien@xamarin.com>
2021-04-02 07:02:27 +03:00
$(Q) touch $$@
[.NET] Rename several DOTNET6_* variables to to DOTNET_*. (#14463) Also rename DOTNET_VERSION to SYSTEM_DOTNET_VERSION to make it clear what it's referring to (and to not clash with DOTNET6_VERSION which has now been renamed to DOTNET_VERSION). .NET 7 is right around the corner.
2022-03-23 10:07:34 +03:00
$(DOTNET_MANIFESTS_PATH)/microsoft.net.sdk.$3: .stamp-workload-replace-$1-$(DOTNET_VERSION) | $(DOTNET_MANIFESTS_PATH)
Mono changed the location of the AOT compiler, so we have to update our code accordingly. (#11789) * [tests] Augment the .NET unit tests to verify that more runtime identifiers build. * [dotnet] Show a better error if the AOT compiler doesn't exist. * [dotnet] Use the official path for the AOT compiler. * [dotnet] Use platform-specific templates for WorkloadManifest.json. * [dotnet] Generate the workload targets before the nupkgs. This avoids a random build failure when doing parallel make. * [builds] Install the runtime workloads for iOS and tvOS so that we have the AOT compilers downloaded for our local tests. * [dotnet] Make the iOS and tvOS workloads load the AOT compiler packages from Mono. * [dotnet] Move the workloads into a common subdirectory. Also delete the watchOS workload, we're not shipping it for now. * [dotnet] Set DOTNETSDK_WORKLOAD_MANIFEST_ROOTS when install workloads to get our local ones. * Set DOTNETSDK_WORKLOAD_MANIFEST_ROOTS to where our local workloads are to use them when installing our locally built workloads into .NET (the local one). * Stop installing workloads from builds/ * Get NuGet.config with local feed, and make sure those feed contain local build before running 'workload install'. * Fix makefile logic. * Another tweak.
2021-06-04 09:34:32 +03:00
$$(Q_LN) ln -Fhs $$(abspath Workloads/Microsoft.NET.Sdk.$1) $$(abspath $$@)
[dotnet] Install our workloads into the dotnet directory (as symlinks).
2020-10-15 12:38:29 +03:00
[dotnet] Install the Sdk and Ref packages too into the dotnet directory (as symlinks).
2020-10-15 12:39:20 +03:00
$(DOTNET_PACKS_PATH)/Microsoft.$1.Sdk/$2: | $(DOTNET_PACKS_PATH)/Microsoft.$1.Sdk
$$(Q_LN) ln -Fhs $$(abspath $(DOTNET_DESTDIR)/Microsoft.$1.Sdk) $$(abspath $$@)
$(DOTNET_PACKS_PATH)/Microsoft.$1.Ref/$2: | $(DOTNET_PACKS_PATH)/Microsoft.$1.Ref
$$(Q_LN) ln -Fhs $$(abspath $(DOTNET_DESTDIR)/Microsoft.$1.Ref) $$(abspath $$@)
.NET 6 templates for iOS, macOS, tvOS, & MacCatalyst (#10741) Context: https://docs.microsoft.com/dotnet/core/tutorials/cli-templates-create-template-pack Context: https://github.com/dotnet/templating/wiki Context: https://github.com/dotnet/designs/pull/120 Fixes: https://github.com/xamarin/xamarin-macios/issues/10252 To implement templates in a .NET workload: 1. Make `.nupkg` files that follow the structure of the `dotnet new` templating system, using `$(PackageType)` of `Template`. 2. Install the `.nupkg` files in in `dotnet/template-packs/` 3. Update `WorkloadManifest.json`, to be part of the workload: "Microsoft.@PLATFORM@.Templates": { "kind": "template", "version": "@VERSION@" } These are a starting point, for what I would consider the minimum for the xamarin-macios repo to provide for now: Template Name Short Name Language Tags -------------------------------------------- -------------- ---------- ---------------------- iOS Controller template ios-controller [C#] iOS iOS Application ios [C#] iOS iOS Class library ioslib [C#] iOS macOS Application macos [C#] macOS MacCatalyst Application maccatalyst [C#] macOS/Catalyst tvOS Application tvos [C#] tvOS We will probably need PM input on what the final templates will be. To use these, you might do: $ mkdir MyApp && cd MyApp $ dotnet new ios $ dotnet new ios-controller --name LoginController --namespace MyApp Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
2021-03-02 18:23:05 +03:00
$(DOTNET_TEMPLATE_PACKS_PATH)/Microsoft.$1.Templates.$(2).nupkg: $(TEMPLATE_PACKS_$(shell echo $(1) | tr a-z A-Z)) | $(DOTNET_TEMPLATE_PACKS_PATH)
$$(Q) $$(CP) $$< $$@
[dotnet] Install our workloads into the dotnet directory (as symlinks).
2020-10-15 12:38:29 +03:00
WORKLOAD_TARGETS += \
.NET 6 templates for iOS, macOS, tvOS, & MacCatalyst (#10741) Context: https://docs.microsoft.com/dotnet/core/tutorials/cli-templates-create-template-pack Context: https://github.com/dotnet/templating/wiki Context: https://github.com/dotnet/designs/pull/120 Fixes: https://github.com/xamarin/xamarin-macios/issues/10252 To implement templates in a .NET workload: 1. Make `.nupkg` files that follow the structure of the `dotnet new` templating system, using `$(PackageType)` of `Template`. 2. Install the `.nupkg` files in in `dotnet/template-packs/` 3. Update `WorkloadManifest.json`, to be part of the workload: "Microsoft.@PLATFORM@.Templates": { "kind": "template", "version": "@VERSION@" } These are a starting point, for what I would consider the minimum for the xamarin-macios repo to provide for now: Template Name Short Name Language Tags -------------------------------------------- -------------- ---------- ---------------------- iOS Controller template ios-controller [C#] iOS iOS Application ios [C#] iOS iOS Class library ioslib [C#] iOS macOS Application macos [C#] macOS MacCatalyst Application maccatalyst [C#] macOS/Catalyst tvOS Application tvos [C#] tvOS We will probably need PM input on what the final templates will be. To use these, you might do: $ mkdir MyApp && cd MyApp $ dotnet new ios $ dotnet new ios-controller --name LoginController --namespace MyApp Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
2021-03-02 18:23:05 +03:00
$(DOTNET_TEMPLATE_PACKS_PATH)/Microsoft.$1.Templates.$(2).nupkg \
[dotnet] Use lowercase in several places due to https://github.com/dotnet/sdk/issues/19994.
2021-08-19 12:22:06 +03:00
$(DOTNET_MANIFESTS_PATH)/microsoft.net.sdk.$3 \
[dotnet] Install the Sdk and Ref packages too into the dotnet directory (as symlinks).
2020-10-15 12:39:20 +03:00
$(DOTNET_PACKS_PATH)/Microsoft.$1.Sdk/$2 \
$(DOTNET_PACKS_PATH)/Microsoft.$1.Ref/$2
[dotnet] Install our workloads into the dotnet directory (as symlinks).
2020-10-15 12:38:29 +03:00
endef
[dotnet] Use lowercase in several places due to https://github.com/dotnet/sdk/issues/19994.
2021-08-19 12:22:06 +03:00
$(foreach platform,$(DOTNET_PLATFORMS),$(eval $(call InstallWorkload,$(platform),$($(platform)_NUGET_VERSION_NO_METADATA),$(shell echo $(platform) | tr A-Z a-z))))
[dotnet] Create Microsoft.<platform>.Bundle.pkg packages for installing workloads manually.
2020-10-15 12:45:36 +03:00
[dotnet] Install the runtime packs too, now they can be resolved from the packs folder.
2021-08-23 15:40:40 +03:00
define InstallRuntimeWorkload
$(DOTNET_PACKS_PATH)/Microsoft.$1.Runtime.$2/$3: | $(DOTNET_PACKS_PATH)/Microsoft.$1.Runtime.$2
$$(Q_LN) ln -Fhs $$(abspath $(DOTNET_DESTDIR)/Microsoft.$1.Runtime.$2) $$(abspath $$@)
WORKLOAD_TARGETS += \
$(DOTNET_PACKS_PATH)/Microsoft.$1.Runtime.$2/$3
endef
$(foreach platform,$(DOTNET_PLATFORMS),$(foreach rid,$(DOTNET_$(platform)_RUNTIME_IDENTIFIERS),$(eval $(call InstallRuntimeWorkload,$(platform),$(rid),$($(platform)_NUGET_VERSION_NO_METADATA)))))
.NET 6 templates for iOS, macOS, tvOS, & MacCatalyst (#10741) Context: https://docs.microsoft.com/dotnet/core/tutorials/cli-templates-create-template-pack Context: https://github.com/dotnet/templating/wiki Context: https://github.com/dotnet/designs/pull/120 Fixes: https://github.com/xamarin/xamarin-macios/issues/10252 To implement templates in a .NET workload: 1. Make `.nupkg` files that follow the structure of the `dotnet new` templating system, using `$(PackageType)` of `Template`. 2. Install the `.nupkg` files in in `dotnet/template-packs/` 3. Update `WorkloadManifest.json`, to be part of the workload: "Microsoft.@PLATFORM@.Templates": { "kind": "template", "version": "@VERSION@" } These are a starting point, for what I would consider the minimum for the xamarin-macios repo to provide for now: Template Name Short Name Language Tags -------------------------------------------- -------------- ---------- ---------------------- iOS Controller template ios-controller [C#] iOS iOS Application ios [C#] iOS iOS Class library ioslib [C#] iOS macOS Application macos [C#] macOS MacCatalyst Application maccatalyst [C#] macOS/Catalyst tvOS Application tvos [C#] tvOS We will probably need PM input on what the final templates will be. To use these, you might do: $ mkdir MyApp && cd MyApp $ dotnet new ios $ dotnet new ios-controller --name LoginController --namespace MyApp Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
2021-03-02 18:23:05 +03:00
# We create four packages: one for the workload, one for the sdk package, one for the ref package, and one for templates
[dotnet] Create Microsoft.<platform>.Bundle.pkg packages for installing workloads manually.
2020-10-15 12:45:36 +03:00
# and then bundle them into a single pkg for distribution (named Microsoft.<platform>.Bundle.<version>.pkg).
Fix typos in comments.
2020-10-19 11:38:11 +03:00
# This way we can create and publish separate updates for each workload/sdk/ref package later if we want to.
[dotnet] Create Microsoft.<platform>.Bundle.pkg packages for installing workloads manually.
2020-10-15 12:45:36 +03:00
define CreatePackage
# The workload package
$(TMP_PKG_DIR)/Microsoft.$1.Workload.$2.pkg: $($(1)_NUGET_TARGETS) $(WORKLOAD_TARGETS) Makefile | $(TMP_PKG_DIR)
$$(Q) rm -f $$@
[dotnet] rename workload to Microsoft.NET.Sdk._platform_.Manifest-6.0.100 (#11436) * [dotnet] rename workload to Microsoft.NET.Sdk._platform_.Manifest-6.0.100 Context: https://github.com/dotnet/designs/pull/188/files#diff-8fcaa29d8e6f00b34b3cb1830d93f33e75f04424780a66a3c658c7021048e74fR125 Context: https://github.com/xamarin/xamarin-android/pull/5898 The `$(PackageId)` of our workload `.nupkg` needs to be: Microsoft.NET.Sdk._platform_.Manifest-6.0.100 While the `$(PackageVersion)` remains the same as before. The layout on disk will change to: dotnet\sdk-manifests\6.0.100\Microsoft.NET.Sdk._platform_\ WorkloadManifest.json WorkloadManifest.targets Note that `.Manifest` and `-6.0.100` are not in the folder name on disk. At the same time, let's also update the `version` in `WorkloadManifest.json` so it contains the proper version for our workload. This used to not be possible because `version` was a `long`, but it now is a `string` where we can put our version. * Use $(DOTNET6_VERSION_BAND) * Pass in -p:VersionBand to 'dotnet pack'
2021-05-06 08:46:01 +03:00
$$(Q) rm -rf tmpdir/Microsoft.NET.Sdk.$1.$2/
[.NET] Rename several DOTNET6_* variables to to DOTNET_*. (#14463) Also rename DOTNET_VERSION to SYSTEM_DOTNET_VERSION to make it clear what it's referring to (and to not clash with DOTNET6_VERSION which has now been renamed to DOTNET_VERSION). .NET 7 is right around the corner.
2022-03-23 10:07:34 +03:00
$$(Q) mkdir -p tmpdir/Microsoft.NET.Sdk.$1.$2/usr/local/share/dotnet/sdk-manifests/$(DOTNET_VERSION_BAND)/
$$(Q) $$(CP) -r Workloads/Microsoft.NET.Sdk.$1 tmpdir/Microsoft.NET.Sdk.$1.$2/usr/local/share/dotnet/sdk-manifests/$(DOTNET_VERSION_BAND)/
[dotnet] rename workload to Microsoft.NET.Sdk._platform_.Manifest-6.0.100 (#11436) * [dotnet] rename workload to Microsoft.NET.Sdk._platform_.Manifest-6.0.100 Context: https://github.com/dotnet/designs/pull/188/files#diff-8fcaa29d8e6f00b34b3cb1830d93f33e75f04424780a66a3c658c7021048e74fR125 Context: https://github.com/xamarin/xamarin-android/pull/5898 The `$(PackageId)` of our workload `.nupkg` needs to be: Microsoft.NET.Sdk._platform_.Manifest-6.0.100 While the `$(PackageVersion)` remains the same as before. The layout on disk will change to: dotnet\sdk-manifests\6.0.100\Microsoft.NET.Sdk._platform_\ WorkloadManifest.json WorkloadManifest.targets Note that `.Manifest` and `-6.0.100` are not in the folder name on disk. At the same time, let's also update the `version` in `WorkloadManifest.json` so it contains the proper version for our workload. This used to not be possible because `version` was a `long`, but it now is a `string` where we can put our version. * Use $(DOTNET6_VERSION_BAND) * Pass in -p:VersionBand to 'dotnet pack'
2021-05-06 08:46:01 +03:00
$$(Q_GEN) pkgbuild --quiet --version '$2' --root tmpdir/Microsoft.NET.Sdk.$1.$2 --component-plist PackageInfo.plist --install-location / --identifier com.microsoft.net.$3.workload.pkg $$@.tmp
[dotnet] Create Microsoft.<platform>.Bundle.pkg packages for installing workloads manually.
2020-10-15 12:45:36 +03:00
$$(Q) mv $$@.tmp $$@
# The sdk package
$(TMP_PKG_DIR)/Microsoft.$1.Sdk.$2.pkg: $(REF_PACK_$(4)) | $(TMP_PKG_DIR)
$$(Q) rm -f $$@
[dotnet] Don't use install-location in pkgs. (#10583) Don't use install-location to specify where files should be installed, because our notarization process replaces this value in the pkg manifest with the root directory (without updating anything else), with the result that notarized packages tries to install files in the wrong location. Instead specify the full path for each individual file, so that the install-location can be the root directory (and thus the notarization process won't corrupt the package).
2021-02-08 09:35:32 +03:00
$$(Q) rm -rf tmpdir/Microsoft.$1.Sdk.$2/
$$(Q) mkdir -p tmpdir/Microsoft.$1.Sdk.$2/usr/local/share/dotnet/packs/Microsoft.$1.Sdk/$2/
$$(Q) $$(CP) -r $(DOTNET_DESTDIR)/Microsoft.$1.Sdk/ tmpdir/Microsoft.$1.Sdk.$2/usr/local/share/dotnet/packs/Microsoft.$1.Sdk/$2/
$$(Q_GEN) pkgbuild --quiet --version '$2' --root tmpdir/Microsoft.$1.Sdk.$2 --component-plist PackageInfo.plist --install-location / --identifier com.microsoft.net.$3.sdk.pkg $$@.tmp
[dotnet] Create Microsoft.<platform>.Bundle.pkg packages for installing workloads manually.
2020-10-15 12:45:36 +03:00
$$(Q) mv $$@.tmp $$@
# The ref package
$(TMP_PKG_DIR)/Microsoft.$1.Ref.$2.pkg: $(SDK_PACK_$(4)) | $(TMP_PKG_DIR)
$$(Q) rm -f $$@
[dotnet] Don't use install-location in pkgs. (#10583) Don't use install-location to specify where files should be installed, because our notarization process replaces this value in the pkg manifest with the root directory (without updating anything else), with the result that notarized packages tries to install files in the wrong location. Instead specify the full path for each individual file, so that the install-location can be the root directory (and thus the notarization process won't corrupt the package).
2021-02-08 09:35:32 +03:00
$$(Q) rm -rf tmpdir/Microsoft.$1.Ref.$2/
$$(Q) mkdir -p tmpdir/Microsoft.$1.Ref.$2/usr/local/share/dotnet/packs/Microsoft.$1.Ref/$2/
$$(Q) $$(CP) -r $(DOTNET_DESTDIR)/Microsoft.$1.Ref/ tmpdir/Microsoft.$1.Ref.$2/usr/local/share/dotnet/packs/Microsoft.$1.Ref/$2/
$$(Q_GEN) pkgbuild --quiet --version '$2' --root tmpdir/Microsoft.$1.Ref.$2 --component-plist PackageInfo.plist --install-location / --identifier com.microsoft.net.$3.ref.pkg $$@.tmp
[dotnet] Create Microsoft.<platform>.Bundle.pkg packages for installing workloads manually.
2020-10-15 12:45:36 +03:00
$$(Q) mv $$@.tmp $$@
.NET 6 templates for iOS, macOS, tvOS, & MacCatalyst (#10741) Context: https://docs.microsoft.com/dotnet/core/tutorials/cli-templates-create-template-pack Context: https://github.com/dotnet/templating/wiki Context: https://github.com/dotnet/designs/pull/120 Fixes: https://github.com/xamarin/xamarin-macios/issues/10252 To implement templates in a .NET workload: 1. Make `.nupkg` files that follow the structure of the `dotnet new` templating system, using `$(PackageType)` of `Template`. 2. Install the `.nupkg` files in in `dotnet/template-packs/` 3. Update `WorkloadManifest.json`, to be part of the workload: "Microsoft.@PLATFORM@.Templates": { "kind": "template", "version": "@VERSION@" } These are a starting point, for what I would consider the minimum for the xamarin-macios repo to provide for now: Template Name Short Name Language Tags -------------------------------------------- -------------- ---------- ---------------------- iOS Controller template ios-controller [C#] iOS iOS Application ios [C#] iOS iOS Class library ioslib [C#] iOS macOS Application macos [C#] macOS MacCatalyst Application maccatalyst [C#] macOS/Catalyst tvOS Application tvos [C#] tvOS We will probably need PM input on what the final templates will be. To use these, you might do: $ mkdir MyApp && cd MyApp $ dotnet new ios $ dotnet new ios-controller --name LoginController --namespace MyApp Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
2021-03-02 18:23:05 +03:00
# The templates package
[msbuild/dotnet] Build the Xamarin.PreBuilt.iOS app bundle. Fixes #12945. (#13342) Build the Xamarin.PreBuilt.iOS app bundle instead of using a prebuilt bundle. This makes sure that we're always using the latest BCL. Some accurate build massaging was needed, because: * To build the prebuilt app we need the iOS workload installed (into our build-local .NET installation). * The iOS workload contains the Microsoft.iOS.Windows.Sdk pack. * The Microsoft.iOS.Windows.Sdk pack contains the prebuilt app. Thus we had a circular reference. Fortunately, the Microsoft.iOS.Windows.Sdk pack is only required on Windows, which means we can break this circular reference by: * Mark Microsoft.iOS.Windows.Sdk pack as only to be installed on Windows (unfortunately it seems we have to list the exact runtime identifiers for the platforms where to install the pack, so we can't do something like "win-*", but new variations of the "win-*" runtime identifier shouldn't show up all that often). * Build the prebuilt app on macOS. This way we don't need the Microsoft.iOS.Windows.Sdk pack when installing the iOS workload locally. The .NET build order is now: * Build general sdk, runtime and ref packs for .NET. * Build the prebuilt app. * Build the Microsoft.iOS.Windows.Sdk pack. Fixes https://github.com/xamarin/xamarin-macios/issues/12945.
2021-11-12 09:38:07 +03:00
$(TMP_PKG_DIR)/Microsoft.$1.Templates.$2.pkg: $(TEMPLATE_PACKS_$(4)) | $(TMP_PKG_DIR)
.NET 6 templates for iOS, macOS, tvOS, & MacCatalyst (#10741) Context: https://docs.microsoft.com/dotnet/core/tutorials/cli-templates-create-template-pack Context: https://github.com/dotnet/templating/wiki Context: https://github.com/dotnet/designs/pull/120 Fixes: https://github.com/xamarin/xamarin-macios/issues/10252 To implement templates in a .NET workload: 1. Make `.nupkg` files that follow the structure of the `dotnet new` templating system, using `$(PackageType)` of `Template`. 2. Install the `.nupkg` files in in `dotnet/template-packs/` 3. Update `WorkloadManifest.json`, to be part of the workload: "Microsoft.@PLATFORM@.Templates": { "kind": "template", "version": "@VERSION@" } These are a starting point, for what I would consider the minimum for the xamarin-macios repo to provide for now: Template Name Short Name Language Tags -------------------------------------------- -------------- ---------- ---------------------- iOS Controller template ios-controller [C#] iOS iOS Application ios [C#] iOS iOS Class library ioslib [C#] iOS macOS Application macos [C#] macOS MacCatalyst Application maccatalyst [C#] macOS/Catalyst tvOS Application tvos [C#] tvOS We will probably need PM input on what the final templates will be. To use these, you might do: $ mkdir MyApp && cd MyApp $ dotnet new ios $ dotnet new ios-controller --name LoginController --namespace MyApp Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
2021-03-02 18:23:05 +03:00
$$(Q) rm -f $$@
$$(Q) rm -rf tmpdir/Microsoft.$1.Templates.$2/
$$(Q) mkdir -p tmpdir/Microsoft.$1.Templates.$2/usr/local/share/dotnet/template-packs/
[dotnet] remove +sha from templates in installers (#10816) I noticed the new templates did not actually work from the installer unless I did: % sudo mv \ /usr/local/share/dotnet/template-packs/Microsoft.iOS.Templates.14.4.100-ci.main.1180+sha.bccef33d3.nupkg \ /usr/local/share/dotnet/template-packs/Microsoft.iOS.Templates.14.4.100-ci.main.1180.nupkg I checked other templates like Android or ASP.NET, and they do not currently have a hash like `+sha.bccef33d3` in the file name. To fix this problem, I updated the file in the installers so we now remove the `+sha.bccef33d3` portion from file name: $(subst +$(NUGET_BUILD_METADATA),,$(notdir $(TEMPLATE_PACKS_$(4)))) I also found the `Microsoft.iOS.Bundle.*.zip` did not contain `template-packs` at all, so I fixed this as well.
2021-03-10 01:56:26 +03:00
$$(Q) $$(CP) $(TEMPLATE_PACKS_$(4)) tmpdir/Microsoft.$1.Templates.$2/usr/local/share/dotnet/template-packs/$(subst +$(NUGET_BUILD_METADATA),,$(notdir $(TEMPLATE_PACKS_$(4))))
.NET 6 templates for iOS, macOS, tvOS, & MacCatalyst (#10741) Context: https://docs.microsoft.com/dotnet/core/tutorials/cli-templates-create-template-pack Context: https://github.com/dotnet/templating/wiki Context: https://github.com/dotnet/designs/pull/120 Fixes: https://github.com/xamarin/xamarin-macios/issues/10252 To implement templates in a .NET workload: 1. Make `.nupkg` files that follow the structure of the `dotnet new` templating system, using `$(PackageType)` of `Template`. 2. Install the `.nupkg` files in in `dotnet/template-packs/` 3. Update `WorkloadManifest.json`, to be part of the workload: "Microsoft.@PLATFORM@.Templates": { "kind": "template", "version": "@VERSION@" } These are a starting point, for what I would consider the minimum for the xamarin-macios repo to provide for now: Template Name Short Name Language Tags -------------------------------------------- -------------- ---------- ---------------------- iOS Controller template ios-controller [C#] iOS iOS Application ios [C#] iOS iOS Class library ioslib [C#] iOS macOS Application macos [C#] macOS MacCatalyst Application maccatalyst [C#] macOS/Catalyst tvOS Application tvos [C#] tvOS We will probably need PM input on what the final templates will be. To use these, you might do: $ mkdir MyApp && cd MyApp $ dotnet new ios $ dotnet new ios-controller --name LoginController --namespace MyApp Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
2021-03-02 18:23:05 +03:00
$$(Q_GEN) pkgbuild --quiet --version '$2' --root tmpdir/Microsoft.$1.Templates.$2 --component-plist PackageInfo.plist --install-location / --identifier com.microsoft.net.$3.template.pkg $$@.tmp
$$(Q) mv $$@.tmp $$@
[dotnet] Create Microsoft.<platform>.Bundle.pkg packages for installing workloads manually.
2020-10-15 12:45:36 +03:00
# The final bundle package for distribution
.NET 6 templates for iOS, macOS, tvOS, & MacCatalyst (#10741) Context: https://docs.microsoft.com/dotnet/core/tutorials/cli-templates-create-template-pack Context: https://github.com/dotnet/templating/wiki Context: https://github.com/dotnet/designs/pull/120 Fixes: https://github.com/xamarin/xamarin-macios/issues/10252 To implement templates in a .NET workload: 1. Make `.nupkg` files that follow the structure of the `dotnet new` templating system, using `$(PackageType)` of `Template`. 2. Install the `.nupkg` files in in `dotnet/template-packs/` 3. Update `WorkloadManifest.json`, to be part of the workload: "Microsoft.@PLATFORM@.Templates": { "kind": "template", "version": "@VERSION@" } These are a starting point, for what I would consider the minimum for the xamarin-macios repo to provide for now: Template Name Short Name Language Tags -------------------------------------------- -------------- ---------- ---------------------- iOS Controller template ios-controller [C#] iOS iOS Application ios [C#] iOS iOS Class library ioslib [C#] iOS macOS Application macos [C#] macOS MacCatalyst Application maccatalyst [C#] macOS/Catalyst tvOS Application tvos [C#] tvOS We will probably need PM input on what the final templates will be. To use these, you might do: $ mkdir MyApp && cd MyApp $ dotnet new ios $ dotnet new ios-controller --name LoginController --namespace MyApp Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
2021-03-02 18:23:05 +03:00
$(TMP_PKG_DIR)/Microsoft.$1.Bundle.$2.pkg: $(TMP_PKG_DIR)/Microsoft.$1.Workload.$2.pkg $(TMP_PKG_DIR)/Microsoft.$1.Sdk.$2.pkg $(TMP_PKG_DIR)/Microsoft.$1.Ref.$2.pkg $(TMP_PKG_DIR)/Microsoft.$1.Templates.$2.pkg
[dotnet] Create Microsoft.<platform>.Bundle.pkg packages for installing workloads manually.
2020-10-15 12:45:36 +03:00
$$(Q) rm -f $$@
$$(Q_GEN) productbuild \
--quiet \
--identifier com.microsoft.net.$3.pkg \
--version '$2' \
--package $(TMP_PKG_DIR)/Microsoft.$1.Workload.$2.pkg \
--package $(TMP_PKG_DIR)/Microsoft.$1.Sdk.$2.pkg \
--package $(TMP_PKG_DIR)/Microsoft.$1.Ref.$2.pkg \
.NET 6 templates for iOS, macOS, tvOS, & MacCatalyst (#10741) Context: https://docs.microsoft.com/dotnet/core/tutorials/cli-templates-create-template-pack Context: https://github.com/dotnet/templating/wiki Context: https://github.com/dotnet/designs/pull/120 Fixes: https://github.com/xamarin/xamarin-macios/issues/10252 To implement templates in a .NET workload: 1. Make `.nupkg` files that follow the structure of the `dotnet new` templating system, using `$(PackageType)` of `Template`. 2. Install the `.nupkg` files in in `dotnet/template-packs/` 3. Update `WorkloadManifest.json`, to be part of the workload: "Microsoft.@PLATFORM@.Templates": { "kind": "template", "version": "@VERSION@" } These are a starting point, for what I would consider the minimum for the xamarin-macios repo to provide for now: Template Name Short Name Language Tags -------------------------------------------- -------------- ---------- ---------------------- iOS Controller template ios-controller [C#] iOS iOS Application ios [C#] iOS iOS Class library ioslib [C#] iOS macOS Application macos [C#] macOS MacCatalyst Application maccatalyst [C#] macOS/Catalyst tvOS Application tvos [C#] tvOS We will probably need PM input on what the final templates will be. To use these, you might do: $ mkdir MyApp && cd MyApp $ dotnet new ios $ dotnet new ios-controller --name LoginController --namespace MyApp Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
2021-03-02 18:23:05 +03:00
--package $(TMP_PKG_DIR)/Microsoft.$1.Templates.$2.pkg \
[dotnet] Create Microsoft.<platform>.Bundle.pkg packages for installing workloads manually.
2020-10-15 12:45:36 +03:00
$$@.tmp
$$(Q) mv $$@.tmp $$@
# Copy the bundle package from our temporary directory to the target directory
[dotnet] Package the workloads in a Windows installer (.msi) as well. (#9979)
2020-10-28 13:09:55 +03:00
$(DOTNET_PKG_DIR)/%: $(TMP_PKG_DIR)/% | $(DOTNET_PKG_DIR)
[dotnet] Create Microsoft.<platform>.Bundle.pkg packages for installing workloads manually.
2020-10-15 12:45:36 +03:00
$$(Q) $(CP) $$< $$@
PACKAGE_TARGETS += $(DOTNET_PKG_DIR)/Microsoft.$1.Bundle.$2.pkg
[dotnet] Package the workloads in a Windows installer (.msi) as well. (#9979)
2020-10-28 13:09:55 +03:00
[dotnet] remove +sha from templates in installers (#10816) I noticed the new templates did not actually work from the installer unless I did: % sudo mv \ /usr/local/share/dotnet/template-packs/Microsoft.iOS.Templates.14.4.100-ci.main.1180+sha.bccef33d3.nupkg \ /usr/local/share/dotnet/template-packs/Microsoft.iOS.Templates.14.4.100-ci.main.1180.nupkg I checked other templates like Android or ASP.NET, and they do not currently have a hash like `+sha.bccef33d3` in the file name. To fix this problem, I updated the file in the installers so we now remove the `+sha.bccef33d3` portion from file name: $(subst +$(NUGET_BUILD_METADATA),,$(notdir $(TEMPLATE_PACKS_$(4)))) I also found the `Microsoft.iOS.Bundle.*.zip` did not contain `template-packs` at all, so I fixed this as well.
2021-03-10 01:56:26 +03:00
$(TMP_PKG_DIR)/Microsoft.$1.Bundle.$2.zip: $($(1)_NUGET_TARGETS) $(WORKLOAD_TARGETS) Makefile $(REF_PACK_$(4)) $(SDK_PACK_$(4)) $(TEMPLATE_PACKS_$(4)) | $(TMP_PKG_DIR)
[dotnet] Package the workloads in a Windows installer (.msi) as well. (#9979)
2020-10-28 13:09:55 +03:00
$$(Q) rm -rf $$@ $$@.tmpdir $$@.tmp
[.NET] Rename several DOTNET6_* variables to to DOTNET_*. (#14463) Also rename DOTNET_VERSION to SYSTEM_DOTNET_VERSION to make it clear what it's referring to (and to not clash with DOTNET6_VERSION which has now been renamed to DOTNET_VERSION). .NET 7 is right around the corner.
2022-03-23 10:07:34 +03:00
$$(Q) mkdir -p $$@.tmpdir/dotnet/sdk-manifests/$(DOTNET_VERSION_BAND)/
[dotnet] Package the workloads in a Windows installer (.msi) as well. (#9979)
2020-10-28 13:09:55 +03:00
$$(Q) mkdir -p $$@.tmpdir/dotnet/packs/Microsoft.$1.Sdk
$$(Q) mkdir -p $$@.tmpdir/dotnet/packs/Microsoft.$1.Ref
.NET 6 templates for iOS, macOS, tvOS, & MacCatalyst (#10741) Context: https://docs.microsoft.com/dotnet/core/tutorials/cli-templates-create-template-pack Context: https://github.com/dotnet/templating/wiki Context: https://github.com/dotnet/designs/pull/120 Fixes: https://github.com/xamarin/xamarin-macios/issues/10252 To implement templates in a .NET workload: 1. Make `.nupkg` files that follow the structure of the `dotnet new` templating system, using `$(PackageType)` of `Template`. 2. Install the `.nupkg` files in in `dotnet/template-packs/` 3. Update `WorkloadManifest.json`, to be part of the workload: "Microsoft.@PLATFORM@.Templates": { "kind": "template", "version": "@VERSION@" } These are a starting point, for what I would consider the minimum for the xamarin-macios repo to provide for now: Template Name Short Name Language Tags -------------------------------------------- -------------- ---------- ---------------------- iOS Controller template ios-controller [C#] iOS iOS Application ios [C#] iOS iOS Class library ioslib [C#] iOS macOS Application macos [C#] macOS MacCatalyst Application maccatalyst [C#] macOS/Catalyst tvOS Application tvos [C#] tvOS We will probably need PM input on what the final templates will be. To use these, you might do: $ mkdir MyApp && cd MyApp $ dotnet new ios $ dotnet new ios-controller --name LoginController --namespace MyApp Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
2021-03-02 18:23:05 +03:00
$$(Q) mkdir -p $$@.tmpdir/dotnet/template-packs
[.NET] Rename several DOTNET6_* variables to to DOTNET_*. (#14463) Also rename DOTNET_VERSION to SYSTEM_DOTNET_VERSION to make it clear what it's referring to (and to not clash with DOTNET6_VERSION which has now been renamed to DOTNET_VERSION). .NET 7 is right around the corner.
2022-03-23 10:07:34 +03:00
$$(Q) $(CP) -r Workloads/Microsoft.NET.Sdk.$1 $$@.tmpdir/dotnet/sdk-manifests/$(DOTNET_VERSION_BAND)/
[dotnet] Package the workloads in a Windows installer (.msi) as well. (#9979)
2020-10-28 13:09:55 +03:00
$$(Q) $(CP) -r $(DOTNET_DESTDIR)/Microsoft.$1.Sdk $$@.tmpdir/dotnet/packs/Microsoft.$1.Sdk/$2
$$(Q) $(CP) -r $(DOTNET_DESTDIR)/Microsoft.$1.Ref $$@.tmpdir/dotnet/packs/Microsoft.$1.Ref/$2
[dotnet] remove +sha from templates in installers (#10816) I noticed the new templates did not actually work from the installer unless I did: % sudo mv \ /usr/local/share/dotnet/template-packs/Microsoft.iOS.Templates.14.4.100-ci.main.1180+sha.bccef33d3.nupkg \ /usr/local/share/dotnet/template-packs/Microsoft.iOS.Templates.14.4.100-ci.main.1180.nupkg I checked other templates like Android or ASP.NET, and they do not currently have a hash like `+sha.bccef33d3` in the file name. To fix this problem, I updated the file in the installers so we now remove the `+sha.bccef33d3` portion from file name: $(subst +$(NUGET_BUILD_METADATA),,$(notdir $(TEMPLATE_PACKS_$(4)))) I also found the `Microsoft.iOS.Bundle.*.zip` did not contain `template-packs` at all, so I fixed this as well.
2021-03-10 01:56:26 +03:00
$$(Q) $(CP) $(TEMPLATE_PACKS_$(4)) $$@.tmpdir/dotnet/template-packs/$(subst +$(NUGET_BUILD_METADATA),,$(notdir $(TEMPLATE_PACKS_$(4))))
[dotnet] Package the workloads in a Windows installer (.msi) as well. (#9979)
2020-10-28 13:09:55 +03:00
$$(Q_GEN) cd $$@.tmpdir && zip -9rq $$(abspath $$@.tmp) .
$$(Q) mv $$@.tmp $$@
$$(Q) echo Created $$@
PACKAGE_TARGETS += $(DOTNET_PKG_DIR)/Microsoft.$1.Bundle.$2.zip
[dotnet] Create Microsoft.<platform>.Bundle.pkg packages for installing workloads manually.
2020-10-15 12:45:36 +03:00
endef
$(foreach platform,$(DOTNET_PLATFORMS),$(eval $(call CreatePackage,$(platform),$($(platform)_NUGET_VERSION_NO_METADATA),$(shell echo $(platform) | tr A-Z a-z),$(shell echo $(platform) | tr a-z A-Z))))
[dotnet] Install our workloads into the dotnet directory (as symlinks).
2020-10-15 12:38:29 +03:00
[dotnet] Initial support for .NET6 from Windows (#10590) These changes add support for executing iOS and MacDev tasks remotely (on a Mac) when running a build from Windows, and creates a specific .NET6 pack for Windows that's only included in the MSI. For now this only enables builds for the iOS Simulator, physical devices are not yet supported. - Each task decides if it should run locally or remotely depending on the SessionId property, which will only have a value on Windows. - The XMA Build agent is now part of this repo and will be included in the iOS .NET6 Windows pack. - On this first version we're including some Windows specific tasks and references into the Xamarin.iOS.Tasks project for simplicity, but those will be moved to the Windows specific project. ------------ * [msbuild] Adds support for executing Xamarin.iOS tasks from Windows * [msbuild] Adds support for executing Xamarin.MacDev tasks from Windows * Added XMA Build Agent to Xamarin.MacDev.Tasks.sln * Fixes some MSBuild versioning problems * Makes the XMA Build agent load Xamarin.iOS tasks We need to load a type from the iOS tasks assembly so we can run the tasks requested by MSBuild from Windows. We only need to load Xamarin.iOS.Tasks.dll since MacDev.tasks is already embedded in that one. There's a little trick on the csproj, we can't directly use the Xamarin.iOS.Tasks project ref assemblies because that includes both Xamarin.iOS.Tasks.dll and Xamarin.MacDev.Tasks.dll, so the MacDev tasks will collide. We use the project ref only for build dependency purposes but we add an assembly reference to Xamarin.iOS.Tasks.dll. * Added Xamarin.iOS.Tasks.Windows project * Removed unnecessary references on Xamarin.iOS.Tasks.Windows.csproj * Adds Messaging assemblies when ILRepacking Xamarin Tasks The Xamarin Task assemblies now depend on Messaging, so we need the Messaging assemblies to be packed into Xamarin.Mac.Tasks and Xamarin.iOS.Tasks. Also had to remove the direct Messaging dependencies from the build agent since those are already contained in Xamarin.iOS.Tasks * Adds a reference to Messaging.Core targets to the Agent's project * [msbuild] Adds Xamarin iOS Windows targets * [msbuild] Adds missing dependencies to Xamarin.iOS.Tasks This should fix build errors because of missing dependencies. Had to move System.Net.Mqtt.Server from the Build agent project to the tasks one to avoid conflicts with System.Diagnostics.Tracer. * [dotnet] Creates iOS Windows pack Creates a new pack for Windows specific (targets, build agent, etc.) files that shouldn't be installed on the Mac. We have a separate package for this to avoid increasing the core pack size with things that are not needed when using it from macOS. * Fixes type in dotnet makefile * [dotnet] Fixes the iOS Windows pack generation - The windows pack should not include the Sdk and Targets folders - For now we'll just create an iOS pack - Fixes the path to the files to include on the Windows Sdk pack * Added reference to the Windows iOS SDK from the Xamarin.iOS.Common.targets Added a property to navigate to the Windows iOS SDK folder, based on a naming convention that assumes that both packs will always have the same version * Added reference to the core iOS SDK from the Windows iOS SDK Added a property to navigate to the core iOS SDK folder, based on a naming convention that assumes that both packs will always have the same version * Updated Messaging version * Override MessagingBuildClientAssemblyFile property and correctly imported props from targets * [dotnet] Make Windows pack using target files from the output dir We need to take the target files from the output dir to include targets that are part of nuget packages, otherwise we will only include targets from our source * [dotnet] Adds the Windows Sdk pack to the workload manifest * [msbuild] Fixes the Windows Sdk pack name * [dotnet] Merge Mqtt instead of Mqtt.Server We only need System.Net.Mqtt to be merged into Xamarin.iOS.Tasks * Updated Messaging version * [dotnet] Several fixes for the Windows Sdk - Adds missing task CollectMonotouchReferences - Merges more dependencies into Xamarin.iOS.Tasks.dll needed by XMA - Updates the msbuild/Makefile to include files from both the output dir and the source dir - Overrides the agents directory to look for them on the Windows pack * [dotnet] Fixes the XMA Build agent - The build agent is an app so it cannot target ns2.0 - The MSBuild dependencies should be copied into the agent zip file - Avoids copying all the Xamarin iOS SDK core targets into the build agent, since those are not needed - Ensures the broker zip file is copied into the Xamarin.iOS.Windows.Tasks output dir so its included in the Windows pack * Bumps Xamarin.Messaging to 1.2.102 * Adds net6-win branch to trigger builds * Adds Messaging.Client missing dependency to Xamarin.Mac.Tasks * Added Xamarin.Messaging.Apple.Tasks project and VerifyXcodeVersion Task * Fix unloaded Xamarin.Messaging.Build project * Added Build contracts project and unified Xamarin.Messaigng.Apple.Tasks in Xamarin.iOS.Tasks.Windows Also added missing tasks and changes .After.targets * Updated Xamarin.Messaging version * Build agent - reference MSBuild assemblies from the framework Since the assemblies will be included in the build agent we need those to be the ones that come from the framework to be compatible with macOS * [msbuild] Fixes _UpdateDynamicLibraryId target The tasks con this target need to be executed remotely (when building from Windows). * Updates resources * Bump Xamarin.Messaging Fixes problems when executing Exec task remotely * [dotnet] Overrides Publish targets to execute them remotely from Windows The `_CopyResolvedFilesToPublishPreserveNewest` and `_CopyResolvedFilesToPublishAlways` targets essentially copy files into the app bundle. Since those are part of the .NET SDK we need to override those so we can pass to the Copy task the SessionId parameter and then it will be executed remotely when building from Windows. This is done in a Windows.After.targets file so it won't affect builds on macOS. * Added ILMerge to Xamarin.iOS.Tasks.Windows Also modified ILMerge.targets to not include System assemblies because we don't need them on the Windows package * Bumps Messaging This new version of messaging fixes a problem when copying task inputs from Windows to the Mac * [dotnet] Fixes copying files to the Mac when building from Windows When building from Windows there are .NET SDK targets that copy dynamic libraries from the SDK to the intermediate output directory or other files to the publish directory, since we can't control those we can't run them remotely so we need to copy those files to the Mac to ensure other targets will find those. * [dotnet] Fixes how files are copied to the output dir - Before executing `_CopyResolvedFilesToPublishPreserveNewest` and `_CopyResolvedFilesToPublishAlways` we copy the input files for those targets to the Mac - Then we override the original targets to execute the same copy task as the original ones but on the Mac, so the output files are placed in the right location for the following targets to pick them up. * Fixes typo on Xamarin.iOS.Common.After.targets * Bumps Xamarin.Messaging * [msbuild] Fixes VerifyXcodeVersion and ResolveUTIs tasks Both tasks were not being able to connect to the Mac mostly because of ILRepack, there were kind of 2 versions of Xamarin.Messaging, one merged into Xamarin.iOS.Tasks and another one merged into Xamarin.iOS.Windows.Tasks. Because of this the build connection object registered on the task could not be casted to the build connection type. This essentially moves both tasks into the Xamarin.iOS.Tasks assembly to avoid this issue, and as part of that also includes the Messaging contracts into that same project. * [msbuild] Fixes warnings when building from Windows * [dotnet] Adds missing assemblies to merge into Xamarin.iOS.Tasks Those 2 new assemblies will only be used from Windows and we need their implementation instead of the ref assemblies. In the future we will need to find a way of doing this on the Windows only pack insted of doing it on the core Xamarin.iOS.Tasks assembly. * [dotnet] Compute PublishTrimmed on a target We need to do this so the property is evaluated after VS on Windows connects to the Mac, otherwise by default IsMacEnabled is false from Windows. * Bumps Messaging to 1.2.111 * [dotnet] Execute ILLink remotely when building from Windows - Overrides the ILLink task and _RunILLink target to add the hability to execute it remotely, adding input and output properties so files are copied to the server and output files are created on Windows. - This "custom" ILLink task will only be executed from the Windows targets so when building from a Mac it will execute the core SDK task. * [dotnet] Fixes intput/output files creation for linker tasks - Custom Linker options file should be created on the Mac so we need to execute WriteLinesToFile remotely - All the *.items files from the linker are created on the Mac so we need to execute ReadItemsFromFile remotely - CompileNativeCode: fixes the OutputFile metadata path, otherwise the execution fails; also copies all the files in the declared "IncludeDirectories" to the Mac - Avoids copying input files from Windows to the Mac when running LinkNativeCode since the real input files already exist on the Mac, and Windows contains only empty files just to make MSBuild inputs/outputs check work. If we copy those empty files to the Mac we brake the build. * [msbuild] Minor fixes after merging from main * [dotnet] Adds missing output files to the Xamarin.iOS.Tasks.Windows project The output of this project was missing Messaging build targets and the build agent zip file that are needed to create the dotnet Windows specific pack * [dotnet] Fixes dotnet Windows specific pack generation Ensures the Windows projects are built and the files are copied to the dotnet pack directory before creating the package. It also adds a variable to enable building this pack. * [dotnet] Adds iOS Windows specific pack to iOS only MSI There's only a Windows specific pack for iOS available for now, so we should only add it to the iOS SDK MSI * [dotnet] Create a separate bundle for the iOS Windows MSI We need to do this to avoid including the Windows specific pack in the pkg. Also for now we'll only create an MSI for iOS since it's the only supported platform from Windows. * Fixes spacing issues in Xamarin.iOS.Tasks.csproj * Bumps Touch.Unit back to 05db76 * Fixes formatting problems * [msbuild] Replaces error E0176 by E0186 Because there's a warning W0176 that will overlap with the error * [msbuild] Fixes CompileEntitlements task There were 2 problems: 1- The if statement on the DefaultEntitlementsPath was wrong, because we should return the base value if there's no SessionId (which means the task is running on a Mac) 2- We should copy to the Mac the default entitlements file if no custom file was specified * Several fixes to cleanup the code to support iOS from Windows * Apply suggestions from code review Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com> * Formatting fixes in Xamarin.Messaging.Build * Reverted formatting changes in CompileEntitlements.cs * More formatting fixes * Update msbuild/Messaging/Xamarin.Messaging.Build/Handlers/ExecuteTaskMessageHandler.cs Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com> * Fixes order of MSBuild errors in the resource file * Add newly added localizable strings to canary test of translated strings. * Delete tests that ensure theres code only on the abstract tasks These were needed to ensure all the code was in the base tasks so we could have tasks implementations on Windows to remote those. Now that code is part of this repo (and that is why these tests are failing now) so we do not need them anymore. * [dotnet] Don't build the Windows SDK pack if not configured to do so. Co-authored-by: mag <mauro.agnoletti@gmail.com> Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
2021-02-12 09:43:17 +03:00
define CreateWindowsBundle
.NET 6 templates for iOS, macOS, tvOS, & MacCatalyst (#10741) Context: https://docs.microsoft.com/dotnet/core/tutorials/cli-templates-create-template-pack Context: https://github.com/dotnet/templating/wiki Context: https://github.com/dotnet/designs/pull/120 Fixes: https://github.com/xamarin/xamarin-macios/issues/10252 To implement templates in a .NET workload: 1. Make `.nupkg` files that follow the structure of the `dotnet new` templating system, using `$(PackageType)` of `Template`. 2. Install the `.nupkg` files in in `dotnet/template-packs/` 3. Update `WorkloadManifest.json`, to be part of the workload: "Microsoft.@PLATFORM@.Templates": { "kind": "template", "version": "@VERSION@" } These are a starting point, for what I would consider the minimum for the xamarin-macios repo to provide for now: Template Name Short Name Language Tags -------------------------------------------- -------------- ---------- ---------------------- iOS Controller template ios-controller [C#] iOS iOS Application ios [C#] iOS iOS Class library ioslib [C#] iOS macOS Application macos [C#] macOS MacCatalyst Application maccatalyst [C#] macOS/Catalyst tvOS Application tvos [C#] tvOS We will probably need PM input on what the final templates will be. To use these, you might do: $ mkdir MyApp && cd MyApp $ dotnet new ios $ dotnet new ios-controller --name LoginController --namespace MyApp Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
2021-03-02 18:23:05 +03:00
$(TMP_PKG_DIR)/Microsoft.$1.Windows.Bundle.$2.zip: $($(1)_NUGET_TARGETS) $($(1)_WINDOWS_NUGET_TARGETS) $(WORKLOAD_TARGETS) Makefile $(REF_PACK_$(4)) $(SDK_PACK_$(4)) $(SDK_PACK_$(4)_WINDOWS) $(TEMPLATE_PACKS_$(4)) | $(TMP_PKG_DIR)
[dotnet] Initial support for .NET6 from Windows (#10590) These changes add support for executing iOS and MacDev tasks remotely (on a Mac) when running a build from Windows, and creates a specific .NET6 pack for Windows that's only included in the MSI. For now this only enables builds for the iOS Simulator, physical devices are not yet supported. - Each task decides if it should run locally or remotely depending on the SessionId property, which will only have a value on Windows. - The XMA Build agent is now part of this repo and will be included in the iOS .NET6 Windows pack. - On this first version we're including some Windows specific tasks and references into the Xamarin.iOS.Tasks project for simplicity, but those will be moved to the Windows specific project. ------------ * [msbuild] Adds support for executing Xamarin.iOS tasks from Windows * [msbuild] Adds support for executing Xamarin.MacDev tasks from Windows * Added XMA Build Agent to Xamarin.MacDev.Tasks.sln * Fixes some MSBuild versioning problems * Makes the XMA Build agent load Xamarin.iOS tasks We need to load a type from the iOS tasks assembly so we can run the tasks requested by MSBuild from Windows. We only need to load Xamarin.iOS.Tasks.dll since MacDev.tasks is already embedded in that one. There's a little trick on the csproj, we can't directly use the Xamarin.iOS.Tasks project ref assemblies because that includes both Xamarin.iOS.Tasks.dll and Xamarin.MacDev.Tasks.dll, so the MacDev tasks will collide. We use the project ref only for build dependency purposes but we add an assembly reference to Xamarin.iOS.Tasks.dll. * Added Xamarin.iOS.Tasks.Windows project * Removed unnecessary references on Xamarin.iOS.Tasks.Windows.csproj * Adds Messaging assemblies when ILRepacking Xamarin Tasks The Xamarin Task assemblies now depend on Messaging, so we need the Messaging assemblies to be packed into Xamarin.Mac.Tasks and Xamarin.iOS.Tasks. Also had to remove the direct Messaging dependencies from the build agent since those are already contained in Xamarin.iOS.Tasks * Adds a reference to Messaging.Core targets to the Agent's project * [msbuild] Adds Xamarin iOS Windows targets * [msbuild] Adds missing dependencies to Xamarin.iOS.Tasks This should fix build errors because of missing dependencies. Had to move System.Net.Mqtt.Server from the Build agent project to the tasks one to avoid conflicts with System.Diagnostics.Tracer. * [dotnet] Creates iOS Windows pack Creates a new pack for Windows specific (targets, build agent, etc.) files that shouldn't be installed on the Mac. We have a separate package for this to avoid increasing the core pack size with things that are not needed when using it from macOS. * Fixes type in dotnet makefile * [dotnet] Fixes the iOS Windows pack generation - The windows pack should not include the Sdk and Targets folders - For now we'll just create an iOS pack - Fixes the path to the files to include on the Windows Sdk pack * Added reference to the Windows iOS SDK from the Xamarin.iOS.Common.targets Added a property to navigate to the Windows iOS SDK folder, based on a naming convention that assumes that both packs will always have the same version * Added reference to the core iOS SDK from the Windows iOS SDK Added a property to navigate to the core iOS SDK folder, based on a naming convention that assumes that both packs will always have the same version * Updated Messaging version * Override MessagingBuildClientAssemblyFile property and correctly imported props from targets * [dotnet] Make Windows pack using target files from the output dir We need to take the target files from the output dir to include targets that are part of nuget packages, otherwise we will only include targets from our source * [dotnet] Adds the Windows Sdk pack to the workload manifest * [msbuild] Fixes the Windows Sdk pack name * [dotnet] Merge Mqtt instead of Mqtt.Server We only need System.Net.Mqtt to be merged into Xamarin.iOS.Tasks * Updated Messaging version * [dotnet] Several fixes for the Windows Sdk - Adds missing task CollectMonotouchReferences - Merges more dependencies into Xamarin.iOS.Tasks.dll needed by XMA - Updates the msbuild/Makefile to include files from both the output dir and the source dir - Overrides the agents directory to look for them on the Windows pack * [dotnet] Fixes the XMA Build agent - The build agent is an app so it cannot target ns2.0 - The MSBuild dependencies should be copied into the agent zip file - Avoids copying all the Xamarin iOS SDK core targets into the build agent, since those are not needed - Ensures the broker zip file is copied into the Xamarin.iOS.Windows.Tasks output dir so its included in the Windows pack * Bumps Xamarin.Messaging to 1.2.102 * Adds net6-win branch to trigger builds * Adds Messaging.Client missing dependency to Xamarin.Mac.Tasks * Added Xamarin.Messaging.Apple.Tasks project and VerifyXcodeVersion Task * Fix unloaded Xamarin.Messaging.Build project * Added Build contracts project and unified Xamarin.Messaigng.Apple.Tasks in Xamarin.iOS.Tasks.Windows Also added missing tasks and changes .After.targets * Updated Xamarin.Messaging version * Build agent - reference MSBuild assemblies from the framework Since the assemblies will be included in the build agent we need those to be the ones that come from the framework to be compatible with macOS * [msbuild] Fixes _UpdateDynamicLibraryId target The tasks con this target need to be executed remotely (when building from Windows). * Updates resources * Bump Xamarin.Messaging Fixes problems when executing Exec task remotely * [dotnet] Overrides Publish targets to execute them remotely from Windows The `_CopyResolvedFilesToPublishPreserveNewest` and `_CopyResolvedFilesToPublishAlways` targets essentially copy files into the app bundle. Since those are part of the .NET SDK we need to override those so we can pass to the Copy task the SessionId parameter and then it will be executed remotely when building from Windows. This is done in a Windows.After.targets file so it won't affect builds on macOS. * Added ILMerge to Xamarin.iOS.Tasks.Windows Also modified ILMerge.targets to not include System assemblies because we don't need them on the Windows package * Bumps Messaging This new version of messaging fixes a problem when copying task inputs from Windows to the Mac * [dotnet] Fixes copying files to the Mac when building from Windows When building from Windows there are .NET SDK targets that copy dynamic libraries from the SDK to the intermediate output directory or other files to the publish directory, since we can't control those we can't run them remotely so we need to copy those files to the Mac to ensure other targets will find those. * [dotnet] Fixes how files are copied to the output dir - Before executing `_CopyResolvedFilesToPublishPreserveNewest` and `_CopyResolvedFilesToPublishAlways` we copy the input files for those targets to the Mac - Then we override the original targets to execute the same copy task as the original ones but on the Mac, so the output files are placed in the right location for the following targets to pick them up. * Fixes typo on Xamarin.iOS.Common.After.targets * Bumps Xamarin.Messaging * [msbuild] Fixes VerifyXcodeVersion and ResolveUTIs tasks Both tasks were not being able to connect to the Mac mostly because of ILRepack, there were kind of 2 versions of Xamarin.Messaging, one merged into Xamarin.iOS.Tasks and another one merged into Xamarin.iOS.Windows.Tasks. Because of this the build connection object registered on the task could not be casted to the build connection type. This essentially moves both tasks into the Xamarin.iOS.Tasks assembly to avoid this issue, and as part of that also includes the Messaging contracts into that same project. * [msbuild] Fixes warnings when building from Windows * [dotnet] Adds missing assemblies to merge into Xamarin.iOS.Tasks Those 2 new assemblies will only be used from Windows and we need their implementation instead of the ref assemblies. In the future we will need to find a way of doing this on the Windows only pack insted of doing it on the core Xamarin.iOS.Tasks assembly. * [dotnet] Compute PublishTrimmed on a target We need to do this so the property is evaluated after VS on Windows connects to the Mac, otherwise by default IsMacEnabled is false from Windows. * Bumps Messaging to 1.2.111 * [dotnet] Execute ILLink remotely when building from Windows - Overrides the ILLink task and _RunILLink target to add the hability to execute it remotely, adding input and output properties so files are copied to the server and output files are created on Windows. - This "custom" ILLink task will only be executed from the Windows targets so when building from a Mac it will execute the core SDK task. * [dotnet] Fixes intput/output files creation for linker tasks - Custom Linker options file should be created on the Mac so we need to execute WriteLinesToFile remotely - All the *.items files from the linker are created on the Mac so we need to execute ReadItemsFromFile remotely - CompileNativeCode: fixes the OutputFile metadata path, otherwise the execution fails; also copies all the files in the declared "IncludeDirectories" to the Mac - Avoids copying input files from Windows to the Mac when running LinkNativeCode since the real input files already exist on the Mac, and Windows contains only empty files just to make MSBuild inputs/outputs check work. If we copy those empty files to the Mac we brake the build. * [msbuild] Minor fixes after merging from main * [dotnet] Adds missing output files to the Xamarin.iOS.Tasks.Windows project The output of this project was missing Messaging build targets and the build agent zip file that are needed to create the dotnet Windows specific pack * [dotnet] Fixes dotnet Windows specific pack generation Ensures the Windows projects are built and the files are copied to the dotnet pack directory before creating the package. It also adds a variable to enable building this pack. * [dotnet] Adds iOS Windows specific pack to iOS only MSI There's only a Windows specific pack for iOS available for now, so we should only add it to the iOS SDK MSI * [dotnet] Create a separate bundle for the iOS Windows MSI We need to do this to avoid including the Windows specific pack in the pkg. Also for now we'll only create an MSI for iOS since it's the only supported platform from Windows. * Fixes spacing issues in Xamarin.iOS.Tasks.csproj * Bumps Touch.Unit back to 05db76 * Fixes formatting problems * [msbuild] Replaces error E0176 by E0186 Because there's a warning W0176 that will overlap with the error * [msbuild] Fixes CompileEntitlements task There were 2 problems: 1- The if statement on the DefaultEntitlementsPath was wrong, because we should return the base value if there's no SessionId (which means the task is running on a Mac) 2- We should copy to the Mac the default entitlements file if no custom file was specified * Several fixes to cleanup the code to support iOS from Windows * Apply suggestions from code review Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com> * Formatting fixes in Xamarin.Messaging.Build * Reverted formatting changes in CompileEntitlements.cs * More formatting fixes * Update msbuild/Messaging/Xamarin.Messaging.Build/Handlers/ExecuteTaskMessageHandler.cs Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com> * Fixes order of MSBuild errors in the resource file * Add newly added localizable strings to canary test of translated strings. * Delete tests that ensure theres code only on the abstract tasks These were needed to ensure all the code was in the base tasks so we could have tasks implementations on Windows to remote those. Now that code is part of this repo (and that is why these tests are failing now) so we do not need them anymore. * [dotnet] Don't build the Windows SDK pack if not configured to do so. Co-authored-by: mag <mauro.agnoletti@gmail.com> Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
2021-02-12 09:43:17 +03:00
$$(Q) rm -rf $$@ $$@.tmpdir $$@.tmp
[.NET] Rename several DOTNET6_* variables to to DOTNET_*. (#14463) Also rename DOTNET_VERSION to SYSTEM_DOTNET_VERSION to make it clear what it's referring to (and to not clash with DOTNET6_VERSION which has now been renamed to DOTNET_VERSION). .NET 7 is right around the corner.
2022-03-23 10:07:34 +03:00
$$(Q) mkdir -p $$@.tmpdir/dotnet/sdk-manifests/$(DOTNET_VERSION_BAND)/
[dotnet] Initial support for .NET6 from Windows (#10590) These changes add support for executing iOS and MacDev tasks remotely (on a Mac) when running a build from Windows, and creates a specific .NET6 pack for Windows that's only included in the MSI. For now this only enables builds for the iOS Simulator, physical devices are not yet supported. - Each task decides if it should run locally or remotely depending on the SessionId property, which will only have a value on Windows. - The XMA Build agent is now part of this repo and will be included in the iOS .NET6 Windows pack. - On this first version we're including some Windows specific tasks and references into the Xamarin.iOS.Tasks project for simplicity, but those will be moved to the Windows specific project. ------------ * [msbuild] Adds support for executing Xamarin.iOS tasks from Windows * [msbuild] Adds support for executing Xamarin.MacDev tasks from Windows * Added XMA Build Agent to Xamarin.MacDev.Tasks.sln * Fixes some MSBuild versioning problems * Makes the XMA Build agent load Xamarin.iOS tasks We need to load a type from the iOS tasks assembly so we can run the tasks requested by MSBuild from Windows. We only need to load Xamarin.iOS.Tasks.dll since MacDev.tasks is already embedded in that one. There's a little trick on the csproj, we can't directly use the Xamarin.iOS.Tasks project ref assemblies because that includes both Xamarin.iOS.Tasks.dll and Xamarin.MacDev.Tasks.dll, so the MacDev tasks will collide. We use the project ref only for build dependency purposes but we add an assembly reference to Xamarin.iOS.Tasks.dll. * Added Xamarin.iOS.Tasks.Windows project * Removed unnecessary references on Xamarin.iOS.Tasks.Windows.csproj * Adds Messaging assemblies when ILRepacking Xamarin Tasks The Xamarin Task assemblies now depend on Messaging, so we need the Messaging assemblies to be packed into Xamarin.Mac.Tasks and Xamarin.iOS.Tasks. Also had to remove the direct Messaging dependencies from the build agent since those are already contained in Xamarin.iOS.Tasks * Adds a reference to Messaging.Core targets to the Agent's project * [msbuild] Adds Xamarin iOS Windows targets * [msbuild] Adds missing dependencies to Xamarin.iOS.Tasks This should fix build errors because of missing dependencies. Had to move System.Net.Mqtt.Server from the Build agent project to the tasks one to avoid conflicts with System.Diagnostics.Tracer. * [dotnet] Creates iOS Windows pack Creates a new pack for Windows specific (targets, build agent, etc.) files that shouldn't be installed on the Mac. We have a separate package for this to avoid increasing the core pack size with things that are not needed when using it from macOS. * Fixes type in dotnet makefile * [dotnet] Fixes the iOS Windows pack generation - The windows pack should not include the Sdk and Targets folders - For now we'll just create an iOS pack - Fixes the path to the files to include on the Windows Sdk pack * Added reference to the Windows iOS SDK from the Xamarin.iOS.Common.targets Added a property to navigate to the Windows iOS SDK folder, based on a naming convention that assumes that both packs will always have the same version * Added reference to the core iOS SDK from the Windows iOS SDK Added a property to navigate to the core iOS SDK folder, based on a naming convention that assumes that both packs will always have the same version * Updated Messaging version * Override MessagingBuildClientAssemblyFile property and correctly imported props from targets * [dotnet] Make Windows pack using target files from the output dir We need to take the target files from the output dir to include targets that are part of nuget packages, otherwise we will only include targets from our source * [dotnet] Adds the Windows Sdk pack to the workload manifest * [msbuild] Fixes the Windows Sdk pack name * [dotnet] Merge Mqtt instead of Mqtt.Server We only need System.Net.Mqtt to be merged into Xamarin.iOS.Tasks * Updated Messaging version * [dotnet] Several fixes for the Windows Sdk - Adds missing task CollectMonotouchReferences - Merges more dependencies into Xamarin.iOS.Tasks.dll needed by XMA - Updates the msbuild/Makefile to include files from both the output dir and the source dir - Overrides the agents directory to look for them on the Windows pack * [dotnet] Fixes the XMA Build agent - The build agent is an app so it cannot target ns2.0 - The MSBuild dependencies should be copied into the agent zip file - Avoids copying all the Xamarin iOS SDK core targets into the build agent, since those are not needed - Ensures the broker zip file is copied into the Xamarin.iOS.Windows.Tasks output dir so its included in the Windows pack * Bumps Xamarin.Messaging to 1.2.102 * Adds net6-win branch to trigger builds * Adds Messaging.Client missing dependency to Xamarin.Mac.Tasks * Added Xamarin.Messaging.Apple.Tasks project and VerifyXcodeVersion Task * Fix unloaded Xamarin.Messaging.Build project * Added Build contracts project and unified Xamarin.Messaigng.Apple.Tasks in Xamarin.iOS.Tasks.Windows Also added missing tasks and changes .After.targets * Updated Xamarin.Messaging version * Build agent - reference MSBuild assemblies from the framework Since the assemblies will be included in the build agent we need those to be the ones that come from the framework to be compatible with macOS * [msbuild] Fixes _UpdateDynamicLibraryId target The tasks con this target need to be executed remotely (when building from Windows). * Updates resources * Bump Xamarin.Messaging Fixes problems when executing Exec task remotely * [dotnet] Overrides Publish targets to execute them remotely from Windows The `_CopyResolvedFilesToPublishPreserveNewest` and `_CopyResolvedFilesToPublishAlways` targets essentially copy files into the app bundle. Since those are part of the .NET SDK we need to override those so we can pass to the Copy task the SessionId parameter and then it will be executed remotely when building from Windows. This is done in a Windows.After.targets file so it won't affect builds on macOS. * Added ILMerge to Xamarin.iOS.Tasks.Windows Also modified ILMerge.targets to not include System assemblies because we don't need them on the Windows package * Bumps Messaging This new version of messaging fixes a problem when copying task inputs from Windows to the Mac * [dotnet] Fixes copying files to the Mac when building from Windows When building from Windows there are .NET SDK targets that copy dynamic libraries from the SDK to the intermediate output directory or other files to the publish directory, since we can't control those we can't run them remotely so we need to copy those files to the Mac to ensure other targets will find those. * [dotnet] Fixes how files are copied to the output dir - Before executing `_CopyResolvedFilesToPublishPreserveNewest` and `_CopyResolvedFilesToPublishAlways` we copy the input files for those targets to the Mac - Then we override the original targets to execute the same copy task as the original ones but on the Mac, so the output files are placed in the right location for the following targets to pick them up. * Fixes typo on Xamarin.iOS.Common.After.targets * Bumps Xamarin.Messaging * [msbuild] Fixes VerifyXcodeVersion and ResolveUTIs tasks Both tasks were not being able to connect to the Mac mostly because of ILRepack, there were kind of 2 versions of Xamarin.Messaging, one merged into Xamarin.iOS.Tasks and another one merged into Xamarin.iOS.Windows.Tasks. Because of this the build connection object registered on the task could not be casted to the build connection type. This essentially moves both tasks into the Xamarin.iOS.Tasks assembly to avoid this issue, and as part of that also includes the Messaging contracts into that same project. * [msbuild] Fixes warnings when building from Windows * [dotnet] Adds missing assemblies to merge into Xamarin.iOS.Tasks Those 2 new assemblies will only be used from Windows and we need their implementation instead of the ref assemblies. In the future we will need to find a way of doing this on the Windows only pack insted of doing it on the core Xamarin.iOS.Tasks assembly. * [dotnet] Compute PublishTrimmed on a target We need to do this so the property is evaluated after VS on Windows connects to the Mac, otherwise by default IsMacEnabled is false from Windows. * Bumps Messaging to 1.2.111 * [dotnet] Execute ILLink remotely when building from Windows - Overrides the ILLink task and _RunILLink target to add the hability to execute it remotely, adding input and output properties so files are copied to the server and output files are created on Windows. - This "custom" ILLink task will only be executed from the Windows targets so when building from a Mac it will execute the core SDK task. * [dotnet] Fixes intput/output files creation for linker tasks - Custom Linker options file should be created on the Mac so we need to execute WriteLinesToFile remotely - All the *.items files from the linker are created on the Mac so we need to execute ReadItemsFromFile remotely - CompileNativeCode: fixes the OutputFile metadata path, otherwise the execution fails; also copies all the files in the declared "IncludeDirectories" to the Mac - Avoids copying input files from Windows to the Mac when running LinkNativeCode since the real input files already exist on the Mac, and Windows contains only empty files just to make MSBuild inputs/outputs check work. If we copy those empty files to the Mac we brake the build. * [msbuild] Minor fixes after merging from main * [dotnet] Adds missing output files to the Xamarin.iOS.Tasks.Windows project The output of this project was missing Messaging build targets and the build agent zip file that are needed to create the dotnet Windows specific pack * [dotnet] Fixes dotnet Windows specific pack generation Ensures the Windows projects are built and the files are copied to the dotnet pack directory before creating the package. It also adds a variable to enable building this pack. * [dotnet] Adds iOS Windows specific pack to iOS only MSI There's only a Windows specific pack for iOS available for now, so we should only add it to the iOS SDK MSI * [dotnet] Create a separate bundle for the iOS Windows MSI We need to do this to avoid including the Windows specific pack in the pkg. Also for now we'll only create an MSI for iOS since it's the only supported platform from Windows. * Fixes spacing issues in Xamarin.iOS.Tasks.csproj * Bumps Touch.Unit back to 05db76 * Fixes formatting problems * [msbuild] Replaces error E0176 by E0186 Because there's a warning W0176 that will overlap with the error * [msbuild] Fixes CompileEntitlements task There were 2 problems: 1- The if statement on the DefaultEntitlementsPath was wrong, because we should return the base value if there's no SessionId (which means the task is running on a Mac) 2- We should copy to the Mac the default entitlements file if no custom file was specified * Several fixes to cleanup the code to support iOS from Windows * Apply suggestions from code review Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com> * Formatting fixes in Xamarin.Messaging.Build * Reverted formatting changes in CompileEntitlements.cs * More formatting fixes * Update msbuild/Messaging/Xamarin.Messaging.Build/Handlers/ExecuteTaskMessageHandler.cs Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com> * Fixes order of MSBuild errors in the resource file * Add newly added localizable strings to canary test of translated strings. * Delete tests that ensure theres code only on the abstract tasks These were needed to ensure all the code was in the base tasks so we could have tasks implementations on Windows to remote those. Now that code is part of this repo (and that is why these tests are failing now) so we do not need them anymore. * [dotnet] Don't build the Windows SDK pack if not configured to do so. Co-authored-by: mag <mauro.agnoletti@gmail.com> Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
2021-02-12 09:43:17 +03:00
$$(Q) mkdir -p $$@.tmpdir/dotnet/packs/Microsoft.$1.Sdk
$$(Q) mkdir -p $$@.tmpdir/dotnet/packs/Microsoft.$1.Windows.Sdk
$$(Q) mkdir -p $$@.tmpdir/dotnet/packs/Microsoft.$1.Ref
.NET 6 templates for iOS, macOS, tvOS, & MacCatalyst (#10741) Context: https://docs.microsoft.com/dotnet/core/tutorials/cli-templates-create-template-pack Context: https://github.com/dotnet/templating/wiki Context: https://github.com/dotnet/designs/pull/120 Fixes: https://github.com/xamarin/xamarin-macios/issues/10252 To implement templates in a .NET workload: 1. Make `.nupkg` files that follow the structure of the `dotnet new` templating system, using `$(PackageType)` of `Template`. 2. Install the `.nupkg` files in in `dotnet/template-packs/` 3. Update `WorkloadManifest.json`, to be part of the workload: "Microsoft.@PLATFORM@.Templates": { "kind": "template", "version": "@VERSION@" } These are a starting point, for what I would consider the minimum for the xamarin-macios repo to provide for now: Template Name Short Name Language Tags -------------------------------------------- -------------- ---------- ---------------------- iOS Controller template ios-controller [C#] iOS iOS Application ios [C#] iOS iOS Class library ioslib [C#] iOS macOS Application macos [C#] macOS MacCatalyst Application maccatalyst [C#] macOS/Catalyst tvOS Application tvos [C#] tvOS We will probably need PM input on what the final templates will be. To use these, you might do: $ mkdir MyApp && cd MyApp $ dotnet new ios $ dotnet new ios-controller --name LoginController --namespace MyApp Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
2021-03-02 18:23:05 +03:00
$$(Q) mkdir -p $$@.tmpdir/dotnet/template-packs
[.NET] Rename several DOTNET6_* variables to to DOTNET_*. (#14463) Also rename DOTNET_VERSION to SYSTEM_DOTNET_VERSION to make it clear what it's referring to (and to not clash with DOTNET6_VERSION which has now been renamed to DOTNET_VERSION). .NET 7 is right around the corner.
2022-03-23 10:07:34 +03:00
$$(Q) $(CP) -r Workloads/Microsoft.NET.Sdk.$1 $$@.tmpdir/dotnet/sdk-manifests/$(DOTNET_VERSION_BAND)/
[dotnet] Initial support for .NET6 from Windows (#10590) These changes add support for executing iOS and MacDev tasks remotely (on a Mac) when running a build from Windows, and creates a specific .NET6 pack for Windows that's only included in the MSI. For now this only enables builds for the iOS Simulator, physical devices are not yet supported. - Each task decides if it should run locally or remotely depending on the SessionId property, which will only have a value on Windows. - The XMA Build agent is now part of this repo and will be included in the iOS .NET6 Windows pack. - On this first version we're including some Windows specific tasks and references into the Xamarin.iOS.Tasks project for simplicity, but those will be moved to the Windows specific project. ------------ * [msbuild] Adds support for executing Xamarin.iOS tasks from Windows * [msbuild] Adds support for executing Xamarin.MacDev tasks from Windows * Added XMA Build Agent to Xamarin.MacDev.Tasks.sln * Fixes some MSBuild versioning problems * Makes the XMA Build agent load Xamarin.iOS tasks We need to load a type from the iOS tasks assembly so we can run the tasks requested by MSBuild from Windows. We only need to load Xamarin.iOS.Tasks.dll since MacDev.tasks is already embedded in that one. There's a little trick on the csproj, we can't directly use the Xamarin.iOS.Tasks project ref assemblies because that includes both Xamarin.iOS.Tasks.dll and Xamarin.MacDev.Tasks.dll, so the MacDev tasks will collide. We use the project ref only for build dependency purposes but we add an assembly reference to Xamarin.iOS.Tasks.dll. * Added Xamarin.iOS.Tasks.Windows project * Removed unnecessary references on Xamarin.iOS.Tasks.Windows.csproj * Adds Messaging assemblies when ILRepacking Xamarin Tasks The Xamarin Task assemblies now depend on Messaging, so we need the Messaging assemblies to be packed into Xamarin.Mac.Tasks and Xamarin.iOS.Tasks. Also had to remove the direct Messaging dependencies from the build agent since those are already contained in Xamarin.iOS.Tasks * Adds a reference to Messaging.Core targets to the Agent's project * [msbuild] Adds Xamarin iOS Windows targets * [msbuild] Adds missing dependencies to Xamarin.iOS.Tasks This should fix build errors because of missing dependencies. Had to move System.Net.Mqtt.Server from the Build agent project to the tasks one to avoid conflicts with System.Diagnostics.Tracer. * [dotnet] Creates iOS Windows pack Creates a new pack for Windows specific (targets, build agent, etc.) files that shouldn't be installed on the Mac. We have a separate package for this to avoid increasing the core pack size with things that are not needed when using it from macOS. * Fixes type in dotnet makefile * [dotnet] Fixes the iOS Windows pack generation - The windows pack should not include the Sdk and Targets folders - For now we'll just create an iOS pack - Fixes the path to the files to include on the Windows Sdk pack * Added reference to the Windows iOS SDK from the Xamarin.iOS.Common.targets Added a property to navigate to the Windows iOS SDK folder, based on a naming convention that assumes that both packs will always have the same version * Added reference to the core iOS SDK from the Windows iOS SDK Added a property to navigate to the core iOS SDK folder, based on a naming convention that assumes that both packs will always have the same version * Updated Messaging version * Override MessagingBuildClientAssemblyFile property and correctly imported props from targets * [dotnet] Make Windows pack using target files from the output dir We need to take the target files from the output dir to include targets that are part of nuget packages, otherwise we will only include targets from our source * [dotnet] Adds the Windows Sdk pack to the workload manifest * [msbuild] Fixes the Windows Sdk pack name * [dotnet] Merge Mqtt instead of Mqtt.Server We only need System.Net.Mqtt to be merged into Xamarin.iOS.Tasks * Updated Messaging version * [dotnet] Several fixes for the Windows Sdk - Adds missing task CollectMonotouchReferences - Merges more dependencies into Xamarin.iOS.Tasks.dll needed by XMA - Updates the msbuild/Makefile to include files from both the output dir and the source dir - Overrides the agents directory to look for them on the Windows pack * [dotnet] Fixes the XMA Build agent - The build agent is an app so it cannot target ns2.0 - The MSBuild dependencies should be copied into the agent zip file - Avoids copying all the Xamarin iOS SDK core targets into the build agent, since those are not needed - Ensures the broker zip file is copied into the Xamarin.iOS.Windows.Tasks output dir so its included in the Windows pack * Bumps Xamarin.Messaging to 1.2.102 * Adds net6-win branch to trigger builds * Adds Messaging.Client missing dependency to Xamarin.Mac.Tasks * Added Xamarin.Messaging.Apple.Tasks project and VerifyXcodeVersion Task * Fix unloaded Xamarin.Messaging.Build project * Added Build contracts project and unified Xamarin.Messaigng.Apple.Tasks in Xamarin.iOS.Tasks.Windows Also added missing tasks and changes .After.targets * Updated Xamarin.Messaging version * Build agent - reference MSBuild assemblies from the framework Since the assemblies will be included in the build agent we need those to be the ones that come from the framework to be compatible with macOS * [msbuild] Fixes _UpdateDynamicLibraryId target The tasks con this target need to be executed remotely (when building from Windows). * Updates resources * Bump Xamarin.Messaging Fixes problems when executing Exec task remotely * [dotnet] Overrides Publish targets to execute them remotely from Windows The `_CopyResolvedFilesToPublishPreserveNewest` and `_CopyResolvedFilesToPublishAlways` targets essentially copy files into the app bundle. Since those are part of the .NET SDK we need to override those so we can pass to the Copy task the SessionId parameter and then it will be executed remotely when building from Windows. This is done in a Windows.After.targets file so it won't affect builds on macOS. * Added ILMerge to Xamarin.iOS.Tasks.Windows Also modified ILMerge.targets to not include System assemblies because we don't need them on the Windows package * Bumps Messaging This new version of messaging fixes a problem when copying task inputs from Windows to the Mac * [dotnet] Fixes copying files to the Mac when building from Windows When building from Windows there are .NET SDK targets that copy dynamic libraries from the SDK to the intermediate output directory or other files to the publish directory, since we can't control those we can't run them remotely so we need to copy those files to the Mac to ensure other targets will find those. * [dotnet] Fixes how files are copied to the output dir - Before executing `_CopyResolvedFilesToPublishPreserveNewest` and `_CopyResolvedFilesToPublishAlways` we copy the input files for those targets to the Mac - Then we override the original targets to execute the same copy task as the original ones but on the Mac, so the output files are placed in the right location for the following targets to pick them up. * Fixes typo on Xamarin.iOS.Common.After.targets * Bumps Xamarin.Messaging * [msbuild] Fixes VerifyXcodeVersion and ResolveUTIs tasks Both tasks were not being able to connect to the Mac mostly because of ILRepack, there were kind of 2 versions of Xamarin.Messaging, one merged into Xamarin.iOS.Tasks and another one merged into Xamarin.iOS.Windows.Tasks. Because of this the build connection object registered on the task could not be casted to the build connection type. This essentially moves both tasks into the Xamarin.iOS.Tasks assembly to avoid this issue, and as part of that also includes the Messaging contracts into that same project. * [msbuild] Fixes warnings when building from Windows * [dotnet] Adds missing assemblies to merge into Xamarin.iOS.Tasks Those 2 new assemblies will only be used from Windows and we need their implementation instead of the ref assemblies. In the future we will need to find a way of doing this on the Windows only pack insted of doing it on the core Xamarin.iOS.Tasks assembly. * [dotnet] Compute PublishTrimmed on a target We need to do this so the property is evaluated after VS on Windows connects to the Mac, otherwise by default IsMacEnabled is false from Windows. * Bumps Messaging to 1.2.111 * [dotnet] Execute ILLink remotely when building from Windows - Overrides the ILLink task and _RunILLink target to add the hability to execute it remotely, adding input and output properties so files are copied to the server and output files are created on Windows. - This "custom" ILLink task will only be executed from the Windows targets so when building from a Mac it will execute the core SDK task. * [dotnet] Fixes intput/output files creation for linker tasks - Custom Linker options file should be created on the Mac so we need to execute WriteLinesToFile remotely - All the *.items files from the linker are created on the Mac so we need to execute ReadItemsFromFile remotely - CompileNativeCode: fixes the OutputFile metadata path, otherwise the execution fails; also copies all the files in the declared "IncludeDirectories" to the Mac - Avoids copying input files from Windows to the Mac when running LinkNativeCode since the real input files already exist on the Mac, and Windows contains only empty files just to make MSBuild inputs/outputs check work. If we copy those empty files to the Mac we brake the build. * [msbuild] Minor fixes after merging from main * [dotnet] Adds missing output files to the Xamarin.iOS.Tasks.Windows project The output of this project was missing Messaging build targets and the build agent zip file that are needed to create the dotnet Windows specific pack * [dotnet] Fixes dotnet Windows specific pack generation Ensures the Windows projects are built and the files are copied to the dotnet pack directory before creating the package. It also adds a variable to enable building this pack. * [dotnet] Adds iOS Windows specific pack to iOS only MSI There's only a Windows specific pack for iOS available for now, so we should only add it to the iOS SDK MSI * [dotnet] Create a separate bundle for the iOS Windows MSI We need to do this to avoid including the Windows specific pack in the pkg. Also for now we'll only create an MSI for iOS since it's the only supported platform from Windows. * Fixes spacing issues in Xamarin.iOS.Tasks.csproj * Bumps Touch.Unit back to 05db76 * Fixes formatting problems * [msbuild] Replaces error E0176 by E0186 Because there's a warning W0176 that will overlap with the error * [msbuild] Fixes CompileEntitlements task There were 2 problems: 1- The if statement on the DefaultEntitlementsPath was wrong, because we should return the base value if there's no SessionId (which means the task is running on a Mac) 2- We should copy to the Mac the default entitlements file if no custom file was specified * Several fixes to cleanup the code to support iOS from Windows * Apply suggestions from code review Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com> * Formatting fixes in Xamarin.Messaging.Build * Reverted formatting changes in CompileEntitlements.cs * More formatting fixes * Update msbuild/Messaging/Xamarin.Messaging.Build/Handlers/ExecuteTaskMessageHandler.cs Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com> * Fixes order of MSBuild errors in the resource file * Add newly added localizable strings to canary test of translated strings. * Delete tests that ensure theres code only on the abstract tasks These were needed to ensure all the code was in the base tasks so we could have tasks implementations on Windows to remote those. Now that code is part of this repo (and that is why these tests are failing now) so we do not need them anymore. * [dotnet] Don't build the Windows SDK pack if not configured to do so. Co-authored-by: mag <mauro.agnoletti@gmail.com> Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
2021-02-12 09:43:17 +03:00
$$(Q) $(CP) -r $(DOTNET_DESTDIR)/Microsoft.$1.Sdk $$@.tmpdir/dotnet/packs/Microsoft.$1.Sdk/$2
$$(Q) $(CP) -r $(DOTNET_DESTDIR)/Microsoft.$1.Windows.Sdk $$@.tmpdir/dotnet/packs/Microsoft.$1.Windows.Sdk/$2
$$(Q) $(CP) -r $(DOTNET_DESTDIR)/Microsoft.$1.Ref $$@.tmpdir/dotnet/packs/Microsoft.$1.Ref/$2
[dotnet] remove +sha from templates in installers (#10816) I noticed the new templates did not actually work from the installer unless I did: % sudo mv \ /usr/local/share/dotnet/template-packs/Microsoft.iOS.Templates.14.4.100-ci.main.1180+sha.bccef33d3.nupkg \ /usr/local/share/dotnet/template-packs/Microsoft.iOS.Templates.14.4.100-ci.main.1180.nupkg I checked other templates like Android or ASP.NET, and they do not currently have a hash like `+sha.bccef33d3` in the file name. To fix this problem, I updated the file in the installers so we now remove the `+sha.bccef33d3` portion from file name: $(subst +$(NUGET_BUILD_METADATA),,$(notdir $(TEMPLATE_PACKS_$(4)))) I also found the `Microsoft.iOS.Bundle.*.zip` did not contain `template-packs` at all, so I fixed this as well.
2021-03-10 01:56:26 +03:00
$$(Q) $(CP) $(TEMPLATE_PACKS_$(4)) $$@.tmpdir/dotnet/template-packs/$(subst +$(NUGET_BUILD_METADATA),,$(notdir $(TEMPLATE_PACKS_$(4))))
[dotnet] Initial support for .NET6 from Windows (#10590) These changes add support for executing iOS and MacDev tasks remotely (on a Mac) when running a build from Windows, and creates a specific .NET6 pack for Windows that's only included in the MSI. For now this only enables builds for the iOS Simulator, physical devices are not yet supported. - Each task decides if it should run locally or remotely depending on the SessionId property, which will only have a value on Windows. - The XMA Build agent is now part of this repo and will be included in the iOS .NET6 Windows pack. - On this first version we're including some Windows specific tasks and references into the Xamarin.iOS.Tasks project for simplicity, but those will be moved to the Windows specific project. ------------ * [msbuild] Adds support for executing Xamarin.iOS tasks from Windows * [msbuild] Adds support for executing Xamarin.MacDev tasks from Windows * Added XMA Build Agent to Xamarin.MacDev.Tasks.sln * Fixes some MSBuild versioning problems * Makes the XMA Build agent load Xamarin.iOS tasks We need to load a type from the iOS tasks assembly so we can run the tasks requested by MSBuild from Windows. We only need to load Xamarin.iOS.Tasks.dll since MacDev.tasks is already embedded in that one. There's a little trick on the csproj, we can't directly use the Xamarin.iOS.Tasks project ref assemblies because that includes both Xamarin.iOS.Tasks.dll and Xamarin.MacDev.Tasks.dll, so the MacDev tasks will collide. We use the project ref only for build dependency purposes but we add an assembly reference to Xamarin.iOS.Tasks.dll. * Added Xamarin.iOS.Tasks.Windows project * Removed unnecessary references on Xamarin.iOS.Tasks.Windows.csproj * Adds Messaging assemblies when ILRepacking Xamarin Tasks The Xamarin Task assemblies now depend on Messaging, so we need the Messaging assemblies to be packed into Xamarin.Mac.Tasks and Xamarin.iOS.Tasks. Also had to remove the direct Messaging dependencies from the build agent since those are already contained in Xamarin.iOS.Tasks * Adds a reference to Messaging.Core targets to the Agent's project * [msbuild] Adds Xamarin iOS Windows targets * [msbuild] Adds missing dependencies to Xamarin.iOS.Tasks This should fix build errors because of missing dependencies. Had to move System.Net.Mqtt.Server from the Build agent project to the tasks one to avoid conflicts with System.Diagnostics.Tracer. * [dotnet] Creates iOS Windows pack Creates a new pack for Windows specific (targets, build agent, etc.) files that shouldn't be installed on the Mac. We have a separate package for this to avoid increasing the core pack size with things that are not needed when using it from macOS. * Fixes type in dotnet makefile * [dotnet] Fixes the iOS Windows pack generation - The windows pack should not include the Sdk and Targets folders - For now we'll just create an iOS pack - Fixes the path to the files to include on the Windows Sdk pack * Added reference to the Windows iOS SDK from the Xamarin.iOS.Common.targets Added a property to navigate to the Windows iOS SDK folder, based on a naming convention that assumes that both packs will always have the same version * Added reference to the core iOS SDK from the Windows iOS SDK Added a property to navigate to the core iOS SDK folder, based on a naming convention that assumes that both packs will always have the same version * Updated Messaging version * Override MessagingBuildClientAssemblyFile property and correctly imported props from targets * [dotnet] Make Windows pack using target files from the output dir We need to take the target files from the output dir to include targets that are part of nuget packages, otherwise we will only include targets from our source * [dotnet] Adds the Windows Sdk pack to the workload manifest * [msbuild] Fixes the Windows Sdk pack name * [dotnet] Merge Mqtt instead of Mqtt.Server We only need System.Net.Mqtt to be merged into Xamarin.iOS.Tasks * Updated Messaging version * [dotnet] Several fixes for the Windows Sdk - Adds missing task CollectMonotouchReferences - Merges more dependencies into Xamarin.iOS.Tasks.dll needed by XMA - Updates the msbuild/Makefile to include files from both the output dir and the source dir - Overrides the agents directory to look for them on the Windows pack * [dotnet] Fixes the XMA Build agent - The build agent is an app so it cannot target ns2.0 - The MSBuild dependencies should be copied into the agent zip file - Avoids copying all the Xamarin iOS SDK core targets into the build agent, since those are not needed - Ensures the broker zip file is copied into the Xamarin.iOS.Windows.Tasks output dir so its included in the Windows pack * Bumps Xamarin.Messaging to 1.2.102 * Adds net6-win branch to trigger builds * Adds Messaging.Client missing dependency to Xamarin.Mac.Tasks * Added Xamarin.Messaging.Apple.Tasks project and VerifyXcodeVersion Task * Fix unloaded Xamarin.Messaging.Build project * Added Build contracts project and unified Xamarin.Messaigng.Apple.Tasks in Xamarin.iOS.Tasks.Windows Also added missing tasks and changes .After.targets * Updated Xamarin.Messaging version * Build agent - reference MSBuild assemblies from the framework Since the assemblies will be included in the build agent we need those to be the ones that come from the framework to be compatible with macOS * [msbuild] Fixes _UpdateDynamicLibraryId target The tasks con this target need to be executed remotely (when building from Windows). * Updates resources * Bump Xamarin.Messaging Fixes problems when executing Exec task remotely * [dotnet] Overrides Publish targets to execute them remotely from Windows The `_CopyResolvedFilesToPublishPreserveNewest` and `_CopyResolvedFilesToPublishAlways` targets essentially copy files into the app bundle. Since those are part of the .NET SDK we need to override those so we can pass to the Copy task the SessionId parameter and then it will be executed remotely when building from Windows. This is done in a Windows.After.targets file so it won't affect builds on macOS. * Added ILMerge to Xamarin.iOS.Tasks.Windows Also modified ILMerge.targets to not include System assemblies because we don't need them on the Windows package * Bumps Messaging This new version of messaging fixes a problem when copying task inputs from Windows to the Mac * [dotnet] Fixes copying files to the Mac when building from Windows When building from Windows there are .NET SDK targets that copy dynamic libraries from the SDK to the intermediate output directory or other files to the publish directory, since we can't control those we can't run them remotely so we need to copy those files to the Mac to ensure other targets will find those. * [dotnet] Fixes how files are copied to the output dir - Before executing `_CopyResolvedFilesToPublishPreserveNewest` and `_CopyResolvedFilesToPublishAlways` we copy the input files for those targets to the Mac - Then we override the original targets to execute the same copy task as the original ones but on the Mac, so the output files are placed in the right location for the following targets to pick them up. * Fixes typo on Xamarin.iOS.Common.After.targets * Bumps Xamarin.Messaging * [msbuild] Fixes VerifyXcodeVersion and ResolveUTIs tasks Both tasks were not being able to connect to the Mac mostly because of ILRepack, there were kind of 2 versions of Xamarin.Messaging, one merged into Xamarin.iOS.Tasks and another one merged into Xamarin.iOS.Windows.Tasks. Because of this the build connection object registered on the task could not be casted to the build connection type. This essentially moves both tasks into the Xamarin.iOS.Tasks assembly to avoid this issue, and as part of that also includes the Messaging contracts into that same project. * [msbuild] Fixes warnings when building from Windows * [dotnet] Adds missing assemblies to merge into Xamarin.iOS.Tasks Those 2 new assemblies will only be used from Windows and we need their implementation instead of the ref assemblies. In the future we will need to find a way of doing this on the Windows only pack insted of doing it on the core Xamarin.iOS.Tasks assembly. * [dotnet] Compute PublishTrimmed on a target We need to do this so the property is evaluated after VS on Windows connects to the Mac, otherwise by default IsMacEnabled is false from Windows. * Bumps Messaging to 1.2.111 * [dotnet] Execute ILLink remotely when building from Windows - Overrides the ILLink task and _RunILLink target to add the hability to execute it remotely, adding input and output properties so files are copied to the server and output files are created on Windows. - This "custom" ILLink task will only be executed from the Windows targets so when building from a Mac it will execute the core SDK task. * [dotnet] Fixes intput/output files creation for linker tasks - Custom Linker options file should be created on the Mac so we need to execute WriteLinesToFile remotely - All the *.items files from the linker are created on the Mac so we need to execute ReadItemsFromFile remotely - CompileNativeCode: fixes the OutputFile metadata path, otherwise the execution fails; also copies all the files in the declared "IncludeDirectories" to the Mac - Avoids copying input files from Windows to the Mac when running LinkNativeCode since the real input files already exist on the Mac, and Windows contains only empty files just to make MSBuild inputs/outputs check work. If we copy those empty files to the Mac we brake the build. * [msbuild] Minor fixes after merging from main * [dotnet] Adds missing output files to the Xamarin.iOS.Tasks.Windows project The output of this project was missing Messaging build targets and the build agent zip file that are needed to create the dotnet Windows specific pack * [dotnet] Fixes dotnet Windows specific pack generation Ensures the Windows projects are built and the files are copied to the dotnet pack directory before creating the package. It also adds a variable to enable building this pack. * [dotnet] Adds iOS Windows specific pack to iOS only MSI There's only a Windows specific pack for iOS available for now, so we should only add it to the iOS SDK MSI * [dotnet] Create a separate bundle for the iOS Windows MSI We need to do this to avoid including the Windows specific pack in the pkg. Also for now we'll only create an MSI for iOS since it's the only supported platform from Windows. * Fixes spacing issues in Xamarin.iOS.Tasks.csproj * Bumps Touch.Unit back to 05db76 * Fixes formatting problems * [msbuild] Replaces error E0176 by E0186 Because there's a warning W0176 that will overlap with the error * [msbuild] Fixes CompileEntitlements task There were 2 problems: 1- The if statement on the DefaultEntitlementsPath was wrong, because we should return the base value if there's no SessionId (which means the task is running on a Mac) 2- We should copy to the Mac the default entitlements file if no custom file was specified * Several fixes to cleanup the code to support iOS from Windows * Apply suggestions from code review Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com> * Formatting fixes in Xamarin.Messaging.Build * Reverted formatting changes in CompileEntitlements.cs * More formatting fixes * Update msbuild/Messaging/Xamarin.Messaging.Build/Handlers/ExecuteTaskMessageHandler.cs Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com> * Fixes order of MSBuild errors in the resource file * Add newly added localizable strings to canary test of translated strings. * Delete tests that ensure theres code only on the abstract tasks These were needed to ensure all the code was in the base tasks so we could have tasks implementations on Windows to remote those. Now that code is part of this repo (and that is why these tests are failing now) so we do not need them anymore. * [dotnet] Don't build the Windows SDK pack if not configured to do so. Co-authored-by: mag <mauro.agnoletti@gmail.com> Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
2021-02-12 09:43:17 +03:00
$$(Q_GEN) cd $$@.tmpdir && zip -9rq $$(abspath $$@.tmp) .
$$(Q) mv $$@.tmp $$@
$$(Q) echo Created $$@
[msbuild/dotnet] Build the Xamarin.PreBuilt.iOS app bundle. Fixes #12945. (#13342) Build the Xamarin.PreBuilt.iOS app bundle instead of using a prebuilt bundle. This makes sure that we're always using the latest BCL. Some accurate build massaging was needed, because: * To build the prebuilt app we need the iOS workload installed (into our build-local .NET installation). * The iOS workload contains the Microsoft.iOS.Windows.Sdk pack. * The Microsoft.iOS.Windows.Sdk pack contains the prebuilt app. Thus we had a circular reference. Fortunately, the Microsoft.iOS.Windows.Sdk pack is only required on Windows, which means we can break this circular reference by: * Mark Microsoft.iOS.Windows.Sdk pack as only to be installed on Windows (unfortunately it seems we have to list the exact runtime identifiers for the platforms where to install the pack, so we can't do something like "win-*", but new variations of the "win-*" runtime identifier shouldn't show up all that often). * Build the prebuilt app on macOS. This way we don't need the Microsoft.iOS.Windows.Sdk pack when installing the iOS workload locally. The .NET build order is now: * Build general sdk, runtime and ref packs for .NET. * Build the prebuilt app. * Build the Microsoft.iOS.Windows.Sdk pack. Fixes https://github.com/xamarin/xamarin-macios/issues/12945.
2021-11-12 09:38:07 +03:00
WINDOWS_PACKAGE_TARGETS += $(DOTNET_PKG_DIR)/Microsoft.$1.Windows.Bundle.$2.zip
[dotnet] Initial support for .NET6 from Windows (#10590) These changes add support for executing iOS and MacDev tasks remotely (on a Mac) when running a build from Windows, and creates a specific .NET6 pack for Windows that's only included in the MSI. For now this only enables builds for the iOS Simulator, physical devices are not yet supported. - Each task decides if it should run locally or remotely depending on the SessionId property, which will only have a value on Windows. - The XMA Build agent is now part of this repo and will be included in the iOS .NET6 Windows pack. - On this first version we're including some Windows specific tasks and references into the Xamarin.iOS.Tasks project for simplicity, but those will be moved to the Windows specific project. ------------ * [msbuild] Adds support for executing Xamarin.iOS tasks from Windows * [msbuild] Adds support for executing Xamarin.MacDev tasks from Windows * Added XMA Build Agent to Xamarin.MacDev.Tasks.sln * Fixes some MSBuild versioning problems * Makes the XMA Build agent load Xamarin.iOS tasks We need to load a type from the iOS tasks assembly so we can run the tasks requested by MSBuild from Windows. We only need to load Xamarin.iOS.Tasks.dll since MacDev.tasks is already embedded in that one. There's a little trick on the csproj, we can't directly use the Xamarin.iOS.Tasks project ref assemblies because that includes both Xamarin.iOS.Tasks.dll and Xamarin.MacDev.Tasks.dll, so the MacDev tasks will collide. We use the project ref only for build dependency purposes but we add an assembly reference to Xamarin.iOS.Tasks.dll. * Added Xamarin.iOS.Tasks.Windows project * Removed unnecessary references on Xamarin.iOS.Tasks.Windows.csproj * Adds Messaging assemblies when ILRepacking Xamarin Tasks The Xamarin Task assemblies now depend on Messaging, so we need the Messaging assemblies to be packed into Xamarin.Mac.Tasks and Xamarin.iOS.Tasks. Also had to remove the direct Messaging dependencies from the build agent since those are already contained in Xamarin.iOS.Tasks * Adds a reference to Messaging.Core targets to the Agent's project * [msbuild] Adds Xamarin iOS Windows targets * [msbuild] Adds missing dependencies to Xamarin.iOS.Tasks This should fix build errors because of missing dependencies. Had to move System.Net.Mqtt.Server from the Build agent project to the tasks one to avoid conflicts with System.Diagnostics.Tracer. * [dotnet] Creates iOS Windows pack Creates a new pack for Windows specific (targets, build agent, etc.) files that shouldn't be installed on the Mac. We have a separate package for this to avoid increasing the core pack size with things that are not needed when using it from macOS. * Fixes type in dotnet makefile * [dotnet] Fixes the iOS Windows pack generation - The windows pack should not include the Sdk and Targets folders - For now we'll just create an iOS pack - Fixes the path to the files to include on the Windows Sdk pack * Added reference to the Windows iOS SDK from the Xamarin.iOS.Common.targets Added a property to navigate to the Windows iOS SDK folder, based on a naming convention that assumes that both packs will always have the same version * Added reference to the core iOS SDK from the Windows iOS SDK Added a property to navigate to the core iOS SDK folder, based on a naming convention that assumes that both packs will always have the same version * Updated Messaging version * Override MessagingBuildClientAssemblyFile property and correctly imported props from targets * [dotnet] Make Windows pack using target files from the output dir We need to take the target files from the output dir to include targets that are part of nuget packages, otherwise we will only include targets from our source * [dotnet] Adds the Windows Sdk pack to the workload manifest * [msbuild] Fixes the Windows Sdk pack name * [dotnet] Merge Mqtt instead of Mqtt.Server We only need System.Net.Mqtt to be merged into Xamarin.iOS.Tasks * Updated Messaging version * [dotnet] Several fixes for the Windows Sdk - Adds missing task CollectMonotouchReferences - Merges more dependencies into Xamarin.iOS.Tasks.dll needed by XMA - Updates the msbuild/Makefile to include files from both the output dir and the source dir - Overrides the agents directory to look for them on the Windows pack * [dotnet] Fixes the XMA Build agent - The build agent is an app so it cannot target ns2.0 - The MSBuild dependencies should be copied into the agent zip file - Avoids copying all the Xamarin iOS SDK core targets into the build agent, since those are not needed - Ensures the broker zip file is copied into the Xamarin.iOS.Windows.Tasks output dir so its included in the Windows pack * Bumps Xamarin.Messaging to 1.2.102 * Adds net6-win branch to trigger builds * Adds Messaging.Client missing dependency to Xamarin.Mac.Tasks * Added Xamarin.Messaging.Apple.Tasks project and VerifyXcodeVersion Task * Fix unloaded Xamarin.Messaging.Build project * Added Build contracts project and unified Xamarin.Messaigng.Apple.Tasks in Xamarin.iOS.Tasks.Windows Also added missing tasks and changes .After.targets * Updated Xamarin.Messaging version * Build agent - reference MSBuild assemblies from the framework Since the assemblies will be included in the build agent we need those to be the ones that come from the framework to be compatible with macOS * [msbuild] Fixes _UpdateDynamicLibraryId target The tasks con this target need to be executed remotely (when building from Windows). * Updates resources * Bump Xamarin.Messaging Fixes problems when executing Exec task remotely * [dotnet] Overrides Publish targets to execute them remotely from Windows The `_CopyResolvedFilesToPublishPreserveNewest` and `_CopyResolvedFilesToPublishAlways` targets essentially copy files into the app bundle. Since those are part of the .NET SDK we need to override those so we can pass to the Copy task the SessionId parameter and then it will be executed remotely when building from Windows. This is done in a Windows.After.targets file so it won't affect builds on macOS. * Added ILMerge to Xamarin.iOS.Tasks.Windows Also modified ILMerge.targets to not include System assemblies because we don't need them on the Windows package * Bumps Messaging This new version of messaging fixes a problem when copying task inputs from Windows to the Mac * [dotnet] Fixes copying files to the Mac when building from Windows When building from Windows there are .NET SDK targets that copy dynamic libraries from the SDK to the intermediate output directory or other files to the publish directory, since we can't control those we can't run them remotely so we need to copy those files to the Mac to ensure other targets will find those. * [dotnet] Fixes how files are copied to the output dir - Before executing `_CopyResolvedFilesToPublishPreserveNewest` and `_CopyResolvedFilesToPublishAlways` we copy the input files for those targets to the Mac - Then we override the original targets to execute the same copy task as the original ones but on the Mac, so the output files are placed in the right location for the following targets to pick them up. * Fixes typo on Xamarin.iOS.Common.After.targets * Bumps Xamarin.Messaging * [msbuild] Fixes VerifyXcodeVersion and ResolveUTIs tasks Both tasks were not being able to connect to the Mac mostly because of ILRepack, there were kind of 2 versions of Xamarin.Messaging, one merged into Xamarin.iOS.Tasks and another one merged into Xamarin.iOS.Windows.Tasks. Because of this the build connection object registered on the task could not be casted to the build connection type. This essentially moves both tasks into the Xamarin.iOS.Tasks assembly to avoid this issue, and as part of that also includes the Messaging contracts into that same project. * [msbuild] Fixes warnings when building from Windows * [dotnet] Adds missing assemblies to merge into Xamarin.iOS.Tasks Those 2 new assemblies will only be used from Windows and we need their implementation instead of the ref assemblies. In the future we will need to find a way of doing this on the Windows only pack insted of doing it on the core Xamarin.iOS.Tasks assembly. * [dotnet] Compute PublishTrimmed on a target We need to do this so the property is evaluated after VS on Windows connects to the Mac, otherwise by default IsMacEnabled is false from Windows. * Bumps Messaging to 1.2.111 * [dotnet] Execute ILLink remotely when building from Windows - Overrides the ILLink task and _RunILLink target to add the hability to execute it remotely, adding input and output properties so files are copied to the server and output files are created on Windows. - This "custom" ILLink task will only be executed from the Windows targets so when building from a Mac it will execute the core SDK task. * [dotnet] Fixes intput/output files creation for linker tasks - Custom Linker options file should be created on the Mac so we need to execute WriteLinesToFile remotely - All the *.items files from the linker are created on the Mac so we need to execute ReadItemsFromFile remotely - CompileNativeCode: fixes the OutputFile metadata path, otherwise the execution fails; also copies all the files in the declared "IncludeDirectories" to the Mac - Avoids copying input files from Windows to the Mac when running LinkNativeCode since the real input files already exist on the Mac, and Windows contains only empty files just to make MSBuild inputs/outputs check work. If we copy those empty files to the Mac we brake the build. * [msbuild] Minor fixes after merging from main * [dotnet] Adds missing output files to the Xamarin.iOS.Tasks.Windows project The output of this project was missing Messaging build targets and the build agent zip file that are needed to create the dotnet Windows specific pack * [dotnet] Fixes dotnet Windows specific pack generation Ensures the Windows projects are built and the files are copied to the dotnet pack directory before creating the package. It also adds a variable to enable building this pack. * [dotnet] Adds iOS Windows specific pack to iOS only MSI There's only a Windows specific pack for iOS available for now, so we should only add it to the iOS SDK MSI * [dotnet] Create a separate bundle for the iOS Windows MSI We need to do this to avoid including the Windows specific pack in the pkg. Also for now we'll only create an MSI for iOS since it's the only supported platform from Windows. * Fixes spacing issues in Xamarin.iOS.Tasks.csproj * Bumps Touch.Unit back to 05db76 * Fixes formatting problems * [msbuild] Replaces error E0176 by E0186 Because there's a warning W0176 that will overlap with the error * [msbuild] Fixes CompileEntitlements task There were 2 problems: 1- The if statement on the DefaultEntitlementsPath was wrong, because we should return the base value if there's no SessionId (which means the task is running on a Mac) 2- We should copy to the Mac the default entitlements file if no custom file was specified * Several fixes to cleanup the code to support iOS from Windows * Apply suggestions from code review Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com> * Formatting fixes in Xamarin.Messaging.Build * Reverted formatting changes in CompileEntitlements.cs * More formatting fixes * Update msbuild/Messaging/Xamarin.Messaging.Build/Handlers/ExecuteTaskMessageHandler.cs Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com> * Fixes order of MSBuild errors in the resource file * Add newly added localizable strings to canary test of translated strings. * Delete tests that ensure theres code only on the abstract tasks These were needed to ensure all the code was in the base tasks so we could have tasks implementations on Windows to remote those. Now that code is part of this repo (and that is why these tests are failing now) so we do not need them anymore. * [dotnet] Don't build the Windows SDK pack if not configured to do so. Co-authored-by: mag <mauro.agnoletti@gmail.com> Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
2021-02-12 09:43:17 +03:00
endef
$(foreach platform,$(DOTNET_WINDOWS_PLATFORMS),$(eval $(call CreateWindowsBundle,$(platform),$($(platform)_NUGET_VERSION_NO_METADATA),$(shell echo $(platform) | tr A-Z a-z),$(shell echo $(platform) | tr a-z A-Z))))
[dotnet] Package the workloads in a Windows installer (.msi) as well. (#9979)
2020-10-28 13:09:55 +03:00
define CreateMsi
[dotnet] Initial support for .NET6 from Windows (#10590) These changes add support for executing iOS and MacDev tasks remotely (on a Mac) when running a build from Windows, and creates a specific .NET6 pack for Windows that's only included in the MSI. For now this only enables builds for the iOS Simulator, physical devices are not yet supported. - Each task decides if it should run locally or remotely depending on the SessionId property, which will only have a value on Windows. - The XMA Build agent is now part of this repo and will be included in the iOS .NET6 Windows pack. - On this first version we're including some Windows specific tasks and references into the Xamarin.iOS.Tasks project for simplicity, but those will be moved to the Windows specific project. ------------ * [msbuild] Adds support for executing Xamarin.iOS tasks from Windows * [msbuild] Adds support for executing Xamarin.MacDev tasks from Windows * Added XMA Build Agent to Xamarin.MacDev.Tasks.sln * Fixes some MSBuild versioning problems * Makes the XMA Build agent load Xamarin.iOS tasks We need to load a type from the iOS tasks assembly so we can run the tasks requested by MSBuild from Windows. We only need to load Xamarin.iOS.Tasks.dll since MacDev.tasks is already embedded in that one. There's a little trick on the csproj, we can't directly use the Xamarin.iOS.Tasks project ref assemblies because that includes both Xamarin.iOS.Tasks.dll and Xamarin.MacDev.Tasks.dll, so the MacDev tasks will collide. We use the project ref only for build dependency purposes but we add an assembly reference to Xamarin.iOS.Tasks.dll. * Added Xamarin.iOS.Tasks.Windows project * Removed unnecessary references on Xamarin.iOS.Tasks.Windows.csproj * Adds Messaging assemblies when ILRepacking Xamarin Tasks The Xamarin Task assemblies now depend on Messaging, so we need the Messaging assemblies to be packed into Xamarin.Mac.Tasks and Xamarin.iOS.Tasks. Also had to remove the direct Messaging dependencies from the build agent since those are already contained in Xamarin.iOS.Tasks * Adds a reference to Messaging.Core targets to the Agent's project * [msbuild] Adds Xamarin iOS Windows targets * [msbuild] Adds missing dependencies to Xamarin.iOS.Tasks This should fix build errors because of missing dependencies. Had to move System.Net.Mqtt.Server from the Build agent project to the tasks one to avoid conflicts with System.Diagnostics.Tracer. * [dotnet] Creates iOS Windows pack Creates a new pack for Windows specific (targets, build agent, etc.) files that shouldn't be installed on the Mac. We have a separate package for this to avoid increasing the core pack size with things that are not needed when using it from macOS. * Fixes type in dotnet makefile * [dotnet] Fixes the iOS Windows pack generation - The windows pack should not include the Sdk and Targets folders - For now we'll just create an iOS pack - Fixes the path to the files to include on the Windows Sdk pack * Added reference to the Windows iOS SDK from the Xamarin.iOS.Common.targets Added a property to navigate to the Windows iOS SDK folder, based on a naming convention that assumes that both packs will always have the same version * Added reference to the core iOS SDK from the Windows iOS SDK Added a property to navigate to the core iOS SDK folder, based on a naming convention that assumes that both packs will always have the same version * Updated Messaging version * Override MessagingBuildClientAssemblyFile property and correctly imported props from targets * [dotnet] Make Windows pack using target files from the output dir We need to take the target files from the output dir to include targets that are part of nuget packages, otherwise we will only include targets from our source * [dotnet] Adds the Windows Sdk pack to the workload manifest * [msbuild] Fixes the Windows Sdk pack name * [dotnet] Merge Mqtt instead of Mqtt.Server We only need System.Net.Mqtt to be merged into Xamarin.iOS.Tasks * Updated Messaging version * [dotnet] Several fixes for the Windows Sdk - Adds missing task CollectMonotouchReferences - Merges more dependencies into Xamarin.iOS.Tasks.dll needed by XMA - Updates the msbuild/Makefile to include files from both the output dir and the source dir - Overrides the agents directory to look for them on the Windows pack * [dotnet] Fixes the XMA Build agent - The build agent is an app so it cannot target ns2.0 - The MSBuild dependencies should be copied into the agent zip file - Avoids copying all the Xamarin iOS SDK core targets into the build agent, since those are not needed - Ensures the broker zip file is copied into the Xamarin.iOS.Windows.Tasks output dir so its included in the Windows pack * Bumps Xamarin.Messaging to 1.2.102 * Adds net6-win branch to trigger builds * Adds Messaging.Client missing dependency to Xamarin.Mac.Tasks * Added Xamarin.Messaging.Apple.Tasks project and VerifyXcodeVersion Task * Fix unloaded Xamarin.Messaging.Build project * Added Build contracts project and unified Xamarin.Messaigng.Apple.Tasks in Xamarin.iOS.Tasks.Windows Also added missing tasks and changes .After.targets * Updated Xamarin.Messaging version * Build agent - reference MSBuild assemblies from the framework Since the assemblies will be included in the build agent we need those to be the ones that come from the framework to be compatible with macOS * [msbuild] Fixes _UpdateDynamicLibraryId target The tasks con this target need to be executed remotely (when building from Windows). * Updates resources * Bump Xamarin.Messaging Fixes problems when executing Exec task remotely * [dotnet] Overrides Publish targets to execute them remotely from Windows The `_CopyResolvedFilesToPublishPreserveNewest` and `_CopyResolvedFilesToPublishAlways` targets essentially copy files into the app bundle. Since those are part of the .NET SDK we need to override those so we can pass to the Copy task the SessionId parameter and then it will be executed remotely when building from Windows. This is done in a Windows.After.targets file so it won't affect builds on macOS. * Added ILMerge to Xamarin.iOS.Tasks.Windows Also modified ILMerge.targets to not include System assemblies because we don't need them on the Windows package * Bumps Messaging This new version of messaging fixes a problem when copying task inputs from Windows to the Mac * [dotnet] Fixes copying files to the Mac when building from Windows When building from Windows there are .NET SDK targets that copy dynamic libraries from the SDK to the intermediate output directory or other files to the publish directory, since we can't control those we can't run them remotely so we need to copy those files to the Mac to ensure other targets will find those. * [dotnet] Fixes how files are copied to the output dir - Before executing `_CopyResolvedFilesToPublishPreserveNewest` and `_CopyResolvedFilesToPublishAlways` we copy the input files for those targets to the Mac - Then we override the original targets to execute the same copy task as the original ones but on the Mac, so the output files are placed in the right location for the following targets to pick them up. * Fixes typo on Xamarin.iOS.Common.After.targets * Bumps Xamarin.Messaging * [msbuild] Fixes VerifyXcodeVersion and ResolveUTIs tasks Both tasks were not being able to connect to the Mac mostly because of ILRepack, there were kind of 2 versions of Xamarin.Messaging, one merged into Xamarin.iOS.Tasks and another one merged into Xamarin.iOS.Windows.Tasks. Because of this the build connection object registered on the task could not be casted to the build connection type. This essentially moves both tasks into the Xamarin.iOS.Tasks assembly to avoid this issue, and as part of that also includes the Messaging contracts into that same project. * [msbuild] Fixes warnings when building from Windows * [dotnet] Adds missing assemblies to merge into Xamarin.iOS.Tasks Those 2 new assemblies will only be used from Windows and we need their implementation instead of the ref assemblies. In the future we will need to find a way of doing this on the Windows only pack insted of doing it on the core Xamarin.iOS.Tasks assembly. * [dotnet] Compute PublishTrimmed on a target We need to do this so the property is evaluated after VS on Windows connects to the Mac, otherwise by default IsMacEnabled is false from Windows. * Bumps Messaging to 1.2.111 * [dotnet] Execute ILLink remotely when building from Windows - Overrides the ILLink task and _RunILLink target to add the hability to execute it remotely, adding input and output properties so files are copied to the server and output files are created on Windows. - This "custom" ILLink task will only be executed from the Windows targets so when building from a Mac it will execute the core SDK task. * [dotnet] Fixes intput/output files creation for linker tasks - Custom Linker options file should be created on the Mac so we need to execute WriteLinesToFile remotely - All the *.items files from the linker are created on the Mac so we need to execute ReadItemsFromFile remotely - CompileNativeCode: fixes the OutputFile metadata path, otherwise the execution fails; also copies all the files in the declared "IncludeDirectories" to the Mac - Avoids copying input files from Windows to the Mac when running LinkNativeCode since the real input files already exist on the Mac, and Windows contains only empty files just to make MSBuild inputs/outputs check work. If we copy those empty files to the Mac we brake the build. * [msbuild] Minor fixes after merging from main * [dotnet] Adds missing output files to the Xamarin.iOS.Tasks.Windows project The output of this project was missing Messaging build targets and the build agent zip file that are needed to create the dotnet Windows specific pack * [dotnet] Fixes dotnet Windows specific pack generation Ensures the Windows projects are built and the files are copied to the dotnet pack directory before creating the package. It also adds a variable to enable building this pack. * [dotnet] Adds iOS Windows specific pack to iOS only MSI There's only a Windows specific pack for iOS available for now, so we should only add it to the iOS SDK MSI * [dotnet] Create a separate bundle for the iOS Windows MSI We need to do this to avoid including the Windows specific pack in the pkg. Also for now we'll only create an MSI for iOS since it's the only supported platform from Windows. * Fixes spacing issues in Xamarin.iOS.Tasks.csproj * Bumps Touch.Unit back to 05db76 * Fixes formatting problems * [msbuild] Replaces error E0176 by E0186 Because there's a warning W0176 that will overlap with the error * [msbuild] Fixes CompileEntitlements task There were 2 problems: 1- The if statement on the DefaultEntitlementsPath was wrong, because we should return the base value if there's no SessionId (which means the task is running on a Mac) 2- We should copy to the Mac the default entitlements file if no custom file was specified * Several fixes to cleanup the code to support iOS from Windows * Apply suggestions from code review Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com> * Formatting fixes in Xamarin.Messaging.Build * Reverted formatting changes in CompileEntitlements.cs * More formatting fixes * Update msbuild/Messaging/Xamarin.Messaging.Build/Handlers/ExecuteTaskMessageHandler.cs Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com> * Fixes order of MSBuild errors in the resource file * Add newly added localizable strings to canary test of translated strings. * Delete tests that ensure theres code only on the abstract tasks These were needed to ensure all the code was in the base tasks so we could have tasks implementations on Windows to remote those. Now that code is part of this repo (and that is why these tests are failing now) so we do not need them anymore. * [dotnet] Don't build the Windows SDK pack if not configured to do so. Co-authored-by: mag <mauro.agnoletti@gmail.com> Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
2021-02-12 09:43:17 +03:00
$(TMP_PKG_DIR)/Microsoft.NET.Workload.$1.$2.wsx: ./generate-wix.csharp Makefile $(TMP_PKG_DIR)/Microsoft.$1.Windows.Bundle.$2.zip
$$(Q_GEN) ./generate-wix.csharp "$1" "$$@" "$(TMP_PKG_DIR)/Microsoft.$1.Windows.Bundle.$2.zip.tmpdir/dotnet" "$2"
[dotnet] Package the workloads in a Windows installer (.msi) as well. (#9979)
2020-10-28 13:09:55 +03:00
$(TMP_PKG_DIR)/Microsoft.NET.Workload.$1.$2.msi: $(TMP_PKG_DIR)/Microsoft.NET.Workload.$1.$2.wsx .stamp-check-wixl
$$(Q_GEN) wixl -o "$$@" "$$<" -a x64
MSI_TARGETS += $(DOTNET_PKG_DIR)/Microsoft.NET.Workload.$1.$2.msi
endef
[dotnet] Initial support for .NET6 from Windows (#10590) These changes add support for executing iOS and MacDev tasks remotely (on a Mac) when running a build from Windows, and creates a specific .NET6 pack for Windows that's only included in the MSI. For now this only enables builds for the iOS Simulator, physical devices are not yet supported. - Each task decides if it should run locally or remotely depending on the SessionId property, which will only have a value on Windows. - The XMA Build agent is now part of this repo and will be included in the iOS .NET6 Windows pack. - On this first version we're including some Windows specific tasks and references into the Xamarin.iOS.Tasks project for simplicity, but those will be moved to the Windows specific project. ------------ * [msbuild] Adds support for executing Xamarin.iOS tasks from Windows * [msbuild] Adds support for executing Xamarin.MacDev tasks from Windows * Added XMA Build Agent to Xamarin.MacDev.Tasks.sln * Fixes some MSBuild versioning problems * Makes the XMA Build agent load Xamarin.iOS tasks We need to load a type from the iOS tasks assembly so we can run the tasks requested by MSBuild from Windows. We only need to load Xamarin.iOS.Tasks.dll since MacDev.tasks is already embedded in that one. There's a little trick on the csproj, we can't directly use the Xamarin.iOS.Tasks project ref assemblies because that includes both Xamarin.iOS.Tasks.dll and Xamarin.MacDev.Tasks.dll, so the MacDev tasks will collide. We use the project ref only for build dependency purposes but we add an assembly reference to Xamarin.iOS.Tasks.dll. * Added Xamarin.iOS.Tasks.Windows project * Removed unnecessary references on Xamarin.iOS.Tasks.Windows.csproj * Adds Messaging assemblies when ILRepacking Xamarin Tasks The Xamarin Task assemblies now depend on Messaging, so we need the Messaging assemblies to be packed into Xamarin.Mac.Tasks and Xamarin.iOS.Tasks. Also had to remove the direct Messaging dependencies from the build agent since those are already contained in Xamarin.iOS.Tasks * Adds a reference to Messaging.Core targets to the Agent's project * [msbuild] Adds Xamarin iOS Windows targets * [msbuild] Adds missing dependencies to Xamarin.iOS.Tasks This should fix build errors because of missing dependencies. Had to move System.Net.Mqtt.Server from the Build agent project to the tasks one to avoid conflicts with System.Diagnostics.Tracer. * [dotnet] Creates iOS Windows pack Creates a new pack for Windows specific (targets, build agent, etc.) files that shouldn't be installed on the Mac. We have a separate package for this to avoid increasing the core pack size with things that are not needed when using it from macOS. * Fixes type in dotnet makefile * [dotnet] Fixes the iOS Windows pack generation - The windows pack should not include the Sdk and Targets folders - For now we'll just create an iOS pack - Fixes the path to the files to include on the Windows Sdk pack * Added reference to the Windows iOS SDK from the Xamarin.iOS.Common.targets Added a property to navigate to the Windows iOS SDK folder, based on a naming convention that assumes that both packs will always have the same version * Added reference to the core iOS SDK from the Windows iOS SDK Added a property to navigate to the core iOS SDK folder, based on a naming convention that assumes that both packs will always have the same version * Updated Messaging version * Override MessagingBuildClientAssemblyFile property and correctly imported props from targets * [dotnet] Make Windows pack using target files from the output dir We need to take the target files from the output dir to include targets that are part of nuget packages, otherwise we will only include targets from our source * [dotnet] Adds the Windows Sdk pack to the workload manifest * [msbuild] Fixes the Windows Sdk pack name * [dotnet] Merge Mqtt instead of Mqtt.Server We only need System.Net.Mqtt to be merged into Xamarin.iOS.Tasks * Updated Messaging version * [dotnet] Several fixes for the Windows Sdk - Adds missing task CollectMonotouchReferences - Merges more dependencies into Xamarin.iOS.Tasks.dll needed by XMA - Updates the msbuild/Makefile to include files from both the output dir and the source dir - Overrides the agents directory to look for them on the Windows pack * [dotnet] Fixes the XMA Build agent - The build agent is an app so it cannot target ns2.0 - The MSBuild dependencies should be copied into the agent zip file - Avoids copying all the Xamarin iOS SDK core targets into the build agent, since those are not needed - Ensures the broker zip file is copied into the Xamarin.iOS.Windows.Tasks output dir so its included in the Windows pack * Bumps Xamarin.Messaging to 1.2.102 * Adds net6-win branch to trigger builds * Adds Messaging.Client missing dependency to Xamarin.Mac.Tasks * Added Xamarin.Messaging.Apple.Tasks project and VerifyXcodeVersion Task * Fix unloaded Xamarin.Messaging.Build project * Added Build contracts project and unified Xamarin.Messaigng.Apple.Tasks in Xamarin.iOS.Tasks.Windows Also added missing tasks and changes .After.targets * Updated Xamarin.Messaging version * Build agent - reference MSBuild assemblies from the framework Since the assemblies will be included in the build agent we need those to be the ones that come from the framework to be compatible with macOS * [msbuild] Fixes _UpdateDynamicLibraryId target The tasks con this target need to be executed remotely (when building from Windows). * Updates resources * Bump Xamarin.Messaging Fixes problems when executing Exec task remotely * [dotnet] Overrides Publish targets to execute them remotely from Windows The `_CopyResolvedFilesToPublishPreserveNewest` and `_CopyResolvedFilesToPublishAlways` targets essentially copy files into the app bundle. Since those are part of the .NET SDK we need to override those so we can pass to the Copy task the SessionId parameter and then it will be executed remotely when building from Windows. This is done in a Windows.After.targets file so it won't affect builds on macOS. * Added ILMerge to Xamarin.iOS.Tasks.Windows Also modified ILMerge.targets to not include System assemblies because we don't need them on the Windows package * Bumps Messaging This new version of messaging fixes a problem when copying task inputs from Windows to the Mac * [dotnet] Fixes copying files to the Mac when building from Windows When building from Windows there are .NET SDK targets that copy dynamic libraries from the SDK to the intermediate output directory or other files to the publish directory, since we can't control those we can't run them remotely so we need to copy those files to the Mac to ensure other targets will find those. * [dotnet] Fixes how files are copied to the output dir - Before executing `_CopyResolvedFilesToPublishPreserveNewest` and `_CopyResolvedFilesToPublishAlways` we copy the input files for those targets to the Mac - Then we override the original targets to execute the same copy task as the original ones but on the Mac, so the output files are placed in the right location for the following targets to pick them up. * Fixes typo on Xamarin.iOS.Common.After.targets * Bumps Xamarin.Messaging * [msbuild] Fixes VerifyXcodeVersion and ResolveUTIs tasks Both tasks were not being able to connect to the Mac mostly because of ILRepack, there were kind of 2 versions of Xamarin.Messaging, one merged into Xamarin.iOS.Tasks and another one merged into Xamarin.iOS.Windows.Tasks. Because of this the build connection object registered on the task could not be casted to the build connection type. This essentially moves both tasks into the Xamarin.iOS.Tasks assembly to avoid this issue, and as part of that also includes the Messaging contracts into that same project. * [msbuild] Fixes warnings when building from Windows * [dotnet] Adds missing assemblies to merge into Xamarin.iOS.Tasks Those 2 new assemblies will only be used from Windows and we need their implementation instead of the ref assemblies. In the future we will need to find a way of doing this on the Windows only pack insted of doing it on the core Xamarin.iOS.Tasks assembly. * [dotnet] Compute PublishTrimmed on a target We need to do this so the property is evaluated after VS on Windows connects to the Mac, otherwise by default IsMacEnabled is false from Windows. * Bumps Messaging to 1.2.111 * [dotnet] Execute ILLink remotely when building from Windows - Overrides the ILLink task and _RunILLink target to add the hability to execute it remotely, adding input and output properties so files are copied to the server and output files are created on Windows. - This "custom" ILLink task will only be executed from the Windows targets so when building from a Mac it will execute the core SDK task. * [dotnet] Fixes intput/output files creation for linker tasks - Custom Linker options file should be created on the Mac so we need to execute WriteLinesToFile remotely - All the *.items files from the linker are created on the Mac so we need to execute ReadItemsFromFile remotely - CompileNativeCode: fixes the OutputFile metadata path, otherwise the execution fails; also copies all the files in the declared "IncludeDirectories" to the Mac - Avoids copying input files from Windows to the Mac when running LinkNativeCode since the real input files already exist on the Mac, and Windows contains only empty files just to make MSBuild inputs/outputs check work. If we copy those empty files to the Mac we brake the build. * [msbuild] Minor fixes after merging from main * [dotnet] Adds missing output files to the Xamarin.iOS.Tasks.Windows project The output of this project was missing Messaging build targets and the build agent zip file that are needed to create the dotnet Windows specific pack * [dotnet] Fixes dotnet Windows specific pack generation Ensures the Windows projects are built and the files are copied to the dotnet pack directory before creating the package. It also adds a variable to enable building this pack. * [dotnet] Adds iOS Windows specific pack to iOS only MSI There's only a Windows specific pack for iOS available for now, so we should only add it to the iOS SDK MSI * [dotnet] Create a separate bundle for the iOS Windows MSI We need to do this to avoid including the Windows specific pack in the pkg. Also for now we'll only create an MSI for iOS since it's the only supported platform from Windows. * Fixes spacing issues in Xamarin.iOS.Tasks.csproj * Bumps Touch.Unit back to 05db76 * Fixes formatting problems * [msbuild] Replaces error E0176 by E0186 Because there's a warning W0176 that will overlap with the error * [msbuild] Fixes CompileEntitlements task There were 2 problems: 1- The if statement on the DefaultEntitlementsPath was wrong, because we should return the base value if there's no SessionId (which means the task is running on a Mac) 2- We should copy to the Mac the default entitlements file if no custom file was specified * Several fixes to cleanup the code to support iOS from Windows * Apply suggestions from code review Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com> * Formatting fixes in Xamarin.Messaging.Build * Reverted formatting changes in CompileEntitlements.cs * More formatting fixes * Update msbuild/Messaging/Xamarin.Messaging.Build/Handlers/ExecuteTaskMessageHandler.cs Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com> * Fixes order of MSBuild errors in the resource file * Add newly added localizable strings to canary test of translated strings. * Delete tests that ensure theres code only on the abstract tasks These were needed to ensure all the code was in the base tasks so we could have tasks implementations on Windows to remote those. Now that code is part of this repo (and that is why these tests are failing now) so we do not need them anymore. * [dotnet] Don't build the Windows SDK pack if not configured to do so. Co-authored-by: mag <mauro.agnoletti@gmail.com> Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
2021-02-12 09:43:17 +03:00
$(foreach platform,$(DOTNET_WINDOWS_PLATFORMS),$(eval $(call CreateMsi,$(platform),$($(platform)_NUGET_VERSION_NO_METADATA))))
[dotnet] Package the workloads in a Windows installer (.msi) as well. (#9979)
2020-10-28 13:09:55 +03:00
[main] Update dependencies from dotnet/installer (#13093) * Update dependencies from https://github.com/dotnet/installer build 20211022.1 Microsoft.Dotnet.Sdk.Internal From Version 6.0.100-rtm.21521.3 -> To Version 6.0.100-rtm.21522.1 * Update dependencies from https://github.com/dotnet/installer build 20211022.16 Microsoft.Dotnet.Sdk.Internal From Version 6.0.100-rtm.21521.3 -> To Version 6.0.100-rtm.21522.16 * Update dependencies from https://github.com/dotnet/installer build 20211023.8 Microsoft.Dotnet.Sdk.Internal From Version 6.0.100-rtm.21521.3 -> To Version 6.0.100-rtm.21523.8 * Update dependencies from https://github.com/dotnet/installer build 20211024.1 Microsoft.Dotnet.Sdk.Internal From Version 6.0.100-rtm.21521.3 -> To Version 6.0.100-rtm.21524.1 * Add a dependency to Microsoft.NETCore.App.Ref. That way we match what XA did here: https://github.com/xamarin/xamarin-android/commit/16c1226dde50d95107a040fcc49fe0aab8471fd6 It also makes Maestro update our NuGet.config for us, which additional feeds we seem to need to build. * [dotnet] Use all the sources in the NuGet.config when installing workloads. * Update dependencies from https://github.com/dotnet/installer build 20211025.3 Microsoft.Dotnet.Sdk.Internal From Version 6.0.100-rtm.21521.3 -> To Version 6.0.100-rtm.21525.3 * Add dependency on Microsoft.AspNetCore.App.Ref. * Update dependencies from https://github.com/dotnet/installer build 20211026.10 Microsoft.Dotnet.Sdk.Internal From Version 6.0.100-rtm.21521.3 -> To Version 6.0.100-rtm.21526.10 * [tests] Disable the implicit FSharp.Core reference. Fixes this: xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: Unable to find a stable package FSharp.Core with version (>= 6.0.1) xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 792 version(s) in dotnet-tools [ Nearest version: 6.0.2-beta.21519.1 ] xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 46 version(s) in dotnet-public [ Nearest version: 6.0.0 ] xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 0 version(s) in xamarin-impl xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 0 version(s) in darc-pub-dotnet-aspnetcore-ae1a6cb-1 xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 0 version(s) in darc-pub-dotnet-aspnetcore-ae1a6cb xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 0 version(s) in darc-pub-dotnet-runtime-4822e3c-1 xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 0 version(s) in darc-pub-dotnet-runtime-4822e3c-2 xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 0 version(s) in darc-pub-dotnet-runtime-4822e3c-4 xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 0 version(s) in darc-pub-dotnet-runtime-4822e3c-5 xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 0 version(s) in Dotnet arcade xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 0 version(s) in dotnet6 xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 0 version(s) in macios-dependencies * [tests] Use a specific FSharp.Core version. * Update dependencies from https://github.com/dotnet/installer build 20211027.11 Microsoft.Dotnet.Sdk.Internal From Version 6.0.100-rtm.21521.3 -> To Version 6.0.100-rtm.21527.11 Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com> Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
2021-10-29 19:46:00 +03:00
NUGET_SOURCES:=$(shell grep https://pkgs.dev.azure.com $(TOP)/NuGet.config | sed -e 's/.*value="//' -e 's/".*//')
[dotnet] use **FromWorkload** for targeting/runtime pack versions (#12449) Context: https://github.com/dotnet/sdk/pull/19596 Context: https://github.com/xamarin/xamarin-android/pull/6184 If we use the version number string of `**FromWorkload**`, then our runtime packages don't need to be resolved from a NuGet feed. They can be resolved from the `dotnet/packs` directory. This completely eliminates the need for a `NuGet.config` file when building a .NET 6 app with a local build of xamarin-macios. You will no longer need a feed such as: <add key="local-dotnet-feed" value="~/src/xamarin-macios/_build/nuget-feed" /> To further clean things up, I removed the need for: * Any NuGet feed named `local-dotnet-feed` * `$(DOTNET_FEED_DIR)` * Generation of `dotnet/Workloads/NuGet.config`
2021-08-19 10:03:11 +03:00
.stamp-install-workloads: Makefile $(WORKLOAD_TARGETS) $(RUNTIME_PACKS) $(REF_PACKS) $(SDK_PACKS) $(TEMPLATE_PACKS) $(WORKLOAD_PACKS)
[dotnet] Rename the DOTNET6 make variable to DOTNET. (#14441) This is the follow-up to where the DOTNET variable was renamed SYSTEM_DOTNET.
2022-03-21 17:56:57 +03:00
$(Q) $(DOTNET) workload install --skip-manifest-update \
[main] Update dependencies from dotnet/installer (#13093) * Update dependencies from https://github.com/dotnet/installer build 20211022.1 Microsoft.Dotnet.Sdk.Internal From Version 6.0.100-rtm.21521.3 -> To Version 6.0.100-rtm.21522.1 * Update dependencies from https://github.com/dotnet/installer build 20211022.16 Microsoft.Dotnet.Sdk.Internal From Version 6.0.100-rtm.21521.3 -> To Version 6.0.100-rtm.21522.16 * Update dependencies from https://github.com/dotnet/installer build 20211023.8 Microsoft.Dotnet.Sdk.Internal From Version 6.0.100-rtm.21521.3 -> To Version 6.0.100-rtm.21523.8 * Update dependencies from https://github.com/dotnet/installer build 20211024.1 Microsoft.Dotnet.Sdk.Internal From Version 6.0.100-rtm.21521.3 -> To Version 6.0.100-rtm.21524.1 * Add a dependency to Microsoft.NETCore.App.Ref. That way we match what XA did here: https://github.com/xamarin/xamarin-android/commit/16c1226dde50d95107a040fcc49fe0aab8471fd6 It also makes Maestro update our NuGet.config for us, which additional feeds we seem to need to build. * [dotnet] Use all the sources in the NuGet.config when installing workloads. * Update dependencies from https://github.com/dotnet/installer build 20211025.3 Microsoft.Dotnet.Sdk.Internal From Version 6.0.100-rtm.21521.3 -> To Version 6.0.100-rtm.21525.3 * Add dependency on Microsoft.AspNetCore.App.Ref. * Update dependencies from https://github.com/dotnet/installer build 20211026.10 Microsoft.Dotnet.Sdk.Internal From Version 6.0.100-rtm.21521.3 -> To Version 6.0.100-rtm.21526.10 * [tests] Disable the implicit FSharp.Core reference. Fixes this: xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: Unable to find a stable package FSharp.Core with version (>= 6.0.1) xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 792 version(s) in dotnet-tools [ Nearest version: 6.0.2-beta.21519.1 ] xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 46 version(s) in dotnet-public [ Nearest version: 6.0.0 ] xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 0 version(s) in xamarin-impl xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 0 version(s) in darc-pub-dotnet-aspnetcore-ae1a6cb-1 xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 0 version(s) in darc-pub-dotnet-aspnetcore-ae1a6cb xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 0 version(s) in darc-pub-dotnet-runtime-4822e3c-1 xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 0 version(s) in darc-pub-dotnet-runtime-4822e3c-2 xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 0 version(s) in darc-pub-dotnet-runtime-4822e3c-4 xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 0 version(s) in darc-pub-dotnet-runtime-4822e3c-5 xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 0 version(s) in Dotnet arcade xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 0 version(s) in dotnet6 xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 0 version(s) in macios-dependencies * [tests] Use a specific FSharp.Core version. * Update dependencies from https://github.com/dotnet/installer build 20211027.11 Microsoft.Dotnet.Sdk.Internal From Version 6.0.100-rtm.21521.3 -> To Version 6.0.100-rtm.21527.11 Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com> Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
2021-10-29 19:46:00 +03:00
$(foreach source,$(NUGET_SOURCES),--source $(source)) \
[dotnet] use **FromWorkload** for targeting/runtime pack versions (#12449) Context: https://github.com/dotnet/sdk/pull/19596 Context: https://github.com/xamarin/xamarin-android/pull/6184 If we use the version number string of `**FromWorkload**`, then our runtime packages don't need to be resolved from a NuGet feed. They can be resolved from the `dotnet/packs` directory. This completely eliminates the need for a `NuGet.config` file when building a .NET 6 app with a local build of xamarin-macios. You will no longer need a feed such as: <add key="local-dotnet-feed" value="~/src/xamarin-macios/_build/nuget-feed" /> To further clean things up, I removed the need for: * Any NuGet feed named `local-dotnet-feed` * `$(DOTNET_FEED_DIR)` * Generation of `dotnet/Workloads/NuGet.config`
2021-08-19 10:03:11 +03:00
--source $(DOTNET_NUPKG_DIR) --verbosity diag \
[dotnet] shorten workload ids (#12035) Context: https://github.com/xamarin/xamarin-android/pull/6045 We are aiming to simplify the .NET workload ids to short names like: dotnet workload install maui dotnet workload install android dotnet workload install ios dotnet workload install maccatalyst dotnet workload install macos dotnet workload install tvos Updated the workload ids here, as well as the `.stamp-install-workloads` make target. Other changes: * Updated descriptions to match Android. Still waiting on an *official* description we should be using for each workload. * Fixed trailing `,` that showed up as JSON errors in VS Code.
2021-06-29 17:49:39 +03:00
$(foreach platform,$(DOTNET_PLATFORMS),$(shell echo $(platform) | tr A-Z a-z))
Mono changed the location of the AOT compiler, so we have to update our code accordingly. (#11789) * [tests] Augment the .NET unit tests to verify that more runtime identifiers build. * [dotnet] Show a better error if the AOT compiler doesn't exist. * [dotnet] Use the official path for the AOT compiler. * [dotnet] Use platform-specific templates for WorkloadManifest.json. * [dotnet] Generate the workload targets before the nupkgs. This avoids a random build failure when doing parallel make. * [builds] Install the runtime workloads for iOS and tvOS so that we have the AOT compilers downloaded for our local tests. * [dotnet] Make the iOS and tvOS workloads load the AOT compiler packages from Mono. * [dotnet] Move the workloads into a common subdirectory. Also delete the watchOS workload, we're not shipping it for now. * [dotnet] Set DOTNETSDK_WORKLOAD_MANIFEST_ROOTS when install workloads to get our local ones. * Set DOTNETSDK_WORKLOAD_MANIFEST_ROOTS to where our local workloads are to use them when installing our locally built workloads into .NET (the local one). * Stop installing workloads from builds/ * Get NuGet.config with local feed, and make sure those feed contain local build before running 'workload install'. * Fix makefile logic. * Another tweak.
2021-06-04 09:34:32 +03:00
$(Q) touch $@
TARGETS += .stamp-install-workloads
[dotnet] Package the workloads in a Windows installer (.msi) as well. (#9979)
2020-10-28 13:09:55 +03:00
.stamp-check-wixl:
$(Q) if ! type wixl; then \
echo "Installing msitools to get wixl..."; \
if ! brew install msitools; then \
if ! type wixl; then \
echo "Failed to install wixl"; \
exit 1; \
fi; \
fi; \
echo "Installed msitools"; \
fi
$(Q) touch $@
[msbuild/dotnet] Build the Xamarin.PreBuilt.iOS app bundle. Fixes #12945. (#13342) Build the Xamarin.PreBuilt.iOS app bundle instead of using a prebuilt bundle. This makes sure that we're always using the latest BCL. Some accurate build massaging was needed, because: * To build the prebuilt app we need the iOS workload installed (into our build-local .NET installation). * The iOS workload contains the Microsoft.iOS.Windows.Sdk pack. * The Microsoft.iOS.Windows.Sdk pack contains the prebuilt app. Thus we had a circular reference. Fortunately, the Microsoft.iOS.Windows.Sdk pack is only required on Windows, which means we can break this circular reference by: * Mark Microsoft.iOS.Windows.Sdk pack as only to be installed on Windows (unfortunately it seems we have to list the exact runtime identifiers for the platforms where to install the pack, so we can't do something like "win-*", but new variations of the "win-*" runtime identifier shouldn't show up all that often). * Build the prebuilt app on macOS. This way we don't need the Microsoft.iOS.Windows.Sdk pack when installing the iOS workload locally. The .NET build order is now: * Build general sdk, runtime and ref packs for .NET. * Build the prebuilt app. * Build the Microsoft.iOS.Windows.Sdk pack. Fixes https://github.com/xamarin/xamarin-macios/issues/12945.
2021-11-12 09:38:07 +03:00
TARGETS += $(WORKLOAD_TARGETS) $(WINDOWS_PACKAGE_TARGETS)
[dotnet] Install our workloads into the dotnet directory (as symlinks).
2020-10-15 12:38:29 +03:00
[dotnet] Package the workloads in a Windows installer (.msi) as well. (#9979)
2020-10-28 13:09:55 +03:00
msi: $(MSI_TARGETS)
[msbuild/dotnet] Build the Xamarin.PreBuilt.iOS app bundle. Fixes #12945. (#13342) Build the Xamarin.PreBuilt.iOS app bundle instead of using a prebuilt bundle. This makes sure that we're always using the latest BCL. Some accurate build massaging was needed, because: * To build the prebuilt app we need the iOS workload installed (into our build-local .NET installation). * The iOS workload contains the Microsoft.iOS.Windows.Sdk pack. * The Microsoft.iOS.Windows.Sdk pack contains the prebuilt app. Thus we had a circular reference. Fortunately, the Microsoft.iOS.Windows.Sdk pack is only required on Windows, which means we can break this circular reference by: * Mark Microsoft.iOS.Windows.Sdk pack as only to be installed on Windows (unfortunately it seems we have to list the exact runtime identifiers for the platforms where to install the pack, so we can't do something like "win-*", but new variations of the "win-*" runtime identifier shouldn't show up all that often). * Build the prebuilt app on macOS. This way we don't need the Microsoft.iOS.Windows.Sdk pack when installing the iOS workload locally. The .NET build order is now: * Build general sdk, runtime and ref packs for .NET. * Build the prebuilt app. * Build the Microsoft.iOS.Windows.Sdk pack. Fixes https://github.com/xamarin/xamarin-macios/issues/12945.
2021-11-12 09:38:07 +03:00
package: $(PACKAGE_TARGETS) $(MSI_TARGETS) $(WINDOWS_PACKAGE_TARGETS)
[dotnet] Create Microsoft.<platform>.Bundle.pkg packages for installing workloads manually.
2020-10-15 12:45:36 +03:00
Only build dotnet/ if dotnet is enabled. (#8614)
2020-05-20 10:26:27 +03:00
ifdef ENABLE_DOTNET
[dotnet] Templateify some build logic. (#10618) * [dotnet-linker] Templateify the install logic. * [builds] Templateify the Versions.plist install logic. * [dotnet] Create a per-platform Versions.props file with only the values applicable to that platform. Also move the definition of the default TargetPlatformVersion to Make.versions, where we have other versions. * [dotnet] Templateify some build code.
2021-02-11 22:17:12 +03:00
all-local:: $(TARGETS)
Only build dotnet/ if dotnet is enabled. (#8614)
2020-05-20 10:26:27 +03:00
endif
Create and publish .NET NuGet packages. (#8576) Create the various NuGet packages to support .NET 5+. The packages are currently empty (and not very useful), but the actual content will come later. The current set of NuGet packages are (this list is duplicated for each platform: iOS, tvOS, watchOS and macOS): * Microsoft.iOS.Sdk: currently contains the basic MSBuild targets files for an MSBuild Project SDK. Will eventually contain all the build logic. Might also eventually contain other tools (mlaunch, bgen, etc.), but these might also end up in a different package. * Microsoft.iOS.Ref: will contain the Xamarin.iOS.dll reference assembly. * Microsoft.iOS.Runtime.[RID]: will contain architecture-specific files (libxamarin*.dylib, the Xamarin.iOS.dll implementation assembly, etc.): The NuGets built on CI are automatically published to a NuGet feed. The versioning for the NuGet packages required a few changes: OS bumps are now changed in Make.versions instead of Make.config (this is explained in the files themselves as well).
2020-05-13 16:23:29 +03:00
clean-local::
[dotnet] use **FromWorkload** for targeting/runtime pack versions (#12449) Context: https://github.com/dotnet/sdk/pull/19596 Context: https://github.com/xamarin/xamarin-android/pull/6184 If we use the version number string of `**FromWorkload**`, then our runtime packages don't need to be resolved from a NuGet feed. They can be resolved from the `dotnet/packs` directory. This completely eliminates the need for a `NuGet.config` file when building a .NET 6 app with a local build of xamarin-macios. You will no longer need a feed such as: <add key="local-dotnet-feed" value="~/src/xamarin-macios/_build/nuget-feed" /> To further clean things up, I removed the need for: * Any NuGet feed named `local-dotnet-feed` * `$(DOTNET_FEED_DIR)` * Generation of `dotnet/Workloads/NuGet.config`
2021-08-19 10:03:11 +03:00
$(Q) rm -Rf $(DOTNET_NUPKG_DIR)
Create and publish .NET NuGet packages. (#8576) Create the various NuGet packages to support .NET 5+. The packages are currently empty (and not very useful), but the actual content will come later. The current set of NuGet packages are (this list is duplicated for each platform: iOS, tvOS, watchOS and macOS): * Microsoft.iOS.Sdk: currently contains the basic MSBuild targets files for an MSBuild Project SDK. Will eventually contain all the build logic. Might also eventually contain other tools (mlaunch, bgen, etc.), but these might also end up in a different package. * Microsoft.iOS.Ref: will contain the Xamarin.iOS.dll reference assembly. * Microsoft.iOS.Runtime.[RID]: will contain architecture-specific files (libxamarin*.dylib, the Xamarin.iOS.dll implementation assembly, etc.): The NuGets built on CI are automatically published to a NuGet feed. The versioning for the NuGet packages required a few changes: OS bumps are now changed in Make.versions instead of Make.config (this is explained in the files themselves as well).
2020-05-13 16:23:29 +03:00
$(Q) git clean -xfdq
[dotnet] Try to implement a workaround for xamarin/maccore#2427. (#11897) We randomly run into a NuGet restore failure, which breaks the build, and is quite annoying. This might be due to a problem with multiple simultaneous restores, so this is an attempt to first restore the packages we need, in a single serialized restore, and once that's done we can process everything else in parallel. Ref: https://github.com/xamarin/maccore/issues/2427 Ref: https://github.com/NuGet/Home/issues/10935
2021-06-11 16:22:31 +03:00
Make our local .NET the default .NET for the build. (#15086) Make our local .NET the default .NET (in the root's global.json), and then if a directory wants to use the system .NET, then that directory would have to opt-in (using its own global.json). This way we don't have to copy global.json/NuGet.config files around to run tests with the correct .NET setup.
2022-06-07 11:11:02 +03:00
.stamp-workaround-for-maccore-issue-2427: $(TOP)/eng/Versions.props $(LOCAL_WORKLOAD_TARGETS)
[dotnet] Rename the DOTNET6 make variable to DOTNET. (#14441) This is the follow-up to where the DOTNET variable was renamed SYSTEM_DOTNET.
2022-03-21 17:56:57 +03:00
$(Q) $(DOTNET) restore package/workaround-for-maccore-issue-2427/restore.csproj /bl:package/workaround-for-maccore-issue-2427/restore.binlog $(MSBUILD_VERBOSITY)
[dotnet] Try to implement a workaround for xamarin/maccore#2427. (#11897) We randomly run into a NuGet restore failure, which breaks the build, and is quite annoying. This might be due to a problem with multiple simultaneous restores, so this is an attempt to first restore the packages we need, in a single serialized restore, and once that's done we can process everything else in parallel. Ref: https://github.com/xamarin/maccore/issues/2427 Ref: https://github.com/NuGet/Home/issues/10935
2021-06-11 16:22:31 +03:00
$(Q) touch $@
[msbuild/dotnet] Build the Xamarin.PreBuilt.iOS app bundle. Fixes #12945. (#13342) Build the Xamarin.PreBuilt.iOS app bundle instead of using a prebuilt bundle. This makes sure that we're always using the latest BCL. Some accurate build massaging was needed, because: * To build the prebuilt app we need the iOS workload installed (into our build-local .NET installation). * The iOS workload contains the Microsoft.iOS.Windows.Sdk pack. * The Microsoft.iOS.Windows.Sdk pack contains the prebuilt app. Thus we had a circular reference. Fortunately, the Microsoft.iOS.Windows.Sdk pack is only required on Windows, which means we can break this circular reference by: * Mark Microsoft.iOS.Windows.Sdk pack as only to be installed on Windows (unfortunately it seems we have to list the exact runtime identifiers for the platforms where to install the pack, so we can't do something like "win-*", but new variations of the "win-*" runtime identifier shouldn't show up all that often). * Build the prebuilt app on macOS. This way we don't need the Microsoft.iOS.Windows.Sdk pack when installing the iOS workload locally. The .NET build order is now: * Build general sdk, runtime and ref packs for .NET. * Build the prebuilt app. * Build the Microsoft.iOS.Windows.Sdk pack. Fixes https://github.com/xamarin/xamarin-macios/issues/12945.
2021-11-12 09:38:07 +03:00
$(DOTNET_DESTDIR)/Microsoft.iOS.Windows.Sdk/tools/msbuild/iOS/Xamarin.PreBuilt.iOS.app.zip: .stamp-install-workloads
$(Q) $(MAKE) -C $(TOP)/msbuild/Xamarin.HotRestart.PreBuilt all
$(Q) touch $@
[dotnet] Fix hang after packing .NET NuGets. Fixes #13355. (#15407) This has been bothering me for a while... the symptom is that the build just hangs at the end. Curiously it's never happend on the bots, only locally. 1. It only happens when using parallel make. When using parallel make, make is in a jobserver mode, where sub-makes are controlled using a pair of file descriptors inherited by the sub-makes. A consequence of this algorithm is that the controlling make process will wait until all inherited file descriptors have been closed before it will realize that all its sub-makes have finished. 2. 'dotnet pack' will build the corresponding project, and that might start a background compiler server. 3. This background compiler server does not seem to close any file descriptors it inherits. 4. The background compiler server does not necessarily exit by the time `make` is done. 5. The result is that `make` things there are still sub-makes doing stuff, because there are inherited file descriptors still open. 6. Killing the compiler server (in another terminal for instance) will make make realize it's done (and the hang is resolved). So I'm applying the last point: shutting down the compiler server after packing all the .NET NuGets. Fixes https://github.com/xamarin/xamarin-macios/issues/13355.
2022-07-08 17:50:20 +03:00
# We need to shut down the builder server, because:
# We're using parallel make, and parallel make will start a jobserver, managed by file descriptors, where these file descriptors must be closed in all subprocesses for make to realize it's done.
# 'dotnet pack' might have started a build server
# The build server does not close any file descriptors it may have inherited when daemonizing itself.
# Thus the build server (which will still be alive after we're done building here) might have a file descriptor open which make is waiting for.
# The proper fix is to fix the build server to close its file descriptors.
# The intermediate working is to shut down the build server instead. An alternative solution would be to pass /p:UseSharedCompilation=false to 'dotnet pack' to disable the usage of the build server.
#
# The 'shutdown-build-server' is executed in a sub-make (and not as a dependency to the all-hook target),
# to make sure it's executed after everything else is built in this file.
all-hook::
$(Q) $(MAKE) shutdown-build-server
shutdown-build-server:
$(Q) $(DOTNET) build-server shutdown