I suggest you ...

Support for collectible assemblies

Support for collectible assemblies, i.e. assemblies that can be unloaded from memory (without deleting appdomain).
Example: Build a kind of REPL on top of your application so that user can script your application. This leads to high customization capabilities. The user script might be sent via files to the application running 24/7, hence you need emitted code to be collected.

1,514 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Stéphane shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    21 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)
      Submitting...
      • BR commented  ·   ·  Flag as inappropriate

        Refer to Borland's Vroom OO based automatic code memory management from 25 years ago. It's been done and could be done now.

      • wilmer barrios commented  ·   ·  Flag as inappropriate

        i developer app , all code is store into sql (XAML+c#) ..

        my app not used many memory.

        i can send app x email , your cant test...

      • Aaron Shumaker commented  ·   ·  Flag as inappropriate

        For those noting the documentation that states this feature already existed. This only applied to to Reflection.Emit. Trying to load a DLL in this way, as you might with a plugin, does not apply. Personally, I am interested in this because I want to be able to load and unload plugin DLLs as the user desires, and/or unload/reload a plugin DLL. So Reflection.Emit is not a good a solution.

        See the note: "Reflection emit is the only mechanism that is supported for loading collectible assemblies. Assemblies that are loaded by any other form of assembly loading cannot be unloaded."

        I am aware of MEF, but it is somewhat restrictive and complicated to use. There's also limited resources around it because it is so specialized.

        With Collectible Assemblies, we'd be able to load/unload DLLs, and use existing libraries/skills/knowledge with DI Container libraries to resolve types from interfaces. We'd just use standard C# interfaces to define plugin contracts, and not have to learn a new framework like MEF to accomplish what C# is really already perfectly capable of. This is how alot of applications supporting "plugins" already work, the only difference is once the assembly is loaded, they cannot unload it. So if you want to disable a plugin or update it, the application must be restarted.

      • Suren commented  ·   ·  Flag as inappropriate

        Ability to continuously churn code within the same domain opens up number high scalability\throughput scenarios not possible\costly otherwise.

        Please add support for it or at least ability to translate SyntaxTree => Expression<T>

      • Pontus Eliason commented  ·   ·  Flag as inappropriate

        One of the main selling-points of Roslyn was the ability to dispose of assemblies, and bring C# into the world of possibilities that scripting gives to larger enterprise applications, dynamic user-built editor software, or custom web engine solutions.

        Remoting over AppDomains is cumbersome and slow, and to me the whole idea of scripting in .NET falls extremely flat without the ability to dispose of the resources.

      • ac commented  ·   ·  Flag as inappropriate

        As far as I am concerned, this isn't solved until there's a similar answer to the "Advantage #1" seen here:

        http://www.artima.com/articles/coding_with_jrebel.html

        Summary: you run plain old console app with a loop - this app can be running on another computer, then when you make edit to the code and press a key, the change is now in effect on the app running on the other computer.

        That's "keeping it simple, stupid" and the fastest practically possible feedback loop.

        To make this more practical, one should have TWO copies of the app running that are - one key updates the "test app" and another updates the production app - so that if your change causes app to crash you'll notice that before committing changes to the live production app.

      • t3sture commented  ·   ·  Flag as inappropriate

        I'm unsure how this couldn't be solved with an injection library (Unity?) and a FileSystemWatcher.

      • Jake commented  ·   ·  Flag as inappropriate

        This is going to become a real issue now that AppDomain's are going away in CoreClr.

      • Josh Varty commented  ·   ·  Flag as inappropriate

        I need this to quickly compile user's code, run it and then unload the DLL. There's some uncomfortable overhead when using AppDomains as well as some issues with MarshalRefByObject and PCLs.

      • Peter commented  ·   ·  Flag as inappropriate

        We need this, because without it, our story for using scripts in our server based product really is not viable.

      • Mark commented  ·   ·  Flag as inappropriate

        Today the only way to unload assemblies is by separating them into different AppDomains and use remoting for the communication.
        .NET comes with the feature of "collectible assemblies" but this feature has too much limitations and issues.

      • James Gaunt commented  ·   ·  Flag as inappropriate

        For some of us this was the big win with the roslyn ctp. The work on the compiler is great but I kind of already had a working compiler. Scripting with c# however was a massive bonus.

      • aaaa commented  ·   ·  Flag as inappropriate

        Hot swapping is an important issue that should be addressed.

      • Markus Schaber commented  ·   ·  Flag as inappropriate

        Java supports complete garbage collection of classes (at least most of the Desktop / Server VMs I ever used in production).

      ← Previous 1

      Feedback and Knowledge Base