This won't work in principle, but you can do something similar which would work. I don't see any practical purpose of such things. Maybe you can explain the idea? And the ultimate goal?
As I understand, it can be used just as a toy used to understand programming better. Of course.
Now, Code DOM. It looks like right now you don't understand what it does from the very beginning. A code you can compile using Code DOM has to be a fully-fledged assembly, so the set of source codes (it can be more then one "file" a set of "files") should be a complete C# project, which can compile normally, as if you used a C# compiler directly. (By the way, Code DOM actually uses this C# compiler:
csc.exe, the one bundled with the Framework redistributable.) So, it should be a complete project. This is assembly has nothing to do with the loaded assembly with is running in you process, the one which is calling the compiler. Let's call it "host assembly" and "host process". Let's call the assembly being compiled the "dynamic assembly". In particular, it means: if your source code uses
combobox1, this variable or a method parameter should be declared in dynamic assembly; it cannot know anything about any objects declared in your host assembly. At the same time, the dynamic assembly can be loaded in the same process as the host assembly. Code DOM will return you the variable of the type
System.Reflection.Assembly, if the compilation was successful, host assembly can instantiate some class in the dynamic assembly using Reflection, and then some code from the dynamic assembly can be called by the host process. You can pass your variable from the host assembly and make them processed by the dynamic assembly. This way, the dynamic assembly can modify you UI, depending on the code the user enters. Practically, this is the as as creating a small toy Visual Studio, but also with self modifying UI. Excellent programming exercise, I would say.
Next problem is this. Imaging you successfully compile some code into dynamic assembly. Once, twice, again and again… the memory used by your process will grow and grow. There is no way to unload any assembly — not from existing Application Domain; this is sound decision put in the base of .NET architecture. This will create a permanent memory leak in you process. There is a solution. You should not just load new assembly created out of source code. You can do the following: each time, create a new Application Domain, do all the compilation in the new Application Domain and load your new dynamic assembly and run its code there. When you need to do it again, you can delete whole Application Domain — this is the only method to unload any code; no other way of unloaded code is theoretically possible.
The problem of this approach is strict isolation between Application Domains: you cannot pass any data between them. You can only use IPC, as if the Application Domains withing the same process were different processes. The
System.AppDomain class provides highly simplified IPC for this purpose. So, no, you won't be able to pass your instance of
combobox1 or
label2 to your dynamic assembly. Doing something like (without the memory leak which is unavoidable if you work in a single Application Domain) will need a serious work around. I suggest some wait to do something like that in my Answer to one past Question.
Please see my Answers to these Questions:
code generating using CodeDom[
^],
Create WPF Application that uses Reloadable Plugins...[
^]
These Answers refer to each other. You will find a lot of detail, so you can actually do it all.
My warning: this would be a really serious exercise, will take considerable working time and will need deep understanding of programming.
—SA
Submit an article or tip