search

dotnet / fsharp

The F# compiler, F# core library, F# language service, and F# tooling integration for Visual Studio
https://dotnet.microsoft.com/languages/fsharp
MIT License
3.94k stars 788 forks source link

F# Support in .NET Native and UWP #1096

Closed NumberByColors closed 7 years ago

NumberByColors commented 8 years ago

Update

See this comment

There is now an official solution by Microsoft to put a .NET/Win32 app in the Windows Store that does not require the use of UWP APIs, Xamarin, React Native, or even changes to your existing F#/.NET code, because they removed the requirement of UWP APIs and .NET Native for Windows Store apps: Desktop to UWP Bridge.

Microsoft has basically modified the Windows Store in Windows 10 to support “Desktop” apps that are not using the UWP APIs. They just need to be packaged as UWP apps and they will even run on ARM devices (through x86 emulation) that run the recently announced Windows 10 for ARM in the future,

Original Issue

We’ve been working on adding F# support to the .NET Native compiler. When this work is finished, you’ll be able to write Portable Class Libraries in F# that can be used from Universal Windows apps, which are compiled with .NET Native. Since the .NET Native compiler is closed source, this issue is here as a way to share status regularly from the Microsoft team.

As some background, .NET Native is a compiler that turns .NET IL code directly into native code ahead-of-time, rather than just-in-time. If you hear “.NET Native doesn’t support F#,” what’s meant is “.NET Native doesn’t support all of the IL produced by the Visual F# compiler.”

Outline of the work required

  1. Identify the specific work required for .NET Native to support F# - In progress
  2. Implement the corresponding bug fixes and new features in the .NET Native and Visual F# compilers - In progress
  3. Implement whatever is necessary in Visual Studio to support source code, projects, and assemblies for F# Portable Class Libraries in Universal Windows apps - Not yet started.

    Identifying the specific work required

There are two kinds of issues we’re looking into: issues which we’ve confirmed by observing failing .NET Native compilations of F# IL; and issues we expect to have, but haven’t yet confirmed.

David (@numberbycolors) and Kevin (@KevinRansom) have spent several weeks working to compile the fsharp test suite with .NET Native. Most tests compiled without problems: 18 of the 23 unit tests with the coreclr tag. Several issues have been encountered in the other 5 failing tests:

There are other issues which we expect to encounter, but still need to confirm in other tests:

The next step is implementing the corresponding fixes and features in the .NET Native and Visual F# compilers. This work will be prioritized against the other work going on in .NET Native and Visual F#. Since the total amount of work is still unknown, we don’t have an estimate for when this F# support will be finished and delivered.

Some of these features and fixes have already been underway for months. While we’ve been investigating F#-specific issues in .NET Native, the team has continued to improve .NET Native. One feature known as “universal shared generics” is likely to have improved .NET Native’s support for F#, even without that being an explicit goal of the feature. Learn more about universal shared generics here.

Implement Visual Studio changes

Once the changes are made to the .NET Native and Visual F# compilers, the Visual F# team will need to do some work in Visual Studio to make sure F# projects behave correctly in Universal Windows app solutions.

forki commented 7 years ago

You have to realize that companies, organizations, and developers (👼) have over a decade of investment in this stack.

into what stack? UI frameworks on windows came and go like crazy.

Mike-E-angelo commented 7 years ago

into what stack? UI frameworks on windows came and go like crazy.

Indeed. I mean .NET in general. While not UI specifically, I refer to not only the knowledge gained by working with it, but code (which is encapsulated knowledge). The idea/concept here is the cost savings realized when being able to leverage knowledge yielded from one tier into another -- much like you can do with NodeJS/React right now. Silverlight was the premiere example of this on the .NET side as it was able to reach into other, non-Windows platforms.

charlesroddie commented 7 years ago

Can we keep the thread on topic please? This thread about standard F# UWP applications, which work when compiled normally to IL, but not when compiled with .NET Native, and therefore cannot be released on the Windows Store. Unless XYZ javascript frameworks are a means to compile F# UWP and Xamarin applications to machine code to allow release on the Windows Store, then they don't solve this problem.

