Provide tests that will ensure that the Tcp listener and File listener
will work correctly. Tests ensure that both listeners receive the data
and write it in the ILog
The tcp test is an interesting one because it redirects the call of the
method to a diff callback that will write the data in a stream to check
the final result.
Move to use interfaces, that will let us later add tests that will
verify that all the correct logging is performed. As an example, added a
test for XmlResultParser that ensures that the failures are correctly
generated. The test uses Moq to pass the different paths to be used and
later be able to verify the wirtten xml.
Co-authored-by: Přemek Vysoký <premek.vysoky@microsoft.com>
so if we optimize (to remove references) the tests will be ignored.
Doing this based on define was wrong since we have different (and more)
configurations executed on devices,
Move to use interfaces, that will let us later add tests that will
verify that all the correct logging is performed. As an example, added a
test for XmlResultParser that ensures that the failures are correctly
generated. The test uses Moq to pass the different paths to be used and
later be able to verify the wirtten xml.
* Merge IOS_native_DEFINES and IOS_GENERATOR_native_FLAGS into IOS_DEFINES and
IOS_GENERATOR_FLAGS, respectively.
* Remove MAC_*_GENERATOR and MAC_*_GENERATE, use MAC_GENERATOR and
MAC_GENERATE instead.
* Simplify the MAC_TARGETS_template by removing empty and useless arguments.
Don't use assembly identity when converting between reflected attributes and
instantiated attributes, because types will move to different assemblies in
.NET 5, and the code to keep track of everything ends up being complicated if
we were to verify assembly identity for each attribute type.
So don't verify assembly identity anymore.
When converting from IKVM.Reflection.Type to System.Type we can just create a
big switch statement with typeof expressions as the result, and let the C#
compiler figure out where those typeof types come from.
When converting from System.Type to IKVM.Reflection.Type we now look in all
the loaded assemblies in IKVM for the type name. To try to prevent unpleasant
surprises, we verify that any particular typename is only findable once (this
seems obvious, but this check actually found a bug in IKVM when loading .NET 5
assemblies - which will be fixed in a different PR).
Also this allowed us to remove some code to manually load assemblies we needed
to know about (since now we don't need to know about those assemblies
anymore).
An additional bonus is that this seems to be slightly faster too (a clean
build in src/ takes 1m33s instead of 1m39s).
This optimization can be enabled when it's not possible to use the
managed linker (e.g. **Don't link**) or when the managed linker cannot
remove references to deprecated types that would cause an application
to be rejected by Apple.
References to the existing types will be renamed, e.g. `UIWebView` to
`DeprecatedWebView`, in every assemblies.
The type definition is also renamed (for validity) and all custom
attributes on the types and their members will be removed.
Code inside the members will be replaced with a
`throw new NotSupportedException ();`.
The msbuild test app `MyReleaseBuild` has been updated to test that the
optimization is working as expected (device builds are slow so reusing
this test has little impact in test time).
Basically the test ensure that `UIWebView` is used and cannot be removed
by the compiler (optimization) or the managed linker (since it's
referenced). Since the optimization is enabled then we can `grep` then
final `.app` directory to ensure there's no mention of `UIWebView` inside
any of the files that would be submitted.
The application can be run, by itself, and will turn green if OK, red if
`DeprecatedWebView` can't be found (skeleton replacement for `UIWebView`)
or orange if a `NotSupportedException` is thrown.
Finally introspection tests have been updated to skip over the deprecated
(and renamed) types. It should not be an issue right now, since this
optimization is not enabled by default, but it made testing easier.
Instead verify that it's not a nested type, which should be more than good
enough. If someone else defines a System.Nullable`1, they'll probably have
much bigger problems.
This solves an issue with .NET 5 where System.Nullable`1 doesn't actually come
from mscorlib.
More future-proof, because new and different target frameworks will be
introduced in the future with .NET 5.
Also: fewer string comparisons is always good.
Some crashes are reported as tcp connection issues because they happen
before the app had the chance to write anything in the log. In that
case, we checked for the presence of the file, and if not present we
decided it was a tcp issue when it is not the case.
In this commit, we check for the tcp erorr message in the main_log so
that we are certain that the issue was with the connection and not
anyother.
Testingis simple, ran tests without the phone being part of the same
network and test with a branch that has a crash. For example the one in
https://github.com/xamarin/xamarin-macios/pull/8009 hash 83240612e8
Using assembly identity to verify that a type is the expected one becomes
complicated with .NET 5, because types move around a lot between assemblies.
There are also type forwarders all over the place which doesn't make things
better. So instead use (only) string comparisons on type names to determine
which types we're dealing with.
The only time this change can become a problem is if someone decides to
implement their own version of the built-in System types, but that would be a
very bad idea for a number of other reasons.
* XAMARIN_MAC: Used once, replace with MONOMAC.
* UNIFIED: Use once elsewhere, replace with __UNIFIED__.
* OBJECT_REF_TRACKING: not used anywhere.
* XAMARIN_MODERN: not used anywhere.
* NET_2_0: not used anywhere.
Also update the README a bit.
The make target names both Xamarin.iOS.dll and Xamarin.iOS.pdb. Depending on
ordering, make might want to ask the target to make the .pdb, in which case
we'd use that as the output name of the compilation. So instead explicitly
make the output assembly a .dll.
We support different outputs, lets add the avility for the caller to
decide which one to use. We default to NUnit V3 due to or dependency to
it in VSTS.
We do not longer compile the bcl tests, but we consume them as part or
mono. The old BCL targets and classes are not needed. As you can see,
the lists were empty.
Add tests to make sure that we can be safe when we make changes to that
part of the code.
Some methods are not tested but due to dependencies. Will work un
separating things a little to keep moving fwd.
New commits in xamarin/maccore:
* [MLaunch] Add support to add tcp tunnels to communicate with the
device. b64c9250d7
* [Errors] Do not use the old bugzilla url. 4c92d05de7
Complete diff: 66d2bdad24..b64c9250d7
This will spot cases like https://github.com/xamarin/xamarin-macios/issues/7959
where a type (static) constructor can fail at runtime, leading to
`TypeLoadException`
Ideally it's covered by it's own tests but it's better covered twice
than never :)
On iOS 64bits [1] simulator we hit some failures [2], later, if the
`.cctor` is executed. It's not a big deal to avoid those types since
we it will be executed on devices later.
[1] API not present on 32bits
[2] Fixing the following triggers similar failures for `DCDevice`
```
ApiClassPtrTest.VerifyClassPtr: class_ptr and RegisterAttribute are different: NFCIso15693CustomCommandConfiguration
Expected: 0
But was: 140735471513712
ApiSelectorTest.StaticMethods: 7 errors found in 2788 static selector validated:
CoreNFC.NFCIso15693ReaderSession : readingAvailable
CoreNFC.NFCNdefMessage : ndefMessageWithData:
CoreNFC.NFCNdefPayload : wellKnownTypeURIPayloadWithString:
CoreNFC.NFCNdefPayload : wellKnownTypeURIPayloadWithURL:
CoreNFC.NFCNdefPayload : wellKnownTypeTextPayloadWithString:locale:
CoreNFC.NFCNdefReaderSession : readingAvailable
CoreNFC.NFCReaderSession : readingAvailable
Expected: 0
But was: 7
```
We initially added a cmd to do the bcl test import generation that has
never been used.
We are moving the bcl test importer code to xharness and creating a
NUnit test project to run the tests that we already added. Unit tests
pass.
* [mmp] Set 'disable_omit_fp' by default to provide better native stack traces in certain cases.
This may produce better stack traces when crashes occur, which could be
helpful for tracking down issues like
https://github.com/xamarin/maccore/issues/643.
Also add an mmp option to override the default behavior.
This is unlikely to cause any problems, because Visual Studio for Mac sets
MONO_DEBUG=disable_omit_fp at launch, which means that all processes launched
by VSMac will also have this variable set already.
* Fix lldb attach disabling.
It will be nice to be able to have a smaller set of tests to be ran by
xharness. In this commit we add a set of labels to be able to divide the
test in the following groups:
* Xamarin - all tests BUT monotouch.
* Monotouch - just monotouch tests.
* Old BCL - The BCL tests that are based on NUnit
* New BCL - The BCL tests that are based on xUnit.
* mscorlib - Just the test that exercise mscorlib (and the different
groups, mscorlib 1, mscorlib 2 etc..)
This will allow to parallelize the execution of the full test suit in
different agents in VSTS.
* [mmp] Don't ignore failures to execute pkg-config and simplify/improve logic.
* Show proper errors if pkg-config fails to execute.
* Extract logic to verify system mono version into its own function.
* Extract logic to execute pkg-config into its own function.
* Simplify code slightly.
* [mmp] Remove the MM5301 error message.
It's never used in mmp, and the same error code is already used in mtouch.
`Default` property was using a nil-handle which is incorrect since
* we don't allow that (this is generally a bad sign)
* it does not map to `OS_LOG_DEFAULT`
Since `Default` was assigned in the type (static) constructor then
the whole type became unusable :(
Header `log.h` shows that the right definition requires us to load a
field and use it.
```
define OS_LOG_DEFAULT OS_OBJECT_GLOBAL_OBJECT(os_log_t, _os_log_default)
```
While `NULL` can actually be used for disabled (not exposed) by this
contradicting (nullability-wise) macro
```
define OS_LOG_DISABLED ((os_log_t _Nonnull)NULL)
```
Also adds unit tests. A more general tests for `.cctor` will be added
to introspection tests in a separate PR.
Fixes https://github.com/xamarin/xamarin-macios/issues/7959
* [mmp] Use relative path in mmp script.
Makes relocating mmp easier.
* [mmp] Resolve the right directory.
mmp might be in two locations (the second one works because the Commands
directory is a symlink to the actual bin directory):
* /Library/Frameworks/Xamarin.Mac.framework/Versions/Current/bin/mmp
* /Library/Frameworks/Xamarin.Mac.framework/Commands/mmp
The mmp script didn't work properly in the latter case, because it would
calculate where to find the mmp.exe assembly based on real location the parent
directory (which would be /Library/Frameworks/Xamarin.Mac.framework), instead
of the real location of the directory where mmp is
(/Library/Frameworks/Xamarin.Mac.framework/Commands, which would resolve to
/Library/Frameworks/Xamarin.Mac.framework/Versions/Current/bin).
The fix is to just get the real path of the Commands directory, and compute
the location of the mmp.exe from there.
bmac-mobile-mono is an old name (when we needed a specific executable to
execute bmac) that has nothing to do with its current usage (AOT code for
Xamarin.Mac apps).
So rename the executable to reflect current usage.
This makes looking at the installed files a bit less confusing.
This makes the `--time` options more useful to see inside the linker's
pipeline steps.
This was used only in `mtouch` before (and missed some steps [1]).
Now it's shared between both tools.
[1] not sure why... merge issue/backport maybe ?
Custom initialization of Xamarin.Mac is tricky. You can easily start
using ObjC features before everything is ready / loaded into memory.
In contrast a _normal_ XM application, from an app bundle, already has a
lot of things loaded into memory when it starts to initialize.
This means that some things can work _by chance_ due to timing and that
semi-related (and correct) changes could affect your _lucky_ timings.
Such a semi-related change was a239fa9ebd (diff-4aa19167162888aec0ccc2261a7ddbd3)
In #7932 the attached code
```csharp
NSApplication.IgnoreMissingAssembliesDuringRegistration = false;
```
triggers the `.cctor` which means that `class_ptr` is initialized.
Note: That's not fully correct/safe since `Init` is not been called
but that's a different issue...
Anyway the dual calls that existed before was enough to hide the first
(which failed but triggered the rest of the native initialization).
That extra call made older XM version works (with attached code).
So in this (#7932) case our generated code
```csharp
static readonly IntPtr class_ptr = Class.GetHandle ("NSApplication");
```
happens too early. Now that cannot be changed because
* it's how .net `readonly` works
* existing/correct code depends on this
* it depends on native side (being loaded/initialized/ready)
but we can **add** to this and make `Init` safer to use by duplicating
the call _only if_ the original call had failed.
Of course the generated code has the `class_ptr` field as `readonly`...
```
error CS0198: A static readonly field cannot be assigned to (except in a static constructor or a variable initializer)
```
so we need to use reflection to achieve this (but that cost will occur
if the original initialization failed)
Fix https://github.com/xamarin/xamarin-macios/issues/7932
Manuel de la Pena
Rolf Bjarne Kvinge
Sebastien Pouliot
Waleed Chaudhry
Chris Hamons
Thays Grazia