https://bugzilla.xamarin.com/show_bug.cgi?id=58479
_AssignAppExtensionConfiguration assigns project configuration from
`$(CurrentSolutionConfigurationContents)`, using the
`AssignProjectConfiguration` task, which is set if
`$(BuildingSolutionFile)` or `$(BuildingVisualStudio)` is true. We check
only for the former. It would be simpler to just check for ..
`$(CurrentSolutionConfigurationContents) != ''`
.. like the iOS targets. This mapping from this task is used when
invoking `GetBundleTargetPath` on the extension project:
Properties="%(_AppExtensionReferenceWithConfigurationExistent.SetConfiguration); %(_AppExtensionReferenceWithConfigurationExistent.SetPlatform)"
Details:
This failed for a project that had a reference to an app extension
project, with VSMac/msbuild. The app extension project was being built
with `Configuration==Debug` and `Platform==x86` for which the project
does not define any properties (like `$(OutputPath)`).
When the main project is built, we invoke `GetBundleTargetPath` on
the extension project, which in this case, has a different
config+platform mapping than the one for the referencing project. But
since the earlier `AssignProjectConfiguration` was skipped due to the
incorrect condition, `GetBundleTargetPath` is invoked with no
config+platform, thus falling back to extension project's defaults.
Note: The referencing project was being built with Debug|x86 and the
referenced project was expected to be built with Debug|AnyCPU .
This project:
- VSMac/xbuild - Works
- This happens to work because the default from the extension
project is Debug|AnyCPU, so even though
`AssignProjectConfiguration` didn't set those properties, it
builds just fine.
- command line xbuild/msbuild - works!
- `AssignProjectConfiguration` works because this time the
condition `$(BuildingSolutionFile) == 'true'` is True.
- VSMac/msbuild - fails
- In this case, the default case does not work because in VSMac,
we use `SetGlobalProperty` to set config+platform properties
when starting the build for the referencing project.
- And when the referencing project builds the referenced project
(via `GetBundleTargetPath`), it is built with config+platform
global properties set, and thus defaults from the referenced
don't get picked up!
<Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
- With the `AssignProjectConfiguration` fix, we set the
properties via the `MSBuild` task, so it works.
But this needs to be fixed in VSMac anyway.
This can save a significant amount of space when using code-sharing: the PIX
app saved ~11mb in release mode (when stripping).
`man strip` says:
```
For dynamic shared libraries, the maximum level of stripping is usually -x (to remove all non-global symbols).
-x Remove all local symbols (saving only global symbols).
```
Fix collecting required internal symbols which aren't in the objc_msgSend
family by not bailing out early for a function which isn't in the objc_msgSend
family.
Also add a test.
For some reason the target to build OpenTK.dll.config may cause an infinite
recursion in make.
I don't understand what's happening, but we don't need OpenTK.dll.config
anymore, so just not produce/ship it anymore.
On at least one of my devices I get MACaptionAppearanceDisplayType.AlwaysOn,
while the locale is 'en'.
So just allow all valid enum values for the return type.
When we process P/Invokes to add support for exception marshaling, we may
change P/Invokes to be __Internal. This means that we need to move the check
for __Internal P/Invokes to after processing P/Invokes for exception
marshaling.
https://bugzilla.xamarin.com/show_bug.cgi?id=57833
Previously the assumption was that if an assembly not using dlsym references a
native symbol, it's not a required symbol. This is true as far as the native
linker goes: the native linker will see that the native symbol is referenced
by the AOT-compiled code, and it won't be removed.
However, we use also this exact logic to create the list of functions we ask
the native strip command to preserve, and in this case we need to include all
symbols needed in all assemblies that looks up native functions using dlsym.
https://bugzilla.xamarin.com/show_bug.cgi?id=57826
Some Quote implementations quoted backslashes, some didn't. When selecting a
common implementation, one of the implementations that didn't quote
backslashes won, and the rest were forgotten. Almost. Except for the MT0106
test, which started failing, thus exposing the winner's deficiencies.
So dethrone the implementation that won and reinstante the importance of the
backslash.
https://bugzilla.xamarin.com/show_bug.cgi?id=57768
* [registrar] BindAs uses Nullable types so allow them to be registered as NSObjects
BindAsAttribute allows to bind NSValue and NSNumber into more
accurate C# types lyke bool?, int? etc. so we must teach registrar
about this.
* [tests][introspection] Teach intro about BindAs and Nullable types
Introspection will currently fail if BindAs is used, introspection
will report that the incorrect type is registered so we need to skip
this check if Nullable type is found in the signature
* [introspection] Add better type checking instead of totally skipping the type when Nullable type is encountered
Introspection will currently fail if BindAs is used. Introspection
will report that the incorrect type is registered so we need verify
if a Nullable type is found in the signature and check against of
a withelist of BindAs supported types
* Revert "[registrar] BindAs uses Nullable types so allow them to be registered as NSObjects"
This reverts commit 911eab97b7.
* [tests] Add comment about where to find BindAs types
Very occasionally this may happen:
/bin/sh: /Users/builder/data/lanes/5024/08614af6/source/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/MonoTouch.iphonesimulator.sdk/Frameworks/Xamarin-debug.framework/Info.plist: No such file or directory
make[4]: *** [/Users/builder/data/lanes/5024/08614af6/source/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/MonoTouch.iphonesimulator.sdk/Frameworks/Xamarin-debug.framework/Info.plist] Error 1
which is fixed by using the right dependencies for the Info.plist target.
This was due to an integer overflow. The original value was based on Int32
1 << 40 == 256
The correct value should be based on a UInt64.
1UL << 40 == 1099511627776
HFS normalizes filenames to Form D when files are stored. This means that an
assembly whose assembly name is stored in Form C might be stored in a file
whose filename is Form D (which you'll get if you use the Form C filename).
However, this is a problem when we've already loaded an assembly and if we
doesn't take normalization into account: we check the cache based on the
filename, but store in the cache based on the assembly name. If those two uses
different normalization schemes, bad things (bug #57266) happen.
So in these scenarios normalize strings before comparing them.
https://bugzilla.xamarin.com/show_bug.cgi?id=57266
This allows things to work on both xbuild and msbuild.
In xbuild, both lists are exactly the same and on msbuild,
only @(ReferencePath) exists.
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=55147
Rolf Kvinge [8:59 AM]
@dalexsoto the fix is to not strip the executable please PR that
(it should probably go into master as well). This probably started
happening when Jeff implemented support for stripping debug builds
(previously the setting was ignored)
* [Foundation] Set 'sentRequest' when sending a request in NSUrlSessionHandler.
Fixes this compiler warning:
> [..]/external/mono/mcs/class/System.Net.Http/HttpClientEx.cs(50,8): warning CS0649: Field `Foundation.NSUrlSessionHandler.sentRequest' is never assigned to, and will always have its default value `false'
However it changes the runtime behavior, and we'll now throw an exception in
cases that we accepted before:
* `sentRequest` is only read in `EnsureModifiability ()`, which throws an
exception if `sentRequest` is true.
* Previously `sentRequest` was never set (thus the compiler warning), which
meant `EnsureModifiability` would never throw an exception.
* Looking at the similar `CFNetworkHandler` (which has the identical field and
methods), it seems that the intended behavior is to set `sentRequest` in
`SendAsync`, and then `EnsureModifiability` is called whenever a property is
set to ensure the property isn't set too late (and any change would be
ignored because the request was already sent).
* This means that previously setting any property after the request was sent
would not throw any exceptions (even though the change would be ignored),
while with this change we'd start throwing exceptions.
* Add missing tests for the setRequest var.
* Redesign tests to make sure that all handlers run the same code.
* Fix failing test.
* Add the managed handler to the HttpClient tests.
* Fix minor style issues.
Rolf Bjarne Kvinge
Sebastien Pouliot
Matt Sylvia
Jeffrey Stedfast
Andy Martin
Bernhard Urban
Alex Soto
James Clancey
Nick Berardi
Timothy Risi
Chris Hamons
Miguel de Icaza