@psfblair interesting that lack of support for deeply nested generics is similar to the bug mentioned by @NumberByColors at the beginnig of the thread (which of those bugs still remain now?). Is it possible to workaround by avoiding using this type of code in F#? At any rate the fact that IL2CPP works on some code suggests they are doing better than .NET native.

forki commented 7 years ago

Can we keep the thread on topic please?

tbh realistically @cartermp should close it as won't fix.

OnurGumus commented 7 years ago

@Mike-EEE, off topic but need to clarify, i meant winrt which are language agnostic com components. WinJS was just a JavaScript library invented by Microsoft without looking what the rest of the world was doing and this failed inevitably. WinJS also runs in regular browsers.

Krzysztof-Cieslak commented 7 years ago

All you guys want is Microsoft stamp of approval. Can we just get @cartermp to say Fable + React Native is fine and everyone will be happy.

KevinRansom commented 7 years ago

Ahead of Time compilation of F# is a goal but not yet a priority of the F# team. There are a number of .NetNative toolchain issues to iron out, for example .tail Tail calls are a big deal in F# and almost non-existent in C#. Therefore those code paths are likely to be full of bugs that will be tricky to fix. We have a lot to do that is higher priority and more broadly impactful right now.

forki commented 7 years ago

As I said. Close as "won't fix" is most honest thing to do.

OnurGumus commented 7 years ago

@KevinRansom and why don't you ignore tail calls for the time being? (I asked this question so many times but never received any response)

forki commented 7 years ago

Because then excuses are gone. ;-)

(Javascript does not have tail calls - fable still works somehow. Magic ;-) )

dsyme commented 7 years ago

@KevinRansom and why don't you ignore tail calls for the time being? (I asked this question so many times but never received any response)

This would be the correct thing to do to unblock the use of F#. Taking "tail." instruction tailcalls is not critical for app programming as long as the developer preparing the app knows that they are not being taken and can workaround the cases where they are critical.

KevinRansom commented 7 years ago

It’s not the only problem. There were issues around generics, with the coreclr pre-allocating all possible generics instead of generating them dynamically, bloating the size of assembies … and other stuff that I don’t even recall right now. The issue is making the time to figure out what all of the current issues are. Doing that means some other work has to go on the back burner.

We took the decision that other priorities trump this. I will work on Phillip to take over the investigation, since David was the guy on point for it, however, he too has other work to do.

Kevin

OnurGumus commented 7 years ago

I have a hypothetical question. Is it possible to craft a special version of F# compiler and libraries so that all F# generated generics are erased and thus making AOT happy?

dsyme commented 7 years ago

@KevinRansom My impression was that F# libraries would likely work immediately in UWP (not coreclr native code gen) if tail. was ignored. I think it's up to the UWP team though, not the Visual F# Tools team. It's not a compiler problem, it's a runtime problem.

To be honest, it appears UWP is simply not implementing the .NET specs correctly - tail. has been in all editions of the ECMA 335 CLI Standard... Mind you, generics have also been in that standard, with no mention of "limits of 7 deep" or anything like that. I'm always somewhat surprised when I see adhoc limitations that incorrectly implement the ECMA standard - I really thought that was a standard which mattered.

@OnurGumus

I have a hypothetical question. Is it possible to craft a special version of F# compiler and libraries so that all F# generated generics are erased and thus making AOT happy?

Yes and no. We used to have a system that ran F# code on .NET 1.x by erasure and inserting lots of boxing, and no type passing. I think it's feasible but quite hard to resurrect.

charlesroddie commented 7 years ago

@KevinRansom Of course the F# team has a huge amount of work to do with all the changes in .NET and VS, and some of this is obviously urgent. But to say that what is now the main Windows application platform is not yet a priority is hard to understand. Hundreds of people have been wanting to use F# code in UWP apps for years and this includes some well known applications and developers. So I think you are underestimating how much this problem is weighing down F#.

