Microsoft has a new compiler that claims to mix managed and native code. The video on channel nine claims that you develop normally, then at the build you specify the processor, etc. They claim significant speed improvements for certain situations. I wonder if RemObjects C# is following this and perhaps is developing its’ own version of this technology?
1 Like
For one, our .NET compiler should work fine with .NET Native. We’ll be exploring and testing, and staying on this is it matures from preview to shipping version. (not that rright now .NE Native is a preview and ONLY supports Windows Store apps).
We also have some technologies of our own in the works, which we’ll start talking about more later in the year, to bring benefits of something like .NET native to running .NET code on Windows and Mac/iOS.
Note that RemObjects C# for Cocoa (ie for native Mac and iOS apps) already generates 100% CPU-native code; it does not use .NET, Mono or any kind of managed runtime.
On Cocoa, our compiler already compiles to cpu-native ARM, or x64 code, correct. This (and anything about the compiler) applies to Oxygene and RemObjects C# (and Silver, too).
Work on Infrared is progressing nicely, but we have no timelines to announce yet, sorry. We’re also looking at “.NET Native” support for when that ships officially from MS wit VS14 — right now it’s stolen early preview, and —i believe — still only supports WinRT.
1 Like
Can Elements generate .NET native? Or any update to this OP?
Settings -> Target Framework
1 Like
In Settings->Target Framework, I only saw a list of .NET frameworks including .NET core? Which one should I select for generating Native code?
I do not believe we support .NET Native (yet). TBH, since this thread, five years ago, this is the first time I hear anyone mentioning it again, so I cannot say demand for it has been high. Is it still a thing even, with .NET Core and .NET 5 looming ahead?
I think .Net Native is a promising technology.
But as long as it is only for UWP, I am not interested.
Yeah I misunderstands the Question,
but as Theo69 says, at moment only UWP and that seems dead anywhere.
Exactly, UWP itself seems to be dead or dying, so given no-one has asked for .NET Native in the five years this thread has been idle… probably best if we focus our efforts elsewhere.
2 Likes
But maybe one idea: you have Island Windows.
A conversion tool tool to convert a project from .Net to Island (and a checker if it is possible) would set you ahead of Microsoft with native compiling.
What would you envision the conversion doing?
The language already is the same for both platforms and should be 100% compatible. The only difference is the APIs (if you’re using .NET APIs and not Elements RTL), and there’s really no way to automatically translate those)…
The conversion: change the project files to island.
Checker: See if something is used (b.e. a .Net API) that is not supported in Island.
But maybe I have to use Island first to have an opinion about it 
That is literally changing one (not currently public in there IDE) setting. Though I’m not sure it it’d be good to expose that directly, because toggling that will break other stuff. e.g. all your references are of course .NET specific, so what would be the “correct” approach here — just drop them and add the default/base set of Island references? It’s not as clear cut what to do here.
That said, I probably do wanna add a few “conversion” helpers, probably in the Help|Internal Use menu of Fire/Water, for now, including converting from legacy <Import with platform-named .targets files to a clean Mode/SubMode setting, and for adding more/all Targets to a project to make it cross-platform. Maybe changing the platform could be an option there, as well.
You should check it out; feedback appreciated. Note you can mix and match it with .NET too, if you use Hydra.
Maybe that is something for a converter - call the used .Net libraries with Hydra.
I’m afraid that’d go much beyond what a converter can do or how Hydra works. Hydra doesn’t just give you direct access to .NET (or native) APIs from the other side; with Hydra, you create plugins that encapsulate functionality you want to write in the “other” platform (could be just app logic, or could be a block of UI), optionally its a custom interface that the two sides can use to communicate. and you then load this plugins into your host app.
I will dive in to it when I have the time.
1 Like