Граф коммитов

26 Коммитов

Автор SHA1 Сообщение Дата
Rolf Bjarne Kvinge 728347ad63
[dotnet] Remove watchOS code and from our .NET support. (#12764)
It's not tested, and thus has probably already bitrotted. If we add support
for watchOS to .NET in the future, it would likely be easier to start from
scratch (copying some of the other platforms), than having incomplete and
bitrotted code.
2021-09-20 07:40:03 +02:00
Peter Collins c272040bdb
[ci] Push .NET 6 packages to dnceng dotnet6 feed (#12492)
We should now have the ability to push to the `dotnet6` feed that
contains the rest of the .NET 6 SDK Workload packages.  This should help
simplify workload acquisition.  The .nupkg files containing .msi the
.msi installers used for VS insertions will also now be pushed to this
feed.
2021-08-20 11:33:47 +02:00
Rolf Bjarne Kvinge 7ac3417ee9
[dotnet/templates/tests] Update template code. (#12109)
* Move the templates to a common subdirectory.
* Add .NET unit test to verify that all the templates build and that they have
  no warnings.
* Modify the template code to:
   * Use the UIApplication.Main overload that takes a Type.
   * Use top-level statements for the Main method to simplify code.
   * Remove a few unnecessary usings.

Partial fix for #12085.
2021-07-14 17:58:31 +02:00
Rolf Bjarne Kvinge 5b15159fc0
[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 15:22:31 +02:00
VS MobileTools Engineering Service 2 941d2d75e8
[dotnet] Fix the path to the workloads in one more location. (#11867)
This fixes a regression where the data/WorkloadManifest.* files were missing
from the Microsoft.NET.Sdk.<platform>.Manifest-6.0.100.<version> NuGets.

Updated contents are now:

    $ unzip -l nupkgs/Microsoft.NET.Sdk.iOS.Manifest-6.0.100.*sha*.nupkg
    Archive:  nupkgs/Microsoft.NET.Sdk.iOS.Manifest-6.0.100.14.5.100-preview.5.891+sha.130c40321.nupkg
      Length      Date    Time    Name
    ---------  ---------- -----   ----
          528  06-08-2021 20:38   _rels/.rels
          845  06-08-2021 20:38   Microsoft.NET.Sdk.iOS.Manifest-6.0.100.nuspec
         6434  09-27-2016 14:08   LICENSE
          656  06-08-2021 18:36   data/WorkloadManifest.json
          645  06-02-2021 06:24   data/WorkloadManifest.targets
          594  06-08-2021 20:38   [Content_Types].xml
          664  06-08-2021 20:38   package/services/metadata/core-properties/be25c66390ef48fa911d2e7a3f184c3c.psmdcp
    ---------                     -------
        10366                     7 files

Regressed in: e4e57c703f

Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
2021-06-09 07:53:37 +02:00
Jonathan Peppers 7bf450b987
[dotnet] publishing settings for NuGet.org (#11687)
* [dotnet] publishing settings for NuGet.org

Context: https://github.com/xamarin/xamarin-android/pull/5948

Microsoft has rules for submitting signed NuGet packages with the
namespace `Microsoft.*` under the Microsoft + Xamarin organizations.

Some of these rules include:

* Package must be signed.
* Must include a license.
* `$(Authors)` should be `Microsoft`
* `$(PackageProjectUrl)` can't be blank.
* `$(Copyright)` must *exactly* say `© Microsoft Corporation. All rights reserved.`

If any of these are wrong, you'll get errors during `nuget push` such as:

    Response status code does not indicate success:
    400 (The package is not compliant with metadata requirements for Microsoft packages on NuGet.org.
    Go to https://aka.ms/Microsoft-NuGet-Compliance for more information.
    Policy violations: The package metadata is missing required ProjectUrl.

We used a script to fix up these values and resign for .NET 6 Preview
4. This was painful but got us by for the current release.

Going forward, we should just fill out these values for .NET 6 .nupkg
files.

* Forgot $(PackageLicenseFile)
2021-05-26 21:35:05 +02:00
Jonathan Peppers cb96817f07
[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 07:46:01 +02:00
Jonathan Peppers 3b890b2d4b
[dotnet] move WorkloadManifest.* files to /data/ folder (#11221)
Context: https://github.com/dotnet/designs/pull/188/files#diff-8fcaa29d8e6f00b34b3cb1830d93f33e75f04424780a66a3c658c7021048e74fR125

The future `dotnet workload install` commands will be expecting that
the `.nupkg` for a workload will contain:

* `data/WorkloadManifest.json`
* `data/WorkloadManifest.targets`

This was done so that we don't interfere with NuGet's spec for layout
of a `.nupkg` file. You are allowed to put whatever you like in a
`/data/` folder.

The layout on disk in `/usr/local/share/dotnet`, etc. is unchanged, so
we don't need any changes to our installers, etc.

Android side:

https://github.com/xamarin/xamarin-android/pull/5843
2021-04-15 17:18:40 -04:00
Peter Collins 2dc113ea28
[CI] Upload build asset data to darc/maestro (#11189) 2021-04-14 17:34:30 -04:00
Peter Collins 5c12fdfac9
[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 00:02:27 -04:00
Rolf Bjarne Kvinge c8b6bc6c85
[dotnet] Build macOS/.NET for ARM64 as well. (#10959)
Partial fix for #10959.
2021-03-25 07:26:48 +01:00
Jonathan Peppers 94fb7823f2
[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-04 16:33:42 -06:00
Jonathan Peppers 11ca5a8619
.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 09:23:05 -06:00
Rolf Bjarne Kvinge 6e8e5da301 [dotnet] Add all assemblies in the ref package to the FrameworkList.xml. 2021-02-23 07:59:14 +01:00
Emanuel Fernandez Dell'Oca d337f0deac
[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 07:43:17 +01:00
Rolf Bjarne Kvinge f4ac99efc0
[dotnet] Build & publish MacCatalyst packs. (#10624)
* [dotnet] Build & publish MacCatalyst packs.

* Add runtime support.
2021-02-12 07:38:43 +01:00
Rolf Bjarne Kvinge f127e614c9
[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 20:17:12 +01:00
Alex Soto 72c7b1ffcc
[main][watchOS] Add x86_64 simulator support (#10059)
* [watchOS] Add x86_64 simulator support

* Build runtime/registrar x86_64 slices
* Produce a 64 bit version of Xamarin.WatchOS.dll
* Allow building x86_64 for watch simulators in mtouch
* Let xharness know about x86_64

* [tests] Add x86_64 arch to test-libraries

* Make dotnet package aware of x64

* [ObjCRuntime] Fix computing if we're calling a stret function or not in a 64-bit watchOS simulator.

* [xharness] Re-enable some watchOS tests.

Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
2020-11-20 09:27:46 -05:00
Rolf Bjarne Kvinge 8f0ca7508a [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-10 11:41:30 +01:00
Rolf Bjarne Kvinge c640775699 [dotnet] Bump to .NET 6.0.100-alpha.1.20556.2. and net6.0
New commits in spouliot/Touch.Unit:

* spouliot/Touch.Unit@f8768d9 Advance into the world of net6.0

Diff: 9abe69e6f5..f8768d99ef
2020-11-10 11:41:06 +01:00
Rolf Bjarne Kvinge a249ac2c80 [dotnet] Rename Xamarin.Shared.Sdk.Versions.props to Xamarin.Shared.Sdk.Versions.targets. 2020-10-16 14:27:57 +02:00
Rolf Bjarne Kvinge f6e8259a23 [dotnet] Write FrameworkList.xml and RuntimeList.xml into our on-disk nuget representation.
This makes it so that we can create a symlink in the dotnet path directly into
our on-disk nuget representation.
2020-10-16 14:27:42 +02:00
Rolf Bjarne Kvinge 748612fbc2
[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 17:47:18 +02:00
Rolf Bjarne Kvinge 518a95b61b
[src] Put the implementation assemblies for our product assemblies in the NuGet runtime packages. (#8628)
This is the current structure:

        Microsoft.iOS.Runtime.<rid>
        └─── data
        │    └─── RuntimeList.xml
        └─── runtimes
        │    └─── <rid>
        │    │    └─── lib
        │    │    │    └─── net5.0
        │    │    │    │    └─── Xamarin.iOS.dll
        │    │    │    │    └─── Xamarin.iOS.pdb

and likewise for tvOS, watchOS and macOS.

Also fix the nuget packaging to include the reference/implementation
assemblies in FrameworkList.xml and RuntimeList.xml.
2020-05-20 18:39:18 +02:00
Rolf Bjarne Kvinge 161d46ce2f
Switch to net5.0 instead of netcoreapp5.0. (#8615)
This also requires bumping .NET to a version that supports 'net5.0'.

The actual TFM is still '.NETCoreApp,Version=5.0', it's just the short name
that has changed.
2020-05-20 09:26:41 +02:00
Rolf Bjarne Kvinge 5834572741
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 15:23:29 +02:00