Embedding a resource at runtime

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
Tue Jun 06 10:47:29 CDT 2006

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]
- mvp@spam.guard.caspershouse.com

"Dave Brown" <no_spam@_nospam.com> wrote in message
news:Ol4pG5XiGHA.5036@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
Tue Jun 06 11:06:26 CDT 2006

> 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
Tue Jun 06 11:13:12 CDT 2006

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]
- mvp@spam.guard.caspershouse.com

"Dave Brown" <no_spam@_nospam.com> wrote in message
news:%23QVttMYiGHA.4512@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
Tue Jun 06 11:29:22 CDT 2006

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

DinhduyTran
Tue Jun 06 11:45:02 CDT 2006

Hi Dave,

I don't think that you can modify assembly that already loaded in the CLR
because the assembly is protected (cannot modify or delete) untill it is
unloaded.

You can use Resource Writer classes to update resources for a file (or
assembly) without using command line tool.

-Dinhduy
CSDP/MCSD/MCSD.NET/MST

"Dave Brown" wrote:

> > 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
Tue Jun 06 11:51:21 CDT 2006

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
Tue Jun 06 12:00:43 CDT 2006

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]
- mvp@spam.guard.caspershouse.com

"Stuart Carnie" <stuart.carnie@nospam.nospam> wrote in message
news:4485B289.5070802@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
Tue Jun 06 12:09:51 CDT 2006

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
Tue Jun 06 13:34:44 CDT 2006

>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
Tue Jun 06 17:35:43 CDT 2006

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
Wed Jun 07 07:32:50 CDT 2006

> 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
Wed Jun 07 12:27:59 CDT 2006


"Stuart Carnie" <stuart.carnie@nospam.nospam> wrote in message
news:%23VexGwYiGHA.3816@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.
>>