Laden...

.NET Native: C# erzeugt jetzt auch nativen Code [momentan nur für Windows Store apps]

Erstellt von gelöschtem Konto vor 9 Jahren Letzter Beitrag vor 9 Jahren 6.985 Views
Gelöschter Account
vor 9 Jahren
.NET Native: C# erzeugt jetzt auch nativen Code [momentan nur für Windows Store apps]

Microsoft hat auf der letzten Build Conference seinen Native Compiler für C# vorgestellt.

Microsoft .NET Native

Migrating Your Windows Store App to .NET Native

Aus meiner Sicht derzeit eher Proof-Of-Concept. Solange ich kein neues Unmanaged-Projekt in Visual Studio erstellen kann.

3.511 Beiträge seit 2005
vor 9 Jahren

Man muss dazu sagen, dass es momentan nur für Store Apps (RT) und IMHO Win Phone ist. Ob und wann das für den Desktop Bereich kommt, ist ungewiss.

Meiner Meinung nach, geht MS damit aber einen riesen Schritt in Richtung ".NET im Kernel". Was ich schon seit Jahren ersehne.

"Jedes Ding hat drei Seiten, eine positive, eine negative und eine komische." (Karl Valentin)

E
12 Beiträge seit 2014
vor 9 Jahren

Also wenn es so wird wie sie sich das vorstellen finde ich das gut ! 😃

1.696 Beiträge seit 2006
vor 9 Jahren

Da werden die Firmen mit Produkten gegen Decompiling sehr traurig sein 😃

Ich bin verantwortlich für das, was ich sage, nicht für das, was du verstehst.

**:::

A
31 Beiträge seit 2009
vor 9 Jahren

In diesem Zusammenhang passt auch, dass Microsoft das Roslyn-Projekt als Open Source veröffentlich hat. Sprachcompiler für C# und Visual Basic sind jetzt Open Source
C#-Erfinder Anders Hejlsberg hat das gestern auf der BUILD und bei Twitter bekannt gegeben.

U
1.688 Beiträge seit 2007
vor 9 Jahren

Aus meiner Sicht derzeit eher Proof-Of-Concept.

... mit so vielen Einschränkungen, dass es eher ein Schritt weg vom vorhandenen als eine Erweiterung ist. Auch ist es z. Z. nur (als Preview) für Windows Apps und nicht für Desktop-Anwendungen verfügbar. Wann diese kommt, steht wohl in den Sternen.

