.NET-Code direkt in nativen Code kompilieren?

  • Allgemein

Es gibt 15 Antworten in diesem Thema. Der letzte Beitrag () ist von Vultrax.

    .NET-Code direkt in nativen Code kompilieren?

    Kann mir jemand sagen, ob es eine Möglichkeit gibt, .NET-Code direkt in nativen Code zu kompilieren (sollte mit Windows-Forms kompatibel sein)?
    Ich konnte nicht mehr als .NET Native (scheint wohl nur mit UWP-Anwendungen zu funktionieren) und IL2CPU (keine Ahnung wie man das verwenden soll) finden.

    Da die Anwendung dadurch an Performance gewinnt und der eigene Code auch nicht mehr direkt eingesehen werden kann, wäre es für mich ziemlich interessant zu wissen, wie das genau funktioniert.
    (Einen Artikel den ich darüber gelesen habe: telerik.com/blogs/understanding-net-just-in-time-compilation)

    EDIT: Habe dazu noch einen (möglicherweise) nützlichen Artikel gefunden: blogs.msdn.microsoft.com/alpha…jit-when-you-can-codegen/


    Ich hoffe doch, dass Ihr mir weiterhelfen könnt! :)

    Verschoben. ~Thunderbolt
    "Denken ist die schwerste Arbeit, die es gibt. Das ist wahrscheinlich auch der Grund, warum sich so wenig Leute damit beschäftigen." - Henry Ford

    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „Vultrax“ ()

    @Vultrax Du kannst eine CLI-DLL schreiben und dort direkt native Klassen reinschreiben und aufrufen.
    Du kannst auch nativen und CLI-Code mischen.
    Aufpassen musst Du bei New und Pointern:
    C++: new, *,
    CLI: gcnew, ^.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!
    #RodFromGermany - Danke erstmal für Deine Antwort!

    Davon habe ich auch schon was gelesen, allerdings müsste ich dann meinen bereits geschriebenen VB.NET-Code in C++-Code umwandeln, was bei meinen noch nicht so fortgeschrittenen C++-Kenntnissen doch noch ein wenig mühsam sein könnte (besonders bei der Menge an Code, die ich geschrieben habe). Da dies ja möglich zu sein scheint, gibt es den keine Tools wie bei Obfuskation, wo man die kompilierte .NET-Datei nicht einfach nochmal nachkompiliert?
    "Denken ist die schwerste Arbeit, die es gibt. Das ist wahrscheinlich auch der Grund, warum sich so wenig Leute damit beschäftigen." - Henry Ford

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „Vultrax“ ()

    Eventuell kannst Du mit NGen was anfangen. Aber das installiert das Resultat meines Wissens nach direkt in den GAC.
    "Luckily luh... luckily it wasn't poi-"
    -- Brady in Wonderland, 23. Februar 2015, 1:56
    Desktop Pinner | ApplicationSettings | OnUtils
    #Niko Ortner - Danke auch für Deine Antwort!

    Ja, es wird wohl keine ausführbare Datei generiert.
    "Denken ist die schwerste Arbeit, die es gibt. Das ist wahrscheinlich auch der Grund, warum sich so wenig Leute damit beschäftigen." - Henry Ford

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „Vultrax“ ()

    Ich würde dir nicht empfehlen das ganze zu machen:
    Der Grund der Performance dürfte relativ minimalistisch bleiben, vorallem die Startzeit wurde mit .Net 3.5 nochmals minimiert. Und ansonsten ist der größte Performancevorteil den man sich holen kann immer noch durch den eigentlich geschriebenen Code geschrieben. Ein BubbleSort in C++ wird auch langsamer sein wie ein Quicksort in C#, da ist es ganz egal, dass die C++ Compiler viel besser optimieren können als C# Compiler und JIT kombiniert. schlechter Algorithmus bleibt schlechter Algorithmus. Deshalb wenn es dir um Performance geht guck lieber erst mal was du an deinem Code verbessern kannst.

    Und dass man deinen Code nicht einsehen kann ist nie ein Grund. Erstmal gehste hin und schnappst dir eine schöne Lizenz und lizenzierst das ganze und wenn dann wirklich was wäre, dass jemand deinen Millionen dollar Code geklaut hat kannst du vor Gericht gehen, nachdem du sowieso bereits so viel Geld durch deinen Code verdient haben solltest, wenn er es denn wirklich Wert ist nochmal besonders geschützt zu werden :P
    Also mMn muss Code nie so stark geschützt werden und wenn es dabei um irgendetwas mit Verschlüsselung/Passwörter/Sicherheit sonst was zu tun hat dann gilt:
    en.wikipedia.org/wiki/Security_through_obscurity

    Wikipedia schrieb:

    Security experts have rejected this view as far back as 1851, and advise that obscurity should never be the only security mechanism.


    Andererseits ein weiterer Nachteil ist, dass du ein paar Vorteile dadurch verlierst, angefangen bei der Platformunabhängigkeit. Aber wer weiß, vlt. wird das alles mal besser und irgendwann funktioniert das ganze wie bei Android > 5 und es wird bei der Installation der Anwendung der ganze Code einmal nativ kompiliert um ein paar der Vorteile von JIT(nicht alle) mit Vorteilen von Nativer Kompilierung zu verknüpfen...
    Ich wollte auch mal ne total überflüssige Signatur:
    ---Leer---

    Vultrax schrieb:


    Ich konnte nicht mehr als .NET Native (scheint wohl nur mit UWP-Anwendungen zu funktionieren)


    So wie ich das verstehe funktioniert .NET Native mit jeder .NET Core Anwendung. Also wenn für deinen Code .NET Core ausreicht, würde ich darauf einen blick werfen.
    NGen ist ein interessantes Thema, oder besser gesagt, war es.

    Auf alten oder langsamen Rechnern, wie z.B. den ersten Ultra-books, konnte man damit eine träge Anwendung zu bis zu 200% Startperformance verhelfen. Wohl gemerkt Startperformance, denn sobald ein gewisser Codebereich einmal durch den JIT gelaufen ist, ist NGen "bearbeiteter" Code genausoschnell wie normaler Code. Da sich unsere Kunden oft darüber beschwert hatten, dass unsere Anwendung anfangs immer etwas träge ist, dann jedoch normal Betrieben werden kann (was teilweise grauenhaftem Anwendungsdesign geschuldet ist), haben wir nach einer schnellen Möglichkeit gesucht, um diese anfängliche Trägheit zu umgehen.
    Und da kam NGen ins Spiel. Ganz am Ende eines Setups ausgeführt, hat es ein natives Image für die Anwendung erstellt, sodass der JIT nicht mehr aktiv werden musste. Super Sache, denn nun war die Anwendung nicht mehr träge. Doch dann kam das erste Update und die Performance war wieder im Keller. Stellt sich raus, dass diese Images natürlich nur für exakt den Code vorliegen, von dem aus sie erstellt wurden. Also, am Ende des Updates nochmal NGen. Und dann gab es natürlich die Fraktion, die die Anwenung auf einem Zentralen Netzlaufwerk liegen hat. Geht auch, man kann dafür Images erstellen, doch es darf sich auch ja nichts an den Pfaden verändern. Und darüber hinaus liegt die Anwendung ja gerade dort, damit man nicht auf jedem Client ein Update durchführen muss.

    Glücklicherweise werden die Prozessoren selbst auf kleinen Notebooks immer schneller, sodass diese anfängliche Trägheit immer weniger spürbar wird. Der Vorteil von NGen also schrumpft immer weiter, während die Nachteile nicht abgenommen haben.

    jvbsl schrieb:

    Aber wer weiß, vlt. wird das alles mal besser und irgendwann funktioniert das ganze wie bei Android > 5 und es wird bei der Installation der Anwendung der ganze Code einmal nativ kompiliert um ein paar der Vorteile von JIT(nicht alle) mit Vorteilen von Nativer Kompilierung zu verknüpfen...
    Wenn man inzwischen eine UWP-App in den Store laden möchte, so muss diese afaik mit .NET-Native kompiliert sein.
    #jvbsl

    Die Performance spielt dort für auch mehr eine zweitrangige Rolle, da dies sowieso keine großen Unterschiede mehr machen wird (wobei ich mir bei meinem ReadWriteMemory-Modul doch schon ein wenig mehr Performance wünschen würde). Der Hauptsächliche Grund ist für mich mehr der Kopierschutz meiner Arbeit. Es stört mich schon seit Ewigkeiten, dass ich meinen Code nur auf brutale Art und Weise schützen kann, indem ich einen Confuser(Ex) mit maximalen Einstellungen nutzen muss (das dies nicht gut ist, ist mir absolut bewusst). Ich schreibe natürlich auch nicht den krassesten und begehrenswerten Code den die IT-Welt jemals gesehen hat, dennoch wurde bei mir schon zwei Mal Code geklaut.

    Wenn ich meinen Code nun auf natürlichen Weg schützen könnte, würde der Confuser bei mir auch endlich mal in die Tonne fliegen.

    #Quadsoft

    So wie ich das verstehe funktioniert .NET Native mit jeder .NET Core Anwendung. Also wenn für deinen Code .NET Core ausreicht, würde ich darauf einen blick werfen.[/quote]
    Nach meiner mehrstündigen Suche hieß es leider, dass dies wohl nur für UWP-Anwendungen gedacht und "Windows 10 Only" sein soll. Ich werde mir das aber auf jeden Fall nochmal anschauen! :)
    "Denken ist die schwerste Arbeit, die es gibt. Das ist wahrscheinlich auch der Grund, warum sich so wenig Leute damit beschäftigen." - Henry Ford

    Dieser Beitrag wurde bereits 8 mal editiert, zuletzt von „Vultrax“ ()

    @EaranMaleasi was ich viel mehr meinte war, dass der Nativ-Compiler besser wird und dann das ganze vlt. irwann auf normalen PCs zum Einsatz kommt. Aber erst mal muss er dafür besser optimieren können, dazu gehören meiner Meinung nach auch Codeanalysen, die eben nicht nur die nächsten paar Zeilen angucken, sondern komplexer sind als was der JIT eben kann sowie dass man eben auch alle Features von .Net auch mit Native verwenden kann. Vorher wird es sich denke ich wohl auch auf UWP belassen(Oder evtl. maximal dann noch Android/iOS Geräte wenn es mit .Net Standard irwann soweit ist)...
    Ich wollte auch mal ne total überflüssige Signatur:
    ---Leer---

    Vultrax schrieb:

    allerdings müsste ich dann meinen bereits geschriebenen VB.NET-Code in C++-Code umwandeln
    Diesen könntest Du Dir mit IlSpy in C#-Code konvertieren lassen. Von dort ist es zu C++ ein kleinerer Schritt.
    Aber
    Wenn Du Deinen Code schützen willst, genügt der native PArt in einer CLI-DLL nicht aus, der ist ebenfalls einsehbar.
    Da müsstest Du eine komplett native C++-DLL schreiben und deren Lib an die CLI-DLL linken (da kommt eine gemeinsame DLL raus).
    Diese wäre dann außerordentlich sicher.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!
    Microsoft arbeitet derzeit daran siehe corert. Das Projekt ist noch work in progress und wird noch eine Weile dauern bis es Release bereit ist. Damit kann man .Net mit Hilfe vom JIT in kompilierten native code umwandeln oder c++ code generieren was dann mit einem C++ compiler kompiliert werden kann. WinForms wird allerdings nicht funktionieren da es nicht Teil von .Net Core ist. Als alternative für GUIs in Kombination mit corert gibt es Avalonia womit es schon erste Erfolge gab siehe twitter.com/wieslawsoltes/status/982377588294410241 und github.com/AvaloniaUI/Avalonia/issues/1476
    #RodFromGermany

    Das klingt schon deutlich besser, als alles nachschreiben zu müssen.
    Ist nativer Code nicht auch schon so unlesbar? Wenn mein Code nur noch in Maschinensprache vorliegt, ist dies für mich vollkommen ausreichend.

    #Pinki

    Von CoreRT habe ich auch schon was gelesen, ist wohl tatsächlich schon seit einer Weile in Entwicklung.
    Danke, dieses Projekt werde ich mir mal anschauen!
    "Denken ist die schwerste Arbeit, die es gibt. Das ist wahrscheinlich auch der Grund, warum sich so wenig Leute damit beschäftigen." - Henry Ford

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Vultrax“ ()

    Vultrax schrieb:

    Ist nativer Code nicht auch schon so unlesbar?
    Wir haben das auf Arbeit ausprobiert.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!
    @Vultrax Ich möchte dich bitten, in Zukunft sinnvoller zu zitieren. Es ist unnötig und auch hier nicht erlaubt, Postings vollständig zu zitieren, wenn diese recht lang sind und vor allem direkt über deinem Post stehen. Manchmal reicht auch ein Ansprechen des Users über @...
    Besucht auch mein anderes Forum:
    Das Amateurfilm-Forum