Support .NET Standard & Xamarin

[YZahringer]

Migration to multi-targeting project is planned for .NET Standard & Xamarin support?

[ddobrev]

@YZahringer is completely correct, this wonderful converter is even more important for mobile applications so please support Xamarin.Forms as well.

[timothylcooke]

I have no opposition to supporting other targets. The only reason I've never made it for .NET Standard or Xamarin Forms is because I've never needed it. I've only ever worked with the full .NET framework on Windows. This project has no dependencies. I would imagine it should just work with little or no modifications. I would love it if you would submit a pull request. If not, I might get around to this eventually. If you need me to rewrite portions of the parser because .NET Standard doesn't support some classes or methods that this project uses, I'd be happy to do that.

[ddobrev]

@timothylcooke fair enough. I'll get back to you as soon as I can.

[glen-nicol]

Hi there, I am looking into updating the projects to include .net core. I can't seem to find a way to target .net standard and wpf.

While working on that there is a test failing due to string interpolation differences between framework and core. The following strings throw FormatExceptions:

• $"{(true ? x : 0):{{0}}}"
• $"{null ?? x:0.0} + {null ?? y:"{{0.0}}"} = {$"{x + y}":0.0}"

I have never used that feature so I am unfamiliar with the strings. @timothylcooke Can you provide more context on the intent for these?

Also note, when I build in 2019 it gives an error about some compiler feature missing around the dynamic keyword. This is solved by adding a nuget reference to Microsoft.CSharp. Is that okay?

For those wanting to use this in Xamarin Forms, I don't know if it will be possible on all targets because the dynamic keyword is not supported by iOS. I don't have the means to test any platforms besides framework and core. But I am setting up a SDK style project that should be easy to add new platforms.

[timothylcooke]

@glen-nicol Thanks for your interest in the project!

You might want to take a look at pull request #4 -- @RossiDiGi seems to have done a lot of the work of converting this to .NET Core, though I haven't really had time to fully dive in to it yet to see what s/he did.

You've inspired me to take a look at re-working MathConverter to eliminate the dynamic keyword altogether. I didn't realize it wasn't supported in iOS, and I've always felt like relying on dynamic was a cheap hack with some definite downsides. I've also never been happy with some of the type conversions, but I know it's going to require some significant effort to rework them. I expect I will have some availability this week to work on this, and it's a very small project (and doesn't have a UI), so I don't expect it will take that long to refactor. There are also some small shortcomings in the compiler that would be nice to fix (e.g. allowing some way to do type conversions/casting).

As far as your questions related to interpolated strings, they are a feature added in .NET 6.0, which are documented here. After having just read this documentation, I now realize I didn't very well follow the spec (as MathConverter simply converts interpolated strings into a call to string.format). Essentially, $"{x:0}" is equivalent to string.Format("{0:0}", x). Within an interpolated string, if you want the characters "{" or "}", you have to include time twice (i.e. "{{" or "}}"), just like in string.Format. So what I was aiming to do with those interpolated string tests is establish that MathConverter evaulates interpolated strings the same way that C# does (with exceptions of characters like the grave character and single/double quotation marks that MathConverter requires be backslash-escaped). Those strings are very wacky and would never really be used in real C# code.

~I'm curious to mess around with these strings if they're not compiling or throwing runtime exceptions. Can you make a Hello-World-type sample repository targeting .NET Core that throws when compiling/evaluating those statements? I'd like to mess around with it and see if I can't figure out what's wrong.~

EDIT: I'm getting FormatExceptions on these lines too. It's interesting that string.Format behaves differently in .NET Core vs full framework. I'll write some better unit tests that don't break .NET Core as soon as I get a chance.

[RossiDiGi]

My current commits on the pull request #4 allow multitargeting. The UnitTest show problems on netcore and framework.

[timothylcooke]

Hmmm, well the failed tests are no good. I'm happy with all of your changes except for I don't want to merge your changes to the readme into master. I'll try merging your changes into a separate branch, tonight and see if I can't get the unit tests to work. I'm pretty confident this will require writing different tests around the interpolated strings, since string.Format behaves differently in netcore vs framework.

[timothylcooke]

