I suggest you ...

Native .Net Compiler

possibility to compile C# (for example) code to native .exe included framework library inside assembly (here more correctly - .exe)

379 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Dmitry KolesovDmitry Kolesov shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    11 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • Florian S.Florian S. commented  ·   ·  Flag as inappropriate

        IMHO a C# compiler that generates native code and still depends on the CLR/.NET Framework wouldn't bring much benefits. You'd have to think further here - what if one would just take the language (C#) and build a native compiler as well as a native C# runtime/base class library, maybe based on the Windows Runtime (although that's COM again and I wouldn't like the idea, a clean start might be better).

      • FlyFly commented  ·   ·  Flag as inappropriate

        David Kean: First, you always have to ensure that the target machine has installed the .NET framework. When I develop some application, I have even to ensure, that the right framework is installed.

        Additionally, "native" code would be faster, because (at least partially) the MSIL wouldn't need to be parsed, and the instructions would be sent directly to the processor, witch could give a speed up in some situations, especially in situations where performance is needed (like games, havy server-systems, etc)

        Even though I'd really like to see this, I see some cons, for example:
        - The garbage collection is done by the CLR, and I wonder who would collect the garbage
        - Just embedding the DDLs without a "real" native compilation would size up the exe, and the user has to re-download the same code (The .NET-Framework) multiple times.
        - Things like reflection are hard if there is no MSIL, and it is compiled natively
        - You couldn't really restrict the framework like in Silverlight when it is not in an VM (the CLR)
        - Just embedding the DLLs has also other disadvantages, for example Microsoft made a mistake with their secure random number generator [1], then they would update .NET via Windows Update, and would reach a high amount of the customers. If they include the libs in the exe, the update would be useless

        All in all, I'm not really sure if this feature is possible. Anyway I'd like to see the speed boost.

        [1] (google did this: http://android-developers.blogspot.de/2013/08/some-securerandom-thoughts.html )

      • ssjxssjx commented  ·   ·  Flag as inappropriate

        yes! c# is good language, but

        1. .net CLR is too slow! many times slower than vc6's and vb6's
        2. .net framework is many hunders bigger than vb6 and vc6's runtime.
        3. .net eat too many memory, more than ten times memory than vc6's and vc6's.
        4. install vs.net is hunders times slower than vc6 or vb6's. today install vb6 need only 1 minute, but install vs2010 and vs2010sp1 need many hours, this is too long, waste too many time.
        5. vstudio.net is many many times slower than vc6's and vb6's waste too many time to open/edit/compile.
        6. .net waste too many power than vc6 and vb6s, my cpu and hardisk is work very slowly when run .net, but is quickly when run vc6 or vb6.
        6. .net has very bad compatibility, vc6 and vb6 can run win98~win8. but .net 1 can't run win7. .net 4.5 can't run on winxp. so .net's compatibility is much bad than vc6 and vb6's.

        So. MS guys are doing very severely fall back.
        If MS don't change, Sun's dead is MS's dead.
        If MS want force user change to meet MS, then user will discard MS.

        So let c# languge run in a native runtime such as vb6's native runtime or MFC.DLL. just one dll, don't install so many so big stuffs to user's system.

      • David KeanDavid Kean commented  ·   ·  Flag as inappropriate

        Can you expand a little on your suggestion? What problem are you hitting that you you looking at solving?

        David Kean (MSFT)

      • acac commented  ·   ·  Flag as inappropriate

        It's not very clear where the runtime improvements would come from. C++ has advantages in the language that reduce it's runtime overhead.

        If CLR & C# added more performance based language features that would be a good start.

        I think realistically the aim should be to take snippets of existing optimized C and C++ code, somehow verify them (like Xbox SDK has a verifier for Xbox C++) and then mark this verified code as "safe for fast call straight no-overhead interop".

        IDE should have some project type which makes it easy to take these C/C++ snippets, verify them and wizard to create the supporting code to make them usable in C#.

      • EmEm commented  ·   ·  Flag as inappropriate

        I suggest you to build C# native optimizing compiler (like Intel C++ Optimizing Compiler for Intel CPUs)
        C++ goes complex and complex every day , I am programming C++ 10+ years I enjoy it , but I love C# more than C++. because C# has very classic and standard way to program and I just recommend to MS Compiler team to build C# native optimizing compiler like C++ Native Optimizing Compiler , it is obvious that The Native compiler can be optimized better than Virtual Compiler
        the objective of Intermediate language like CIL is to be independent from CPU(as there are so many different CPUs around the world) but The CIL (JIT) Compiler team is very slow to build CIL (JIT) Compiler for even Linux! and ...
        after 10 years there is no (good) multi platform compiler for C#.NET? but here I expected even native optimized compiler for C#.NET (Such as Intel C++ Optimizing Compiler for Intel CPUs).
        from this point of view JAVA has more better support and widely accepted. even JAVA has some direct hardware support :AT91SAM9260B:RISC Processor Based on ARM v5TEJ Architecture with Jazelle technology for Java acceleration

        Em
        http://kennykerr.ca/2011/10/18/the-road-to-windows-8/#comment-504

      Feedback and Knowledge Base