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.
Silence warnings for both legacy and dotnet builds
```
build/maccatalyst/reference/Xamarin.iOS.cs(8014,68): warning CS0108: 'ABPeoplePickerNavigationController.Delegate' hides inherited member 'UINavigationController.Delegate'. Use the new keyword if hiding was intended.
build/maccatalyst/reference/Xamarin.iOS.cs(29868,37): warning CS0114: 'HKWorkoutType.Identifier' hides inherited member 'HKObjectType.Identifier'. To make the current member override that implementation, add the override keyword. Otherwise add the new keyword.
build/maccatalyst/reference/Xamarin.iOS.cs(17769,54): warning CS0108: 'CPTemplateApplicationScene.Delegate' hides inherited member 'UIScene.Delegate'. Use the new keyword if hiding was intended.
build/maccatalyst/reference/Xamarin.iOS.cs(17626,63): warning CS0108: 'CPTemplateApplicationDashboardScene.Delegate' hides inherited member 'UIScene.Delegate'. Use the new keyword if hiding was intended.
build/maccatalyst/reference/Xamarin.iOS.cs(38414,25): warning CS0108: 'MFMessageComposeViewController.Notifications' hides inherited member 'UIViewController.Notifications'. Use the new keyword if hiding was intended.
```
* Avoids one usage of xamarin_set_nsobject_flags (which pokes into managed
memory from native code, which won't be possible with CoreCLR).
* Makes it possible to move more code from native to managed for
xamarin_release_managed_ref in the future.
* Since the code order is exactly the same, it shouldn't have any other side
effects.
* Types can be `sealed`
* Types can be `static` (when both `sealed` and `abstract`)
* Events can be `static`
* Do not add `virtual` members to `sealed` types (fix `CS0549` errors)
Code shared between msbuild and mtouch/mmp needs to share the
localization strings, otherwise the exception being thrown is of no help
to solve the issue.
THis happened if a wrong path was given for an `.xcframework` and
`FileCopier` reported an `MT1022` error.
Reference (not a fix for) https://github.com/xamarin/xamarin-macios/issues/10774
Assembly.GetType works differently between CoreCLR and Mono for nested types:
Mono accepts both '/' and '+' as the character separating the declaring type
from the nested type, while CoreCLR only accepts '+'.
So just switch to '+', since that works everywhere.
The default marshalling size for characters in .NET is a single byte, and that
is potentially lossy (and causes tests to fail for non-ascii characters).
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
* [dotnet] Use the expected case for ARM64.
We use case-sensitive comparisons somewhere else, so make sure to use the same casing
for the architecture as other platforms do.
* [tests] Add tests to verify that Mac Catalyst builds successfully for ARM64.
* [msbuild] Fix platform name in condition.
* [msbuild] Pass -isysroot when building Mac Catalyst apps as well.
Ohterwise clang will use the SDK from the command line tools, which may have
nothing to do with the SDK we want to build with.
* [cecil-tests] Add test for MarshalAs attributes for bool return type / parameters in P/Invokes.
This also meant adding support for resolving additional BCL assemblies (to be able to process Action<> and Func<> types).
* [generator] Add [MarshalAs (UnmanagedType.I1)] to bool return types and parameters.
* Fix all manually bound API to use a MarshalAs attribute for boolean return types and parameters in P/Invokes.
* Add configure option to disable building for legacy Xamarin.
This can greatly speed up the debug-edit-build cycle when doing .NET
development, since it cuts down the build time in half more or less.
* Bump maccore.
New commits in xamarin/maccore:
* xamarin/maccore@548fa45432 [mlaunch] Disable building mlaunch when not including the legacy Xamarin build. (#2403)
Diff: 0562e08b12..548fa45432
This is now possible since our reference is now `d16-9` which has (very
early versions of) the Xamarin.MacCatalyst (and Xamarin.iOS stubs)
assemblies.
This will become more useful when
1. bots resume the generation of commit-by-commit API diff; and
2. a real baseline is defined for the catalyst API coverage
* Add the new links to the comment done by VSTS.
Co-authored-by: Sebastien Pouliot <sebastien.pouliot@microsoft.com>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
and not just methods even if we are generating them on both [1]
That spotted a single error inside `src/Security/SslContext.cs`
which this PR also fix. IOW there's no point in saying the API
was (a long time ago) available since our code to call it was
removed.
[1] which is something we should not need to do on .net since
* the compiler-based tooling does not need it on the getter/setter
* other tools needs to be updated (so it won't break any existing
use case)
* [runtime] Build our runtime for Mac Catalyst/ARM64 for .NET.
* [ObjCRuntime] There's no need for the StartWWAN implementation on Mac Catalyst.
This also fixes a build error:
error MT5214: Native linking failed, undefined symbol: _xamarin_start_wwan. This symbol was referenced by the managed member ObjCRuntime.Runtime.xamarin_start_wwan.
* Only exclude xamarin_start_wwan in the .NET version of Mac Catalyst.
* [tests] Update to not run the StartWWAN test on Mac Catalyst.
* Update conditional logic.
* Fix build with newer make versions.
* [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`.
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>
This makes it so that it's possible to attach to the debugger by setting the
__XAMARIN_DEBUG_HOSTS__/__XAMARIN_DEBUG_PORT__ environment variables, without
the need for enabling a setting somewhere else (like in
Settings.bundle/Root.plist on mobile devices).
- this requires small (but tricky) generator changes
- duplicate availability attributes detection is tested by introspection
- it also requires removing dupes in manual bindings (which was the
current, if not the _named_, goal for this PR)
Long story:
It's always been hard to detect and enforce removal of extraneous
availability attributes since the generator inlined them _freely_
when processing ObjC protocols.
That meant introspection could not report dupes and led to many
extra attributes. This was **not** a problem in binding files since we
could ignore them. IOW their presence (in the input) does not mean they
are _all_ dupes in generated code (output).
However dupes in manual bindings were also (forced to be) _ignored_ and
those were part of the assemblies we ship. Again it was not a big deal,
nor a source of much extra metadata/size, so it was ignored.
Forward to today, manual bindings needs to be updated for net6 [1] so any
extra we have requires more (manual) work. Cleaning this problem up in
the generator code reduce the (manual) work we need to do.
It also means introspection can detect dupes (in generated and manual
code) so we don't end up adding more (which would also require more
manual work to support both set of attributes).
[1] https://github.com/xamarin/xamarin-macios/pull/10580
This reverts commit 9a27951a99.
The purpose of the original commit was to take out 4 tasks that were only executed from Windows to the Windows specific pack (and enabling more tasks that need to be executed remotely on that pack).
To execute tasks remotely the build will initially run `SayHello` which connects to the Mac and shares the connection with all the tasks through IBuildEngine4[1]. When that connection object is retrieved on the tasks we need to cast it as a Messaging connection type, and this works from Visual Studio and msbuild because there's just one messaging assembly loaded.
But it doesn't work on dotnet/msbuild, because there's a feature called ALC (AssemblyLoadContext) which will load each assembly task into it's own context[2], loading all its dependencies in that context. In this scenario sharing custom objects between tasks won't work because the original object type could be from a different context than the one retrieving it. This is described here: https://github.com/dotnet/msbuild/issues/5084.
[1] https://docs.microsoft.com/en-us/dotnet/api/microsoft.build.framework.ibuildengine4?view=msbuild-16-netcore
[2] https://github.com/dotnet/msbuild/blob/master/documentation/specs/task-isolation-and-dependencies.md
Also set to 13.0 (first Catalyst version) any framework that existed
earlier in iOS.
* Avoid multiple lookup in the frameworks collection since we need to access/update most of them anyway
xtro tests are based on Apple's header files and report as _unknown_
bindings to API that are not found in headers - Catalyst in this case.
Removing them is required so the applications can be submitted to the
AppStore.
This also means linking with the runtime packs from .NET instead of the mono archive
(thus we have one less reliance on the mono archive).
We're also using the Xamarin.iOS code for our macOS launch sequence now, since
(at least at first) we're only going to support self-contained .NET macOS apps
(so no need to support a system-installed runtime, which simplifies things a
bit).
Sebastien Pouliot
Jonathan Peppers
Rolf Bjarne Kvinge
Connor Adsit
Emanuel Fernandez Dell'Oca
Manuel de la Pena