search

lbugnion / mvvmlight

The main purpose of the toolkit is to accelerate the creation and development of MVVM applications in Xamarin.Android, Xamarin.iOS, Xamarin.Forms, Windows 10 UWP, Windows Presentation Foundation (WPF), Silverlight, Windows Phone.
http://www.mvvmlight.net
MIT License
1.17k stars 310 forks source link

Multi-targeting & package build in .NET Standard #64

Closed jamesmcroft closed 3 years ago

jamesmcroft commented 5 years ago

Currently, it appears that the management of the packaging and build of the MvvmLight NuGet packages is done with an older mechanism of doing so (NuSpec).

While this works for the older PCL projects, .NET Standard has a very interesting feature which allows multi-targeting and NuGet package building.

With the combination of the MSBuild SDK Extras, it's possible to completely turn on multi-targeting across the current supported platforms that MvvmLight provides.

This is something that has been an effort in the XPlat Windows API project that I contribute towards (ref: https://github.com/XPlat-Apps/XPlat-Windows-APIs/blob/develop/XPlat.Storage/XPlat.Storage.csproj)

The NuGet packaging also comes for free within the csproj format. At the moment, the MvvmLight NuSpec file has some hard-coded parts to it which don't appear to be updated automatically as part of the current build and packaging mechanism which is currently being used.

This is something that I believe will help reduce the overhead of manual changes as well as keeping everything neat and tidy within a single .NET Standard project.

jamesmcroft commented 5 years ago

As a test, I created a "broken" variant of MvvmLight for .NET Standard that shows how this might work (https://github.com/jamesmcroft/mvvmlight/tree/netstandard-multi/GalaSoft.MvvmLight/GalaSoft.MvvmLight).

This wouldn't be mergable as I scraped all the code into a single project and have only made it work for .NET Standard, Xamarin and Windows (UWP).

I believe it might require a fair bit of work to move and support all the platforms, but it is definitely possible.

jamesmcroft commented 5 years ago

So I did eventually get all this working, except it doesn't support the Silverlight components at https://github.com/jamesmcroft/mvvmlight.

Again, the change wouldn't be mergeable into this repo given that I've basically stripped everything out that's not needed now that the intention would be for folks to use .NET Standard unless this is a change that @lbugnion would be willing to make.

For my own peace of mind, I've created an Azure Pipeline for the forked repo which outputs the NuGet packages and I am currently distributing this on NuGet as MADE.App.MvvmLightLibs.

As part of the changes I've made, I've merged the Android Support library into the main component. This way they can be updated as one single unit rather than two separate libraries which will make this more maintainable, however, it doesn't have to be this way. It just made more sense as in all cases where I've used MvvmLightLibs which includes an Android project, I've also taken the dependency on the Android Support component.

My fork needs a lot of work in order to structure it back to how it should be.

michael-hawker commented 3 years ago

@jamesmcroft I suppose this is part of what led to our MVVM Toolkit work, eh? Glad you helped start us down this journey. Should we close this issue?

Migration Guide to the MVVM Toolkit docs are here now: https://docs.microsoft.com/windows/communitytoolkit/mvvm/migratingfrommvvmlight

jamesmcroft commented 3 years ago

Definitely. Thanks to the work on the MVVM Toolkit, I've moved the majority of my projects over now.

Just a few lingering ones 😅