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.
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
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
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.
Gonçalo Lopes commented
It appears that collectible assemblies already exist: https://msdn.microsoft.com/en-us/library/dd554932(v=vs.100).aspx
Anyone knows why Roslyn doesn't emit to them?
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>
Amandeep Singh commented
I wish this support is added soon. Really need this for our application to scale properly.
Pontus Eliason commented
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.
As far as I am concerned, this isn't solved until there's a similar answer to the "Advantage #1" seen here:
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.
I'm unsure how this couldn't be solved with an injection library (Unity?) and a FileSystemWatcher.
This is going to become a real issue now that AppDomain's are going away in CoreClr.
Josh Varty commented
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.
We need this, because without it, our story for using scripts in our server based product really is not viable.
Adalberto Raul Rua Aguirre commented
I need this option for differents puposes, (Application Server, Rules Servers, etc)-
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
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.
Collectible assemblies already exist: http://msdn.microsoft.com/en-us/library/dd554932.
Hasn't this already been solved? http://www.codeplex.com/MEF
Hot swapping is an important issue that should be addressed.
Markus Schaber commented
Java supports complete garbage collection of classes (at least most of the Desktop / Server VMs I ever used in production).
Yan Cui commented
Can the same result be achieved through Vagrant? (https://github.com/nessos/Vagrant)