Lack of support for UWP apps in ML.NET

[CESARDELATORRE]

Current version (0.9 and 0.10) don't support UWP apps properly.

See additional details in this Blog Post:
https://xamlbrewer.wordpress.com/2019/01/25/machine-learning-with-ml-net-in-uwp-clustering/

Related issues:
#1736
#1595

SUGGESTED APPROACH:

Usually, the common scenario for UWP apps (visual desktop applications) is just about scoring a model.
The same common scenario for ARM based platforms like Xamarin on iOS and Android.
(ARM has nothing to do with this #2252 issue, it just happens that we still don't support ARM, neither)

The suggested approach would be to split ML.NET components/NuGet packages so the scoring components are segregated from the rest of ML.NET.

Achieving support in UWP and ARM just for the "scoring part" of ML.NET might be easier and require less cost/work in testing and development than achieving support for the whole ML.NET (training/test model area).

[TomFinley]

Hi @CESARDELATORRE this has been a longstanding desire. As you observe, the predicting logic is trivial compared to the training logic, in terms of complexity along pretty much every conceivable dimension -- e.g., it takes thousands upon thousands of lines of code to write a good linear predictor, but about two lines of code to write the dot product necessary to predict with it. 😄 So this seems like a great idea, just a fair amount of work. We'd want to not only separate trainers from their associated model parameters, but also estimators from their associated transformers, etc., etc.

Considering that it is so much work, I have a question about whether it can be delayed a bit. One question though: would this be considered a breaking change in the API? So let's imagine you have two classes A and B in a single assembly and nuget, and you decide in a later version, "I am going to put A in nuget X and B in separate nuget Y," is that considered just fine from .NET perspective?

Just wondering if this is something we'd need to prioritize somehow as something that must happen prior to v1, and how completely. (E.g., if we could do it in stages and it is not considered a breaking change, we could perhaps do the most popular things first before moving to everything else, etc.)

[markusweimer]

An alternative approach to consider is to emit prediction pipelines as code. @interesaaat leads a research effort in that direction called Pretzel. It might be time to act on that research?

[CESARDELATORRE]

@TomFinley - Since it'll be breaking the compilation, I think it can be considered a breaking change..
Splitting the "scoring" assemblies from the training bits should be done as soon as possible, in my opinion. It will give us a lot more flexibility when incrementally updating/improving in areas like UWP, Unity and ARM support.

[sharpwood]

When will ML.NET officially support UWP? UWP is Microsoft's latest development framework. This project does not even support UWP? @TomFinley

[XamlBrewer]

The ML.NET v0.11.0 NuGet package largely supports UWP (and that is just awesome).

There's still one big issue: compiling a Release build fails. (ilc.exe code 1200).

Reproduction steps:

• create UWP app in Visual Studio 2017,
• add NuGet package,
• set to Release mode,
• compile.

[ianier]

Hi @TomFinley, I agree with @sharpwood that UWP should be treated as a first class citizen. In my opinion this issue should be given much higher priority and addressed before RTM.

[codemzs]

CC: @abetaha