Embedding a resource at runtime

[Dave Brown]

Hi there. Does anyone know if it's possible to embed a new resource into an
assembly at runtime as well as update an existing (assembly) resource. Any
assistance would be appreciated. Thanks.

[Nicholas Paldino [.NET/C# MVP]]

Dave,

Do you want to do this to an assembly that is loaded in the runtime? If
that is the case, then this is not possible. Changing the assembly at
runtime is a bad, bad idea. If you need to manage resources (and I use this
term not in the .NET space, but as a general term) in a dynamic manner, then
you should have some sort of storage solution to do that.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Dave Brown" <no_spam@_nospam.com> wrote in message
news:Ol**************@TK2MSFTNGP04.phx.gbl...

Hi there. Does anyone know if it's possible to embed a new resource into
an assembly at runtime as well as update an existing (assembly) resource.
Any assistance would be appreciated. Thanks.

[Dave Brown]

> Do you want to do this to an assembly that is loaded in the runtime? If

that is the case, then this is not possible. Changing the assembly at
runtime is a bad, bad idea. If you need to manage resources (and I use
this term not in the .NET space, but as a general term) in a dynamic
manner, then you should have some sort of storage solution to do that.

Hope this helps.

Thanks for the feedback. In my particular case however, adding and updating
resources in the assembly (exe) itself would have been the simplest way to
go for my users. I wanted to avoid dealing with extraneous file(s) that is
and just ship one ".exe". Perhaps a religious issue but the specialized
nature of my application actually lends itself to this technique (it
involves the processing of resources). Since it's not doable however I'll
have to package them up another way. In any case, thanks again
(appreciated).

[Nicholas Paldino [.NET/C# MVP]]

Dave,

It's one thing to process resources in an assembly that you actually
don't load in the CLR, but to do it in an assembly already loaded in the
CLR, that's just not feasible.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Dave Brown" <no_spam@_nospam.com> wrote in message
news:%2****************@TK2MSFTNGP04.phx.gbl...

Do you want to do this to an assembly that is loaded in the runtime? If
that is the case, then this is not possible. Changing the assembly at
runtime is a bad, bad idea. If you need to manage resources (and I use
this term not in the .NET space, but as a general term) in a dynamic
manner, then you should have some sort of storage solution to do that.

Hope this helps.

Thanks for the feedback. In my particular case however, adding and
updating resources in the assembly (exe) itself would have been the
simplest way to go for my users. I wanted to avoid dealing with extraneous
file(s) that is and just ship one ".exe". Perhaps a religious issue but
the specialized nature of my application actually lends itself to this
technique (it involves the processing of resources). Since it's not doable
however I'll have to package them up another way. In any case, thanks
again (appreciated).

[Dave Brown]

> It's one thing to process resources in an assembly that you actually don't

load in the CLR, but to do it in an assembly already loaded in the CLR,
that's just not feasible.

I really didn't think so since updating a running executable isn't normally
viable as you said (but I'm fairly new to .NET so I chanced it). Do you know
off-hand how it can be done for an assembly that isn't currently loaded
(without relying on command line tools if possible - I normally prefer to
avoid shelling out to launch external utilities). Thanks.

[Stuart Carnie]

Why don't you duplicate the EXE, embed the resources in the copy, and replace the running exe with the new one, when they exit the
application?

Cheers,

Stu

Nicholas Paldino [.NET/C# MVP] wrote:

Dave,

Do you want to do this to an assembly that is loaded in the runtime? If
that is the case, then this is not possible. Changing the assembly at
runtime is a bad, bad idea. If you need to manage resources (and I use this
term not in the .NET space, but as a general term) in a dynamic manner, then
you should have some sort of storage solution to do that.

Hope this helps.

[Nicholas Paldino [.NET/C# MVP]]

That's a really bad idea.

What if there is a permission set granted to the assembly based on the
hash? Or if the assembly has a strong name? Verification of the assembly
goes out the window now.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Stuart Carnie" <st***********@nospam.nospam> wrote in message
news:44**************@nospam.nospam...

Why don't you duplicate the EXE, embed the resources in the copy, and
replace the running exe with the new one, when they exit the application?

Cheers,

Stu

Nicholas Paldino [.NET/C# MVP] wrote:

Dave,

Do you want to do this to an assembly that is loaded in the runtime?
If that is the case, then this is not possible. Changing the assembly at
runtime is a bad, bad idea. If you need to manage resources (and I use
this term not in the .NET space, but as a general term) in a dynamic
manner, then you should have some sort of storage solution to do that.

Hope this helps.

[Stuart Carnie]

I didn't say it was a good idea :)

I was providing some ideas, given the original question was regarding the possibility of embedding a new resource in their
*existing* executable. Yes, there are side effects, which you have duly pointed out - the assembly cannot be strongly named, and
it can not be verified, therefore posing a severe security risk.

Cheers,

Stu

Nicholas Paldino [.NET/C# MVP] wrote:

That's a really bad idea.

What if there is a permission set granted to the assembly based on the
hash? Or if the assembly has a strong name? Verification of the assembly
goes out the window now.

[Dave Brown]

>I didn't say it was a good idea :)

I was providing some ideas, given the original question was regarding the
possibility of embedding a new resource in their *existing* executable.
Yes, there are side effects, which you have duly pointed out - the
assembly cannot be strongly named, and it can not be verified, therefore
posing a severe security risk.

Thanks for the suggestion. In addtion to the above issues however, it's an
unwieldy solution :) and one I doubt will even work. It's unlikely I can
copy a running executable without encountering some type of sharing
violation nor could I copy it back to itself for the similar reasons (so who
will do this copying). Even if it was doable, it would be a dangerous
venture trying to copy it back to itself while still running (proper
synchronization would be required but this is outside my control).

[Stuart Carnie]

Actually, it is possible and various techniques are available to implement a "self deleting executable", see http://tinyurl.com/eb9o4.


Dave Brown wrote:

I didn't say it was a good idea :)

I was providing some ideas, given the original question was regarding the
possibility of embedding a new resource in their *existing* executable.
Yes, there are side effects, which you have duly pointed out - the
assembly cannot be strongly named, and it can not be verified, therefore
posing a severe security risk.

Thanks for the suggestion. In addtion to the above issues however, it's an
unwieldy solution :) and one I doubt will even work. It's unlikely I can
copy a running executable without encountering some type of sharing
violation nor could I copy it back to itself for the similar reasons (so who
will do this copying). Even if it was doable, it would be a dangerous
venture trying to copy it back to itself while still running (proper
synchronization would be required but this is outside my control).

[Dave Brown]

> Actually, it is possible and various techniques are available to implement

a "self deleting executable", see http://tinyurl.com/eb9o4.

I quickly inspected some of these techniques and what I see is either
dangerous (relying on undocumented techniques and therefore subject to
failure), unsupported on all mainstream versions of Windows (or possibly
future versions), potentially open to failure after the next SP, and
generally cumbersome and unwieldy to implement. Moreover, these techniques
apply to raw Windows programs. .NET programs are platform neutral so it's
cleaner not to assume they're running on Windows (you would have to rely on
pure Windows techniques to pull these tricks off). Also note that deleting a
running executable once it's finished is likely easier than updating it.

[Ben Voigt]

"Stuart Carnie" <st***********@nospam.nospam> wrote in message
news:%2****************@TK2MSFTNGP02.phx.gbl...

I didn't say it was a good idea :)

I was providing some ideas, given the original question was regarding the
possibility of embedding a new resource in their *existing* executable.
Yes, there are side effects, which you have duly pointed out - the
assembly cannot be strongly named, and it can not be verified, therefore
posing a severe security risk.
Modifying resources doesn't affect whether the code is verifiable, does it?
It will, of course, invalidate the cached verification results.

Cheers,

Stu

Nicholas Paldino [.NET/C# MVP] wrote:

That's a really bad idea.

What if there is a permission set granted to the assembly based on
the hash? Or if the assembly has a strong name? Verification of the
assembly goes out the window now.