Recommendations for handling Console/Wpf/MonoMac/XamarinMac separation

Topics: General
Feb 16, 2014 at 3:21 PM
For MvvmCross, nuget has been working increasingly nicely over the last year across all the mobile Microsoft and Xamarin platforms - thank you :)

We're now increasingly looking at how to better support the "old school" platforms like WPF, MonoMac and XamarinMac

For each of these platforms, we seem to need to include different assemblies for things like binding and Views - just as we do with WindowsPhone, Android and iOS.

However, the problem we're currently seeing is that to these different platforms are not clear separate csproj targets (like WP, MonoTouch, etc) but are instead all "net45" projects which are distinguishable only by the assemblies they include - e.g. a MonoMac project is only distinguished from a WPF project because it links to the MonoMac assembly instead of PresentationCore.

One of our community contributors has found a way to get nuget working ok by writing duplicate nuspec files for Mac - e.g. getting users to use instead of

This works and is a fab contribution, but it means we'll need to publish three times as many packages to nuget and it means users will get confused about which packages they are supposed to use (because there will be 3 times as many packages in the catalog).

Looking forwards, is there any technical solution we can work out here? I know that MonoMac is already included as a nuget platform target - but it doesn't seem to be actively used. As a package publisher my ideal request would be that MonoMac, WPF, XamarinMac and Console were all somehow separate targets in a single nuspec just like WinPhone, WinStore, Android and iOS currently are.

Thanks for any suggestions anyone has

Mar 21, 2015 at 10:48 PM
I'm a little late to the party, but I have an interest in getting something like the working as well.

You said "projects which are distinguishable only by the assemblies they include", but actually, they are also distinguishable by the <ProjectTypeGuids> value (see

Right now, the correct assembly from the nuget package is based on the target framework and optionally a framework profile (like the Client profile that existed in .NET 3.5/4.0). So why not add a 3rd level of matching that looks at the project guids? You could have a table of well know project types that translates to guids in addition to just using a guid.

Right now, you can have lib\{framework name}-{profile}, so just extend this to lib\{framework name}-{profile}-{project type}. You could join multiple project types with a + like portable-x+y+z.

Then your directory structure would look something like:

The profile could still be optional, in which case you could just have a double dash like net45--wpf. Also, { is probably not the best choice to include in a directory name, but you get the idea.