Hi, The Roslyn "C# compiler as a service" project is not part of .NET 4.5, it will probably be released some time after .NET 4.5 (and C# 5). At the moment, it only exists as a technology preview ( http://blogs.msdn.com/b/ericlippert/archive/2012/06/05/announcing-microsoft-roslyn-june-2012-ctp.aspx ).
Since you're talking about non-saveable collectible assemblies generated at runtime, I don't think Cecil will be able to help you at all. Cecil can't analyze dynamic assemblies that only exist in memory, so it can't be used with the "serialization" part. It also can't define dynamic assemblies in memory, so it can't be used for the "deserialization" part either (you'd need to use Reflection.Emit instead). I don't think there is a way to persist a collectible assembly, but maybe you can somehow write the data structures produced by Roslyn to disk before a dynamic assembly is generated. Or can you configure Roslyn to write a non-collectible assembly instead? Best regards, Fabian On Thu, Jun 28, 2012 at 4:26 PM, Dlux <[email protected]> wrote: > I'm referring to the C# compiler services in NET 4.5 that can generate > GC'able assemblies from C# source. > > By serializeable assembly, I mean an assembly that can be saved to disk as > a file. According to an MSDN forums comment, the GC'able assemblies > generated by the NET 4.5 C# compiler cannot be saved out to disk. See > http://social.msdn.microsoft.com/Forums/en-US/dlr/thread/13403a6c-5e73-43d6-9a9a-1a7c2b5626c4 > . > I figured you guys would know more about this, thus the question: > Ultimately I want to compile C# code to a discardable assembly, be able to > save that to disk, and be able to load it from disk. I'm not too picky on > the mechanisms - [Serializeable] is pretty old anyway - I just need basic > capability. The only version of NET where you can compile C# to produce a > GC'able assembly is NET 4.5. In all earlier versions, you can produce an > assembly, but it won't GC. Mono won't do it either :-(. So I figure I can > accomplish this by taking together a few techniques: using NET 4.5's C# > compiler to produce a collectible assembly, using Cecil to persist it to > disk in standard format, then using Cecil to interrogate that persisted > assembly and re-create a collectible assembly in memory via Reflection.Emit. > > In other words, I'm trying to workaround the limitation that a collectible > assembly cannot be loaded by calling Load(filename), and the corollary that > it can't be saved either. > > >> One interesting thing to research is whether it is possible to return a > collectible assembly from the AppDomain.AssemblyResolve event. If this is > not possible, your code wouldn't be able to statically reference assembly > A; everything would need to be triggered > > That's why I'm asking the question! > > David L- > > On Thursday, June 28, 2012 10:02:28 AM UTC-4, Fabian Schmied wrote: > >> Hi, >> >> First of all, Roslyn is not the same as .NET 4.5, so it's not really >> clear how these assemblies you're talking about are generated. >> Second, when you say "serializeable assembly", what exactly do you mean? >> An assembly that puts the SerializableAttribute on all types within the >> assembly? (This is what Gavin interpreted.) An assembly that you can write >> to disk and read back? (Assemblies can already be stored on disk and read >> back.) >> >> I'm just trying a guess and assume the latter: you have an assembly file >> (DLL file) generated somehow before runtime, and you want to load it, at >> runtime, as a collectible assembly. Is that right? Now, the only way to get >> collectible assemblies into the .NET runtime is to define them using >> Reflection.Emit, so you can't just load them the ordinary way. Instead, >> you'd have to analyze the source assembly's contents and rebuild everything >> in memory using Reflection.Emit. The only part where Cecil can help you in >> this is the analysis part. >> >> Steps: >> - At runtime, somebody needs to use code from assembly A. >> - Use Cecil to read in assembly A. >> - Create a dynamic collectible in-memory assembly with the same full name >> as A. >> - Use Reflection.Emit to redefine everything found within the real >> assembly A in the dynamic assembly. >> >> If this is what you need, this will probably work (although cloning an >> assembly in memory will be a very complex task). However, consider the >> limitations of collectible assemblies listed here: >> http://msdn.microsoft.com/en-**us/library/dd554932.aspx<http://msdn.microsoft.com/en-us/library/dd554932.aspx> >> . >> >> One interesting thing to research is whether it is possible to return a >> collectible assembly from the AppDomain.AssemblyResolve event. If this is >> not possible, your code wouldn't be able to statically reference assembly >> A; everything would need to be triggered dynamically. >> >> Regards, >> Fabian >> >> On Thu, Jun 28, 2012 at 12:13 AM, Dlux wrote: >> >>> Good day (or night) fine developers. I am considering using Cecil to >>> create an assembly cloner and loader. This was take assemblies generated >>> by Rosalyn (NET 4.5), clone them to a serializeable assembly that I could >>> then save, and then later reconstruct a CollectibleAssembly from the >>> serialized version. This would be used on file close in an application >>> that uses a great many expressions to convert raw values into unitized >>> values. I'd save the compiled version as a part of the "document", sign >>> it, then on load, if the signature vets, I don't have to recompile them. >>> >>> From looking at Cecil I think I could do this, but I haven't done >>> anything this low-level with assemblies before. Does anyone else have any >>> relevant experience or knowledge on roadblocks or problems I may encounter >>> [attempting to] do this? >>> >>> David L- >>> >>> -- >>> -- >>> mono-cecil >> >> >> -- > -- > mono-cecil -- -- mono-cecil
