Commit list for xamarin/maccore:
* xamarin/maccore@aa77d5e811 Bump maciostools to get mlaunch fixes.
* xamarin/maccore@0d74e34e16 Merge pull request #659 from xamarin/ts-swift4mangling
* xamarin/maccore@5135e9dd60 Reformatted an exception, switched to Ordinal string comparisons where it makes sense (everywhere, as it turns out).
* xamarin/maccore@40d676bf96 Updates for PR: formatting, names, obsolete comments addressed.
* xamarin/maccore@9751df85ca Updated for swift4 support - major changes include new name demangling, new demangled name -> SwiftType conversion, updated pinvokes, ABI changes.
Diff: 689fae7440...aa77d5e811
Fixesxamarin/maccore#658
When a MidiThruConnection is created but for some reason is not disposed
the system keeps it alive even between app/simulator restarts, if you want
to clean the connections you must reset contents and settings from simulator.
In order to avoid this test from failing randomly and since the intent of the
test is to check if `MidiThruConnection.Find` works we change the assert to
`>= 2` since this is at least the number of connections we expect.
The F# compiler complains that:
/Users/xamarinqa/vsts/_work/52/s/tests/fsharp/Main.fs(13,9): error FS0433: A function labeled with the 'EntryPointAttribute' attribute must be the last declaration in the last file in the compilation sequence.
Main.fs is the last file in the project file, but the MSBuild tasks adds
another one at the end:
obj/iPhone/Debug64-today-extension/Xamarin.iOS,Version=v1.0.AssemblyAttribute.fs
because we're building a library (in which case the MSBuild tasks assume that
there won't be any Main functions in the project, and as such it's safe to
append files to compile).
Work around this by excluding the Main function from F# extensions, it's not
needed anyway.
* [security] Modifying structure of bindings
Added strong dictionary for key generation according to
https://developer.apple.com/documentation/security/certificate_key_and_trust_services/keys/key_generation_attributes
in preparation making a strongly typed key generation possible.
* Making strong dictionary and composite of other strong dictionaries.
* Implementing access control as property type of SecPublicPrivateKeyAttrs.
* Adding new overload for SecKey.CreateRandomKey.
* Moving TokenID to strongly typed property.
* Fix coding style + use nameof
* Fixing Xcode version assertion of key generation tests.
* Fixing errors in test case.
* Fixing whitespace issue.
* Resolving inheritance issue
Removing inheritance between SecKeyGenerationParameters and
SecPublicPrivateKeyAttrs and instead add the necessary properties
to SecKeyGenerationParameters. Adds redundant code, but I don't
see a way around it.
* Moving test case to appropriate test class.
* Creating necessary strong dictionaries for key generation.
* [formatting] Mono coding guidelines
Make sure you're following http://www.mono-project.com/community/contributing/coding-guidelines/
In VSMac: Preferences > Source Code > Code Formatting > C# source code > Policy Mono.
* Remove [Advice] that are specific to GenerateKeyPair
`SecKeyGenerationParameters` and `SecKeyParameters` cannot be used for `GenerateKeyPair`.
* Clarify 'ArgumentException' for invalid 'SecKeyType'
* Fixed CreateRandomKeyTest
- Renamed CreateRandomKeyWithParametersTests to CreateRandomKeyTest.
- Add messages to all asserts.
```
keyGenerationParameters = new SecKeyGenerationParameters ();
keyGenerationParameters.KeyType = SecKeyType.Invalid;
Assert.Throws<ArgumentException> (() => { SecKey.CreateRandomKey (keyGenerationParameters, out _); }, "CreateRandomKey - invalid key type");
```
- ^ didn't work because `SecKeyGenerationParameters`'s setter protects against invalid. There's no constant for invalid so null is returned.
```
Assert.That (SecKey.CreateRandomKey (keyGenerationParameters, out _), Is.EqualTo (SecStatusCode.Param), "CreateRandomKey - Param issue, invalid RSA key size");
```
- ^ `SecKey.CreateRandomKey` doesn't return a `SecStatusCode` like `GenerateKeyPair`.
* Fixes based on spouliot's input.
* Mono styling fix.
The main cause of the warning: "warning MSB6002: The command-line for the 'MTouch' task is too long" was the number of references that can be passed to `mtouch`.
Now all the arguments are written in a response file which in turn is passed to `mtouch`.
- Fixes bug #56501: MSB6002 command-line for MTouch task is too long, > 32000 characters
(https://bugzilla.xamarin.com/show_bug.cgi?id=56501)
- The response file is created in the device specific folder, as `response-file.rsp`. It is re-created every time.
- Added an msbuild test to ensure the response file is created by `GenerateCommandLineCommands` and that it includes all the references.
- Introduce `AddLine` and `AddQuotedLine` which we use to populate the response file (and go to the next line).
- Move to C# 7 syntax for string replacement.
- Update all tests in `MTouchTaskTests` to use the response file since the arguments are no longer passed directly to `mtouch`.
- Update MT0018's documentation for response files.
If a class implements a protocol with optional members, and that class also exports methods whose selectors match an optional member, but the signature doesn't match, we must show a useful warning instead of erroring out due to a NullReferenceException.
Fixes this:
System.NullReferenceException: Object reference not set to an instance of an object
at Registrar.StaticRegistrar.GetBlockProxyAttributeMethod (Mono.Cecil.MethodDefinition method, System.Int32 parameter) [0x00001] in /Users/builder/data/lanes/1381/9de35b83/source/xamarin-macios/tools/common/StaticRegistrar.cs:4113
at Registrar.StaticRegistrar.GetBlockWrapperCreator (Registrar.Registrar+ObjCMethod obj_method, System.Int32 parameter) [0x001e1] in /Users/builder/data/lanes/1381/9de35b83/source/xamarin-macios/tools/common/StaticRegistrar.cs:4101
at Registrar.StaticRegistrar.Specialize (Registrar.AutoIndentStringBuilder sb, Registrar.Registrar+ObjCMethod method, System.Collections.Generic.List`1[T] exceptions) [0x0216b] in /Users/builder/data/lanes/1381/9de35b83/source/xamarin-macios/tools/common/StaticRegistrar.cs:3683
when building the msbuild/tests/MyWatchKit2IntentsExtension project.
Since that's what all the other test suites that use NUnit v2 use, and it's
also what xharness expects (and tries to execute).
This fixes running these tests when other tests haven't already restored the
v2.6.4 nuget.
* [MMP] Revert recursive search dirs changes
* [MMP] Allow resolving assemblies to the ones passed in command line args
This is what actually makes the MonoMacResolver actually resolve to
assemblies given as arguments.
This mirrors the behaviour of Pack, which is called on the other
code-path (that's not --runregistrar)
3113c5d2b5/tools/mmp/driver.cs (L513)
Fixes this test failure:
1) Failed : Xamarin.MTouch.MT0113_linker
The error 'MT0113: Native code sharing has been disabled for the extension 'testServiceExtension' because the managed linker settings are different between the container app (None) and the extension (All).' was not found in the output:
Message #1 did not match:
actual: 'Native code sharing has been disabled for the extension 'testServiceExtension' because the remove-dynamic-registrar optimization differ between the container app (default) and the extension (false).'
expected: 'Native code sharing has been disabled for the extension 'testServiceExtension' because the managed linker settings are different between the container app (None) and the extension (All).'
which happens because:
* Removing the dynamic registrar requires the linker, so removal of the dynamic registrar is disabled if the linker is not disabled
* This results in the app and appex having different values for the remove-dynamic-registrar option
* Thus the error message.
Technically either error is correct, but I prefer the previous one (about the
linker), because it directly assigns blame (the linker setting). Figuring out
what has to change (the linker setting) when the error message complains about
an optimization is not so straight forward for users.
* [static registrar] Optimize creation of delegates for blocks.
Optimize creation of delegates for blocks so that it doesn't require the
dynamic registrar.
This is done by getting the metadata token for the Create method that creates
the delegate, and embed that metadata token in the generated code from the
static registrar.
Also add tests, since this scenario was not covered by tests already.
* [mmptest] Fix test after recent changes.
* [test-libraries] Avoid duplicate symbols.
* [tests] Update according to changes.
Assemblies that satisfy all of these conditions:
* Are not in the container project.
* Are in multiple app extensions.
can (and should) be bundled in the container app.
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=58873
* [tests] Don't run mmp regression tests in parallel. Fixes maccore #645.
For some reason vstool becomes confused and starts erroring out if multiple
vstools are running at the same time.
So work around this by executing the MMP regression tests serialized.
Fixes https://github.com/xamarin/maccore/issues/645.
* [xharness] Upload the logs from the mmp regression tests.
* [xharness] Improve html report by formatting newlines and tabs in test failure messages using corresponding html tags.
* [xharness] Improve nunit test reporting in html report by creating a list of failures.
- https://github.com/xamarin/xamarin-macios/issues/3367
- App Store will now fail builds if you add in a 32-bit dylib
- If you are a 32-bit app you don't need the 64-bit part of your fat
dylib anyway
- Add --optimize=-trim-architectures to allow customization of behavior, as not everyone
uses app store
In addition, while writing tests for this is was noticed that mmp tests did not "really" run Release configuration correctly in most cases. Fixing this turned out to be a bit of a pain, but necessary to correctly test this (and other things).
- Turns out that /p:configuration:debug is not sufficient to tell mmp to
do the right thing
- That, in most projects, sets the DebugSymbols property, which really
is what is checked.
- However, two of our projects did not have that, so we always did
release mmp work.
- Removed configuration property for tests and added real "Release"
configuration option
When asking for user credentials it was not possible to change the
default authorization prompt message so the application name is used
by default. When running an application with Mono this will be
mono-sgen64 or mono-sgen32.
The prompt is now added to the environment authorization item set
passed to AuthorizationCreate. It was being passed as part of the
rights item set. This allows a custom message to be set in the
authorization dialog.
This fixes a startup crash in code shared app extensions due to having the
wrong value set in the runtime (the dynamic registrar was removed, but the
executable didn't know it).
At some point the code wasn't able to figure out the framework for linked away
types (because linked away types don't know which assembly they belong to, and
thus we couldn't verify that the type in question was a platform type or not),
so I skipped checking the namespace for such types.
Some time later I implemented support for storing the assembly for a linked
away type separately, so that it can later be looked up, and thus it's not
necessary to exclude linked away types anymore.
This fixes a build problem with the generated registrar code (which happens
only if the INCWidgetProviding interface is linked away) when building the
linkall extension tests:
/work/maccore/master/xamarin-macios/tests/xharness/tmp-test-dir/link all1894/obj/iPhone/Debug64-today-extension/mtouch-cache/registrar.h:319:51: error: no type or protocol named 'NCWidgetProviding'
@interface TodayViewController : UIViewController<NCWidgetProviding> {
^
This can be reproduced by running monotouch-test with all optimizations in
Debug mode (because some of the exception marshalling tests are only enabled
in debug mode), so add such a configuration to xharness. To avoid bloating PR
builds, this configuration is only enabled when running all tests (either
manually selecting all tests for a PR, or on Wrench, where everything is
always tested).
The ProtocolTest test is located in the bindings-test assembly, and it
requires certain conditional compilation defines to be set in order to behave
properly.
With this fix we correctly set these defines when cloning the bindings-test
project (in addition to when we set the defines for the main project, which is
either monotouch-test or linkall for this test).
Fixes https://github.com/xamarin/maccore/issues/655.
* [tests][macos] Fix AuthenticodeDeformatterTest.VerifySignedAssembly failure on modern. Fixes 3207
Modern does not, by default/design, ship a machine.config file. This
means it only knowns about the default crypto shipped with .NET.
That's a problem for MD2 for which some old certificates might still
exists in the computer store, like our wrench bots.
That's generally not a problem since XM apps delegate trust to macOS
except for one case: Authenticode.
So verifying an authenticode signature can end up, thru X509Chain,
loading a certificate using MD2 without knowing how to create the
digest algorithm - and fail.
The fix is to register the algorithm manually (if not found).
https://github.com/xamarin/xamarin-macios/issues/3207
* [tests] Only call CryptoConfig on XM modern builds and add a reference to Mono.Security.dll on such projects
This fixes an issue where multiple copies of the GuiUnit project would have
the same output directory, causing random problems when building those
projects in parallel.
* Update README.md
New README layout which includes sections to help direct visitors to the appropriate areas.
Adds note about the license
* Adds Gitter Button
Back by popular demand!
* Fixes Vote link
The [Protocol] attributes the test checks for are not linked away in
monotouch-test (because monotouch-test only links SDK assemblies), but they
are linked away in link all, so adjust the test accordingly.
Now that we've switched to csc, we're also delighted to get new warnings 🎉
ObjCRuntime/Blocks.cs(54,26): warning CS0649: Field 'XamarinBlockDescriptor.descriptor' is never assigned to, and will always have its default value
AudioUnit/AudioUnit.cs(405,19): warning CS0649: Field 'AudioUnit.handle' is never assigned to, and will always have its default value
ObjCRuntime/Blocks.cs(55,23): warning CS0649: Field 'XamarinBlockDescriptor.ref_count' is never assigned to, and will always have its default value 0
ObjCRuntime/Blocks.cs(54,26): warning CS0649: Field 'XamarinBlockDescriptor.descriptor' is never assigned to, and will always have its default value
AudioUnit/AudioUnit.cs(405,19): warning CS0649: Field 'AudioUnit.handle' is never assigned to, and will always have its default value
ObjCRuntime/Blocks.cs(55,23): warning CS0649: Field 'XamarinBlockDescriptor.ref_count' is never assigned to, and will always have its default value 0
We're so delighted that we want them gone asap 😎
Rolf Bjarne Kvinge
Alex Soto
Chris Hamons
Eberhard Beilharz
mdbech
Vincent Dondain
Marius Ungureanu
Matt Ward
Sebastien Pouliot
Bernhard Urban
Joel Martinez
John Miller