* [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)
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.
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
* [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.
* [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.
* 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
- https://github.com/xamarin/xamarin-macios/issues/5480
- Related: https://github.com/NuGet/NuGet.Client/pull/2572
To allow nuget to target XM Full we need to have a unique TFI (TargetFrameworkIdentifier).
However, that's a really scary change to force, so let's opt-in for now. You can set
<MigrateToNewXMIdentifier>true</MigrateToNewXMIdentifier> in your project or
MigrateToNewXMIdentifier=true msbuild project.csproj
to try it out. We can convert the opt-in to an opt-out with sufficient validation \ releases.
* Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/801867
System.Memory.dll not being copied anywhere when Roslyn package is referenced
The issue was that the XM FrameworkList was shared for the 2 profiles and there are differences.
The Full profile for instance doesn't have `System.Memory` and that causes some issues with Nuget package references.
* Updated tests to report issues against the XM Full and Mobile Framework lists
* Now using 2 separate XM FrameworkList files (updated makefile) since the list of assemblies is different and that's expected by the mono team.
One mono bump (6f2ebedb74 (diff-e801bb766cbaad95b50b1487b865f971)) changed our `Xamarin.iOS-FrameworkList.xml.in` (and the tvOS and watchOS ones) and added 2 files
```
<File AssemblyName="System.Buffers" Version="4.0.99.0" />
<File AssemblyName="System.Memory" Version="4.0.99.0" />
```
Around the same time this change was made in the IDE: e355f65870/main/src/core/MonoDevelop.Core/MonoDevelop.Core.Assemblies/TargetFramework.cs (L260)
That means that VSMac, when creating a new cache file listing the assemblies, won’t scan the assemblies in those directories `/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS`.
This resulted in an incomplete cache file missing most assemblies leading to the IDE showing red checkmarks for known and installed assemblies.
Ideally the FrameworkList files we ship should have a list of all the assemblies with PublicKeyToken and friends (the framework shouldn't be lazy and expect the IDEs to generate that file for us).
This commit ships a test using the same logic as the IDE to populate the FrameworkList file. The test will report any missing assembly and print the xml element that should be added to the file.
E.g: `<File AssemblyName="FSharp.Core" Version="3.98.4.0" PublicKeyToken="b03f5f7f11d50a3a" ProcessorArchitecture="MSIL" />`
Then it's only a matter of copy/pasting that (:
Note: even though this is the msbuild tests for iOS land I'm also scanning the Xamarin.Mac files here for simplicity.
We also scan all assemblies in `/Facades`.
Discussed in slack but adding all the facades assemblies doesn't compromise the project in the IDE (e.g: we still can't add incorrect assemblies) and it's required for some NuGet conflict resolution.
See: ac8fd9e60a
- 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
The problem is that AppBundleDir never gets defined for library projects.
Luckily, _AppBundleName and AppBundleExtension are always defined and
all we need is the directory name (i.e. MyApp.app), so this will work
just fine.
Fixes issue #5129
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.
```
* [msbuild] Fix SceneKit asset compilation. Fixes#3766.
It seems SceneKit assets must be compiled into a directory whose parent
directory is named like the app.
In addition the `--resource-folder-path` argument is required.
Fixes https://github.com/xamarin/xamarin-macios/issues/3766.
* [msbuild] Use AppBundlePath to get correct .app[ex] variant.
* [msbuild] Fix XM builds.
* [msbuild] Use AppBundleDir instead of AppBundlePath.
* [msbuild] Fix SceneKit asset compilation. Fixes#3766.
It seems SceneKit assets must be compiled into a directory whose parent
directory is named like the app.
In addition the `--resource-folder-path` argument is required.
Fixes https://github.com/xamarin/xamarin-macios/issues/3766.
* [msbuild] Use AppBundlePath to get correct .app[ex] variant.
* [msbuild] Fix XM builds.
* [msbuild] Use AppBundleDir instead of AppBundlePath.
We don't need to use a custom mono to run the generator anymore, so stop doing
it.
Unfortunately we can't remove the custom mono, since we're now using it for
another purpose (AOT-compiling XM apps).
Fixes https://github.com/xamarin/xamarin-macios/issues/3675.
In Xamarin.iOS.Common.targets, just before the _CompileToNative target, we
modify the mtouch references to ensure that we get the lib assemblies for
nugets, and not the ref references:
9e31d07ecc/msbuild/Xamarin.iOS.Tasks.Core/Xamarin.iOS.Common.targets (L784-L791)
This logic removes nuget references, and then re-adds any copy-local dll
references.
This works fine in executable projects, but not in library projects (aka
extensions), because nugets aren't copied for library projects:
cf4b0a12cf/src/Microsoft.NuGet.Build.Tasks/Microsoft.NuGet.targets (L86)
So we need to set the CopyNuGetImplementations variable to 'true' for our
library projects.
Fixes https://github.com/xamarin/xamarin-macios/issues/4235.
Fixes https://github.com/xamarin/xamarin-macios/issues/4237.
* [tests] Redirect MSBuildExtensionsPath to MSBuildExtensionsPathFallbackPathsOverride when running msbuild for package reference tests.
This fixes a problem where nuget restore would fail for projects with
PackageReferences, because a variable would be empty and msbould would try to
write to /:
nuget restore ../MyAppWithPackageReference/MyAppWithPackageReference.csproj
MSBuild auto-detection: using msbuild version '15.0' from '/Library/Frameworks/Mono.framework/Versions/Current/lib/mono/msbuild/15.0/bin/'.
Restoring packages for /Users/builder/jenkins/workspace/xamarin-macios-pr-builder/msbuild/tests/MyAppWithPackageReference/MyAppWithPackageReference.csproj...
Committing restore...
Generating MSBuild file /MyAppWithPackageReference.csproj.nuget.g.props.
Path / is a directory
This will become unnecessary when PR #4111 is merged.
* Add Xamarin.Mac test showing that fix is not needed (?!?)
* Add AppExtension test with packagereference
* Make extension actually have json code generated
* Fix ProjectTypeGuids of checked in extension projects, as they were not openable in VSfM
* XM extension test now correctly fails
* Now that we have a failing test, fix XM same as rest of platforms
* Disable XM tests due to msbuild redirect sadness
* Disable iOS tests as well due to #4110
* Disable iOS tests by using the Ignore attribute.
Disable tests by using the Ignore attribute, because just commenting out the
TestCase attributes makes the test fail:
1) NotRunnable : Xamarin.iOS.Tasks.ProjectReferenceTests.BasicTest
No suitable constructor was found
* [msbuild] Set 'CopyNuGetImplementations' to true for app extensions. Fixes#4235 and #4237.
In Xamarin.iOS.Common.targets, just before the _CompileToNative target, we
modify the mtouch references to ensure that we get the lib assemblies for
nugets, and not the ref references:
9e31d07ecc/msbuild/Xamarin.iOS.Tasks.Core/Xamarin.iOS.Common.targets (L784-L791)
This logic removes nuget references, and then re-adds any copy-local dll
references.
This works fine in executable projects, but not in library projects (aka
extensions), because nugets aren't copied for library projects:
cf4b0a12cf/src/Microsoft.NuGet.Build.Tasks/Microsoft.NuGet.targets (L86)
So we need to set the CopyNuGetImplementations variable to 'true' for our
library projects.
Fixes https://github.com/xamarin/xamarin-macios/issues/4235.
Fixes https://github.com/xamarin/xamarin-macios/issues/4237.
* [tests] Redirect MSBuildExtensionsPath to MSBuildExtensionsPathFallbackPathsOverride when running msbuild for package reference tests.
This fixes a problem where nuget restore would fail for projects with
PackageReferences, because a variable would be empty and msbould would try to
write to /:
nuget restore ../MyAppWithPackageReference/MyAppWithPackageReference.csproj
MSBuild auto-detection: using msbuild version '15.0' from '/Library/Frameworks/Mono.framework/Versions/Current/lib/mono/msbuild/15.0/bin/'.
Restoring packages for /Users/builder/jenkins/workspace/xamarin-macios-pr-builder/msbuild/tests/MyAppWithPackageReference/MyAppWithPackageReference.csproj...
Committing restore...
Generating MSBuild file /MyAppWithPackageReference.csproj.nuget.g.props.
Path / is a directory
This will become unnecessary when PR #4111 is merged.
* Add Xamarin.Mac test showing that fix is not needed (?!?)
* Add AppExtension test with packagereference
* Make extension actually have json code generated
* Fix ProjectTypeGuids of checked in extension projects, as they were not openable in VSfM
* XM extension test now correctly fails
* Now that we have a failing test, fix XM same as rest of platforms
* Disable XM tests due to msbuild redirect sadness
* Disable iOS tests as well due to #4110
* Disable iOS tests by using the Ignore attribute.
Disable tests by using the Ignore attribute, because just commenting out the
TestCase attributes makes the test fail:
1) NotRunnable : Xamarin.iOS.Tasks.ProjectReferenceTests.BasicTest
No suitable constructor was found
* [msbuild] Set 'CopyNuGetImplementations' to true for app extensions. Fixes#4235 and #4237.
In Xamarin.iOS.Common.targets, just before the _CompileToNative target, we
modify the mtouch references to ensure that we get the lib assemblies for
nugets, and not the ref references:
9e31d07ecc/msbuild/Xamarin.iOS.Tasks.Core/Xamarin.iOS.Common.targets (L784-L791)
This logic removes nuget references, and then re-adds any copy-local dll
references.
This works fine in executable projects, but not in library projects (aka
extensions), because nugets aren't copied for library projects:
cf4b0a12cf/src/Microsoft.NuGet.Build.Tasks/Microsoft.NuGet.targets (L86)
So we need to set the CopyNuGetImplementations variable to 'true' for our
library projects.
Fixes https://github.com/xamarin/xamarin-macios/issues/4235.
Fixes https://github.com/xamarin/xamarin-macios/issues/4237.
* [tests] Redirect MSBuildExtensionsPath to MSBuildExtensionsPathFallbackPathsOverride when running msbuild for package reference tests.
This fixes a problem where nuget restore would fail for projects with
PackageReferences, because a variable would be empty and msbould would try to
write to /:
nuget restore ../MyAppWithPackageReference/MyAppWithPackageReference.csproj
MSBuild auto-detection: using msbuild version '15.0' from '/Library/Frameworks/Mono.framework/Versions/Current/lib/mono/msbuild/15.0/bin/'.
Restoring packages for /Users/builder/jenkins/workspace/xamarin-macios-pr-builder/msbuild/tests/MyAppWithPackageReference/MyAppWithPackageReference.csproj...
Committing restore...
Generating MSBuild file /MyAppWithPackageReference.csproj.nuget.g.props.
Path / is a directory
This will become unnecessary when PR #4111 is merged.
* Add Xamarin.Mac test showing that fix is not needed (?!?)
* Add AppExtension test with packagereference
* Make extension actually have json code generated
* Fix ProjectTypeGuids of checked in extension projects, as they were not openable in VSfM
* XM extension test now correctly fails
* Now that we have a failing test, fix XM same as rest of platforms
* Disable XM tests due to msbuild redirect sadness
* Disable iOS tests as well due to #4110
* Disable iOS tests by using the Ignore attribute.
Disable tests by using the Ignore attribute, because just commenting out the
TestCase attributes makes the test fail:
1) NotRunnable : Xamarin.iOS.Tasks.ProjectReferenceTests.BasicTest
No suitable constructor was found
Alex Soto
Rolf Bjarne Kvinge
Sebastien Pouliot
William Kent
monojenkins
Alexander Köplinger
Ankit Jain
Timothé Larivière
Oleg Demchenko
Chris Hamons
Vincent Dondain
Jeffrey Stedfast
Don Syme