We are the patient ones that are left. We are happy with basic support without tailcalls, and we are happy to work around bugs and limitations. Just give us something alpha quality and we can take it from there.

cartermp commented 7 years ago

@charlesroddie Part of the problem - well, the problem around this as a whole - is that there's very little we can technically do aside from diverting our own work and effectively being developers on the .NET Native toolchain itself. There may be work we could do in the F# compiler to make the IL it emits easier for the .NET Native toolchain, but eventually it comes down to that backend compiler being able to understand the IL we emit. That team is working on .NET Standard 2.0 support (as are we), and must move as the general .NET platform moves. Lack of support for .NET Standard 2.0 would cut off the entire UWP ecosystem from the place where the .NET platform is evolving, so they work must happen and must happen right now. This is at the expense of preliminary F# support.

charlesroddie commented 7 years ago

@cartermp That's an interesting angle. Now... in theory... if DNN is working on .NET Standard 2.0, and F# is working on .NET Standard 2.0, and .NET Standard 2.0 is a standard, then if they are both successful then DNN will support F#. Maybe with a bit of "coordination" you can make the theory come true?

Another thought occurs that they could flip a switch to enable compilation. Then we will get more useful errors than "F# is not supported" and can help work out what the issues are. Of course they could also flip a switch to bypass .net native comipilation altogether but that would be too easy!

cartermp commented 7 years ago

@charlesroddie Yes, this is something which may end up being good, though I'm not sure how it solves some of the current issues with understanding the IL we emit. From a targeting standpoint, things are certainly easier. The answer to how you create any class library which runs on UWP is "use .NET Standard 2.0". A simpler story most likely means simpler work overall for that team.

In terms of flipping a switch, AFAIK there's a flag you can set in the targets file which will enable compilation, but bypassing .NET Native compilation altogether would not be possible. It's currently not possible to push to the Windows Store unless it runs through that toolchain. At least that's my current understanding of Windows Store apps.

dsyme commented 7 years ago

Part of the background is that, historically, some teams have implemented subsets of the .NET (by which I mean the ECMA 335 Standard). These subsets have historically had various limitations not subject to a public technical governance process. It's a problem with .NET technical governance that I believe is now being more systematically dealt with.

