By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,238 Members | 1,804 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,238 IT Pros & Developers. It's quick & easy.

Reflection.Emit a dynamic assembly to a static member

P: n/a

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. )

Nov 16 '05 #1
Share this Question
Share on Google+
8 Replies


P: n/a
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
"Eyeawanda Pondicherry" <ou***********@us.india> wrote in message
news:jw****************@newsread3.news.pas.earthli nk.net...

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. )

Nov 16 '05 #2

P: n/a

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 )?


Sherif ElMetainy wrote:
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
"Eyeawanda Pondicherry" <ou***********@us.india> wrote in message
news:jw****************@newsread3.news.pas.earthli nk.net...

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. )


--

http://kentpsychedelic.blogspot.com/
incognito, updated almost daily

Nov 16 '05 #3

P: n/a
Eyeawanda Pondicherry wrote:
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?

--

programmer, author http://www.midnightbeach.com
and father http://www.midnightbeach.com/hs
Nov 16 '05 #4

P: n/a

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.
Jon Shemitz wrote:
Eyeawanda Pondicherry wrote:
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?


--

http://kentpsychedelic.blogspot.com/
incognito, updated almost daily

Nov 16 '05 #5

P: n/a
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
"Existenz" <ga****@r.lamers> wrote in message
news:VK*****************@newsread1.news.pas.earthl ink.net...

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.
Jon Shemitz wrote:
Eyeawanda Pondicherry wrote:
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?


--

http://kentpsychedelic.blogspot.com/
incognito, updated almost daily

Nov 16 '05 #6

P: n/a

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 wrote:
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
"Existenz" <ga****@r.lamers> wrote in message
news:VK*****************@newsread1.news.pas.earthl ink.net...
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.
Jon Shemitz wrote:

Eyeawanda Pondicherry wrote:
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?


--

http://kentpsychedelic.blogspot.com/
incognito, updated almost daily


Nov 16 '05 #7

P: n/a
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

"Super Fan" <ha***@win.next.year> wrote in message
news:Bw*****************@newsread1.news.pas.earthl ink.net...

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 wrote:
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
"Existenz" <ga****@r.lamers> wrote in message
news:VK*****************@newsread1.news.pas.earthl ink.net...
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 containsthe enums and I reference it in the Web Service. These enums change as Ichange each time I emit the dynamic assembly, and so the acceptable valuesshown in the WSDL change ( which is very cool ). But this only happens ifI restart the web service.

That's good enough, but just to go for broke, I wonder if you can emit theassemblies directly into memory, and have the web service pick up the
change without restarting it.
Jon Shemitz wrote:
Eyeawanda Pondicherry wrote:
>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?
--

http://kentpsychedelic.blogspot.com/
incognito, updated almost daily


Nov 16 '05 #8

P: n/a
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 (!)
Sherif ElMetainy wrote:
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

"Super Fan" <ha***@win.next.year> wrote in message
news:Bw*****************@newsread1.news.pas.earthl ink.net...
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 wrote:
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
"Existenz" <ga****@r.lamers> wrote in message
news:VK*****************@newsread1.news.pas.ear thlink.net...
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.
Jon Shemitz wrote:

>Eyeawanda Pondicherry wrote:
>
>
>
>>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?
>

--

http://kentpsychedelic.blogspot.com/
incognito, updated almost daily


--

Go SeaHawks! Beat Saints!
Nov 16 '05 #9

This discussion thread is closed

Replies have been disabled for this discussion.