In .NET there's no mscorlib.dll next to the platform assembly. bgen will find it
anyway when needed if it's not passed explicitly, so just don't pass it.
Use two separate output variables (EntitlementsInExecutable/EntitlementsInSignature)
instead of using the same output variable for two different purposes. This makes
the code more self-explanatory.
Also move the simulator check to the C# code, that way it's easier to re-use elsewhere.
* [msbuild] Share the _CompileEntitlements task.
* [msbuild] Create the same class hierarchy for Xamarin.Mac and Xamarin.iOS for the CompileEntitlements task.
CompileEntitlementsTaskBase
└─── iOS/CompileEntitlementsTaskCore
│ └─── iOS/CompileEntitlements
└─── Mac/CompileEntitlementsTaskCore
└─── Mac/CompileEntitlements
This also means we can remove a known failure in the list of MSBuild tasks that don't
conform to our 'no code in final task implementation' requirements.
If the path to the project or compiled app has spaces, then the URI
that is generated for the on-demand resources in the
AssetPackManifestTemplate.plist file is invalid
Fixes https://github.com/xamarin/xamarin-macios/issues/8452
Co-authored-by: Matthew Leibowitz <mattleibow@live.com>
Fixes numerous build failures like this:
The type or namespace name 'NUnit' could not be found (are you missing a using directive or an assembly reference?)
The type or namespace name 'NUnit' could not be found (are you missing a using directive or an assembly reference?)
The type or namespace name 'NUnit' could not be found (are you missing a using directive or an assembly reference?)
The type or namespace name 'TestFixtureAttribute' could not be found (are you missing a using directive or an assembly reference?)
The type or namespace name 'TestFixtureAttribute' could not be found (are you missing a using directive or an assembly reference?)
The filename arguments to the error logging must be strings, otherwise the
wrong logging overload is picked, and the resulting error message makes no
sense.
It's somewhat of a breaking change, since previously Xamarin.Mac would default
to 'false' if no value was set. It should be exceedingly rare though, since
it's set in all the template projects.
It makes the behavior a bit more intuitive for .NET projects, since then the
values might not be set because of the simplified project files.
If the path to the project or compiled app has spaces, then the URI
that is generated for the on-demand resources in the
AssetPackManifestTemplate.plist file is invalid
Fixes https://github.com/xamarin/xamarin-macios/issues/8452
Co-authored-by: Matthew Leibowitz <mattleibow@live.com>
If the path to the project or compiled app has spaces, then the URI
that is generated for the on-demand resources in the
AssetPackManifestTemplate.plist file is invalid
Fixes https://github.com/xamarin/xamarin-macios/issues/8452
We're starting to use NuGet (packages) more and more, and NuGet stores
information about any package references in the bin/obj directories. This
means that if a directory has multiple project files, NuGet will get quite
confused because it will use the wrong package information half the time.
There are steps that can be taken to make NuGet write its package information
in different directories, but this becomes quite cumbersome to keep
up-to-date, and it's confusing when it breaks. It's much easier to just have a
blanket rule that there shouldn't be more than one project per directory.
However, it did require quite a few changes to xharness to fix assumptions
about where files are located.
- This commit adds a hook, "AdditionalAppExtensions", to the msbuild to allow
extensions written in other languages, such as Swift, to be embedded and signed in an
Xamarin App bundle easily.
- Example:
<AdditionalAppExtensions Include="$(MSBuildProjectDirectory)/../../native">
<Name>NativeTodayExtension</Name>
<BuildOutput Condition="'$(Platform)' == 'iPhone'">build/Debug-iphoneos</BuildOutput>
<BuildOutput Condition="'$(Platform)' == 'iPhoneSimulator'">build/Debug-iphonesimulator</BuildOutput>
</AdditionalAppExtensions>
Fixes https://developercommunity.visualstudio.com/content/problem/934833/xamarinforms-cant-create-archive-for-ios.html
Depending on the default language of the running OS this could cause translating AM/PM to symbols that are not supported on folder names on Windows.
For instance, the value of `timestamp` without this change for an user that sets Chinese as it's main language would be `8-18-15 1.31 下午`, where `下午` represent PM.
Co-authored-by: emaf <ema@xamarin.com>
In addition to the obvious benefit of reducing code duplication, this also
means that implicit inclusion of netstandard.dll works for binding projects as
well.
The existing implementations were slightly different between Xamarin.iOS and
Xamarin.Mac, so I tried to figure out the best merging strategy based on git
history and looking at the original implementation of this code in MSBuild. I
tried to keep close to the original implementation whenever I couldn't find a
good reason to do otherwise.
`GetMinimumOSVersion` should not be run if there's no Mac available because it depends on `_DetectSdkLocations` to calculate the value of `_SdkVersion`, and this will only happen if there's a Mac connected. This change fixes offline builds (plain IL builds) and Hot Restart builds on Windows.
Co-authored-by: emaf <ema@xamarin.com>
`GetMinimumOSVersion` should not be run if there's no Mac available because it depends on `_DetectSdkLocations` to calculate the value of `_SdkVersion`, and this will only happen if there's a Mac connected. This change fixes offline builds (plain IL builds) and Hot Restart builds on Windows.
* [msbuild] Changes GetMinimumOSVersionTaskBase to use ITaskItem for inputs
From Visual Studio we need the input files to be instead of plain strings to identify the files that need to be copied to the Mac
* Adds null check for AppManifest in GetMinimumOSVersionTaskBase
Co-authored-by: emaf <ema@xamarin.com>
* [msbuild] Changes GetMinimumOSVersionTaskBase to use ITaskItem for inputs
From Visual Studio we need the input files to be instead of plain strings to identify the files that need to be copied to the Mac
* Adds null check for AppManifest in GetMinimumOSVersionTaskBase
- This commit adds a hook, "AdditionalAppExtensions", to the msbuild to allow
extensions written in other languages, such as Swift, to be embedded and signed in an
Xamarin App bundle easily.
- Example:
<AdditionalAppExtensions Include="$(MSBuildProjectDirectory)/../../native">
<Name>NativeTodayExtension</Name>
<BuildOutput Condition="'$(Platform)' == 'iPhone'">build/Debug-iphoneos</BuildOutput>
<BuildOutput Condition="'$(Platform)' == 'iPhoneSimulator'">build/Debug-iphonesimulator</BuildOutput>
</AdditionalAppExtensions>
If the Execute method of a task is sealed the Windows side tasks won't be able to "inject" the code that executes the tasks remotely.
Co-authored-by: emaf <ema@xamarin.com>
* Change the parsing code slightly, to make it easier to parse other arguments
(coming soon).
* Add the parsing task to Xamarin.Mac projects, and use it there as well. The
parsed result isn't used yet, but it will be soon.
* Unify a few related MSBuild properties (MtouchNoSymbolStrip and
MtouchNoDSymUtil).
Some of these have been duplicated across various targets files, and when
adding a new task it's annoying to forget to add it somewhere.
So just have them all in the same place, so that they're loaded in every file.
There are still duplicates between the iOS and Mac tasks, but those will be
unified in a later PR.
Also switch to invoking bgen instead of the btouch-native/btv/bwatch wrapper
scripts, since the wrapper scripts just call bgen with an additional
--target-framework argument, which our BTouch task already does anyway, which
means it's not necessary to call the wrapper scripts anymore.
This also required:
* Moving the code to detect which Xamarin.Mac profile we're building for into
Xamarin.Shared.props, since the binding variable logic need to know which
Xamarin.Mac profile we're building for.
* Setting IsBindingProject property earlier in the build process, to make sure
it's set before importing Xamarin.Shared.props.
* For Xamarin.Mac, this means using the _ComputeBundleResourceOutputPaths and
_CopyResourcesToBundle targets from Xamarin.iOS instead of the
_CopyContentToBundle target (which is now unused and thus removed).
* Adapt the Xamarin.iOS logic (now shared) to handle the fact that the
resources shouldn't always go into the root appbundle directory (since they
go into Contents/Resources/ for macOS apps), by using the
'_AppResourcesPath' variable to specify just this.
Once upon a time the Xamarin.iOS logic was identical to the Xamarin.Mac logic,
but then we implemented support for asset packs
(a98693f07e)
and the code diverged. This means that unifying the logic again is a step
towards making asset packs work for Xamarin.Mac apps.
* [msbuild] Share the MSBuild logic for CollectBundleResources and a few related properties.
* [msbuild] Fix/unify more resource collection code.
* Remove the _CollectBundleResources target for Xamarin.iOS binding projects,
we now have a single one for all project types.
* Add an IsBindingProject property to distinguish binding projects from other
projects.
* Use the IsBindingProject to only depend on the other _Compile<ResourceType>
targets when we're not building a binding project (which seems to be the
reason why the _CollectBundleResources target was duplicated between normal
projects and binding projects for both Xamarin.iOS and Xamarin.Mac: the
binding project version didn't have any dependencies).
This is a slight performance improvements when loading the list of frameworks
the managed linker produces, because the MSBuild logic can only load one item
group per file, and if we use two differently named item groups, we'd have to
store weakly and normally linked frameworks in different files.
This way we can store both types of frameworks in a single file.
This will ensure the file isn't kept open until the GC runs, and then
sometimes it can prevent other tasks or targets from opening it if the GC
hasn't run.
Fixes this problem:
/Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(4203,5): warning MSB3026: Could not copy "obj/Debug/Fantas.dll" to "../../../lib/Debug/MonoGame/xamarinios/Fantas.dll". Beginning retry 1 in 1000ms. Sharing violation on path [...]/lib/Debug/MonoGame/xamarinios/Fantas.dll
/Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(4203,5): warning MSB3026: Could not copy "obj/Debug/Fantas.dll" to "../../../lib/Debug/MonoGame/xamarinios/Fantas.dll". Beginning retry 2 in 1000ms. Sharing violation on path [...]/lib/Debug/MonoGame/xamarinios/Fantas.dll
/Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(4203,5): warning MSB3026: Could not copy "obj/Debug/Fantas.dll" to "../../../lib/Debug/MonoGame/xamarinios/Fantas.dll". Beginning retry 3 in 1000ms. Sharing violation on path [...]/lib/Debug/MonoGame/xamarinios/Fantas.dll
/Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(4203,5): warning MSB3026: Could not copy "obj/Debug/Fantas.dll" to "../../../lib/Debug/MonoGame/xamarinios/Fantas.dll". Beginning retry 4 in 1000ms. Sharing violation on path [...]/lib/Debug/MonoGame/xamarinios/Fantas.dll
/Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(4203,5): warning MSB3026: Could not copy "obj/Debug/Fantas.dll" to "../../../lib/Debug/MonoGame/xamarinios/Fantas.dll". Beginning retry 5 in 1000ms. Sharing violation on path [...]/lib/Debug/MonoGame/xamarinios/Fantas.dll
/Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(4203,5): warning MSB3026: Could not copy "obj/Debug/Fantas.dll" to "../../../lib/Debug/MonoGame/xamarinios/Fantas.dll". Beginning retry 6 in 1000ms. Sharing violation on path [...]/lib/Debug/MonoGame/xamarinios/Fantas.dll
/Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(4203,5): warning MSB3026: Could not copy "obj/Debug/Fantas.dll" to "../../../lib/Debug/MonoGame/xamarinios/Fantas.dll". Beginning retry 7 in 1000ms. Sharing violation on path [...]/lib/Debug/MonoGame/xamarinios/Fantas.dll
/Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(4203,5): warning MSB3026: Could not copy "obj/Debug/Fantas.dll" to "../../../lib/Debug/MonoGame/xamarinios/Fantas.dll". Beginning retry 8 in 1000ms. Sharing violation on path [...]/lib/Debug/MonoGame/xamarinios/Fantas.dll
/Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(4203,5): warning MSB3026: Could not copy "obj/Debug/Fantas.dll" to "../../../lib/Debug/MonoGame/xamarinios/Fantas.dll". Beginning retry 9 in 1000ms. Sharing violation on path [...]/lib/Debug/MonoGame/xamarinios/Fantas.dll
/Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(4203,5): warning MSB3026: Could not copy "obj/Debug/Fantas.dll" to "../../../lib/Debug/MonoGame/xamarinios/Fantas.dll". Beginning retry 10 in 1000ms. Sharing violation on path [...]/lib/Debug/MonoGame/xamarinios/Fantas.dll
/Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(4203,5): error MSB3027: Could not copy "obj/Debug/Fantas.dll" to "../../../lib/Debug/MonoGame/xamarinios/Fantas.dll". Exceeded retry count of 10. Failed.
/Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(4203,5): error MSB3021: Unable to copy file "obj/Debug/Fantas.dll" to "../../../lib/Debug/MonoGame/xamarinios/Fantas.dll". Sharing violation on path [...]/lib/Debug/MonoGame/xamarinios/Fantas.dll
Fixes https://github.com/xamarin/maccore/issues/2137.
Fixes https://github.com/xamarin/xamarin-macios/issues/8940.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
This will ensure the file isn't kept open until the GC runs, and then
sometimes it can prevent other tasks or targets from opening it if the GC
hasn't run.
Fixes this problem:
/Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(4203,5): warning MSB3026: Could not copy "obj/Debug/Fantas.dll" to "../../../lib/Debug/MonoGame/xamarinios/Fantas.dll". Beginning retry 1 in 1000ms. Sharing violation on path [...]/lib/Debug/MonoGame/xamarinios/Fantas.dll
/Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(4203,5): warning MSB3026: Could not copy "obj/Debug/Fantas.dll" to "../../../lib/Debug/MonoGame/xamarinios/Fantas.dll". Beginning retry 2 in 1000ms. Sharing violation on path [...]/lib/Debug/MonoGame/xamarinios/Fantas.dll
/Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(4203,5): warning MSB3026: Could not copy "obj/Debug/Fantas.dll" to "../../../lib/Debug/MonoGame/xamarinios/Fantas.dll". Beginning retry 3 in 1000ms. Sharing violation on path [...]/lib/Debug/MonoGame/xamarinios/Fantas.dll
/Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(4203,5): warning MSB3026: Could not copy "obj/Debug/Fantas.dll" to "../../../lib/Debug/MonoGame/xamarinios/Fantas.dll". Beginning retry 4 in 1000ms. Sharing violation on path [...]/lib/Debug/MonoGame/xamarinios/Fantas.dll
/Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(4203,5): warning MSB3026: Could not copy "obj/Debug/Fantas.dll" to "../../../lib/Debug/MonoGame/xamarinios/Fantas.dll". Beginning retry 5 in 1000ms. Sharing violation on path [...]/lib/Debug/MonoGame/xamarinios/Fantas.dll
/Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(4203,5): warning MSB3026: Could not copy "obj/Debug/Fantas.dll" to "../../../lib/Debug/MonoGame/xamarinios/Fantas.dll". Beginning retry 6 in 1000ms. Sharing violation on path [...]/lib/Debug/MonoGame/xamarinios/Fantas.dll
/Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(4203,5): warning MSB3026: Could not copy "obj/Debug/Fantas.dll" to "../../../lib/Debug/MonoGame/xamarinios/Fantas.dll". Beginning retry 7 in 1000ms. Sharing violation on path [...]/lib/Debug/MonoGame/xamarinios/Fantas.dll
/Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(4203,5): warning MSB3026: Could not copy "obj/Debug/Fantas.dll" to "../../../lib/Debug/MonoGame/xamarinios/Fantas.dll". Beginning retry 8 in 1000ms. Sharing violation on path [...]/lib/Debug/MonoGame/xamarinios/Fantas.dll
/Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(4203,5): warning MSB3026: Could not copy "obj/Debug/Fantas.dll" to "../../../lib/Debug/MonoGame/xamarinios/Fantas.dll". Beginning retry 9 in 1000ms. Sharing violation on path [...]/lib/Debug/MonoGame/xamarinios/Fantas.dll
/Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(4203,5): warning MSB3026: Could not copy "obj/Debug/Fantas.dll" to "../../../lib/Debug/MonoGame/xamarinios/Fantas.dll". Beginning retry 10 in 1000ms. Sharing violation on path [...]/lib/Debug/MonoGame/xamarinios/Fantas.dll
/Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(4203,5): error MSB3027: Could not copy "obj/Debug/Fantas.dll" to "../../../lib/Debug/MonoGame/xamarinios/Fantas.dll". Exceeded retry count of 10. Failed.
/Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(4203,5): error MSB3021: Unable to copy file "obj/Debug/Fantas.dll" to "../../../lib/Debug/MonoGame/xamarinios/Fantas.dll". Sharing violation on path [...]/lib/Debug/MonoGame/xamarinios/Fantas.dll
Fixes https://github.com/xamarin/maccore/issues/2137.
Fixes https://github.com/xamarin/xamarin-macios/issues/8940.
Also rework the class hierarchy a little bit, so that Xamarin.iOS and
Xamarin.Mac are identical:
CompileAppManifestTaskBase
└─── iOS/CompileAppManifestTaskCore
│ └─── iOS/CompileAppManifest
└─── Mac/CompileAppManifestTaskCore
│ └─── Mac/CompileAppManifest
* 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).
This makes it possible for several other tasks to take the MinimumOSVersion as
direct input, instead of the app manifest's path. Previously the app manifest
(Info.plist) was loaded and parsed in each task, slightly differently in each
place, and in addition there are differences between macOS and other
platforms, which made it even worse. This code refactoring also made it
possible to remove an error code which wasn't necessary anymore.
This task also computes the default MinimumOSVersion if none is specified in
the app manifest.
There is one breaking change: a library project could previously specify an
inexistent Info.plist, and it would build fine. This will now result in a
"Error loading 'Info.plist': File not found" error. This is trivial to fix:
just remove the Info.plist from the project file (or an alternative solution
could be to condition the inclusion of the Info.plist in the project file on
the existence of the Info.plist).
New commits in xamarin/Xamarin.MacDev:
* xamarin/Xamarin.MacDev@a1bc6f3 [Xamarin.MacDev] Split IAppleSdkVersion.TryParse in two methods. (#73)
Diff: 45c5a680e2..a1bc6f39b3
* [msbuild] Share the DeviceSpecificIntermediateOutputPath property.
We don't technically need this value for Xamarin.Mac, but many of the targets
that can be shared need to use this for Xamarin.iOS, so set this value for
Xamarin.Mac as well. It will always be the default IntermediateOutputPath for
Xamarin.Mac, while for Xamarin.iOS it might be changed in
_ComputeTargetArchitectures.
* [msbuild] Remove usage in Xamarin.Mac of a variable that was always empty in the past.
* [msbuild] Unify MtouchDebug and MmpDebug into _Debug.
* [msbuild] Use _BundlerDebug instead of _Debug.
_Debug is too generic, and more likely to clash with someone else.
Also fix several tests to work when executed from within VS due to some difference
There's also a change to the MtouchTask: lookup of framework assemblies won't
succeed anymore if the path to the assembly is just an unrooted filename
(which may happen to be a file in the current directory (as a test proved
accidentally) - in which case it will never be a framework assembly).
Unfortunately this won't make all tests pass, around 20 tests will still fail with:
#RunTarget-ErrorCount
The "GetReferenceNearestTargetFrameworkTask" task could not be instantiated from the assembly "/Library/Frameworks/Mono.framework/Versions/Current/lib/mono/msbuild/15.0/bin/NuGet.Build.Tasks.dll". Please verify the task assembly has been built using the same version of the Microsoft.Build.Framework assembly as the one installed on your computer and that your host application is not missing a binding redirect for Microsoft.Build.Framework. Specified cast is not valid.
The "GetReferenceNearestTargetFrameworkTask" task has been declared or used incorrectly, or failed during construction. Check the spelling of the task name and the assembly name.
Expected: 0
But was: 2
but I couldn't figure out how to fix these errors.
Fixes https://github.com/xamarin/xamarin-macios/issues/5042.
* [src] Remove Classic code from System.Net.Http.
* [src] Remove Classic code from the ObjCRuntime namespace.
* [src] Remove Classic code from the native types.
* [src] Remove the Classic defines from the makefiles.
* [src] Remove Classic code from the Constants class.
* [src] Update project files to remove XAMCORE_2_0 and __UNIFIED__.
* [src] Remove Classic code from the MonoNativeFunctionWrapper and MonoPInvokeCallback attributes.
* [src] Update README to remove outdated docs about XAMCORE_2_0.
* [d16-7] [registrar] Remove Classic Code.
* Bump Touch.Unit.
New commits in spouliot/Touch.Unit:
* spouliot/Touch.Unit@358b283 Remove code to be compatible with MonoTouch (Classic Xamarin.iOS). (#59)
Diff: 9db795d50d..358b283b64
* [src] NUnitLite still needs the XAMCORE_2_0 and __UNIFIED__ defines.
They still have conditional code with those defines:
a977ca5757/NUnitLite-1.0.0/src/framework/Constraints/Numerics.cs (L57)
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
* We require Xcode 6+,, so remove checks for older Xcode versions.
* We require iOS 6+, so remove checks for older iOS versions.
* We don't need to check the Xamarin.iOS version, since we're shipping
together (code checking Xamarin.iOS version is leftover from when the
MSBuild tasks were shipped with Xamarin Studio).
This also allowed us to remove an error (and the corresponding message).
* [src] Update project files to remove XAMCORE_2_0 and __UNIFIED__.
* [src] Update README to remove outdated docs about XAMCORE_2_0.
* [src] Remove Classic code from System.Net.Http.
* [src] Remove Classic code from the ObjCRuntime namespace.
* [src] Remove Classic code from the native types.
* [src] Remove the Classic defines from the makefiles.
* [src] Remove Classic code from the Constants class.
* [src] Remove Classic code from the MonoNativeFunctionWrapper and MonoPInvokeCallback attributes.
* [src] NUnitLite still needs the XAMCORE_2_0 and __UNIFIED__ defines.
They still have conditional code with those defines:
a977ca5757/NUnitLite-1.0.0/src/framework/Constraints/Numerics.cs (L57)
It's not needed, this was a workaround for an issue with the App Store to get
around an ARM64_32 requirement if building with the watchOS 4.3 SDK. The App
Store does not allow shipping apps built with the watchOS 4.3 SDK anymore, so
this workaround is not useful now.
* [msbuild] Unify MtouchArch and XamMacArch into TargetArchitectures.
* [msbuild] Use $(ComputedPlatform) instead of $(_Platform).
They're identical, and this avoids using $(_Platform) before it's defined.
Also rework the class hierarchy a little bit, so that Xamarin.iOS and
Xamarin.Mac are identical:
DetectSigningIdentityTaskBase
└─── iOS/DetectSigningIdentityTaskCore
│ └─── iOS/DetectSigningIdentity
└─── Mac/DetectSigningIdentityTaskCore
│ └─── Mac/DetectSigningIdentity
There's one difference for Xamarin.Mac library projects: they'll now have the
ability to use an Info.plist to specify a minimum OS version that will be used
when compiling storyboards and other compilable files.
This is the way it's worked for Xamarin.iOS projects for a long time.
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`.
Inject logic into the Build target to start creating the app bundle:
* Make sure the pre-existing list of targets (CreateAppBundleDependsOn) to
create an app bundle is not evaluated.
* Create a new CreateAppBundleDependsOn variable that contains the new targets
we want to run to create the app bundle for net5.
* Call the built-in publishing targets to copy files to the publish directory
(ComputeFilesToPublish / CopyFilesToPublishDirectory).
* Add a target that rewrites the publish directory for assemblies and dylibs
to put them in the app bundle instead.
* [tests] Add a unit test project to test our net5 support.
* [tests] Fix clearing environment variables when launching processes.
* [tests] Add net5 macOS test app.
* [tests] Add net5 tvOS test app.
* [tests] Add net5 watchOS test app.
* [msbuild] Exclude CreateAppBundleDependsOn from net5 builds as well.
* [msbuild] We're not required to know the signing identity to figure out the app extension bundle name.
There is a difference for Xamarin.Mac: the task will not be executed anymore
if IsAppDistribution is set to true. Given that IsAppDistribution is not used
in Xamarin.Mac projects, this is likely a rather uncommon case, and the
potential for breaking behavior is outweighed by the advantage of having the
same behavior for Xamarin.iOS and Xamarin.Mac.
* The ILRepack package uses a 4-year old version of Mono.Cecil, which does not
support portable pdbs. Work is in progress to use a newer version of
Mono.Cecil (https://github.com/gluck/il-repack/pull/236), but this is taking
some time (the PR is over a year old). In the meantime, switch to the
ILRepack.MSBuild.Task package, which ships a forked and updated ILRepack.exe
executable. This means the assembly merging process will produce a working
pdb for the merged assembly, which in turn means we'll get stack traces with
source code location.
* Update the makefile to ship the pdbs we produce. Also don't copy files into
a temporary build/ directory, since it's not needed. This avoids an
intermediate file copy.
* [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.
Fixes: https://github.com/xamarin/xamarin-macios/issues/8211
Context: https://github.com/xamarin/xamarin-android/blob/master/Documentation/workflow/Localization.md
A list of MSBuild error codes came back from the translators. These
had no `<comment/>` fields filled out at all. I added these, so it
should be much clearer what the messages actually mean.
* E0044
* E0094
* E0098
* E0124
* E0128
* E0130
* E0131
* E0133
* E0140
* E0156
* E7022_A
* E7057
* M0119
* W0020
* W0022
Error codes that did not appear to be used anymore:
* E0096
I also added a short `README.md` so others can more easily pick this
up.
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
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.
Instead of having multiple symlinks in the /Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Mac directory
pointing to files in /Library/Frameworks/Xamarin.Mac.framework/Versions/Current/lib/msbuild, have the
/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Mac directory point to the
/Library/Frameworks/Xamarin.Mac.framework/Versions/Current/lib/msbuild directory. This way we
don't have to update the symlinks whenever there are new files somewhere.
The netstandard2.0 version has been the default for a few weeks now, and no
problems have been found, so just delete the net461 version.
This speeds up testing a bit, since we won't be testing the net461 version
anymore.
We now require C# 8 for nullability support. However we allow custom code
to be included inside binding projects and we should not support anything
(stable) that the C# compiler (installed separately) allow, so `latest`
it is.
We now require C# 8 for nullability support. However we allow custom code
to be included inside binding projects and we should not support anything
(stable) that the C# compiler (installed separately) allow, so `latest`
it is.
* [msbuild] Conditionally include MSBuild assets
Updates the Microsoft.Build* references to use PackageReference to match Xamarin.iOS.Tasks.Core.csproj, and conditionally includes the MSBuild assets so these can be copied to the output directory if needed. If `IncludeMSBuildAssets` is not set, the behavior will remain the same, the MSBuild assemblies won't be copied to the output dir.
* Fix whitespace.
* Bump maccore
New commits in xamarin/maccore:
* xamarin/maccore@92a06f7303 [d16-7] Fixes msbuild.zip (#2200)
Diff: a14f74b40a..92a06f7303
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
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).
Updates the Microsoft.Build* references to use PackageReference to match Xamarin.iOS.Tasks.Core.csproj, and conditionally includes the MSBuild assets so these can be copied to the output directory if needed. If `IncludeMSBuildAssets` is not set, the behavior will remain the same, the MSBuild assemblies won't be copied to the output dir.
* Don't validate the TargetFrameworkIdentifier, instead pass it along to bgen
(which will validate it). This means less validation updates when something
changes.
* For Xamarin.Mac's GenerateCommandLineCommands' implementation:
* We'll always have a bgen.exe, so the code for what to do if bgen isn't
there can be removed.
* There's no need to compute the 'isMobile' value, because now it's not used
anymore. So we can remove the first if block in the method completely.
* There's no need to add the -stdlib flag, because the base implementation
in BTouchTaskBase already adds it.
* Now there's nothing left in the method but calling base, so the entire
override can be removed.
* This also removes the need for the FrameworkRoot parameter to the task,
so remove that too.
* For Xamarin.Mac's GetTargetFrameworkArgument's implementation:
* Move the TargetFramework logic to detect the different Xamarin.Mac
variations to the targets file, so that it can be reused by other tasks
and targets.
* This means we don't need an overridable function to get the target
framework argument, so just remove inline the entire virtual method.
Create a common base class for MmpTaskBase and MtouchTaskBase, and move logic
that is common between mtouch and mmp there. Some input variables were renamed
for the MmpTaskBase task, when the resulting code would be identical in
MtouchTaskBase, and thus sharable.
There is still a bit more code that could be shared, but that require a bit
more effort and can always be done later.
* Bump Xamarin.MacDev.
New commits in xamarin/Xamarin.MacDev:
* xamarin/Xamarin.MacDev@a0a11af Adjust SDK validation to allow tools/bin and not allow usr/bin. (#71)
* xamarin/Xamarin.MacDev@e21e1aa Accept 'tools/buildinfo' as an alternative path to 'buildinfo' due to an nuget bug. (#70)
* xamarin/Xamarin.MacDev@ce24236 Don't look in /Developer/MonoTouch anymore, there's nothing there. (#69)
Diff: 210c664e56..a0a11aff27
* [msbuild] Teach tests that mock MonoTouchSdk to mock better.
MonoTouchSdk ends up a bit confused when giving it an Sdk directory that isn't
a real Sdk directory, and then assuming that properties that return Sdk paths
won't throw exceptions.
Fix this by giving MonoTouchSdk a better fake Sdk directory (which
MonoTouchSdk detects as a real Sdk directory), and thus those previously
mentioned properties will return true fake values instead of throwing
exceptions.
When .NET 5 comes, the TargetFrameworkMoniker will change, and we need the
entire moniker to distinguish between various platforms.
So change our msbuild code to consume the entire TargetFrameworkMoniker, so
that we have all the information we need when we need it.
Also redirect everything through an intermediate
_ComputedTargetFrameworkMoniker property, so that the target framework can be
overridden without affecting any other code. This becomes necessary during the
initial implementation phase, because we don't have a .NET version to test
with yet that can give us the new target frameworks. Eventually it should be
possible to remove this intermediate variable
This allows us to replace Xamarin.MacDev.Tasks.PlatformFramework with
Xamarin.Utils.ApplePlatform.
It also allow for more complex target framework handling/parsing in the
future, using the TargetFramework class.
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.
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.
* [msbuild] Provide the correct value for the operating system for tvOS and watchOS to a few tasks. Fixes#6200. (#7226)
The problem with #6200 was that we'd pass -mios-version-min=x.y to the metal
tool even for tvOS apps. This fixes it so that now pass -mtvos-version-min.
Fixes https://github.com/xamarin/xamarin-macios/issues/6200.
* [msbuild] Add support for Metal in the simulator. Fixes#7392. (#7983)
This is a series of commits that tweaks the msbuild tests a little bit.
* [msbuild] Match configuration between MyWatchKit2Extension and MyWatchKit2IntentsExtension.
Fixes this warning:
> MTOUCH : warning MT0113: Native code sharing has been disabled for the extension 'MyWatchKit2IntentsExtension' because the --assembly-build-target options are different between the container app () and the extension (--assembly-build-target:@all=dynamiclibrary). [MyWatchKit2Extension/MyWatchKit2Extension.csproj]
* [msbuild] Add the extra argument for the AppWithExtraArgumentThatOverrides test project to all configurations.
That way the test can be built in all configurations (and still test what it's
supposed to test).
* [msbuild] Clean up project files a bit.
* Removed default 'CodesignKey' values from simulator configurations.
* Removed 'MtouchFastDev' values from simulator configurations.
* Removed 'IOSDebuggerPort' values, not needed for these projects.
* [msbuild] Update test projects to use 64-bit architectures.
Also enable bitcode (+llvm) for release device builds for tvOS and watchOS.
* [msbuild] Simplify test project configuration a bit.
* [msbuild] Unify output path.
Using 'TV' and 'TVSimulator' in the OutputPath works fine, but it makes some
of the tests a bit more complex because they need to special-case this test to
find the path to the resulting .app.
* [msbuild] Fix the MyiOSFrameworkBinding test project to have the same assembly name as the project itself.
This simplifies upcoming testing code a bit.
* [xcode11.4] Add xcode 11.4 b1 initial support
* [xtro] re-enable PDFKit
* Disable watchOS and fix xtro
Unfortunately watchOS simulator hangs when we try to deploy to it
and it keeps our tests timing out. Disabling for now until we
can investigate more.
Disables PDFKit on xtro in macOS
* [jenkins] Switch to use the catalina bot group (#7819)
* Bump maccore to get fix for launching the simulator for watch apps.
New commits in xamarin/maccore:
* xamarin/maccore@546270c8f9 [Xamarin.Hosting] Fix the name of the notification we get when the simulator has launched. (#2145)
Diff: 55957e908d..546270c8f9
* [tests] Diable watch due to time out, enable 10,15,4 in intro, fix min version
* Bump macios-binaries to get updated binary mlaunch as well.
New commits in xamarin/macios-binaries:
* xamarin/macios-binaries@f8c6e63 Bump mlaunch to xamarin/maccore@546270c8f9
Diff: eb6980e8b6..f8c6e63228
* [msbuild] Reflect ibtool changes in our tests
Looks like Apple reverted some changes introduces in Xcode 11
in ibtool, for more context see xamarin/xamarin-macios#6970
* [mtouch] Workaround strange behavior of realpath.
Co-authored-by: Sebastien Pouliot <sebastien.pouliot@gmail.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Fixes:
> /Library/Frameworks/Mono.framework/External/xbuild/Xamarin/iOS/Xamarin.iOS.Common.targets(1726,3): warning : The Watch App 'MyWatchApp2' has a CFBundleVersion (1.33) that does not match the main app bundle's CFBundleVersion (1.0) [MyWatch2Container/MyWatch2Container.csproj]
> /Library/Frameworks/Mono.framework/External/xbuild/Xamarin/iOS/Xamarin.iOS.Common.targets(1726,3): warning : The Watch Extension 'MyWatchKit2Extension' has a CFBundleVersion (1.0) that does not match the main app bundle's CFBundleVersion (1.33) [MyWatch2Container/MyWatch2Container.csproj]
Fixes:
> MyWatchKit2IntentsExtension/IntentHandler.cs(36): warning MT4174: Unable to locate the block to delegate conversion method for the method MyWatchKit2IntentsExtension.IntentHandler.ResolveRecipients's parameter #2. [MyWatchKit2Extension/MyWatchKit2Extension.csproj]
The method signature probably changed from a beta release to the corresponding
stable release, and this method was never updated.
Don't separate command-line arguments to mmp with newlines, in dotnet those
newlines are passed to mmp instead of being treated as whitespace, and that
confuses mmp.
Also remove additional and unneeded whitespace in the command line arguments,
the CommandLineArgumentBuilder class already adds whitespace when needed.
* [msbuild] Fix the MyWatchApp2 test project to include resources already present.
Fixes several warnings:
> MyWatchApp2/obj/iPhoneSimulator/Debug/actool/cloned-assets/Resources/Images.xcassets : actool warning : The file "Icon-27.5x27.5@2x.png" for the image set "AppIcons" does not exist. [MyWatchApp2/MyWatchApp2.csproj]
> MyWatchApp2/obj/iPhoneSimulator/Debug/actool/cloned-assets/Resources/Images.xcassets : actool warning : The file "Icon-86x86@2x.png" for the image set "AppIcons" does not exist. [MyWatchApp2/MyWatchApp2.csproj]
> MyWatchApp2/obj/iPhoneSimulator/Debug/actool/cloned-assets/Resources/Images.xcassets : actool warning : The file "Icon-40x40@2x.png" for the image set "AppIcons" does not exist. [MyWatchApp2/MyWatchApp2.csproj]
> MyWatchApp2/obj/iPhoneSimulator/Debug/actool/cloned-assets/Resources/Images.xcassets : actool warning : The file "Icon-44x44@2x.png" for the image set "AppIcons" does not exist. [MyWatchApp2/MyWatchApp2.csproj]
> MyWatchApp2/obj/iPhoneSimulator/Debug/actool/cloned-assets/Resources/Images.xcassets : actool warning : The file "Icon-24x24@2x.png" for the image set "AppIcons" does not exist. [MyWatchApp2/MyWatchApp2.csproj]
> MyWatchApp2/obj/iPhoneSimulator/Debug/actool/cloned-assets/Resources/Images.xcassets : actool warning : The file "Icon-98x98@2x.png" for the image set "AppIcons" does not exist. [MyWatchApp2/MyWatchApp2.csproj]
> MyWatchApp2/obj/iPhoneSimulator/Debug/actool/cloned-assets/Resources/Images.xcassets : actool warning : The file "Icon-29x29@2x.png" for the image set "AppIcons" does not exist. [MyWatchApp2/MyWatchApp2.csproj]
> MyWatchApp2/obj/iPhoneSimulator/Debug/actool/cloned-assets/Resources/Images.xcassets : actool warning : The file "Icon-29x29@3x.png" for the image set "AppIcons" does not exist. [MyWatchApp2/MyWatchApp2.csproj]
* [msbuild] Add a 1024x1024 icon to the MyWatchApp2 test project.
Fixes this warning:
> MyWatchApp2/obj/iPhoneSimulator/Debug/actool/cloned-assets/Resources/Images.xcassets : actool warning : A 1024x1024 app store icon is required for watchOS apps [MyWatchApp2/MyWatchApp2.csproj]
* [msbuild] Remove the longLook icon entry for MyWatchApp2.
It doesn't seem to be a valid entry, there's no such entry when creating a
watchOS app in Xcode. Additionally it fixes this warning:
> MyWatchApp2/obj/iPhoneSimulator/Debug/actool/cloned-assets/Resources/Images.xcassets : actool warning : The app icon set "AppIcons" has an unassigned child. [MyWatchApp2/MyWatchApp2.csproj]
Copy test projects to a temporary directory before using them for tests. This
makes sure tests don't leave a dirty working tree (because some tests modify
the on-disk test code).
We'll also start running tests using SDK-style project files, and this way
it's much easier to run tests twice, once using the old format and once using
the new format, and then compare the results.
Most of the changes are related to making the test projects and code
relocatable.
This fixes an issue related to single quotes and that the fact that mono's behavior
regarding quoting them has changed (by not using single quotes).
This becomes an issue when running with dotnet.
Mono.Posix comes with a native library, and that makes IL merging much more
complicated, especially when Mono.Posix comes from a nuget. So remove the
Mono.Posix dependency, and instead write the 2 P/Invokes we need manually.
* Bump Xamarin.MacDev.
New commits in xamarin/Xamarin.MacDev:
* xamarin/Xamarin.MacDev@210c664 Adds net451 to Xamarin.MacDev.csproj
* xamarin/Xamarin.MacDev@64db365 [winios] Changes provisioning profiles default path
* xamarin/Xamarin.MacDev@d34430a Switch to short-form projects and build for both net461 and netstandard2.0. (#68)
Diff: 0f578f51e6..210c664e56
* [msbuild] Update to latest Mono.Cecil.
The older version doesn't support netstandard2.0.
No code changes were required.
* [msbuild] Remove unused usings.
* [msbuild] Make ILMerge work when building for netstandard2.0.
Also unify/deduplicate the ILMerge logic between Xamarin.iOS and Xamarin.Mac.
* [msbuild] Build for netstandard2.0 in addition to net461.
* [msbuild] Use custom project configurations to support running the tests for both netstandard2.0 and net461.
Use custom project configurations to support running the tests for when the
tasks assembly is built for netstandard2.0 and net461.
* [tests] Make command-line based 'make test-ios-tasks' run tests for both netstandard2.0 and net461.
* [xharness] Add test configuration to run iOS MSBuild tests using either netstandard2.0 or net461.
* [msbuild] Make the netstandard2.0-buils task assemblies the default.
* [msbuild] ILRepack lib assemblies, not ref assemblies.
Ask MSBuild to copy lib assemblies to the output folder when building for
netstandard2.0, this way we can easily find the actual implementation
libraries to pass to ILRepack.
* [msbuild] Merge System.Text.Encodings.Web.dll as well.
* [xharness] Fix build of MSBuild tests for iOS.
* [msbuild] Convert to short-form csproj.
* [msbuild] Make asserts more useful.
* [msbuild] Make tests ignore the actual location of the test assembly.
* [msbuild] Short-style projects default to deterministic builds, which is not compatible with wildcard versions.
* [msbuild] Adjust test.
* Update .gitignore.
* Bump NUnit.ConsoleRunner version.
* [msbuild] Fix indentation.
* [msbuild] Simplify csproj.
These tests were checking if mtouch is called (or not) by checking for the
full installed path to mtouch. When running the tests locally, we're using the
locally built mtouch, and thus the path is different and the tests failed.
Instead check for a smaller substring that is present in both cases.
- https://devdiv.visualstudio.com/DevDiv/_queries/edit/1041456/
- On Windows the GenerateManifests target will sometimes run and do the wrong thing
as we overload their usages of @(NativeReference). Stub it as a no-op
- Also stub out targets XVS were stubbing.
Since the "quote" refactoring there's no real difference between `Add*`
and `Add*Line` methods, everything is now line-oriented.
However `Add` and `AddQuoted` behaved differently, which meant that `Add`
would add a whitespace before a new argument in the `StringBuilder` was
not empty (as a separator needed _when_ different lines were not used).
That resulted in response files that had some lines starting with a white
space. That was not an issue (spec [1] wise) but it broke some (not so
correct) assumptions in `mtouch` and could also break anything that added
comments (which must start with `#`) in the future.
This brings consistency in the output whether quoted/non-quoted arguments
are used.
Reference:
[0] https://github.com/xamarin/xamarin-macios/issues/7645
[1] https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/compiler-options/response-file-compiler-option
Fixes these warnings:
IPhoneSdks.cs(22,4): warning CS0618: 'AppleSdkSettings.Changed' is obsolete: 'This event is never raised' [/work/maccore/onedotnet/xamarin-macios/msbuild/Xamarin.iOS.Tasks.Core/Xamarin.iOS.Tasks.Core.csproj]
IPhoneSdks.cs(31,4): warning CS0618: 'AppleSdkSettings.CheckChanged()' is obsolete: 'This method does nothing' [/work/maccore/onedotnet/xamarin-macios/msbuild/Xamarin.iOS.Tasks.Core/Xamarin.iOS.Tasks.Core.csproj]
MacOSXSdks.cs(18,4): warning CS0618: 'AppleSdkSettings.Changed' is obsolete: 'This event is never raised' [/work/maccore/onedotnet/xamarin-macios/msbuild/Xamarin.Mac.Tasks.Core/Xamarin.Mac.Tasks.Core.csproj]
MacOSXSdks.cs(25,4): warning CS0618: 'AppleSdkSettings.CheckChanged()' is obsolete: 'This method does nothing' [/work/maccore/onedotnet/xamarin-macios/msbuild/Xamarin.Mac.Tasks.Core/Xamarin.Mac.Tasks.Core.csproj]
Also bump Xamarin.MacDev to pick up updated Xamarin.MacDev:
* xamarin/Xamarin.MacDev@0f578f5 [tests] Upgrade to NUnit 3.12 and use package references. (#65)
* xamarin/Xamarin.MacDev@55a30e2 [tests] Adjust tests to not expect the provisioning profiles in the index in any particular order. (#63)
* xamarin/Xamarin.MacDev@dc270f6 Make methods that do nothing obsolete and fix a compiler warning. (#67)
* xamarin/Xamarin.MacDev@681aef6 Remove unused csproj. (#66)
* xamarin/Xamarin.MacDev@d78a92f Update gitignore (#55)
Diff: ca221c8fd6..0f578f51e6
* [msbuild] Don't use gdk-sharp, use native functions instead.
There's no netstandard version of gdk-sharp.
* Don't require the source checkout to be named 'xamarin-macios'.
We now need to merge System.Text.Json into the final assembly, which means all
the System.Text.Json dependencies as well (there are quite a few), so adjust
the logic to figure out which assemblies to be merged to include every
library, except:
* MSBuild assemblies
* Resource assemblies
* System assemblies.
The Bug60536 is about showing a good error message if the json in an asset
pack is invalid. It turns out that System.Text.Json is a bit more permissive
than System.Json, so the json that was previously failing to parse is now
parsing fine [1]. So introduce something that is certainly invalid json
everywhere, and update the test itself as well to cope with different error
message and error location.
Also remove workaround for xbuild in this test, since xbuild isn't used anymore.
[1]: Technically the json is still invalid, because according to the json spec
it's not valid to end a list of array elements with a trailing comma. The
problem is that System.Json would in some cases allow trailing commas for
lists of array elements, and sometimes not, which means that we have to ask
System.Text.Json to allow trailing commas as well. And when System.Text.Json
is asked to allow trailing commas, it also successfully parses a case of
trailing comma where System.Json didn't, thus the need for coming up with
something even more invalid.
Updating the msbuild tasks to use netstandard2.0 requires us to bump NUnit to 3+.
This requires:
* A few code changes due to breaking API changes in NUnit.
* Changes in xharness and a makefile to cope with the new location for the
NUnit console runner (I added a helper script to make things slightly
easier).
* [vsts-1029041] Add FileType to the list of parameters for altool
* ValidateAppStoreBundle
* UploadAppStoreBundle
* [vsts-1029041] Pass TargetFrameworkIdentifier to identify target platform
The DSymUtil tool not only generates the debug symbol files but also modifies the executable file. Marking that property as Output (and changing it to ITaskItem type) makes Visual Studio on Windows aware of that change. Under certain scenarios this was making the build on VS produce an app bundle that was not fully signed on incremental builds. For instance, the DSymUtil task was run for a framework on an incremental build, but as the executable file of that framework was not modified on Windows the inputs/outputs check for CodesignFrameworks did not fail so that target was skipped. This led to a failure on the CodesignVerify target.
Partial fix for https://developercommunity.visualstudio.com/content/problem/729766/codedesign-exited-with-code-1.html
The DSymUtil tool not only generates the debug symbol files but also modifies the executable file. Marking that property as Output (and changing it to ITaskItem type) makes Visual Studio on Windows aware of that change. Under certain scenarios this was making the build on VS produce an app bundle that was not fully signed on incremental builds. For instance, the DSymUtil task was run for a framework on an incremental build, but as the executable file of that framework was not modified on Windows the inputs/outputs check for CodesignFrameworks did not fail so that target was skipped. This led to a failure on the CodesignVerify target.
Partial fix for https://developercommunity.visualstudio.com/content/problem/729766/codedesign-exited-with-code-1.html
and by friends I mean `mmp` and `btouch`
What does this do ?
1. Assume that output of `mtouch` (and other similar tools) is **always** of high importance. Why ?
- If not then it's not saved in the binary log (even if visible on the console/text logs).
- The logging of `mtouch` (and friends) is dynamic, based on a supplied verbosity level.
- If a verbosity level _anywhere_ then it's a clear sign that the developer wants that extra output (and that includes binary logs).
2. Assume the _global_ verbosity of `msbuild` from the console is just as valid/useful than the one from VSfM.
- CI/bots produce logs and they should be useful to diagnose build issues.
- Setting verbosity in several places is error-prone, which delay investigations and results.
- Running the same project, with the same `msbuild` verbosity, should be identical between IDE and console.
What does that mean ?
Using `msbuild /v:diag /bl:out.binlog` you get a small(er) binary log that has everything[1] you need to diagnose a Xamarin.iOS (or Mac) build. It's also identical to the output what VSfM produce (for the same `msbuild` verbosity level).
[1] we might need to review what we log if we're missing interesting stuff
References:
https://github.com/xamarin/xamarin-macios/issues/7035
* Add bindings for NSXpcConnection and related types
* Re-add accidentally deleted file
* Typo fix
* Add NSXpcInterface.CreateForType()
* Add MethodInfo-taking overloads to NSXpcInterface
* Add null check
* Mark methods with wrappers as internal
Also fixed a formatting bug that I didn't catch earlier.
* Change NSXPCProxyCreating methods to be strongly typed
I got rid of the NSXpcProxyCreating interface in this change,
because its only user was NSXpcConnection, and I needed to
inline the protocol methods into the class definition so I
could mark them as [Internal].
* Add missing casts
* Add NSXpcConnectionOptions enum
* Convert NSXpcConnection constructor to use new enum
* Remove now-unneeded manual constructor
* Fix bgen warning
* Typo fix
* Fix selector
* Remove incorrect use of BindAsAttribute
Per the docs, this only works for enums backed
by NSNumber and NSValue, not for enums
passed directly as integers.
* Fix duplicated selector errors
* Throw ArgumentException instead of InvalidOperationException
* Extend AppExtension targets to produce XPC services
Rather than create an entirely new set of targets
(that would require VS and VSMac updates to properly
consume), I have decided to use the existing AppExtension
build targets to produce XPC services as well. All the
user must do is set the $(IsXPCService) property to true in
their project file, and the targets will do The Right Thing™.
Note that this support is Mac-only for now; I may need a bit
of help adjusting them to work on for iOS/watchOS/tvOS, as I
am not as familiar with those platforms.
* Copy XPC service bundles into the correct location
* Move IsXPCService property definition to props file
* Don't pass /extension to mmp for XPC service targets
This would cause the XPC service binary to
be linked incorrectly.
* Add NSXpcConnection/NSXpcInterface.cs files to the build
* Fix build
* Fix build
* Add required type parameter requirements
* Fix type parameter requirements
* Fix return type
* Fix return type of NSXpcInterface.CreateForProtocol ()
* Take ownership of the returned object types
* Adjust XPC service mmp invocation
I need to link the XPC service bundle as if it is an app extension, but
I must not use xamarin_mac_extension_main. I added a new flag to make
this possible.
* Change mmp to correctly construct XPC service bundle
* Set the MonoBundleExecutable Info.plist key for XPC services
* Use the runtime to get the protocol
* Make NSXpcInterface.CreateForProtocol() public
The static registrar must be used for Cocoa to accept the protocol
as a valid XPC interface, but that then seems to break resolving
the protocol from the type. I must therefore hard-code the protocol
name in my code, and that requires I make this constructor public.
* Add XpcInterfaceAttribute
See the doc comment in XpcInterfaceAttribute.cs for why
this type is required. The referenced mmp optimizations
will be added in future commits.
* Add XpcInterfaceAttribute to generator build
* Add support for XpcInterfaceAttribute to the generator
* Force static generation of protocols decorated with XpcInterfaceAttribute
* Change how static registrar translates block parameters
Previously, they would always be marshalled as "id".
This would throw off the XPC subsystem, which parses
the block signature to determine the communication
protocol.
* Undo whitespace noise
* Remove unneeded casts
* Add trailing comma
* Use HasAttribute instead of GetCustomAttribute
* Fix style issues
* Bind NSXpcConnection.auditSessionIdentifier
* Address naming feedback
* Make Get/SetAllowedClasses public
IMHO, passing the selector as a string is just as
usable as passing a MethodInfo, and is also less
verbose if you copy/paste the selector string
from the ExportAttribute. There is no reason why
we cannot have both overloads be public.
* Update overload names to match
* Update more overload names to match
* Make mmp --xpc imply --extension
* Reformat if statement
* Fix build
* Conditionalize creation of PlugIns and XPCServices directories
* Add AutoGeneratedName
Co-Authored-By: Rolf Bjarne Kvinge <rolf@xamarin.com>
* Get rid of ProtocolizeAttribute
* Update availability attributes to please xharness
I actually think xharness is wrong here, since the
NSXPCConnection header lists these types as being
available starting in macOS 10.8.
* Update sharpie ignore files to reflect changes
This should fix the xtro-sharpie test failures CI has been reporting.
* Fix MM4105 error generation
* Adjust error message in test to match mmp
I had to change the error text slightly, because the type of the parameter
cannot be determined where the error is thrown anymore. However, the newer
exception message IMO is just as clear.
* Make exception message match test exactly
* Remove outdated copyright header text
* Remove more outdated copyright header text
* Revert changes to MM4105 error generation
I have a more elegant way of fixing this test now.
* Return "id" if Invoke method cannot be found
This fixes the MM4105 error unit test,
without requiring modification to that test.
* Remove redundant availability attributes
* Add DesignatedInitializerAttribute
* Re-add required code to macOS-Foundation.ignore
* Put DesignatedInitializer on the right constructor
* Update xtro-sharpie ignore files
The existing test only checked that an assembly was mentioned in the file, but not that its version etc matches.
Updated the test and fixed the differences.
* Implement a different escaping/quoting algorithm for arguments to System.Diagnostics.Process.
mono changed how quotes should be escaped when passed to
System.Diagnostic.Process, so we need to change accordingly.
The main difference is that single quotes don't have to be escaped anymore.
This solves problems like this:
System.ComponentModel.Win32Exception : ApplicationName='nuget', CommandLine='restore '/Users/vsts/agent/2.158.0/work/1/s/tests/sampletester/bin/Debug/repositories/ios-samples/WorkingWithTables/Part 3 - Customizing a Table\'s appearance/3 - CellCustomTable/CellCustomTable.sln' -Verbosity detailed -SolutionDir '/Users/vsts/agent/2.158.0/work/1/s/tests/sampletester/bin/Debug/repositories/ios-samples/WorkingWithTables/Part 3 - Customizing a Table\'s appearance/3 - CellCustomTable'', CurrentDirectory='/Users/vsts/agent/2.158.0/work/1/s/tests/sampletester/bin/Debug/repositories', Native error= Cannot find the specified file
at System.Diagnostics.Process.StartWithCreateProcess (System.Diagnostics.ProcessStartInfo startInfo) [0x0029f] in /Users/builder/jenkins/workspace/build-package-osx-mono/2019-08/external/bockbuild/builds/mono-x64/mcs/class/System/System.Diagnostics/Process.cs:778
ref: https://github.com/mono/mono/pull/15047
* Rework process arguments to pass arrays/lists around instead of quoted strings.
And then only convert to a string at the very end when we create the Process
instance.
In the future there will be a ProcessStartInfo.ArgumentList property we can
use to give the original array/list of arguments directly to the BCL so that
we can avoid quoting at all. These changes gets us almost all the way there
already (except that the ArgumentList property isn't available quite yet).
We also have to bump to target framework version v4.7.2 from v4.5 in several
places because of 'Array.Empty<T> ()' which is now used in more places.
* Parse linker flags from LinkWith attributes.
* [sampletester] Bump to v4.7.2 for Array.Empty<T> ().
* Fix typo.
* Rename GetVerbosity -> AddVerbosity.
* Remove unnecessary string interpolation.
* Remove unused variable.
* [mtouch] Simplify code a bit.
* Use implicitly typed arrays.
The existing test only checked that an assembly was mentioned in the file, but not that its version etc matches.
Updated the test and fixed the differences.
This has a couple of advantages:
* It makes it easier to add a catalyst version of these libraries (because it
becomes cumbersome to build for catalyst when the build rules assumes we're
building for both simulator and device).
* It makes it easier to create an xcframework of our libraries, because the
contents in an xcframework is split like this.
See https://github.com/mono/mono/issues/17064.
The 2019-08 version of the fix adds a new assembly with NS2.1 APIs that we stubbed out in 2019-06: System.Data.DataSetExtensions.dll
See https://github.com/mono/mono/issues/17064.
The 2019-08 version of the fix adds a new assembly with NS2.1 APIs that we stubbed out in 2019-06: System.Data.DataSetExtensions.dll
* [msbuild] Use task assembly path via a property
Xamarin.Mac.Common.ImplicitFacade.msbuild.targets: $(_NETBuildExtensionsTaskAssembly)
* [msbuild] Fix path to NET.Build.Extensions task assembly
.. which is no longer available for `net46`. Instead use the latest
`net472` path.
The incorrect path effectively disabled the `GetDependsOnNETStandard`
task, causing the issue.
Partially fixes https://github.com/xamarin/xamarin-macios/issues/6552 .
* [msbuild] Fix XM builds which use netstandard libraries.
`Xamarin.Mac.Common.ImplicitFacade.msbuild.targets`:
`ImplicitlyExpandDesignTimeFacades` adds a reference to `netstandard.dll`
by expanding the facades, if any of the references depend on it. Usually,
this gets handled by msbuild SDKs but in case of XM, this doesn't happen
in all cases. So, we need to scan the references for a `netstandard`
dependency.
The `ResolveAssemblyReference` task does this for us and populates
`$(_DependsOnNETStandard)` property. If it does not, then we use
`GetDependsOnNETStandard` task to get the same information.
Issue:
- the target incorrectly uses `$(DependsOnNETStandard)` instead of
`($_DependsOnNETStandard)`.
- Fixing that means that condition `$(_DependsOnNETStandard) == ''` fails
whenever `ResolveAssemblyReference` task runs (setting the property
to `true` or `false`), causing `$(XM_DependsOnNETStandard)` to be unset.
- thus failing the following logic to expand the facades when `$(_DependsOnNETStandard) == true`
So, we use the `$(_DependsOnNETStandard)` as the default value for
`$(XM_DependsOnNETStandard)`, so that it is correctly set to `true`,
irrespective of how we got that information, allowing us to correctly
expand facades when required.
Partially fixes https://github.com/xamarin/xamarin-macios/issues/6552 .
* [msbuild] Fix XI builds which use netstandard libraries.
`Xamarin.iOS.Common.targets`:
Issue:
- the target incorrectly uses `$(DependsOnNETStandard)` instead of
`($_DependsOnNETStandard)`.
- Fixing that means that condition `$(_DependsOnNETStandard) == ''` fails
whenever `ResolveAssemblyReference` task runs (setting the property
to `true` or `false`), causing `$(XI_DependsOnNETStandard)` to be unset.
- thus failing the following logic to expand the facades when `$(_DependsOnNETStandard) == true`
So, we use the `$(_DependsOnNETStandard)` as the default value for
`$(XI_DependsOnNETStandard)`, so that it is correctly set to `true`,
irrespective of how we got that information, allowing us to correctly
expand facades when required.
Prompted by: https://github.com/xamarin/xamarin-macios/issues/6552
* [msbuild] Use task assembly path via a property
Xamarin.Mac.Common.ImplicitFacade.msbuild.targets: $(_NETBuildExtensionsTaskAssembly)
* [msbuild] Fix path to NET.Build.Extensions task assembly
.. which is no longer available for `net46`. Instead use the latest
`net472` path.
The incorrect path effectively disabled the `GetDependsOnNETStandard`
task, causing the issue.
Partially fixes https://github.com/xamarin/xamarin-macios/issues/6552 .
* [msbuild] Fix XM builds which use netstandard libraries.
`Xamarin.Mac.Common.ImplicitFacade.msbuild.targets`:
`ImplicitlyExpandDesignTimeFacades` adds a reference to `netstandard.dll`
by expanding the facades, if any of the references depend on it. Usually,
this gets handled by msbuild SDKs but in case of XM, this doesn't happen
in all cases. So, we need to scan the references for a `netstandard`
dependency.
The `ResolveAssemblyReference` task does this for us and populates
`$(_DependsOnNETStandard)` property. If it does not, then we use
`GetDependsOnNETStandard` task to get the same information.
Issue:
- the target incorrectly uses `$(DependsOnNETStandard)` instead of
`($_DependsOnNETStandard)`.
- Fixing that means that condition `$(_DependsOnNETStandard) == ''` fails
whenever `ResolveAssemblyReference` task runs (setting the property
to `true` or `false`), causing `$(XM_DependsOnNETStandard)` to be unset.
- thus failing the following logic to expand the facades when `$(_DependsOnNETStandard) == true`
So, we use the `$(_DependsOnNETStandard)` as the default value for
`$(XM_DependsOnNETStandard)`, so that it is correctly set to `true`,
irrespective of how we got that information, allowing us to correctly
expand facades when required.
Partially fixes https://github.com/xamarin/xamarin-macios/issues/6552 .
* [msbuild] Fix XI builds which use netstandard libraries.
`Xamarin.iOS.Common.targets`:
Issue:
- the target incorrectly uses `$(DependsOnNETStandard)` instead of
`($_DependsOnNETStandard)`.
- Fixing that means that condition `$(_DependsOnNETStandard) == ''` fails
whenever `ResolveAssemblyReference` task runs (setting the property
to `true` or `false`), causing `$(XI_DependsOnNETStandard)` to be unset.
- thus failing the following logic to expand the facades when `$(_DependsOnNETStandard) == true`
So, we use the `$(_DependsOnNETStandard)` as the default value for
`$(XI_DependsOnNETStandard)`, so that it is correctly set to `true`,
irrespective of how we got that information, allowing us to correctly
expand facades when required.
Prompted by: https://github.com/xamarin/xamarin-macios/issues/6552
* Build native code with -std=c++14.
Apple's headers now require -std=c++14 to compile their headers in C++ mode.
This fixes a compile error that would occur with the PhotosUI framework when
compiling code for C++.
* [mmp] Use -std=c++14 when compiling.
* Fix command line output.
* [mmp] Add all source files at the end, so they all get the -x clang argument applied.
* Limit when using c++14 in mtouch according to language.
* [msbuild] Improve altool task by logging execution errors
The altool task was just logging the XML output produced by the tool execution but was not logging any build error neither failing in that case.
* [msbuild] Log the altool output when failing to parse it
* [msbuild] Adds missing SessionId property to altool targets
Sets the missing SessionId property on the altool targets to enable running those from Visual Studio.
* [msbuild] Ensure Entitlements are compiled before creating an IPA
When creating an IPA from an archive the `CreateAppBundle` target will be skipped because we already have a bundle and the same will happen with the Entitlements compilation, but we need to re-compile those with the new certificate and profile. Adding `_CompileEntitlements` as a `CreateIpa` dependency will ensure it's run when creating an IPA file from an archive. Nothing changes when creating IPAs from a regular build since at the point the of creating the IPA the `_CompileEntitlements` target was already run, so it will be skipped.
* [publishing] Added conditional behavior to CreateIpa and its dependencies
The targets execution needs to change based on the 'IsAppDistribution' property value, which will be set from the IDE.
According to the value of this property, some dependencies should be run or should be skipped.
The strategy adopted is to use the BeforeTargets value because doing this way we will force the conditionals over '$(IsAppDistribution)' to be evaluated each time a target is attempted to be run.
The most intuitive way of doing it is by directly add DependsOnTargets and conditions on the PropertyGroup items, but doing this will not work because the IDE usually runs the targets when the MSBuild project is already loaded, which means that the properties have already been evaluated so they will not be evaluated again, which causes conditional values to be out of date.
The only way of making it work in these cases is by forcing the conditional evaluations of each target execution attempt, and that is accomplished by adding the conditions directly on the Target 'Condition' property.
* [publishing] Simplified targets by using DependsOn + conditions in existent targets
- Using BeforeTargets on `_BeforeCreateIpaForDistribution` made that target run even if `CreateIpa` was skipped because its condition was false, which is wrong. Instead of including that condition into `_BeforeCreateIpaForDistribution` it seems more reasonable to move it to the `CreateIpa` DependsOnTargets property group to avoid maintaining the same condition on both targets in future changes that could lead to errors.
- Removed `_BeforeCreateIpaForBuild` since it was an unnecessary extensibility point and made the `CreateIpa` dependencies more complicated.
- We still need `_BeforeCreateIpaForDistribution` and `_BeforeCreateIpaForDistributionDependsOn` as extensibility point for the publishing workflow on VS.
- Simplified the previous approach by removing unnecessary targets and dependencies when the only thing needed was just the following condition on existent targets: `'$(IsAppDistribution)' != 'true'`. For instance, removed `_BeforeCodeSignForBuild` and included the mentioned condition into `_CreateAppBundle`. The purpose of `_BeforeCodeSignForBuild` was just skipping `_CreateAppBundle` for distribution builds, but it made the targets more complicated to understand and maintain.
- Same thing applies to `_BeforeCollectFrameworksForBuild` and `_BeforeCodesignNativeLibrariesForBuildDependsOn` which were just skipping the `_CompileToNative` target for distribution builds.
When building mtouch locally, this will be the mtouch path:
/path/to/somewhere/xamarin-macios/_ios-build//Library/Frameworks/Xamarin.iOS.framework/Versions/git/bin/mtouch
Context: http://feedback.devdiv.io/600039
Context: 6321934237/Documentation/guides/MSBuildReferenceAssemblies.md
Context: https://github.com/dotnet/roslyn/blob/master/docs/features/refout.md#msbuild
For Xamarin.Android, we have been doing a bit of work to enable a new
MSBuild/Roslyn feature called "reference assemblies". You can opt into
this by setting $(ProduceReferenceAssembly)=true in a netstandard
project.
The benefit being that if the public API doesn't change in the
netstandard library, the head projects don't need to run `CoreCompile`
or `<Csc/>` during an incremental build.
Unfortunately, this seems to have uncovered a problem in the
Xamarin.iOS MSBuild targets. If you do a build with a XAML-only change,
you get:
Target "_CompileToNative" in file "/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/iOS/Xamarin.iOS.Common.targets":
Skipping target "_CompileToNative" because all output files are up-to-date with respect to the input files.
Input files: /Users/jonathanpeppers/Projects/HelloForms/HelloForms.iOS/bin/iPhoneSimulator/Debug/HelloForms.iOS.exe
Output files: bin/iPhoneSimulator/Debug/device-builds/iphone11.8-12.2/HelloForms.iOS.app/HelloForms.iOS;bin/iPhoneSimulator/Debug/device-builds/iphone11.8-12.2/mtouch.stamp
Because we are using `$(ProduceReferenceAssembly)` the
`HelloForms.iOS.exe` assembly will have no changes. Only
`HelloForms.dll`, the netstandard project, has changes. We were able
to skip `CoreCompile` in the iOS head project. Faster builds, yeah!
However, we actually need `_CompileToNative` to run, or we won't see
any changes on the device or simulator... It only runs if
`$(TargetPath)` changes.
The fix here is to add new `Inputs`, so `_CompileToNative` runs when
any referenced assemblies change:
<_CompileToNativeInput Include="$(TargetDir)$(TargetFileName);@(ReferencePath);@(MTouchReferencePath)" />
This fixes incremental builds (or changes) for:
* Any `<ProjectReference/>` that has `$(ProduceReferenceAssembly)`
* Any NuGet package that ships a reference assembly alongside its
"regular" assembly
I also moved the `<ItemGroup>`'s, just so the code made sense --
so we have all the important `<ItemGroup>`'s in one place.
I also updated the `XamarinForms` test to verify things are working.
I added a couple helpers to assist in writing MSBuild tests:
* `IsTargetSkipped` to check if a specific MSBuild target ran
* `Logger.Clear` to clear past MSBuild events within a single test
Context: 4ecedac733/src/Shared/BuildEnvironmentHelper.cs (L567-L586)
Context: 1d71d99837/tools/xabuild
When using `xibuild` to build an SDK-style project:
tools/xibuild/xibuild -- msbuild/tests/MyXamarinFormsApp/MyXamarinFormsAppNS/MyXamarinFormsAppNS.csproj /restore
It was failing with:
Resolving SDK 'Microsoft.NET.Sdk'...
Project "msbuild/tests/MyXamarinFormsApp/MyXamarinFormsApp.csproj" is building "msbuild/tests/MyXamarinFormsApp/MyXamarinFormsAppNS/MyXamarinFormsAppNS.csproj" (GetTargetFrameworks target(s)):
Building with tools version "Current".
msbuild/tests/MyXamarinFormsApp/MyXamarinFormsAppNS/MyXamarinFormsAppNS.csproj : error MSB4236: The SDK 'Microsoft.NET.Sdk' specified could not be found.
Looking at this code, it looks pretty familiar -- it came from xabuild!
xibuild was currently setting `MSBuildSDKsPath` via a config file:
<msbuildToolsets default="Current">
<toolset toolsVersion="Current">
<property name="MSBuildSDKsPath" value="/Library/Frameworks/Mono.framework/Versions/Current/lib/mono/msbuild/Current/bin/Sdks" />
Reviewing the source code for MSBuild, they don't even look for this
value via MSBuild properties... They just look for Visual Studio
directories and a `MSBuildSDKsPath` environment variable. We don't have
to use this in Xamarin.Android, because we do things a different way.
There was craziness involved to get both Windows & Mac working.
For this to work on Mac, we can just set `MSBuildSDKsPath` when
starting the new MSBuild process.
I cleaned up how `MSBUILD_EXE_PATH` is set so both of these variables
are just set via `ProcessStartInfo.EnvironmentVariables`.
Now I can fully build a Xamarin.Forms project that references a
netstandard library with `xibuild`:
$ tools/xibuild/xibuild -- msbuild/tests/MyXamarinFormsApp/MyXamarinFormsApp.csproj /restore
...
Build succeeded.
0 Warning(s)
0 Error(s)
Time Elapsed 00:00:15.83
~~ New Tests ~~
I went ahead and added a new Xamarin.Forms project to test and verify
that it builds. It is the Blank Forms app template from latest VS4Mac.
With the changes to `xibuild`, I was able to build with the in-process
MSBuild APIs.
* Bump VSMac to 8.1.0.2742 to fix msbuild issues (#6279)
* Bump VSMac to 8.1.0.2742 to fix msbuild issues
This is required to get the support for the msbuild `ToolsVersion`
change from `15.0` to `Current`.
* [tests][msbuild] Fix Binding resources test with updated msbuild
Test failure with updated msbuild and vsmac 8.1:
```
Xamarin.iOS.Tasks.NativeReferencesNoEmbedding("iPhone").ShouldNotUnnecessarilyRebuildBindingProject(True)
Binding project build did not create package?
Expected: True
But was: False
at Xamarin.iOS.Tasks.NativeReferencesNoEmbedding.ShouldNotUnnecessarilyRebuildBindingProject (System.Boolean framework) [0x000a0] in <74b8f7d8a53e40109916d305bb4d7403>:0
at (wrapper managed-to-native) System.Reflection.RuntimeMethodInfo.InternalInvoke(System.Reflection.RuntimeMethodInfo,object,object[],System.Exception&)
at System.Reflection.RuntimeMethodInfo.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo cul
ture) [0x0006a] in <0519fa732e8845b6a809ce9180f541db>:0
```
The test builds the project multiple times. Before the 3rd build, the project
file's timestamp is updated and expects that the binding package will be
rebuilt. But it is not, because the target `_CreateBindingResourcePackage`
doesn't depend on that project file. So, add that to the target inputs.
* [nuget] Use xibuild to run nuget
Fix errors seen during `nuget restore` for tests:
```
Users/builder/jenkins/workspace/xamarin-macios-pr-builder/tests/xammac_tests/xammac_tests.csproj(213,3): error MSB4024: The imported project file "/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Mac/Xamarin.Mac.CSharp.targets" could not be loaded. Could not find file "/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Mac/Xamarin.Mac.CSharp.targets"
```
* [xibuild] Fix incorrect mscorlib.dll being used (#6068)
* [xibuild] Fix incorrect mscorlib.dll being used
The `GuiUnit_NET_4_5` project, when built with `xibuild` uses the wrong `mscorlib.dll`.
From https://github.com/xamarin/xamarin-macios/issues/5760#issuecomment-472457202 :
```
- mscorlib.dll is being used from mono/4.5 and the other system assemblies are from mono/4.5-api
- GuiNet* project is built with xibuild
What is happening here is:
xibuild sets[1] `SetToolsetProperty ("TargetFrameworkRootPath", FrameworksDirectory + Path.DirectorySeparatorChar);`
which points to `/Library/Frameworks/Mono.framework/Versions/Current/lib/mono/xbuild-frameworks`.
This causes $(FrameworkPathOverride) to be set[2] to `/Library/Frameworks/Mono.framework/Versions/Current/lib/mono/xbuild-frameworks/.NETFramework/v4.5`,
but that doesn't have a mscorlib.dll, so it gets reset[3] to /Library/Frameworks/Mono.framework/Versions/5.22.0/lib/mono/4.5/.
If we don't set TargetFrameworkRoothPath, then we get `FrameworkPathOverride = /Library/Frameworks/Mono.framework/Versions/5.22.0/lib/mono/4.5-api`,
causing `_ExplicitReference=/Library/Frameworks/Mono.framework/Versions/5.22.0/lib/mono/4.5-api/mscorlib.dll`(correct one) to be used.
```
Fixes https://github.com/xamarin/xamarin-macios/issues/5760
1. https://github.com/xamarin/xamarin-macios/blob/master/tools/xibuild/Main.cs#L209
2. https://github.com/mono/msbuild/blob/xplat-master/src/Tasks/Microsoft.Common.CurrentVersion.targets#L79
3. https://github.com/mono/msbuild/blob/xplat-master/src/Tasks/Microsoft.Common.CurrentVersion.targets#L84
* Revert "Workaround https://github.com/xamarin/xamarin-macios/issues/5760 in generator csproj"
This reverts commit 9bd927bb7f.
The previous commit for xibuild removes the need for this.
* [xibuild] Handle "incorrectly" cased msbuild property names (#6202)
msbuild property names are case insensitive. While generating the custom
app.config, in `SetToolsetProperty(..)` we try to update the property if
it already exists. But the name lookup was case sensitive, thus causing
the lookup to fail, resulting in two entries for the same property name
differing only in case. Eg. `MSBuildSDKsPath` vs `MSBuildSdksPath`.
Fixed to ignore case.
Fixes https://github.com/mono/mono/issues/14765 .
* [tests] Minor refactor to get better Xcode version parsing.
* Rename Configuration.XcodeVersion to XcodeVersionString.
* Add Configuration.XcodeVersion a parsed Version instane of XcodeString.
* [tests] Ignore all 'MT0099: Not linking with WatchKit because Xcode 11 beta 1' warnings in tests.
* [tests] Adjust min OS version tests for Xcode 11b1.
* [tests] Adjust tests for changes in 'nm' output.
* [tests] Adjust tests for name changes in Clang.
* [tests] Adjust tests for changes in ld warning format.
* [msbuild] 'metal' and 'metallib' aren't in PATH anymore, so use xcrun to execute them.
* [msbuild] Fix DevicePlatformBinDir for the Metal and MetalLib targets on iOS.
Also set the SDKROOT variable, otherwise metal and metallib don't work
properly, and revert the previous attempt at a fix (use xcrun).
* [tests] Simplify version parsing code to not version parse anymore.
* [tests] Add FIXME for once Apple fixes the WatchKit disappearance.
* Bump VSMac to 8.1.0.2742 to fix msbuild issues
This is required to get the support for the msbuild `ToolsVersion`
change from `15.0` to `Current`.
* [tests][msbuild] Fix Binding resources test with updated msbuild
Test failure with updated msbuild and vsmac 8.1:
```
Xamarin.iOS.Tasks.NativeReferencesNoEmbedding("iPhone").ShouldNotUnnecessarilyRebuildBindingProject(True)
Binding project build did not create package?
Expected: True
But was: False
at Xamarin.iOS.Tasks.NativeReferencesNoEmbedding.ShouldNotUnnecessarilyRebuildBindingProject (System.Boolean framework) [0x000a0] in <74b8f7d8a53e40109916d305bb4d7403>:0
at (wrapper managed-to-native) System.Reflection.RuntimeMethodInfo.InternalInvoke(System.Reflection.RuntimeMethodInfo,object,object[],System.Exception&)
at System.Reflection.RuntimeMethodInfo.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo cul
ture) [0x0006a] in <0519fa732e8845b6a809ce9180f541db>:0
```
The test builds the project multiple times. Before the 3rd build, the project
file's timestamp is updated and expects that the binding package will be
rebuilt. But it is not, because the target `_CreateBindingResourcePackage`
doesn't depend on that project file. So, add that to the target inputs.
* [nuget] Use xibuild to run nuget
Fix errors seen during `nuget restore` for tests:
```
Users/builder/jenkins/workspace/xamarin-macios-pr-builder/tests/xammac_tests/xammac_tests.csproj(213,3): error MSB4024: The imported project file "/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Mac/Xamarin.Mac.CSharp.targets" could not be loaded. Could not find file "/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Mac/Xamarin.Mac.CSharp.targets"
```
Lock variables accessed in a Parallel.ForEach callback, since the callback
must be thread-safe because it's executed in parallel using multiple threads.
Lock variables accessed in a Parallel.ForEach callback, since the callback
must be thread-safe because it's executed in parallel using multiple threads.
The IsMacEnabled condition was missing in this specific usage of the CollectBundleResources task. As with any other task that needs to run on a Mac, we should only run it if there's a Mac available or it will end up showing several warnings when building offline from Windows.
Lock variables accessed in a Parallel.ForEach callback, since the callback
must be thread-safe because it's executed in parallel using multiple threads.
* [msbuild] Add reference to `System.Drawing.Common.dll` to XI projects.
Fixes https://github.com/mono/mono/issues/13483 :
```
@akoeplinger: Since we moved types from Mono.Android.dll and
Xamarin.iOS/WatchOS/TVOS.dll to System.Drawing.Common.dll user projects
would fail to compile. We need to add some msbuild logic to add a
reference to the assembly automatically.
```
* [msbuild] Implement the same fix for XM projects as well.
* [msbuild] Update Xamarin.iOS.Tasks.TargetTests.GetReferencedAssemblies_* tests.
We're including a new assembly, which means the
Xamarin.iOS.Tasks.TargetTests.GetReferencedAssemblies_* must be updated
accordingly.
Also modify these tests so that test assert that fails lists the actual
assembly that's missing, i.e. instead of this:
1) Test Failure : Xamarin.iOS.Tasks.TargetTests.GetReferencedAssemblies_Executable
#1
Expected: 6
But was: 7
we now print:
1) Test Failure : Xamarin.iOS.Tasks.TargetTests.GetReferencedAssemblies_Executable
References
Expected: equivalent to < "mscorlib.dll", "MyLibrary.dll", "System.Core.dll", "System.dll", "System.Xml.dll", "Xamarin.iOS.dll" >
But was: < "mscorlib.dll", "MyLibrary.dll", "System.Core.dll", "System.dll", "System.Drawing.Common.dll", "System.Xml.dll", "Xamarin.iOS.dll" >
* [tests] Adjust Xamarin.MMP.Tests.AssemblyReferencesTests.ShouldNotAllowReference_ToSystemDrawing.
The test was verifying that referencing System.Drawing.dll and trying to use
System.Drawing.RectangleF would fail to compile (because System.Drawing.dll
shouldn't be resolved in this case).
The addition of System.Drawing.Common.dll breaks this assumption, because now
we ship System.Drawing.RectangleF, so the code that was supposed to fail to
compile works just fine instead.
So modify the test to verify that there's no System.Drawing.dll in the final
bundle.
* Remove workarounds for mono/mono#13483.
* [msbuild] Create a way out if automatically referencing System.Drawing.Common.dll causes problems.
* [msbuild] Adjust variable name and boolean logic according to review.
* [msbuild] Add reference to `System.Drawing.Common.dll` to XI projects.
Fixes https://github.com/mono/mono/issues/13483 :
```
@akoeplinger: Since we moved types from Mono.Android.dll and
Xamarin.iOS/WatchOS/TVOS.dll to System.Drawing.Common.dll user projects
would fail to compile. We need to add some msbuild logic to add a
reference to the assembly automatically.
```
* [msbuild] Implement the same fix for XM projects as well.
* [msbuild] Update Xamarin.iOS.Tasks.TargetTests.GetReferencedAssemblies_* tests.
We're including a new assembly, which means the
Xamarin.iOS.Tasks.TargetTests.GetReferencedAssemblies_* must be updated
accordingly.
Also modify these tests so that test assert that fails lists the actual
assembly that's missing, i.e. instead of this:
1) Test Failure : Xamarin.iOS.Tasks.TargetTests.GetReferencedAssemblies_Executable
#1
Expected: 6
But was: 7
we now print:
1) Test Failure : Xamarin.iOS.Tasks.TargetTests.GetReferencedAssemblies_Executable
References
Expected: equivalent to < "mscorlib.dll", "MyLibrary.dll", "System.Core.dll", "System.dll", "System.Xml.dll", "Xamarin.iOS.dll" >
But was: < "mscorlib.dll", "MyLibrary.dll", "System.Core.dll", "System.dll", "System.Drawing.Common.dll", "System.Xml.dll", "Xamarin.iOS.dll" >
* [tests] Adjust Xamarin.MMP.Tests.AssemblyReferencesTests.ShouldNotAllowReference_ToSystemDrawing.
The test was verifying that referencing System.Drawing.dll and trying to use
System.Drawing.RectangleF would fail to compile (because System.Drawing.dll
shouldn't be resolved in this case).
The addition of System.Drawing.Common.dll breaks this assumption, because now
we ship System.Drawing.RectangleF, so the code that was supposed to fail to
compile works just fine instead.
So modify the test to verify that there's no System.Drawing.dll in the final
bundle.
* Remove workarounds for mono/mono#13483.
* [msbuild] Create a way out if automatically referencing System.Drawing.Common.dll causes problems.
* [msbuild] Adjust variable name and boolean logic according to review.
Fixes these test failures:
1) Test Failure : Xamarin.iOS.Tasks.NativeReferencesNoEmbedding("iPhone").FrameworksEmbeddedProperly(True)
#RunTarget-ErrorCount
linker command failed with exit code 1 (use -v to see invocation)
Native linking failed, undefined symbol: _CLLocationCoordinate2DMake. Please verify that all the necessary frameworks have been referenced and native libraries are properly linked in.
Native linking failed. Please review the build log.
Expected: 0
But was: 3
2) Test Failure : Xamarin.iOS.Tasks.NativeReferencesNoEmbedding("iPhone").ShouldNotUnnecessarilyRebuildFinalProject(True)
#RunTarget-ErrorCount
linker command failed with exit code 1 (use -v to see invocation)
Native linking failed, undefined symbol: _CLLocationCoordinate2DMake. Please verify that all the necessary frameworks have been referenced and native libraries are properly linked in.
Native linking failed. Please review the build log.
Expected: 0
But was: 3
Fixes https://github.com/xamarin/xamarin-macios/issues/5974.
Fixes these test failures:
1) Test Failure : Xamarin.iOS.Tasks.NativeReferencesNoEmbedding("iPhone").FrameworksEmbeddedProperly(True)
#RunTarget-ErrorCount
linker command failed with exit code 1 (use -v to see invocation)
Native linking failed, undefined symbol: _CLLocationCoordinate2DMake. Please verify that all the necessary frameworks have been referenced and native libraries are properly linked in.
Native linking failed. Please review the build log.
Expected: 0
But was: 3
2) Test Failure : Xamarin.iOS.Tasks.NativeReferencesNoEmbedding("iPhone").ShouldNotUnnecessarilyRebuildFinalProject(True)
#RunTarget-ErrorCount
linker command failed with exit code 1 (use -v to see invocation)
Native linking failed, undefined symbol: _CLLocationCoordinate2DMake. Please verify that all the necessary frameworks have been referenced and native libraries are properly linked in.
Native linking failed. Please review the build log.
Expected: 0
But was: 3
Fixes https://github.com/xamarin/xamarin-macios/issues/5974.
* Initial commit of ArchiveTaskBase for macOS
* Fix namespace
* Add concrete Archive task
* Add Archive target to Xamarin.Mac.Common.targets
* Remove TODOs for non-applicable items
* Add more properties to archive Info.plist
* Add more parameters to Archive task
* Set the ArchiveDir output parameter
* Move ITunesSourceFiles parameter
* Add test
* Fix msbuild mistakes preventing archive from working
* Reorder ApplicationProperties to be at top like iOS
* Add note
* Improve error handling
* Fix archive to be loadable in Xcode
* 4 spaces to tabs
* More space -> tab
Rolf Bjarne Kvinge
monojenkins
Matthew Leibowitz
Chris Hamons
Emanuel Fernandez Dell'Oca
kiddailey
Sebastien Pouliot
Jonathan Peppers
Alex Soto
Waleed Chaudhry
Manuel de la Pena
Bruno Garcia
Oleg Demchenko
William Kent
Vincent Dondain
Alexander Köplinger
Ankit Jain
Timothé Larivière
Bernhard Urban
Sam