Here are some personal recollections about this (my opinions, not Microsoft's)

AFAICR this started back with the variant of .NET that was supported in-process in SQL Server. There were random restrictions imposed by some SQL Server "verifier" that checked that, for example, static class constructors didn't access fields outside their class. That restriction wasn't documented anywhere, and meant that the ECMA 335 standard wasn't supported correctly, and so innocent tool developers (such as those writing code generators or compilers) simply ended up generating invalid IL. Some assemblies loaded into SQL Server. Some didn't. You just had to suck it and see, and put random hacks into your compiler to make it generate code that satisfied that particular system.

This pattern has repeated itself over the years, e.g.

Mono has had some issues but has generally been pretty good at implementing the whole standard (ok, there are still some issues with some tailcalls), and trying hard to do that for Xamarin targets too. That's one reason why F# on Xamarin fares better than F# on these other targets. (kudos to @migueldeicaza and team)

We at Microsoft have sometimes not seen completeness (i.e. implementing the whole ECMA spec) and design integrity (i.e. no undocumented adhoc limitations) as sufficiently important. These things do matter: every time you miss something in the implementation of a standard, a hundred puppies die (joke - I've nothing against puppies :) )

Some problems also lie with ECMA 335 itself. Some features in that standard are hard or impossible to implement, especially if you aim to do native code generation without a JIT (though again Mono/Xamarin have achieved this pretty well). Tailcalls can be quite tricky, and some aspects of generics too. We should have predicted this. We should have avoided using these constructs in .NET libraries (e.g. generic virtual methods) or as an essential part of F# code generation (e.g. tailcalls) But equally, I do wish that we had adjusted the standard appropriately - and there should have been a public technical governance process in place to allow that to happen.

Of course, standardization and overly rigid technical governance can have problems too. But you can also get situations where individual teams are empowered to cut features to meet deadlines, or to add restrictions to simplify matrix testing, and that needs an over-arching technical governance process to ensure completeness and integrity.

Things are improving greatly with .NET Standard 2.0. But things like tailcalls or proper support for .NET Generics or whatever can still slip through the cracks. F# can get hit badly by this, though there are normally good workarounds - Xamarin, Fable, VSCode etc.

I hope that going forward the .NET architects now take a much more robust point of view about what it means to implement .NET Standard 2.0 properly and completely. This applies particularly to native code generation scenarios (including tailcalls and full support for generics).

And if, for some reason, it is impossible to implement .NET ECMA 335 properly, then the .NET architects should clarify some "officially recognized subset" of .NET and call it ".NET Standard Native" or whatever, and supply an automated verifier to check if code lies in that subset. But it should be an official subset, not adhoc.

carlpaten commented 7 years ago

@dsyme this was an absolutely brilliant answer. I know this is off-topic, but are there any books or blogs which you would recommend to learn about technical governance?

dsyme commented 7 years ago

@lilred No, I don't know of any specific blogs or books, sorry. Anyone have recommendations?

forki commented 7 years ago

@dsyme I think you are right. But unfortunately "in the millions" seems to define the defacto standard. For the rest there is zero priority. After .NET core 2.0 threre will be the next important thing that comes first. It's just pointless to discuss in such issues. We can't get something actionable from this. Someone needs to take a whip and and go to certain offices.

Mike-E-angelo commented 7 years ago

We can't get something actionable from this. Someone needs to take a whip and and go to certain offices

Not to mention/kindly remind everyone that this thread is the destination of the official public feedback tool from UWP, where it clearly states that this is being worked on ("Working On It"), when, in fact, it sounds like it isn't.

charlesroddie commented 7 years ago

@dsyme This could be promising if something comes of it: Proposed .NET Standard Review Body "If a library is written in pure IL (for example C#, VB.NET, F# etc.), and targets .NET Standard, then it can run across all current and future .NET platforms with no code changes."

dsyme commented 7 years ago

@dsyme This could be promising if something comes of it: Proposed .NET Standard Review Body

Thanks, that's a super-helpful link.

psfblair commented 7 years ago

If I might add a case in which F# fails for compilation to UWP: F# core references the System.Net.WebClient class, which is not supported in UWP.

Details:

If I use Unity's Mono scripting back-end to try to compile an F# project for Windows Store, I get the error:

System.Exception: Exception while processing System.Net.WebClient System.Net.WebClient Microsoft.FSharp.Control.WebExtensions/WebClient-Download@2256-1::this, error Failed to resolve System.Net.WebClient

This happens even if I include a reference to System.Net.dll. Some research on the Internet indicates:

".NET for UWP apps includes only a subset of the types provided in the full .NET Framework.... For example, the IPHostEntry class in the System.Net namespace is not available to be used in a UWP app: https://msdn.microsoft.com/en-us/library/system.net.iphostentry%28v=vs.110%29.aspx.

If you look at the 'Version Information' section on the above MSDN link, you see that the class is available only the full .NET Framework only. The version information should list "Universal Windows Platform" for supported types..."

dsyme commented 7 years ago

If I might add a case in which F# fails for compilation to UWP: F# core references the System.Net.WebClient class, which is not supported in UWP.

Which version of FSharp.Core are you referencing?

psfblair commented 7 years ago

I've seen this behavior in 2.3.0.0, 4.3.0.0, 4.3.1.0 and 4.4.1.0.

dsyme commented 7 years ago

@psfblair When attempting to compile for UWP I believe you should be using an appropriate Portable Profile PCL, e.g. the reference to WebCLient is not included in version 3.78.41.0, the Profile 78 portable-net45+netcore45+wp8 profile. That DLL should be used both at compiler time and runtime

(As mentioned in the thread you're likely to hit other issues in any case - but please report back the next problem. Perhaps removing "tail." from FSharp.Core using an ILDASM/grep/ILASM cycle may help.)

charlesroddie commented 7 years ago

In terms of flipping a switch, AFAIK there's a flag you can set in the targets file which will enable compilation

@cartermp I would like to try this. Can you give any more info? Thanks

21c-HK commented 7 years ago

While I am still hoping that .NET Native will support F# in the future (for other use cases than creating a UWP app just to be able to deploy it to the Windows Store), there is now an official solution by Microsoft to put a .NET/Win32 app in the Windows Store that does not require the use of UWP APIs, Xamarin, React Native, or even changes to your existing F#/.NET code, because they removed the requirement of UWP APIs and .NET Native for Windows Store apps: Desktop to UWP Bridge.

Microsoft has basically modified the Windows Store in Windows 10 to support “Desktop” apps that are not using the UWP APIs. They just need to be packaged as UWP apps and they will even run on ARM devices (through x86 emulation) that run the recently announced Windows 10 for ARM in the future, which is rumored to replace the Windows 10 Mobile edition completely. Now that the .NET Native restriction for Windows Store is worked around by use of the Desktop to UWP Bridge, Microsoft should just remove the .NET Native requirement for Windows Store completely. I haven't tested this for F#, but I would be really surprised if this does not work since even Win32 apps are supported. Maybe some one can try it and post their results here.

From the introduction of Desktop to UWP Bridge:

The Desktop Bridge is a set of technologies that help you to convert your Windows desktop application (for example, Win32, Windows Forms, or WPF) or game to a UWP app or game. A converted app is packaged, serviced, and deployed in the form of a UWP app package (an .appx or an .appxbundle) that targets Windows 10 Desktop. There are two parts to this technology. The first part is the conversion process that takes your existing binaries and repackages them as a UWP package. Your code is still the same, it's just packaged differently. The second part comprises runtime technologies in the Windows Anniversary update that enable a UWP package to have executables that run as full trust instead of in an app container. This technology also gives a converted app a package identity. Your app will need that identity to use some UWP APIs.

Mike-E-angelo commented 7 years ago

Way to think creatively, @21c-HK. 👍 🎉

charlesroddie commented 7 years ago

Getting on the Windows Store with F# is not 100% impossible.

For mobile-first apps you can make Windows 8.1 store apps (directly or via Xamarin.Forms), and they will work on Windows 10, although component support for Windows 8.1 apps is dying.

With the desktop to UWP bridge, you can put desktop apps on the store, but that is really a different class of app with a different set of components and a different framework. If your intention is to make traditional desktop apps and have the security and updating mechanism of the store, then it's a good bet.

I don't think it's possible to take a UWP (non-native) app, extract an executable, and package it with the desktop to UWP bridge. If it were, this would be a workaround to the .NET Native requirement.

charlesroddie commented 7 years ago

The next steps seem very straightforward:

  1. Flip the switch on .NET Native to allow (potentially buggy) compilation and avoid the error "GK0025 FSharp support is not yet implemented but is used by 'FSharp.Core'"
  2. Get .NET Native to ignore the .tail instruction instead of failing when it encounters the .tail instruction (if that is what it does)

(Assuming that the easy solution of optional .Net Native is politically impossible.)

Can you communicate this to the .NET Native team please?

jahio commented 7 years ago

I found this thread tonight while looking for information about how to build a UWP application using F# in Visual Studio Community 2017. I kept seeing lots of references to C# .NET and VB.NET for this purpose, but suspiciously F# was missing. Which made me curious:

... CAN you build a Universal Windows Platform native application with F#?

And then I found this thread. _I now regret investing any time in examining F# as a future development platform for any purpose_. I'll probably never pay attention to it again, and I worry about the sincerity of any of Microsoft's future developer endeavors.

Please understand: I have nothing but love + respect for those of you "in the trenches" making this magic real. You're building some pretty incredible stuff lately over there at Microsoft; in fact it's definitely made me, as an OSS/Linux developer sit up and pay attention like never before.

But relative to the other major "holy cow that's awesome" releases from Microsoft across all teams/departments/initiatives in the last year or two, it's clear that management doesn't consider F# a priority. Otherwise we'd see more than a mere 84 comments in a thread over year old reflecting essentially zero progress. If this was important to Microsoft, we'd have working code by now.

In fact, relative to progress in other areas, this signals to the community that Microsoft's next development language/product/whatever could wind up abandonware. Thus, investing in Microsoft's next such endeavor is risky and ill-advised. Will they just ignore the big, massive must-have features necessary to make using "it" worthwhile like they did here, and if so, how much startup funding will be wasted and how long does it set us back when we have to start over with a language somebody actually maintains?

"So, Bob, heard about that new programming language Microsoft just released? Looks pretty great!"

"Yeah, but given how they neglected F# and a dozen other things, let's skip it and write our new application in LOLELECTRONSHELLCUZPERFORMANCE, it'll be sweeeeeeeet!"

😢

OnurGumus commented 7 years ago

@jaustinhughey, your point of view is wrong. F# doesn't need Microsoft. It has a healthy and self sustainable community. What you should avoid is UWP. Even Microsoft abandoned uwp, almost.... They instead bet on Windows on ARM now.

charlesroddie commented 7 years ago

@OnurGumus There is no evidence that microsoft has abandoned UWP. Microsoft's whole cross-platform strategy is based around UWP. The need for UWP support is more and more critical as Windows 8 store technology is abandoned. To run Xamarin Forms apps on Windows basically requires UWP. There is no competing mobile app platform for Windows. Windows on ARM is a version of Windows for low-end devices which 1 supports UWP, 2 may not take off, and 3 hardly makes mobile touch-first development obsolete, so it is not relevant to this.

F# TEAM PLEASE RETEST F# ON THE CURRENT .NET NATIVE AND/OR ALLOW US TO DO SO.

forki commented 7 years ago

@jaustinhughey if you really care that much for F# and UWP then you can checkout "fable |> react native". seriously. it works

OnurGumus commented 7 years ago

@charlesroddie , let me tell you my findings.

Every MS product I get excited for is discarded, changed, or never reaches its potential (Zune, Surface RT, Windows Phone, Kinect, Silverlight,XNA). I've personally banned myself from getting invested in any Microsoft specific tech because I have no confidence they will be maintained for any length of time. I suggest you do the same.

OnurGumus commented 7 years ago

Oh and this UWP and .NET Native thing doesn't even work properly for C# too. Try building Syncfusion samples under release mode with latest windows 10 and vs 2017 with all updates: (https://www.syncfusion.com/products/uwp) And you get:

1>  Cleaning up unreferenced code
1>C:\Program Files (x86)\MSBuild\15.0\.Net\.NetNative\15.0.24211\x64\ilc\IlcInternals.targets(936,5): 
error : Internal compiler error: Exception of type 'System.OutOfMemoryException' was thrown.
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========
charlesroddie commented 7 years ago

@OnurGumus

Everyone, including Microsoft, knows that iOS and Android are the most important mobile platforms. Writing a dedicated piece of software to target only Windows phones and tablets rarely makes sense.

However Xamarin is in a very good state and has a lot of F# users. Judging by the Slack mobiledev channel, mobile development in F# is largely Xamarin. You have no problems making iOS and Android apps on Xamarin. With Xamarin.Forms you get a UWP app for free if you use C#, which can be used on desktops, tablets and phones. This gives amazing reach. But on F# you either need to target a dying platform (Win81) or wait a couple of years and hope that Xamarin->WPF succeeds.

I think that MS should make more use of Xamarin for its mobile apps. The Teams app for example has terrible performance and its exetensions are very tied to web technology and pretty flaky IMO. But that's up to them and these decisions haven't stopped Xamarin from becoming a solid and widely-used platform.

If you know you want a desktop app only, UWP is not important. Clearly for some of the largest and most important apps, including Office, the desktop version is most important, for good reasons, and the importance of these apps will remain. But, also for good reasons, most development of new apps out there is mobile first.

21c-HK commented 7 years ago

@jaustinhughey @OnurGumus @charlesroddie I think you are all right to some extent.

I can sympathize with each of your viewpoints and past experiences. It's true that Microsoft has messed up a lot in the recent past and that even Javascript is preferred over F# is deeply disturbing. But I think they are now getting their act together. A lot seems to have changed with the new CEO of Microsoft (Satya Nadella), who seems to be a very positive influence on Microsoft. It's clear that Microsoft has a lot of faith in Windows 10 and its related efforts. The Windows Store on Windows 10 will be the future of app deployment on Windows. I have no doubt about that.

Like others, I did not even install a single app from the old Windows Store on Windows 8/8.1 and don't know people who did, but I already have a few simple consumer apps installed from the Windows Store on Windows 10 and I am looking forward to replacing more apps with a Windows Store edition (e.g. Whatsapp). It's just really nice to have the assurance that installing a new app is not going to mess with your Windows system. Anyone who has to support Windows devices of non-technical family members knows that this is a big deal. Imagine being able to give a non-technical person a Windows device that they cannot mess up, but still being able to use true desktop apps like Office and connect devices like old printers when they need to. That's huge.

While F# does not really need Microsoft, it would still be nice to be supported as much as other .NET languages (or even Javascript).

Mike-E-angelo commented 7 years ago

What you should avoid is UWP

Said every sensible Silverlight (and .NET, for that matter) developer, ever.

❤️

Microsoft's whole cross-platform strategy is based around UWP

@charlesroddie please quote sources, or source code. 😆 This is the first I have heard of this suggested. Everything "cross platform" (or .NET, for that matter) has been Xamarin/Mono.

AFAIK no one is suggesting and/or recommending UWP. Xamarin.Forms, while neat, also has its technical challenges. It's all Noesis and Avalonia (which support F#???) from what I have seen.

forki commented 7 years ago

I cannot only repeat myself und Really wonder why you dismiss it so easily. But Fable |> reactnative gives you support for Android + iOS + uwp in the same model. ReactNative is used in big apps and works pretty well. Together with elmish you will have a nice architecture that's just not existing damaging world. It is much more than only a way to unblock yourself and much better than waiting for Microsoft to do something that might never come.

Krzysztof-Cieslak commented 7 years ago

@forki but it doesn't have "Microsoft stamp of approval" ™️

And as far as I can tell from reading this issue that's what people want.

forki commented 7 years ago

Yes like silverlight had.

Mike-E-angelo commented 7 years ago

1q8nan

cartermp commented 7 years ago

As a bit of an update @charlesroddie, unfortunately, there's no way for anyone outside of Microsoft to test it. Testing .NET Native support requires using an internal build of the toolchain, which is closed-source 😢. Additionally, we simply lack the bandwidth to do this in the near-term due to the push for .NET Core 2.0/.NET Standard 2.0.

That said, I doubt a much has changed. The most difficult parts of .NET Native support surely haven't been solved in the past few months, especially since the team there has been focused almost solely on support for .NET Core 2.0 and .NET Standard 2.0. It's fair to say that .NET Core/.NET Standard has put most other things on hold for many teams internally.

As @forki mentioned, Fable to React Native works today and is a good solution. I even endorsed it as a way forward at Build this year. I highly recommend taking a look if you want to be unblocked right now.

martinsuchan commented 7 years ago

So it's August 2017, .NET Core 2.0 and Visual Studio 2017 Version 15.3 is almost here. Any good news in the .NET Native area?

cartermp commented 7 years ago

No further news or updates on F# Support for .NET Native. There is no affinity between .NET Native, .NET Core, or VS 2017. It's an orthogonal area.

There are three options: