The `$(_UsingXamarinSdk)` property has been renamed to help improve
external usability. This change increases parity with the Android SDK,
which currently defines `$(UsingAndroidNETSdk)` for internal and
external use.
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.
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.
* 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.
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
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
- Existing binding projects embed the native libraries within the assembly as managed resource
- This does not scale well and has performance implications
- This PR creates a new property, NoBindingEmbedding which when true processes the building and consumption of binding projects differently.
- Existing binding projects are not affected, they will continue as is
- I've written a full XM test suite and ported a subset to iOS. Since iOS only supports checked in projects, and I didn't want to make the existing situation worse by adding more, I only wrote tests that could use the existing test projects.
-When we complete some form of msbuild testing reform, we'll revisit these tests.
- Remove two files in MyiOSFrameworkBinding that are not used (we use copies elsewhere)
- Remove unnecessary sleep and fix broken touch command
- Output failing test log to console instead of test output
- VSfM does not handle thousands of lines of test failure message well
- Add ability to generate binding projects with LinkWith
Fixes https://github.com/mono/mono/issues/10602 .
From the issue:
```
We need to enable this to support the system assemblies conflict
resolution which we now rely on for any new packages to enhance
developers experience and get us out of dependency on specific package
versions.
```
- Fix XM and XI binding projects to use csc instead of mcs
- Add BindingProjectTest to verify csc not mcs for XM
- In non-msbuild use cases, removing -sdk params requires adding System/mscorlib so btouch now knows to add those references.
- Obsolete a few arguments to btouch
* Revert previous revert (9ba23946d1)
* Correctly fall back to Modern if tagless binding projects
* Rework binding tests to cover all supported configurations
* Add XM_FORCE_MSBUILD env variable for mmp/msbuild mac tests for easy local checking
- Fixes https://github.com/xamarin/xamarin-macios/issues/3608
- Refactor and clean up msbuild to be more consistent between binding and "normal" workloads
- Comment on the inconsistencies that are too large to fix in one PR
- Write some actual tests for binding projects to detect regressions
- Due to lack of redirect support these tests are only xbuild current, but I ran tests with msbuild to validate locally
* [msbuild] Pack all iOS MSBuild Task assemblies into a single assembly
* Fixed the build
* Renamed ProcessArgumentBuilder to CommandLineArgumentBuilder
This is needed to prevent symbol conflicts with Xamarin.MacDev's
ProcessArgumentBuilder (which is functionally different from
Xamarin.MacDev.Tasks.Core's class of the same name).
* Fixed ILRepack logic for filtering dll's to repack
* Fixed building of Xamarin.iOS.Tasks.Tests now that X.iOS.Tasks.dll contains all symbols
* Updated Makefile now that only 1 iOS Task assembly needs to be distributed
* ILRepack Xamarin.Mac.Tasks as well
* Fixed up *.targets to specify The One Assembly To Rule Them All
* [xharness] Build MSBuild tests with MSBuild.
* Touch the ilrepack stamp file *after* invoking ILRepack, not before.
* Same for Xamarin.Mac.Tasks
These targets were failing to build on design-time builds for mostly 2 reasons:
- When loading the project VS is not connected to the Mac, which is required for binding projects.
- Since a reduce amount of targets are ran, the ReferencePath list is empty and makes _GeneratedSourcesFileList fail
Anyway, we shouldn't run targets that we don't need on a design-time build to avoid impacting on its performance
Why these targets were being executed on design-time builds? It's a side effect of adding them to CompileDependsOn.
Reference to design-time builds: https://github.com/dotnet/project-system/blob/master/docs/design-time-builds.md#what-is-a-design-time-build
Fixes bug 387900 - Referenced component could not be found for Binding Library projects
https://devdiv.visualstudio.com/DefaultCollection/DevDiv/_workitems/edit/387900
- Significant changes to target file under msbuild, ImplicitFacade processing in particular
- Tests are disabled due to https://bugzilla.xamarin.com/show_bug.cgi?id=53164 where we can't tests local target files only global
- Requires a mono msbuild with 95ab657a90 for tests to pass
- Until then, this is a workaround:
sudo cp /Library/Frameworks/Mono.framework/Versions/Current/lib/mono/msbuild/15.0/bin/Roslyn/System.Reflection.Metadata.dll /Library/Frameworks/Mono.framework/Versions/Current/lib/mono/msbuild/15.0/bin/
Peter Collins
Rolf Bjarne Kvinge
Sebastien Pouliot
Chris Hamons
Ankit Jain
Emanuel
Jeffrey Stedfast