Ich finde eher enttäuschend, was da mal wieder mit hätte/sollte/könnte mitgeteilt wird. Ich finde auch, Microsoft ist für kommerzielle Entwickler zu sprunghaft. (Mir stößt immer noch die Silverlight-Geschichte auf. Ist aber nun auch HTML5/JS schon wieder überholt?

Hier noch zwei Links zum Thema:
C# erzeugt jetzt auch nativen Code

Windows 8 developers are shunning WinJS

Die Entwicklung ist nicht uninteressant, wenn sie denn mal konsequent weiter entwickelt würde. Aber dazu fehlt mir das Vertrauen.

R
212 Beiträge seit 2012
vor 9 Jahren

Microsoft hat ja auch den .net Quellcode veröffentlicht http://referencesource.microsoft.com/
(studio addin ref12)

16.806 Beiträge seit 2008
vor 9 Jahren

Ich kann diese Meinung nicht teilen. Ich verfolge die build und die Umgebung dessen sehr sehr aufmerksam und es ist unfassbar was Microsoft gerade für kommerzielle Entwickler alles macht.

.NET entwickelt sich unfassbar schnell, da mit wenigen Handgriffen sehr sehr große Türen geöffnet wurden.
Schaut man sich allein mal Azure an: das gibts in dieser produktiven Form gerade mal 3 Jahre und hat einen Erfolg in dieser Zeit wie kein anderes Produkt in dieser Branche.

Wenn man aber auf den Zug nicht aufspringt dann verpasst man eben viel.
Ich würde sehr gerne an einem größeren Projekt zusammen mit Azure arbeiten; die Möglichkeiten hat mein AG aber nicht, da eben ein anderer Fokus das Kerngeschäft ist.

Viele Dinge, die es mittlerweile gibt, sind ohne Azure in dieser Form gar nicht realisierbar. Wirklich unfassbar beeindruckend was Microsoft die letzten 2 Tage gezeigt hat. Und sie haben wirklich einen sehr sehr schnellen Innovationszyklus und -Geschwindigkeit.

Ich versteh auch nicht wieso man zu MS weniger vertrauen haben sollte als zu anderen.
Seien wir doch mal ohne Fanboy-Brille ehrlich: wer is besser?
Apple, die erst bestimmte Funktionen für Apps sperren um die Ideen der Entwickler anschließend ins eigene Betriebssystem zu integrieren? Das ist ein super vertrauen 😉

Warum soll denn eine Technologie weiter entwickelt werden, obwohl es bessere alternativen gibt, die sich eben herauskristalisiert haben? Nur weil Firmen diese verwenden?
Man kann doch Silverlight weiterhin entwickeln aber es gibt einfach neue Technologien die evtl. effizienter sind und mehr Möglichkeiten bieten. Man kann von MS wirklich nicht sagen, dass sie Dinge schnell sterben lassen (siehe XP) aber irgendwann gibts auch einen Punkt, an dem sich das einfach halt nicht mehr lohnt.

Dass Previers für Apps für Desktop-Anwendungen derzeit nicht verfügbar sind liegt daran, dass vor allem die Entwickler das nicht haben wollen. Ansonsten geht es dem Ökosystem "Windows Store" ähnlich wie Google Play: unter 10% der Apps werden legal auf einem Smartphone betrieben. Alle anderen kommen weil man die APK einfach kopieren kann.
Und bevor Microsoft hier kein besseres System hat um die Entwicklungen zu schützen sollen sie es auf Desktops bitte lassen. Nativer Code ist hier ein Schritt, der unsere Software besser dagegen schützen wird.
Und danach sind auch Demos auf Desktops kein Thema mehr.

Auch "Proof-of-Concept" ist schon was anderes, da es schon aktiv ist. M# ist Proof of Concept.
Man gibt die Anwendung stand heute wie gewohnt an MS, und die machen daraus dann nun Native Code. Wenn das System dann fertig und das gesamte .NET Framework abgedeckt ist wird es in VS2015 Einzug halten.

@Robin0, der Quellcode von .NET ist schon lange offen. Zwar nicht alles, aber das meiste.
Neu ist nur die Darstellung der Seite.

1.346 Beiträge seit 2008
vor 9 Jahren

Auch sehr interessant finde ich den vorgestellten neuen JIT Compiler, welcher ja nicht nur schneller ist als der alte, sondern auch die Türe zur utilisierung aufwendiger CPU Befehle öffnet, z.B. zu SIMD. Die gezeigten Beispiele (die man sich im übrigen auch selbst runterladen und testen kann) sind wirklich beeindruckend.

LG pdelvo

F
10.010 Beiträge seit 2004
vor 9 Jahren

@ujr:

Ist aber nun auch HTML5/JS schon wieder überholt?

MS hatte bei der W8 entwicklung ja mit viel TamTam HTML5/JS als den Weg angekündigt.
mehr als 90% der Anwendungen werden aber nicht darin geschrieben, sondern die meisten in C#.
Insofern ist das nur konsequent, wenn man HTML5 nicht bevorzugt behandelt.

Y
238 Beiträge seit 2005
vor 9 Jahren

Interessante und begrüßenswerte Entwicklung. Nun haben die C++ Kollegen keine Ausreden mehr a'la "ich verwende nicht C# weil es langsam ist" 😉

MS wird nicht auf dauer beide Varianten des .NET-Frameworks pushen können. Allein schon aus Kostengründen nicht. Ich schätze in 4-5 Jahren haben wir selbst auf Desktop nur das Native .NET. Oder sollte ich besser sagen "Unmanaged"? Was waren doch noch mal die oh so wichtigen Vorteile von ManagedCode vs Unmanaged auf die man jetzt offensichtlich doch so leich verzichten kann 😄

Übrigens wird es keine Reflection mehr geben. Ich kann mir vorsellen dass dies für relativ viele Produkte und kleine Tools ein ernstes Problem bedeutet. Arbeitet z.B. das Databinding nicht im Grunde auch auf Reflection?

16.806 Beiträge seit 2008
vor 9 Jahren

yngwie ich glaub Du verwechselst da was.
Es wird keine zwei Verianten geben; es wird einfach einen zusätzlichen Build geben, der aus MSIL dann Native formt.
Source > MSIL > Native

.NET bleibt managed, das wurde auch ausdrücklich gesagt. Auch der GC bleibt.
Reflection bleibt ebenfalls erhalten; der Entwickler muss bei eigenen Serialisierungen aber Metadaten mitliefern.

Wer C# nicht verwendet "weil es ach so langsam ist" ist sowieso nicht ernst zu nehmen.

Es wird genug Ecken geben, wo NativeCode keine Prio1 ist; zum Beispiel Anwendungen im Web/auf Azure.
In Windows Store macht es derzeit einfach wegen der Diebstahl-Sache einfach sinn.

Y
238 Beiträge seit 2005
vor 9 Jahren

yngwie ich glaub Du verwechselst da was.
Es wird keine zwei Verianten geben; es wird einfach einen zusätzlichen Build geben, der aus MSIL dann Native formt.
Source > MSIL > Native

Haste Recht, da habe ich es wohl erst falsch verstanden.

Reflection bleibt ebenfalls erhalten; der Entwickler muss bei eigenen Serialisierungen aber Metadaten mitliefern.

Was die Allmacht von Reflection angeht so wird diese merklich eingeschränkt (Zugrif auf private Member, erstellen von Instanzen von Typen mit generischen Parametern zur Laufzeit...)

F
10.010 Beiträge seit 2004
vor 9 Jahren

Da es aber ein zusätzlicher Schritt ist, wird man selber entscheiden können ob man das benutzen möchte.