@YZahringer @ddobrev MathConverter now supports .NET Core 3.0 in the netcore branch. I've removed all dynamic code, and will merge this into master once I update the documentation and improve the demo project. Are there any other target frameworks that we should support? @glen-nicol Is there any value in building netcoreapp3.0 and netcoreapp3.1, or should we remove the netcoreapp3.1 TargetFramework?

<TargetFrameworks>netcoreapp3.0;netcoreapp3.1;net35;net40;net45</TargetFrameworks>

[YZahringer]

@timothylcooke Super! Thanks for the adaptations! Is there a reason to target netcoreapp3.0 instead of netstandard1.4 or netstandard2.0? Normally for libraries is better to target netstandard instead of netcoreapp and target the lowest version. For example, Xamarin.Forms targets netstandard2.0 and netstandard1.0.

[timothylcooke]

@YZahringer The only reason I target netcore instead of netstandard is because <UseWPF>true</UseWPF> works for netcore3.0+. Clearly that's not good enough if we want to support Xamarin.Forms. Looks like I have more work ahead of me. Thanks for letting me know.

[ddobrev]

@timothylcooke thank you for your work on this, outstanding! Furthermore, I do support @YZahringer's suggestion about netstandard as well as your noble intention to proceed with it. Keep it up!

[timothylcooke]

I've recently added support for targeting monoandroid90 (adb70ce) and uap10.0 (1c07d5c). I don't have an iPhone or a Mac, so it might take me a while to get a working solution for Xamarin.iOS. If you guys want to take a crack at it, my intuition is it ought to be somewhat easy, given that it works for monoandroid90. I used this project as a sample for implementing the Android tests.

@YZahringer @ddobrev Would it be ideal if I added additional targets for netstandard1.0 or netstandard2.0, or are those not necessary? I didn't spend a lot of time on it, but it looked like it wasn't gonna be straight-forward to add MSTest unit tests for them. Perhaps they're not needed, since we have unit tests on Xamarin.Forms for UWP and Android.

[YZahringer]

@timothylcooke I think it's not necessary to directly target each Xamarin platform. It would be possible to target all Xamarin platforms with netstandard2.0.

This would simplify targeting:

• netstandard2.0 for Xamarin
• net35;net40;net45;netcoreapp3.0 for WPF

[timothylcooke]

I just published v2.0.0-alpha0005, which targets the following frameworks:

• monoandroid90
• uap10.0
• netstandard1.0, netstandard1.3, netstandard2.0
• net35, net40, net45
• netcoreapp3.0, netcoreapp3.1

Ideally, I'd like to also support Xamarin.iOS10 and Xamarin.Mac, and get working tests for both.

[timothylcooke]

I added support for Xamarin.iOS10 and Xamarin.Mac, but in testing, I realized that we cannot target both WPF and Xamarin.Forms in the same application. On a mac, if you try to reference the MathConverter type in a MathConverter build that targets WPF and Xamarin.Forms on a Mac will result in a FileNotFoundException when trying to load PresentationFramework. I assume this is because MathConverter implements System.Windows.Data.IValueConverter. As a result, v2.0.0-alpha0006 is now split into two nuget packages:

MathConverter (which targets WPF) supports:

• net35, net40, net45
• netcoreapp3.0, netcoreapp3.1

MathConverter.XamarinForms supports:

• monoandroid90
• uap10.0
• netstandard1.0, netstandard1.3, netstandard2.0
• netcoreapp2.0, netcoreapp3.0, netcoreapp3.1
• xamarin.mac20
• xamarin.ios10

At this point, the main thing I still need to do is update the documentation. I'm debating whether or not I should deprecate the MathConverter nuget package in favor of the name MathConverter.WPF. At this point, I'm leaning towards keeping the original name.

[Slion]

Can this be used for UWP app then? Which NuGet should be used?

[timothylcooke]

Can this be used for UWP app then? Which NuGet should be used?

Sorry, @Slion, I never saw this. UWP is supported (via Xamarin.Forms). The Nuget pacakge is MathConverter.XamarinForms.

[timothylcooke]

I finally updated the documentation (among other changes). Version 2.1.0 is on Nuget. Closing this issue.