* Initial changes for xcode13 GameController beta1
* syntax and name change
* name change and adding async
Co-authored-by: tj_devel709 <antlambe@microsoft.com>
OutputPath is relative to the project directory, so it doesn't work when the
current directory isn't the same as the project directory.
TargetDir is an absolute directory.
Ref: #11994 / 096c75f425 (same for Mac Catalyst).
* Update dependencies from https://github.com/dotnet/installer build 20210606.2
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.6.21280.2 -> To Version 6.0.100-preview.6.21306.2
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21277.2 -> To Version 6.0.100-preview.6.21304.2 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20210613.2
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.6.21280.2 -> To Version 6.0.100-preview.6.21313.2
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21277.2 -> To Version 6.0.100-preview.6.21304.2 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20210615.23
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.6.21280.2 -> To Version 6.0.100-preview.6.21315.23
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21277.2 -> To Version 6.0.100-preview.6.21304.2 (parent: Microsoft.Dotnet.Sdk.Internal
* Fix custom step order
In response to https://github.com/mono/linker/pull/2082
* Update dependencies from https://github.com/dotnet/installer build 20210620.4
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.6.21280.2 -> To Version 6.0.100-preview.7.21320.4
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21277.2 -> To Version 6.0.100-preview.6.21317.4 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20210621.2
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.6.21280.2 -> To Version 6.0.100-preview.7.21321.2
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21277.2 -> To Version 6.0.100-preview.6.21317.4 (parent: Microsoft.Dotnet.Sdk.Internal
* Remove unnecessary workaround.
* [dotnet] Update our code to get the path to the AOT compiler. Fixes#11905.
* [dotnet] Remove another workaround for runtime packs doing the wrong thing.
* Update dependencies from https://github.com/dotnet/installer build 20210622.1
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.6.21280.2 -> To Version 6.0.100-preview.7.21322.1
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21277.2 -> To Version 6.0.100-preview.6.21321.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20210622.8
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.6.21280.2 -> To Version 6.0.100-preview.7.21322.8
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21277.2 -> To Version 6.0.100-preview.6.21321.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20210623.2
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.6.21280.2 -> To Version 6.0.100-preview.7.21323.2
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21277.2 -> To Version 6.0.100-preview.6.21321.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20210623.11
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.6.21280.2 -> To Version 6.0.100-preview.7.21323.11
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21277.2 -> To Version 6.0.100-preview.6.21321.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20210624.6
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.6.21280.2 -> To Version 6.0.100-preview.7.21324.6
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21277.2 -> To Version 6.0.100-preview.6.21321.1 (parent: Microsoft.Dotnet.Sdk.Internal
* [dotnet] Install the microsoft-net-runtime-maccatalyst workload as well.
* Update dependencies from https://github.com/dotnet/installer build 20210625.1
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.6.21280.2 -> To Version 6.0.100-preview.7.21325.1
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21277.2 -> To Version 6.0.100-preview.6.21321.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20210626.4
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.6.21280.2 -> To Version 6.0.100-preview.7.21326.4
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21277.2 -> To Version 6.0.100-preview.6.21322.1 (parent: Microsoft.Dotnet.Sdk.Internal
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Sven Boemer <sbomer@gmail.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
When we're using 'open' to launch apps, we need to use '--args ...' to pass any additional argument to the app, because otherwise 'open' will try to open those arguments as if they were files:
```
$ open "/Applications/Sublime Text.app" helloworld
The file /Users/rolf/test/helloworld does not exist.
```
(and doesn't launch Sublime Text).
while this works:
```
$ open "/Applications/Sublime Text.app" --args helloworld
```
in that it opens Sublime Text.
It's also possible to not append any other arguments, so this:
```
$ open "/Applications/Sublime Text.app" --args
```
while it looks weird, it works just fine.
Ref: https://github.com/dotnet/sdk/issues/18437
Context: https://github.com/dotnet/templating/issues/3325
Context: https://github.com/dotnet/templating/wiki/Reference-for-template.json#content-manipulation
In current .NET 6 Preview 6 builds, there is an issue if a template
includes a binary file larger than ~8kb, it seems to get truncated when
`dotnet new` extracts the template.
A workaround is to use the `copyOnly` feature for binary files. Really,
we should be doing this anyway, because otherwise the templating system
considers replacing *text* in these binary files. It improves
performance to do this and would hopefully prevent a future bug of
random bytes getting replaced.
* Skip extraneous logic for generated entries where we know the full path is available
* Update generator to use the internal `_dlopen` that skips the checks
* This removes the code below (diff) for a simple application
* Use the linker substitution files to remove the warning on release builds
* If `dlopen` is used then `WarnOnce` method becomes a empty stub and
* field `warningShown` is also removed
```diff
--- a.cs 2021-06-22 20:59:25.000000000 -0400
+++ b.cs 2021-06-22 20:59:28.000000000 -0400
@@ -2023,44 +2023,14 @@
{
public static class System
{
- public static readonly IntPtr Handle = Dlfcn.dlopen("/usr/lib/libSystem.dylib", 0);
+ public static readonly IntPtr Handle = Dlfcn._dlopen("/usr/lib/libSystem.dylib", 0);
}
}
public static class Dlfcn
{
- private static bool warningShown;
-
[DllImport("/usr/lib/libSystem.dylib", EntryPoint = "dlopen")]
internal static extern IntPtr _dlopen(string P_0, int P_1);
- public static IntPtr dlopen(string P_0, int P_1)
- {
- return dlopen(P_0, P_1, true);
- }
-
- internal static IntPtr dlopen(string P_0, int P_1, bool P_2)
- {
- IntPtr intPtr = _dlopen(P_0, P_1);
- if (intPtr != IntPtr.Zero)
- {
- return intPtr;
- }
- if (P_0.IndexOf('/') == -1)
- {
- if (!warningShown && P_2)
- {
- Runtime.NSLog("You are using dlopen without a full path, retrying by prepending /usr/lib");
- warningShown = true;
- }
- intPtr = _dlopen("/usr/lib/" + P_0, P_1);
- if (intPtr != IntPtr.Zero)
- {
- return intPtr;
- }
- }
- return IntPtr.Zero;
- }
-
[DllImport("/usr/lib/libSystem.dylib")]
public static extern IntPtr dlsym(IntPtr P_0, string P_1);
}
```
Co-authored-by: Sebastien Pouliot <sebastien.pouliot@microsoft.com>
* [dotnet] Normalize run target assembly path on the Run target for Mac Catalyst
* Use TargetPath instead of OutputPath for resolving assembly output directory
* Bump min watchOS simulator to 6.0.
Fixes https://github.com/xamarin/maccore/issues/2454.
* Try to keep using the iOS 12 simulator for watchOS 8.0
* [introspection] Fix running on watchOS 6.0.
* [AVFoundation] Adjust availability of AVPlayerWaitingDuringInterstitialEventReason.
to make sure the latest locally build nuget are used
Also document `make strip-dotnet` as a time-saver to analyze the binary
assemblies produced for dotnet
then fix the impact this had on existing nullable-aware code,
including the generator
Also
* Hide `CFObject` empty (of public members) for future profiles
* Fix `CFString.ToString ()` to never return `null`
* Having .NET enabled with the windows-specific parts disabled is not a
scenario tested on CI (where we've always enabled both). This means it's
prone to bitrotting.
* It's another configuration to keep track of and make work locally.
* It doesn't work right now anyway.
So just always enable the windows-specific parts of the .NET build, if the
.NET build is enabled.
* [tools] Fix quoting quotes in StringUtils.QuoteForProcess.
Previously quoting a string with a quote:
a"b
would result in:
"a\"""b"
There are way too many quotes there.
We'll now get:
"a\"b"
which is correct.
* Add unit test.
* It's easier to fix up the path to the linker description in xharness when
cloning project files. This way maybe we'll be able to remove the [hardcoded
logic in xharness][1] to handle ${ProjectDir}.
* .NET doesn't understand the ${ProjectDir} syntax, so this makes it possible
to build these projects from the command line.
[1]: b2297d610d/src/Microsoft.DotNet.XHarness.iOS.Shared/Utilities/ProjectFileExtensions.cs (L1268)
TL&DR: They were removed from headers so we can't use them for our tests.
Long Story:
To avoid app being rejected the selectors must be removed from the app.
This means the removal of the `[Export]` and `[Bind]` attributes inside
the platform assemblies. That, in turn, makes the binding generator
unable to create bindings for those types.
If some 3rd party bindings extended those types then they also need to
remove them (they will not be able to submit with the symbols anyway).
Stubs can be used, whether or not binary compatibility is provided for
the 3rd party bindings consumers.
Fix https://github.com/xamarin/xamarin-macios/issues/11947