Also add a 'None' build target for the BuildTarget enum for when we're
building for neither simulator nor device (i.e. macOS). This means the default
value will change (since 'Simulator' is no longer the first value), but as far
as I can tell we're always assigning a specific value and not relying on the
default, so this should not make any difference.
This will be needed when the .NET code starts using these classes.
This works around a build problem that occurs because NUnit ships with a
P/Invoke to a function that doesn't exist on Apple platforms:
MTOUCH : error MT5210: Native linking failed, undefined symbol: _GetVersionEx. Please verify that all the necessary frameworks have been referenced and native libraries are properly linked in. [/Users/xamarinqa/myagent/_work/8/s/xamarin-macios/tests/xharness/tmp-test-dir/monotouch-test58/monotouch-test-tvos.csproj]
MTOUCH : error MT5201: Native linking failed. Please review the build log and the user flags provided to gcc: -fembed-bitcode-marker [/Users/xamarinqa/myagent/_work/8/s/xamarin-macios/tests/xharness/tmp-test-dir/monotouch-test58/monotouch-test-tvos.csproj]
clang : error : linker command failed with exit code 1 (use -v to see invocation) [/Users/xamarinqa/myagent/_work/8/s/xamarin-macios/tests/xharness/tmp-test-dir/monotouch-test58/monotouch-test-tvos.csproj]
Also fix an issue in mtouch where we would overwrite any previous --dlsym
values; they're now accumulative (`--dlsym:foo.dll --dlsym:bar.dll` works
as expected)
Ref: https://github.com/nunit/nunit/issues/3618
* [mtouch/mmp] Add CoreFoundation and GSS to our list of known frameworks.
Putting these frameworks in our known list of frameworks means we won't try to
weak link them unless needed (when the deployment target is earlier than when
they were introduced), because if we encounter a framework we don't know
about, we'll weak link them to be on the safe side.
* GSS was available in at least macOS 10.1
The shared version isn't used by mmp yet as far as I can tell (mmp has its own logic
to copy assemblies), but sharing this code is the first step towards having the same
implementation as well.
A few changes are required to have an Application instance at hand when we need to
get the ProductName from it.
This is necessary for .NET, since there will be a single linker library for all platforms,
which means we can't use a constant.
* [xcode12] Bump to Xcode 12 Beta 4
* [Tests] Disable Trust_FullChain and Trust2_FullChain tests
These tests started showing a different error than the one we expect
I'll let our security expert chime in
Update the framework to include Xcode beta3 and add support for tvOS.
As of Xcode12 beta 3 it cannot yet be compiled on macOS X, please refer
to https://github.com/xamarin/maccore/issues/2261
This solves a rebuild problem if an assembly has an invalid or unsupported symbol
file, where we'd detect that the symbol file exists, and expect it to be copied,
but then the linker would drop it, causing us to always rebuild the app (this is
not the same as when a symbol file is out of date).
This happens for NUnitLite 3.12.0's nunit.framework.dll, which ships with an old-style
pdb.
Also add a warning that is shown when we detect that there's a symbol file, but it
couldn't be loaded for some reason.
* [DevOps] Report the correct bot used.
The tests are not executed in the same agent that sets the github
status, for that reason, the github comment is not giving the correct
bot name, but the name of the bot that executed the commit message and
not the tests.
Add an output var in the runTests step to set the bot name and pass it
to the comment job in a different bot.
* Update tools/devops/device-tests/scripts/GitHub.psm1
Co-authored-by: Whitney Schmidt <whschm@microsoft.com>
Co-authored-by: Whitney Schmidt <whschm@microsoft.com>
Depending on the pipeline run, we should have the following result:
* failed: issues with bots or provisioning (red in the UI)
* partiallySucceeded: no issues with bots but failing tests.
* succeeded: no issues with bots and all tests pass.
This adds a psh cmdlet that allows to set the result AND sets the
correct result when we have test failures.
Co-authored-by: Whitney Schmidt <whschm@microsoft.com>
* [dotnet] Only pass a single custom step to the linker.
The linker will load the assemblies with the custom steps once per custom step
argument, which means that each step is effectively in a different assembly,
making it impossible to share state between steps.
This behavior is filed as a linker bug: https://github.com/mono/linker/issues/1314
Until this is fixed, we can just have a single step that injects all the other
steps programmatically.
* [tests] Adjust .NET tests according to new behavior.
Few things:
1. Move from Write-Error to Write-Debug so that we do not set the exit
code and an error.
2. Ig we fail in the Clear-HD step, continue, we should be ok or cancel
if not enough space is found.
* [DevOps] Fix issues with the xm stroage path.
For some reason, and it is very probably a bug in the azurepipelines,
the following bash code creates a path with an extra single quote at the
end:
```bash
P=jenkins/xamarin-macios/$BUILD_LANE/$BUILD_REVISION/$ID/device-tests
echo "##vso[task.setvariable variable=XM_STORAGE_PATH]$P"
```
* Should it do it? Not, it should not.
* Does it do it? Yes, it does.
We work around it via td -d \'\" and remove all single and double quotes
in the string. How long did it take to discover this? More than it
should have.
There is another interesting bug with the variable expansion, the
following
```bash
echo '##vso[task.setvariable variable=XAMARIN_STORAGE_PATH;isOutput=true]$P'
```
Does not equal
```bash
echo '##vso[task.setvariable variable=XAMARIN_STORAGE_PATH;isOutput=true]'$P
```
The first will not expand the variable, the second one will. We do need
the value of $P not '$P'.
Co-authored-by: Whitney Schmidt <51677938+whitneyschmidt@users.noreply.github.com>
Includes support for `UTType`-based `[Field]` in the generator as an
hundred (or so) of them were added. Unit test shows the field-based
properties are working as expected.
There are two method not bound due to a dependency on AVAudioSession that
does not seem to be exposed on Mac OS X.
Related issue: https://github.com/xamarin/maccore/issues/2257
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
The microsoft hosted images have a limit of 10gb, or logs are getting
close to that size when expanded, therefore we will get into issues.
Move back to the self-hosted pool before we have problems.
* [arkit] Remove fields (from beta2) to fix introspection
* [tests][introspection] AVMutableMediaSelection is as bad as it's non mutable parent
* [tools] Update IsFrameworkBroken (remove CoreAudioTypes and MediaPlayer)
* [tests][monotouch-test] MKPinAnnotationView seems fixed in beta 2
* [tests][xtro] Update ARKit todo (with previous fix)
This avoids a possible difference in behavior, because in our system
dependency check we verify that the system has a specific version (which might
succeed), but if we don't pick a specific dotnet version in global.json,
dotnet will pick the latest version, which may behave differently than the one
we have in Make.config.
Thus always use the exact same version, so that we don't run into a difference
in behavior between developers and/or bots.
The upload of the results takes 2 hours:
* 1 hour uploading to vsts test results.
* 1 hour uploading to vsdrops.
This means that we are blocking a device bot for an extra hours (since
the vsdrops is done in a windows bot) when it is not needed. We could
add both uploads to the vsdrops job, but since steps cannot be ran in
parallel, it means that we re waiting for 2 hours when we really do not
have to.
We create two jobs to parallelize the upload of files and we release the
device bot ASAP. That means that our device bots can be free to get new
jobs (and they are the bottle neck) while the windows bots perform the
different uploads.
To make things easier a template that downloads the artifacts was added
so that there is not much code repetition.
Add a GatherFrameworksStep that computes the frameworks an app needs, and
returns the result to the MSBuild tasks.
Then we use that list of frameworks to link the native executable correctly.
Add a commit message with a pointer to the maccore hash that GitHub renders as
a link when publishing an mlaunch binary to the macios-binaries repository.
This will hopefully make it _slightly_ easier to review since verifying the
maccore hash is now just a click away.
* add error handling for storage path
* Revert "add error handling for storage path"
This reverts commit 751e54c254.
* revert whitespace changes, only add real change
* small fixes
Use both in those labs that support xamarin-storage so that we have a
backup. To do so, move the parameter to be a bool but keep the rest of
the logic the same.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
With this PR a very basic sample app will build and launch successfully in the simulator.
This PR is best reviewed commit-by-commit; each change is explained by its commit message.
* [linker] Fix infinite queue found with nullability PR (#8337)
and removed previous workaround
Replace previous attempt https://github.com/xamarin/xamarin-macios/pull/8336
* [linker] Remove code to deal with ExportedTypes (#8632)
This is now supported by upstream mono/linker
* [linker] Remove internal [NullablePublicOnly] attribute from apps (#8568)
I've only seen it with .net5 so far but it's better handled in master
and flow back into the branch
* [linker] Update custom attributes that can be removed (#8535)
Some are no longer part of the SDK (or converted into new ones
at build time), others were new (and missing).
A full list of attributes and their usage frequency in what we ship can
be seen in https://gist.github.com/spouliot/ca03c6da7d4d75670ca77749350eb8a2
Also update tests: no need to check for removals of stuff that does not
exists anymore.
Co-authored-by: Sebastien Pouliot <sebastien.pouliot@gmail.com>
Try to create the folder in xamarin-storage, if that fails, rather than
stop with an error, execute the tests and st an env var.
Once the tests are complete, when adding the summaries, check if we did
fail to reach xamarin-storage and notify it.
This will make sure that tests won't fail if:
* xamarin-storage dies.
* bots are not in the vpn and could not reach xamarin-storage.
This commit moves all the different pipelines we have to fully use yaml.
That includes the old ddfun pipeline that was using a mix between using
yaml and the UI interface to configure it.
The new pipelines are found under the tools/devops/device-tests
directory. All of the use a very similar structure and therefore we use
a template. The README.md inside the directory should explain most of
the logic and the devices-tests.yml contains comments for each of the
steps.
Most of the bash scripts have been moved to use pwsh which is inside the
scripts directory and contains tests. Tests can be ran via:
```bash
make -C tools/devops/device-tests/scripts run-tests
```
This commit will only affect the ddfun pipeline that will need to be
updated to use the new yml path. All the other pipelines are not
affected and they will be to be updated manually.
The pipelines support two different storages for the html report.
* xamarin-storage: Old school.
* vsdrops: New age.
Unfortunatly we yet do not know how to workaround the fact that vsdrops
does not serve the files, therefore we use the xamarin-storage in all
pipelines but those in the ddfun lab because they do not have the right
access.
This later can be easily changed editing the
tools/devops/device-tests/tempaltes/cambridge-variables.yml which will
update all the pipelines in the cambridge lab.
PS: Sorry for the size.
The GenerateMain step needs to return the generated filename to the MSBuild targets, and it does so by writing out MSBuild xml which is then loaded into the MSBuild logic.
This also requires adding support for the ErrorHandler machinery, which the
MachO.cs file needs.
I considered extracting the Abi enum from the MachO.cs file, but it's used in
several places (including externally, such as binding-tools-for-swift), which
means this would be a rather disruptive change.
I also considered modifying MachO.cs to make it possible to build without the
ErrorHandler machinery, but since we'll need it all anyway eventually, I
decided against this option as well.
* Create a simple Xamarin.Utils.Execution class that can handle all our
process execution needs:
* Captures or streams stdout/stderr (in UTF8).
* Supports async
* Supports a timeout
* Does not depend on any other source file we have, only uses BCL API.
* Have the execution helper classes from mtouch/mmp
(Xamarin.BundlerDriver.RunCommand) and the tests
(Xamarin.Tests.ExecutionHelper) use this new class.
* Some simplifications were made:
* All API that took a string array for the environment now takes a
Dictionary<string, string>.
* The Driver.RunCommand methods were split out to a separate file. This
file also contains a Verbosity field, which is conditioned on not being
in mtouch nor mmp, which makes including this file from other projects
simpler (such as bgen - in particular bgen was modified to use this
Verbosity field instead of its own).
* Fix links that point to master to point to main instead.
* Implement support in the sample tester for specifying the default branch for
each sample repo.
* Fix various text / documentation to say 'main' instead of 'master.'
* Push to 'main' instead of 'master' in xamarin-macios-data.
* Fix xharness to make 'main' the special branch with regards to documentation tests as opposed to 'master'.
* Fix various CI to use 'main' instead of 'master'.
* Bump maccore
New commits in xamarin/maccore:
* xamarin/maccore@ed6d146822 Rename 'master' to 'main'. (#2233)
Diff: 424fa26148..ed6d146822
* [dotnet] Ship libxamarin.dylib and friends.
Add libxamarin[-debug].[a|dylib] to the NuGets.
* [dotnet] Create a DOTNET_PLATFORMS variable in Make.config.
Create a DOTNET_PLATFORMS variable in Make.config and use it everywhere
instead of the PLATFORMS variable we were defining in multiple Makefiles.
Also move the creation of the DOTNET_<platform>_RUNTIME_IDENTIFIERS variables
from dotnet/Makefile to Make.config, it'll soon be needed elsewhere as well.
* [runtime] Conditionally include bits.
* Make the contents of the DOTNET_[PLATFORMS|RUNTIME_IDENTIFIERS] variables depend on the INCLUDE_[IOS|TVOS|WATCH] variables.
The C# range expression is somewhat confusing: the lower bound is inclusive,
but the upper bound is exclusive. This means that [0..15] is 15 characters,
not the 16 characters we want here.
Fixes this during API comparison:
System.ArgumentException: Byte array for GUID must be exactly 16 bytes long.
Parameter name: b
at System.Guid..ctor (System.ReadOnlySpan`1[T] b) [0x00111] in /Users/builder/jenkins/workspace/build-package-osx-mono/2020-02/external/bockbuild/builds/mono-x64/external/corefx/src/Common/src/CoreLib/System/Guid.cs:66
at System.Guid..ctor (System.Byte[] b) [0x00000] in /Users/builder/jenkins/workspace/build-package-osx-mono/2020-02/external/bockbuild/builds/mono-x64/external/corefx/src/Common/src/CoreLib/System/Guid.cs:45
at Merger.Process (System.String platform, System.String path, System.String os) [0x001d1] in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/tools/apidiff/merger.cs:60
at Merger.Main (System.String[] args) [0x00002] in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/tools/apidiff/merger.cs:94
make[2]: *** [tvos-markdown] Error 1
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
The C# range expression is somewhat confusing: the lower bound is inclusive,
but the upper bound is exclusive. This means that [0..15] is 15 characters,
not the 16 characters we want here.
Fixes this during API comparison:
System.ArgumentException: Byte array for GUID must be exactly 16 bytes long.
Parameter name: b
at System.Guid..ctor (System.ReadOnlySpan`1[T] b) [0x00111] in /Users/builder/jenkins/workspace/build-package-osx-mono/2020-02/external/bockbuild/builds/mono-x64/external/corefx/src/Common/src/CoreLib/System/Guid.cs:66
at System.Guid..ctor (System.Byte[] b) [0x00000] in /Users/builder/jenkins/workspace/build-package-osx-mono/2020-02/external/bockbuild/builds/mono-x64/external/corefx/src/Common/src/CoreLib/System/Guid.cs:45
at Merger.Process (System.String platform, System.String path, System.String os) [0x001d1] in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/tools/apidiff/merger.cs:60
at Merger.Main (System.String[] args) [0x00002] in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/tools/apidiff/merger.cs:94
make[2]: *** [tvos-markdown] Error 1
Solves build errors like this:
xamarin-macios/tools/dotnet-linker/packages/xlifftasks/1.0.0-beta.20154.1/build/XliffTasks.targets(91,5): error : 'Errors.cs.xlf' is out-of-date with 'Errors.resx'. Run `msbuild /t:UpdateXlf` to update .xlf files or set UpdateXlfOnBuild=true to update them on every build, but note that it is strongly discouraged to set UpdateXlfOnBuild=true in official/CI build environments as they should not modify source code during the build.
See also: https://github.com/xamarin/xamarin-macios/pull/8157
Add support for passing configuration from the MSBuild targets to our linker
steps using the linker's --custom-data option.
There are just two values being passed now, but this will grow significantly
over time as linker steps are implemented.
Note: affected tools are not included in the code shipping inside the SDK
Usage of deprecated cryptographic algorithms is not approved anymore,
even if not used for cryptographic purpose.
MD5 was used to create immutable GUID since it's output is 128bits which
is just what a GUID wants as it's input (16 bytes). The same can be
achieved (even if a bit slower) with a newer/longer hash function
https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1128148
Note: affected tools are not included in the code shipping inside the SDK
Usage of deprecated cryptographic algorithms is not approved anymore,
even if not used for cryptographic purpose.
MD5 was used to create immutable GUID since it's output is 128bits which
is just what a GUID wants as it's input (16 bytes). The same can be
achieved (even if a bit slower) with a newer/longer hash function
https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1128148
Fixes this:
Process exited with code 1, command:
/Users/builder/jenkins/workspace/xamarin-macios-pr-builder/tools/xibuild/xibuild System.Collections.Generic.List`1[System.String]
* Use our shared *.csproj.inc target in mk/rules.mk.
* Include the *.csproj.inc target before the variable within is needed. That
way the variable is what we need it to be (the list of dependencies for the
assembly we want to build) when we reference it.
Fixes: https://github.com/xamarin/xamarin-macios/issues/8468
Added missing `<comment/>` fields for:
* BI1033
* BI1077
* MM2007
* MT0073
* MT0074
* MT0112_c
* MT0113_i
* MT4146
* MT4162
I had to split up the `MT4162` error message, introducing:
* `Errors.MT4162_BaseType` - a base type of
* `Errors.MT4162_Parameter` - a parameter in
* `Errors.MT4162_ReturnType` - a return type in
* `Errors.MT4162_PropertyType` - the property type of
This also removed an argument passed into `string.Format`.
* Add support for using dotnet instead of msbuild to build the target project.
* cd into the target project's directory before building it, because there may
be a global.json file there which must be taken into account.
* page through github statuses for manifest URL
* Check to see if the content has values (rather than being the empty string)
* Fix code style.
Co-authored-by: cadsit <connor.adsit@gmail.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
* [mtouch/mmp] Share Application.IsDualBuild, Is32Build and Is64Build.
* [mtouch/mmp] Share --tls-provider and --http-message-handler.
* [mtouch/mmp] Share --force.
* [mtouch/mmp] Share --cache.
* [mtouch/mmp] Share --nolink, --linksdkonly, --linkplatform and --linkskip.
* [mtouch/mmp] Share --i18n.
* [mtouch/mmp] Share --xml.
* [mtouch/mmp] Share --registrar and --runregistrar.
* [mtouch/mmp] Share --warn-on-type-ref.
* [mtouch/mmp] Share --sdk.
* [mtouch/mmp] Share --debug.
* [mtouch/mmp] Share --reference, and deprecate -r|--ref and -a|--assembly.
* [mtouch/mmp] Share --targetver, and deprecate mmp's --minos.
* [msbuild] Adjust tests after switching to use --reference instead of -r.
* Update according to review.
* [mmp] Remove --registrar:il.
The IL generator was what MonoMac had before the dynamic/static registrar code
got shared between MonoTouch and MonoMac. The IL registrar been gone for
years, and as far as I know nobody ever used --registrar:il, even though it
was provided as a compatibility option in the beginning (we still had the IL
registrar around for a while after adding the static+dynamic registrars, until
it was completely replaced by the dynamic registrar).
So just remove this option, if anyone ever used it they can replace it with
--registrar:dynamic.
* [mtouch/mmp] Keep bundler-specific code in its corresponding file.
* Move much of ErrorHandler.cs into a partial class in ErrorHandler.tools.cs,
which is referenced by mtouch and mmp (but not our runtime).
* Add ErrorHandler.runtime.cs for runtime-specific bits, including a simpler
version of ErrorHandler.Show. In particular this gets rid of the call to
Environment.Exit, which should never happen at runtime.
* Rename MonoTouchException and MonoMacException to ProductException, which
allows us to remove a lot of ifdefs.
* This required moving Application.LoadSymbols and Target.LoadSymbols to
shared mtouch/mmp code.
also add a note that it's not optimal, as-is, if "Link All" is used since
it's too early to make a decision on overrides from user code, they could
be removed later (e.g. if the type is unused in the app).
* [mmp] Put the custom bundle name in the App instance.
* [mmp] Put the AOT options in the App instance.
* [mmp] Put the DisableLldbAttach and DisableOmitFramePointer options in the App instance.
* [mmp] Remove Driver.Registrar and use App.Registrar instead.
This fixes this mtouch unit test:
Xamarin.MTouch.Architectures_TVOS_Invalid : The error 'MT0075' was not found in the output.
because now we show MT0075 ("Invalid architecture 'ARMv7' for TVOS projects.")
as expected instead of failing to locate the 32-bit platform directory for
tvOS (which doesn't exist).
Fixes https://github.com/xamarin/maccore/issues/2222.
Move to use the provisionator and add a make file to generat the script
so that we only have to bump xcode in a single place.
Move all deps to provisionator and make provisionator download and
install the xi pkg that has been built to be tested in the pipeline, we
do not longer use curl to do it.
* Files outside the project directory now show up with a much more logical
name in the IDE. External files have a link target which is relative to the
root xamarin-macios directory, and files included from the mono archive show
up as such as well.
* Rename a few mtouch/mmp-specific files to contain 'mtouch' or 'mmp' in the
filename, to avoid having multiple files in the projects with the same name
(it's confusing every time you search for a filename in the IDE and get
multiple filenames where only the directory is different).
* Add a tools.sln that contains only the mtouch and mmp projects. This makes
it easier to work with both mtouch and mmp and the same time, while not
making VSfM unbearably slow by loading many projects in the same solution.
otherwise debug won't work and you'll get a weird error
```
Using Xcode 11.4 (11E146) found in /Applications/Xcode114.app/Contents/Developer
Xamarin.iOS 13.21.0.154 (master): 296eabd9a using framework: /Applications/Xcode114.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.4.sdk
A full rebuild will be performed because the cache is either incomplete or entirely missing.
A full rebuild has been forced because the cache for linker is not valid.
error MT2006: Can not load mscorlib.dll from: '/Users/poupou/git/master/xamarin-macios/tools/mtouch/lib/mono/Xamarin.iOS/mscorlib.dll'. Please reinstall Xamarin.iOS.
at Xamarin.Bundler.Target.Initialize (System.Boolean show_warnings) [0x0002c] in /Users/poupou/git/master/xamarin-macios/tools/mtouch/Target.cs:275
at Xamarin.Bundler.Application.Initialize () [0x007c2] in /Users/poupou/git/master/xamarin-macios/tools/mtouch/Application.cs:1104
at Xamarin.Bundler.Application.BuildInitialize () [0x00008] in /Users/poupou/git/master/xamarin-macios/tools/mtouch/Application.cs:684
at Xamarin.Bundler.Application+<>c.<BuildAll>b__135_0 (Xamarin.Bundler.Application v) [0x00000] in /Users/poupou/git/master/xamarin-macios/tools/mtouch/Application.cs:638
at System.Collections.Generic.List`1[T].ForEach (System.Action`1[T] action) [0x0001e] in /Users/builder/jenkins/workspace/build-package-osx-mono/2020-02/external/bockbuild/builds/mono-x64/external/corefx/src/Common/src/CoreLib/System/Collections/Generic/List.cs:578
at Xamarin.Bundler.Application.BuildAll () [0x00023] in /Users/poupou/git/master/xamarin-macios/tools/mtouch/Application.cs:638
at Xamarin.Bundler.Driver.Main2 (System.String[] args) [0x0041c] in /Users/poupou/git/master/xamarin-macios/tools/mtouch/mtouch.cs:1154
at Xamarin.Bundler.Driver.Main (System.String[] args) [0x00015] in /Users/poupou/git/master/xamarin-macios/tools/common/Driver.cs:35
```
That's in /Library/Frameworks/Xamarin.Mac.framework/Versions/Current/SDKs/Xamarin.macOS.sdk/[lib|include]
This allows for a bit more code share between mtouch and mmp.
[linker] Don't pass information to linker steps by selectively creating them or using constructors.
Instead use the built-in logic to determine if a linker step should light up,
and use information available in the LinkContext to determine how steps should
behave.
This is required for .NET, where linker steps can't have custom constructors.
Several steps have not been modified, because they're not all required in .NET.
Some are no longer part of the SDK (or converted into new ones
at build time), others were new (and missing).
A full list of attributes and their usage frequency in what we ship can
be seen in https://gist.github.com/spouliot/ca03c6da7d4d75670ca77749350eb8a2
Also update tests: no need to check for removals of stuff that does not
exists anymore.
Always add `libmono-profiler-log.dylib` if profiling is enabled and we
are building with dynamic libraries. The profiler code is not (meant to
be) shipped so it can be added even without a `Frameworks` directory.
This fix debugging too (if profiler is enabled) since the library was
linked (even if it was not included).
Fix https://github.com/xamarin/xamarin-macios/issues/8470
Co-authored-by: Sebastien Pouliot <sebastien.pouliot@microsoft.com>
The fact that the mobile profile allows linking doesn't mean it should be done
(it doesn't actually link because we run the registrar before linking happens,
but this way the code is less confusing and there are no unnecessary
differences between full and mobile).
`monotouch-glue.m` was replaced a while ago and the new code does not
need `Class.LookupFullName` to be preserved in debug builds.
Also `PreserveType` was unused code (left from even older times?)
Always add `libmono-profiler-log.dylib` if profiling is enabled and we
are building with dynamic libraries. The profiler code is not (meant to
be) shipped so it can be added even without a `Frameworks` directory.
This fix debugging too (if profiler is enabled) since the library was
linked (even if it was not included).
Fix https://github.com/xamarin/xamarin-macios/issues/8470
The native methods xamarin_get_[generic_]method_from_token are a bit unusual
in that they return an actual GCHandle. This is for performance reasons, since
in some cases their return value is passed as parameters to other function
calls to managed code, in which case we need the GCHandle. This way we avoid
round-tripping a GCHandle multiple times.
The previous pattern would match the output files we created from processing
these directories, and somehow the pattern would match such a file (even
though the pattern should only be executed before doing any processing, when
those files don't exist yet, so I don't know exactly why this is happening),
leading us to try to process those files as if they were directories with
sample data in, with the predictable (disastrous) result.
Fixes https://github.com/xamarin/maccore/issues/2202.
The previous pattern would match the output files we created from processing
these directories, and somehow the pattern would match such a file (even
though the pattern should only be executed before doing any processing, when
those files don't exist yet, so I don't know exactly why this is happening),
leading us to try to process those files as if they were directories with
sample data in, with the predictable (disastrous) result.
Fixes https://github.com/xamarin/maccore/issues/2202.
xamarin-storage can not be reachable or a network issue might happen
when we try to provision the dependencies. In that case, skip those
tasks that are skipped when we cannot provision the certs.
The provisioning dependencies will only execute in the provisioning
profiles was successful, therefore, the if statement is not stepping in
any value that was set by the profiles step.
Add timeouts to the steps to catch possible issues when a step takes
longer than expected. Numbers have been taken from common runs and
rounded up a little to have some buffer.
Not an experiment anymore - it works as expected.
This half-remove the optimization option (it must remain there to avoid
breaking all projects that have it defined) but it will always be `true`
so `Xamarin.Forms.Platform.iOS.dll` will **always** be considered as SDK
code by the linker.
Fix https://github.com/xamarin/xamarin-macios/issues/8407
Not an experiment anymore - it works as expected.
This half-remove the optimization option (it must remain there to avoid
breaking all projects that have it defined) but it will always be `true`
so `Xamarin.Forms.Platform.iOS.dll` will **always** be considered as SDK
code by the linker.
Fix https://github.com/xamarin/xamarin-macios/issues/8407
* Rearrange files in Xamarin.Mac a bit to ease code sharing between mmp and
mtouch, by putting mono's static and dynamic libraries in
/Library/Frameworks/Xamarin.Mac.framework/Versions/Current/Sdks/Xamarin.macOS.sdk
to match how Xamarin.iOS does it.
* Don't use 'usr' as an intermediate directory. This removes another special
case.
* Share many of the functions and properties that return specific directories,
and document (as comments) what each function/property is supposed to
return.
* [mtouch] Handle a failure to launch the native linker better by showing better error messages.
dotnet will throw a Win32Exception if the command line is too long, so handle
that scenario. Also handle any other Win32Exceptions and show a better error
message.
* Make MT5217 an error to avoid multiple potentially confusing errors.
Cecil has a fall-back mode where it looks in the GAC / system mono for
assemblies when failing to find them elsewhere. This is not the expected
behavior when using Xamarin.Mac in the Full/XM mode, because then we should
only resolve to assemblies shipped with Xamarin.Mac.
Unfortunately doing so will break apps (our own tests break), so instead
change our resolution to be explicit about where we find assemblies, and if we
find assemblies in the GAC / system mono when we're not supposed to, then show
a warning.
Also add a fall-back mechanism, where we use the old logic instead, in case
the new logic is not 100% compatible with the old one.
This showed up when I tried to port mmp to dotnet, because then Cecil stopped
looking in the GAC / system mono for assemblies (Cecil has a special case when
running on Mono to look in Mono's GAC), and tests started failing.
Goals
* Reflect Apple nullability annotations in our bindings using C#8
* No warnings when building bindings
Non-Goals
* Update (add or fix) `[NullAllowed]` to match Apple headers (next phase)
* Make the generator or internal code fully nullable aware (`nowarn` is used)
Notes
* Apple's own annotations are not 100% accurate :(
* Where known issue exists we have _fixed_ our attributes to match reality :)
* We also do additional null-checks internally that might seems not required (better safe than sorry).
Goals
* Reflect Apple nullability annotations in our bindings using C#8
* No warnings when building bindings
Non-Goals
* Update (add or fix) `[NullAllowed]` to match Apple headers (next phase)
* Make the generator or internal code fully nullable aware (`nowarn` is used)
Notes
* Apple's own annotations are not 100% accurate :(
* Where known issue exists we have _fixed_ our attributes to match reality :)
* We also do additional null-checks internally that might seems not required (better safe than sorry).
The generator project file still needs some custom logic, because we can't put
the generated makefile fragment next to the csproj (that would break the
API/generator diff).
We're using the Release configuration to build the mtouch and mmp binaries
that we ship, which means that we can use the Debug configuration for
debugging from an IDE, and use the standard conditional compilation symbols to
identify that case.
There is a difference between mono and .netcore with regards to environment
variables when launching processes.
For the following example:
process.StartInfo.EnvironmentVariables ["FOO"] = null;
.netcore will launch the process with an empty FOO variable, while mono will
launch the process with no FOO variable set.
So unstead remove the variable from the collection of environment variables
(this works fine even if the collection doesn't contain the variable).
Ref: https://github.com/dotnet/runtime/issues/34446
In cases where a `Make.config` doesn't exist, there's an unhandled exception and the user friendly one cannot be reached.
Arguably, an edge case not applicable to xamarin-macios I discovered when using that code in an other context (where obviously I don't have a Make.config :P). Still this is making the code more robust (;
Rolf Bjarne Kvinge
Sebastien Pouliot
Whitney Schmidt
Alex Soto
Manuel de la Pena
Whitney Schmidt
Chris Hamons
monojenkins
Jonathan Peppers
Connor Adsit
Sebastien Pouliot
Vincent Dondain