Adding the Xamarin.Mac.NET / xamarinmacnet TFM
#2572
Conversation
- `Xamarin.Mac.NET` is both `Xamarin.Mac,Version=v2.0` (preferred) AND `.NETFramework,Version=v4.5`
- Related to
- NuGet/Home#2662
- NuGet#562
- NuGet/NuGet2#47
mattleibow
changed the title
Xamarin.Mac.NET TFMXamarin.Mac.NET / xamarinmacnet TFM
|
Going through the original thread, my instinct is this is not right because xamarinmacnet45 and net45 are not fully compatible. See https://github.com/NuGet/Home/wiki/Enable-.NET-Core-2.0-projects-to-work-with-.NET-Framework-4.6.1-compatible-packages. |
|
Does PackageTargetFallback and AssetTargetFallback work with projects that use packages.config? I thought it was only for projects that use PackageReferences. |
|
It's only PackageReference. |
|
I created a test app and I tried both |
|
They are fallback target frameworks so they are only used if nothing in the NuGet package matches the project's target framework. The project in the .zip, from NuGet's point of view, has a target framework of .NET Framework 4.7.2 so if the NuGet package has .NET Framework assemblies then those will be used. |
|
Isn't that why we have this PR? To OVERRIDE the behavior of this particular TFM? |
|
The PR is to add support into NuGet for a new Xamarin.Mac.Net target framework, and to allow this target framework to support both Xamarin.Mac and .NET Framework assemblies as well as assemblies that explicitly target Xamarin.Mac.Net. However this target framework does not exist yet - work is required on the Xamarin.Mac side to define and support it. As of today a Xamarin.Mac Full project has a .NETFramework target framework. |
Based on the above comment, this is not something that NuGet can solve on it's own. Can the discussion continue on xamarin side and then loop back if/when ready. Similar to the earlier discussions/PR, I don't see this being merged in this state. Thoughts @mrward @rrelyea @anangaur @jainaashish ? |
|
/cc @chamons |
|
I've talked to @mrward and I believe xamarin/xamarin-macios#5480 describes the work needed on our end. In theory it could be a one-liner in our props file, but I have concerns on the secondary consequences \ regressions such a change might cause. In any case, the soonest such a change could ship at the earliest would be d16-1, so months away. I'll try to get a prototype out soon for testing, but even if lands today in master it'd be awhile. Would that block this PR? |
|
Dropping in to say it's cool that you have picked this back up again |
|
So we haven't had time on the Xamarin.Mac side to implement this yet, but this morning (instead of sleeping apparently), I had an idea on a way we could get this done sooner. I wrote it up here but the short version is that we should feature flag this so projects can opt-in a release earlier so we can test this out in the wild first. |
…c.NET (opt-in) - #5480 - Related: NuGet/NuGet.Client#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 <MigrateToNewXMTFI>true</MigrateToNewXMTFI> in your project or MigrateToNewXMTFI=true msbuild project.csproj to try it out. We can convert the opt-in to an opt-out with sufficient validation \ releases.
|
I have a PR implementation for what I think we need: I'll post a package shortly once it builds, but:
should do what we expect, hopefully. Feedback, 👀 's on the PR, and thoughts welcome. |
…c.NET (opt-in) (#5654) - #5480 - Related: NuGet/NuGet.Client#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.
|
Xamarin.Mac now contains a You can download the package here. This looks to make our next major release as opt-in if no one here raises any objections. We can get some testing and consider making it opt-out later if that goes well. |
|
@chamons I have tried to install you package (on a Visual Studio for Mac 8.1.5 build 9), but when I add the MigrateToNewXMIdentifier in my csproj my project didn't load anymore. Studio Ide logs contains this stack trace
|
|
@Odirb Visual Studio for Mac is not aware of the Xamarin.Mac.NET framework currently. Support for that would need to be added to Visual Studio for Mac. |
|
@mrward do you think this will be supported soon? |
|
@Odirb The problem is being tracked internally but it has not been scheduled. Whilst you could workaround the problem in Visual Studio for Mac by creating an extension which enabled the target framework the problem still remains that NuGet currently does not support this new framework. Which means you would still not be able to install a package that targets Xamarin.Mac.NET into a project in Visual Studio for Mac. |
|
Thanks @mrward for you answer. I will use an ugly workaround I have found to fix my initial issue, and wait the support for this new target framework. |
|
Any news on this PR? We are anxiously waiting on this to move forward |
|
Given the current proposal for .NET 5 TFMs, the TFMs requested in this PR will not be required. If the .NET 5 TFM design proposal falls through and these TFMs are required again, we can re-open this PR. |
Bug
Fixes: NuGet/Home#2662
Regression: No
Fix
Details: This PR adds the existing "Xamarin.Mac.NET" TFM to the set that NuGet actually supports.
More details of the TFM can be found here: https://docs.microsoft.com/en-us/xamarin/mac/platform/target-framework. But, the gist of the framework is:
The need for this specific TFM is not to actually just create another library for a NuGet package (which totally is a use case for some libraries), but also for the case where the consumer app is the full framework, but needs to use the Xamarin.Mac TFM over the .NETFramework. See this issue: mono/SkiaSharp#736
There has been a bit of discussion, but never actually went anywhere. The original issue has had 2 PRs, one against NuGet2 and one against NuGet.Core but the discussion stopped.
Adding a few of the original participants to start the discussion again: @mrward @ghuntley @chamons @joelverhagen @emgarten @mishra14 @onovotny @mhutch
Testing/Validation
Tests Added: Yes
Validation done: