* 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.
* [jenkins] Hide the list of packages by default.
The list of packages got big with the NuGet packages, and we usually don't
want to see the whole thing, so hide it by default.
* Add newline to fix markdown parsing.
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.
Create the various NuGet packages to support .NET 5+. The packages are
currently empty (and not very useful), but the actual content will come later.
The current set of NuGet packages are (this list is duplicated for each
platform: iOS, tvOS, watchOS and macOS):
* Microsoft.iOS.Sdk: currently contains the basic MSBuild targets files for an
MSBuild Project SDK. Will eventually contain all the build logic. Might also
eventually contain other tools (mlaunch, bgen, etc.), but these might also
end up in a different package.
* Microsoft.iOS.Ref: will contain the Xamarin.iOS.dll reference assembly.
* Microsoft.iOS.Runtime.[RID]: will contain architecture-specific files
(libxamarin*.dylib, the Xamarin.iOS.dll implementation assembly, etc.):
The NuGets built on CI are automatically published to a NuGet feed.
The versioning for the NuGet packages required a few changes: OS bumps are now
changed in Make.versions instead of Make.config (this is explained in the
files themselves as well).
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.
* [system-dependencies] Add support for provisioning .NET 5 separately.
Add support for provisioning .NET 5 separately, and by default install it
locally (into builds/downloads) to avoid consuming a lot of disk space with
the various preview versions we'll need. A system install is still detected
and used if available.
* Use full path to the dotnet binary, since it might not be in PATH.
* [jenkins] Clean first, then provision.
Otherwise we'll clean whatever we provision locally.
Once upon a time the Delete task was sealed [1], so we couldn't subclass it as
we wanted. That time is long in the past, so we can now do what we wanted back
then.
[1]: 5c49171303
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.
In make 4.3 the pattern `.libs/watchos/%.arm64_32.dylib` in mk/rules.mk takes
precedence over the pattern `.libs/watchos/libtest.%.dylib` in
tests/test-libraries/Makefile when the pattern replacements are 'libtest' and
'arm64_32' respectively, because the former is shorter.
This seems to be a bug (in make 3.81) that has been fixed, because that's the
documented behavior.
Rewrite the logic to not use a pattern target in test/test-libraries/Makefile.
* 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
```
This makes it possible to select what should be done on CI when building a
commit on internal Jenkins (as opposed to when building a pull request, in
which case labels can be set on the pull request).
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.
The GetReader from the install log is broken and requires a re-eng.
Rollback to using the fullpath, not as nice, but that way we do not have
exceptions.
We are using issue #8545 to track the actual bug in the logs when we
request a Reader, if the reader cannot be created we should not be
throwing an exception, whats more, that reader should not be null since
otherwise we would not get the install logs.
* [Foundation] Do not get in an infinite loop with empty creds.
As decribed in the issue, when the credentials for the base auth are set
to be empty the request reaches a timeout.
The inner issue is that when we have empty credentials the query that
is performed to the credentials db of the system throws an exception.
This exception is not raised to our code, but simply prints out in stderr.
When this situation occurs we get in an infinite loop in which we keep
sending the same credentials, we get another challenge, but the OS does
not do the right thing, we believe that we have to provide the creds
again (which are the same) and we get another challenge.. this goes on
an on until we reach the timeout.
Fortunately we know the number of failed challenges and the failure
response. With this information we can deduce if we already sent the
credentials, and if we did, do not set them again. In this case, the OS
sees no credentials in out delegate, uses the default handler and
correctly returns a 401.
fixes: https://github.com/xamarin/xamarin-macios/issues/8342
fixes: https://github.com/xamarin/xamarin-macios/issues/8344
Fixes: https://github.com/xamarin/xamarin-macios/issues/8265
Usage of `System.Drawing` types in iOS binding projects are failing with:
error CS1069: The type name 'Color' could not be found in the namespace 'System.Drawing'.
This type has been forwarded to assembly 'System.Drawing.Common, Version=4.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'
Consider adding a reference to that assembly.
In 3a7bdc0, an `_AddExtraReferences` MSBuild target was added for iOS
and Mac projects, but mistakenly missing from binding projects.
I moved the `_AddExtraReferences` target to `Xamarin.Shared.targets`,
so it will be used for all project types.
I also updated a test, I could merely use `System.Drawing.Color` in
`StructsAndEnums.cs` to reproduce the failure.
[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.
Rolf Bjarne Kvinge
Sebastien Pouliot
Connor Adsit
Manuel de la Pena
Alex Soto
Daniel Cazzulino
Jonathan Peppers