UWP-support with NetCore 2


(Niles Davis) #1

Hi guys,
from my point it is currently not possible to use Math.NET Numerics in a project based on NETCore.Platform 2.0. Am i right? Am I the only one intersted in this?

Best regards,
Nils


(Christoph Rüegg) #2

Just to make sure I don’t confuse things: NETCore.Platform is the Windows App UWP profile and has nothing to do with “.Net Core” or “.Net Standard”, right?


(Christoph Rüegg) #3

Have you tried whether Math.NET Numerics v3.20.2 works? We used to have explicit PCL builds supporting NetCore45 back then.


(Niles Davis) #4

that’s right it, you can see some more information here: https://github.com/mathnet/mathnet-numerics/issues/579


(Niles Davis) #5

I am pretty sure it’s associated with compiling it via .Net Native-Toolchain because it compiles and runs perfectly without using the toolchain


(Christoph Rüegg) #6

Have you tried calling Control.UseManaged(); before using any Numerics functionality?


(Niles Davis) #7

Yes I just did, without success. The error must definitely happen before the first numerical call as the compiler also throws these warnings: https://github.com/mathnet/mathnet-numerics/issues/579
If I run the .Net Native compiled code (as it was just a warning) the application directly exits with
“[8172] UAP_MathnetTest.exe” has exited with code -1073741515 (0xc0000135) ‘A dependent dll was not found’"


(Christoph Rüegg) #8

So it seems it matters that it’s there, not whether it is actually called or not. You’d therefore need a build where the native provider functionality is completely removed. Incidentally, the v4 packages do include one build where this is the case: the .Net Standard 1.3 builds. But not sure whether these are compatible with UWP?


(Niles Davis) #9

That sounds like it is worth a try because UWP just doesnt allow native calls. I could try the NetStandard build directly from the github repo. Perhaps I’ll get to it tomorrow. Thanks in advance for the support!


(Christoph Rüegg) #10

You can also use the build from the NuGet package (or the zip archive). Just make sure it’s the .Net Standard 1.3 one, as the .Net Standard 2.0 one does include native provider support.


(Niles Davis) #11

DAMN U SAVED MY DAY! @cdrnet that’s so great you gave me the working solution! I’ve been struggling with that issue far too long. THANK YOU
So, how do we get that working in the netstandard2 version? How to add that native provider support?
Thanks again man, that was really genious!


(Christoph Rüegg) #12

So if I understand it correctly:

  • UWP with the native tool chain requires a build where native providers are completely removed
  • UWP without the native tool chain might work with native providers (to be verified).

From a NuGet perspective, is NuGet aware of the native tool chain at all, so we could in theory provide a different build from the same package depending on the tool chain?


(Niles Davis) #13

Hi @cdrnet! I am also pretty sure that NuGet is not aware of that native toolchain. So perhaps we need 2 NuGet packages with and without the native providers. Is that feasible?


(José Manuel Nieto) #14

I have tried to certificate a Windows Universal Application using Math.NET Numerics and it has been rejected due to this:

Error Found: The supported APIs test detected the following errors

  • API c_axpy in mathnet.numerics.cuda.dll is not supported for this application type. SuppaFlight.UWP.dll calls this API.
  • API c_cholesky_factor in mathnet.numerics.cuda.dll is not supported for this application type. SuppaFlight.UWP.dll calls this API.
  • API c_cholesky_solve in mathnet.numerics.cuda.dll is not supported for this application type. SuppaFlight.UWP.dll calls this API.
  • API c_cholesky_solve_factored in mathnet.numerics.cuda.dll is not supported for this application type. SuppaFlight.UWP.dll calls this API.
  • API c_dot_product in mathnet.numerics.cuda.dll is not supported for this application type. SuppaFlight.UWP.dll calls this API.

Please, make it compatible.