|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Embedding a resource at runtimeHi 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,
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. -- Show quote- 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. > > Do you want to do this to an assembly that is loaded in the runtime? If Thanks for the feedback. In my particular case however, adding and updating > 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. 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,
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. -- Show quote- 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). > > It's one thing to process resources in an assembly that you actually don't I really didn't think so since updating a running executable isn't normally > load in the CLR, but to do it in an assembly already loaded in the CLR, > that's just not feasible. 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. 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 Show quote "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. > > > 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: Show quote > 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. > > 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. -- Show quote- 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. >> 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: Show quote > 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. > > >I didn't say it was a good idea :) Thanks for the suggestion. In addtion to the above issues however, it's an > > 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. 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). Actually, it is possible and various techniques are available to implement a "self deleting executable", see http://tinyurl.com/eb9o4.
Dave Brown wrote: Show quote >> 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). > > > Actually, it is possible and various techniques are available to implement I quickly inspected some of these techniques and what I see is either > a "self deleting executable", see http://tinyurl.com/eb9o4. 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. "Stuart Carnie" <stuart.carnie@nospam.nospam> wrote in message Modifying resources doesn't affect whether the code is verifiable, does it? 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. It will, of course, invalidate the cached verification results. Show quote > > 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. >>  |
|||||||||||||||||||||||
Other interesting topics