Reflection.Emit a dynamic assembly to a static member

[Eyeawanda Pondicherry]

I have put some code together that creates an enum dynamically from some
database values.

The enum can be read perfectly by an application that references the
dynamically generated dll.

If I /emit/ a new version of the assembly, and start the application
again, the new values will appear for the enum.

However, suppose I want the application to remain in a running state.

Can I actually emit the newly generated dynamic dll into memory using
the IlGenerator? And, from that point on, will the application use the
new dynamically generated enum?

( From what I have read, it seems possible so long as the assembly is
generated in the same ApplicationDomain as the application. )

 

[Sherif ElMetainy]

Hello

Yes it is possible to generate 2 assemblies in memory and have your
application reference types from both assemblies. To reference an assembly
it must be loaded in the same app domain as the referencing code. Note that
everytime you load a new assembly in an AppDomain it cannot be unloaded
unless you unload the AppDomain. I suggest that you create a new AppDomain
everytime you generate an assembly, and unload the AppDomain when you no
longer need it (after a new one is created for example)

Best regards,
Sherif

 

[Existenz]

Thank you very much.

I need to read up on AppDomain, as I am not that familiar with the concept.

It sounds like /unloading/ the AppDomain is *not* the same as stopping the
application ?

So, if it were an exe referencing a dll, and the dll was dynamic and
changed, I would load both the exe and dll from one AppDomain to a new
AppDomain, and then shut down the old AppDomain ( unload it )?

 

[Jon Shemitz]

Can I actually emit the newly generated dynamic dll into memory using
the IlGenerator? And, from that point on, will the application use the
new dynamically generated enum?

Yes, you can Emit assemblies that get 'baked' into assemblies that you
can run immediately.

However, what does it mean to Emit an enum and use it immediately?
Without creating a saved assembly that you then reference and compile
against, you can't write code that refers to
MyDynamicEnum.SomeDynamicMember (ie, by name); you just have the Type
of the new enum, to use with methods like Enum.ToObject(). Yes, you
have a way to associate numeric values with strings, so that
ToString() on a dynamic enum type returns, say, "SomeDynamicMember"
instead of "42" - but, otherwise, isn't a dynamic enum just an slow
numeric type?

 

[Existenz]

Well, here's what I'm doing, and it almost works, but not quite:

I strongly type the parameteres to a web method, initially I just hard coded
enums into the web service and used those to type my parameters...but I
want the values of the parameters to be dynamic, based on a database...
which will change ( not all the time, so there is a bit of latency ).

So, thanks to some help here, I created a dynamical assembly that contains
the enums and I reference it in the Web Service. These enums change as I
change each time I emit the dynamic assembly, and so the acceptable values
shown in the WSDL change ( which is very cool ). But this only happens if
I restart the web service.

That's good enough, but just to go for broke, I wonder if you can emit the
assemblies directly into memory, and have the web service pick up the
change without restarting it.

 

[Sherif ElMetainy]

Hello

The WSDL of the web service shouldn't change after the release of the web
service, because that would break the web service clients. The WSDL is a
contract. The web service client will not know that a new WSDL is available,
and could end up calling the web service with an enum value that was deleted
or renamed. I suggest that your web method accepts a string parameter
instead of the enum, and have the code in your method validate the string
against a database table. If you want the client to know the list of valid
values, you can have another web method called something like GetValidValues
that returns an array of strings with valid parameter values.

Best regards,
Sherif

 

[Super Fan]

Good point on the contract aspect of WSDL.

However, a contract can be written so to specify that some element of
the contract will be a set of possible values, and those values may
change over time.

You see, 'breaking' the client is /exactly/ what I want to do -- this
prevents them from sending invalid data, *ever* to my web service.

 

[Sherif ElMetainy]

Hello

As I said in my previous post, you can use a string parameter instead of
enum, check for the validity of the parameter and throw an exception if the
client sends an invalid string. This way the client cannot will not be able
to use the invalid value. You can provide the client with an alternative way
to get valid values by creating a method that returns an array of valid
values.

In your way everytime you change the WSDL, the client has to update its web
reference, and be recompiled (I am assuming a .NET client here). In my way
the client can doesn't have to be recompiled.

Best regards,
Sherif

 

[Josef Schneider]

The enums will not change that frequently.

Doing it your way, making a second web method call to the server for
each input parameter, introduces some very heavy overhead.

Whereas using enums, that can be called once by the client, and used
locally -- on the client thereafter -- and which also puts the burden of
supplying correct data before even making a round trip to my server --
well, you can see where enums can be attractive (!)