dynamic functions...

[Guest]

i need to be able to create a dynamic C# function on the fly on an existing
type that exists within an assembly already loaded into memory. basically,
the body of this dynamic function will be loaded from an external source
(e.g. a file).

how can i best accomplish this task?

also, is there a way i can unload this function when i dont need it anymore?

thanks for all your help,

 

[Barry Kelly]

i need to be able to create a dynamic C# function on the fly on an existing
type

You can't create a method on an existing type. Besides, you would only
be able to call it via reflection, so you'd want to put it in a delegate
for performance. You can create a delegate which has an existing
instance of any type as its implicit 'this' parameter, where the code of
the delegate is dynamic - that's what
DynamicMethod.CreateDelegate(Type,Object) does.

that exists within an assembly already loaded into memory. basically,
the body of this dynamic function will be loaded from an external source
(e.g. a file).

If you mean that this external source is written in C#, I think you have
your work cut out for you. You could perhaps insert it into a C#
template file, call CSC on it, and then load up the code of the method
via reflection or other analysis, and stick it into a DynamicMethod.

There are limitations with this, depending on what the source looks like
and if it needs more complex data than arguments, local variables,
strings and numbers. (E.g.: static data? Much trickier.)

how can i best accomplish this task?

It depends on what you expect to see in your external source file. You
may be better off constructing it with Reflection.Emit, rather than
fiddling with CSC, depending on how general you need it to be.

also, is there a way i can unload this function when i dont need it anymore?

DynamicMethods are eligible for collection by the GC in the usual way.

-- Barry

 

[Jon Skeet [C# MVP]]

If you mean that this external source is written in C#, I think you have
your work cut out for you. You could perhaps insert it into a C#
template file, call CSC on it, and then load up the code of the method
via reflection or other analysis, and stick it into a DynamicMethod.

There are limitations with this, depending on what the source looks like
and if it needs more complex data than arguments, local variables,
strings and numbers. (E.g.: static data? Much trickier.)

Any reason you'd suggest not using the CSharpCodeProvider class? Easier
than calling csc, IMO.

 

[Barry Kelly]

Any reason you'd suggest not using the CSharpCodeProvider class? Easier
than calling csc, IMO.

Well, the code providers are targeted towards a DOM model for source
code. More specifically, they support designers that need to write code,
such as the WinForms designer. There's no deep semantic support - cf.
CodeSnippetExpression, not exactly type-safe. So, if the object is to
write code that writes C# code, then sure, CSharpCodeProvider might be
the way to go.

It depends on what's supposed to be in those source files on disk. It
could be viewed as rather pointless to parse some arbitrary language,
only to convert it into C# via a code provider, and then call the C#
compiler, and then try to load it up into a dynamic method (if that is
the goal) - or alternatively in a separate type, perhaps loaded in a
separate domain to get the unloadable / GC requirement in there as well.

If the target is to get a lightweight DynamicMethod that can work with
instances of a specific type, then I think CSharpCodeProvider is helping
with the wrong end of the problem.

It comes down to what's in those source files. If it's C#-like, I think
a C# text-replacement template would be easier than working it through a
code provider only to turn it back into C# again. If it's more
declarative or otherwise limited in scope, then I think more direct
translation into Reflection.Emit may be in order.

-- Barry

 

[Jon Skeet [C# MVP]]

Well, the code providers are targeted towards a DOM model for source
code. More specifically, they support designers that need to write code,
such as the WinForms designer. There's no deep semantic support - cf.
CodeSnippetExpression, not exactly type-safe. So, if the object is to
write code that writes C# code, then sure, CSharpCodeProvider might be
the way to go.

Well, that's *one* use for it. I certainly use it to compile code which
I've already got as C#. It certainly makes that pretty easy.

It depends on what's supposed to be in those source files on disk. It
could be viewed as rather pointless to parse some arbitrary language,
only to convert it into C# via a code provider, and then call the C#
compiler, and then try to load it up into a dynamic method (if that is
the goal) - or alternatively in a separate type, perhaps loaded in a
separate domain to get the unloadable / GC requirement in there as well.

Well, I was going on the basis of: "If you mean that this external
source is written in C#, I think you have your work cut out for you."
In fact, if the source is written in C#, it's really pretty easy.

If the target is to get a lightweight DynamicMethod that can work with
instances of a specific type, then I think CSharpCodeProvider is helping
with the wrong end of the problem.

It comes down to what's in those source files. If it's C#-like, I think
a C# text-replacement template would be easier than working it through a
code provider only to turn it back into C# again. If it's more
declarative or otherwise limited in scope, then I think more direct
translation into Reflection.Emit may be in order.

It's possible you've missed the compilation side of CSharpCodeProvider
- in particular, CompileAssemblyFromSource, CompileAssemblyFromFile
etc.