resources in exe?
-
Sorry, but I got very basic noob question: When I add a string to resources of a .NET win app on "Resources" tab in Properties of the project and I can use the string in code like so: "Properties.Resources.str" instead of hard coding the string in, right? Why can't I see the string in the executable itself (with a resource editor)? I need to be able to change the string in there without recompiling. Thanks a lot!
-
Sorry, but I got very basic noob question: When I add a string to resources of a .NET win app on "Resources" tab in Properties of the project and I can use the string in code like so: "Properties.Resources.str" instead of hard coding the string in, right? Why can't I see the string in the executable itself (with a resource editor)? I need to be able to change the string in there without recompiling. Thanks a lot!
You are not supposed to modify the content of executable files such as EXE and DLL. How do you expect to replace a string by a longer string in there and keep all pointers/references correct ? For your own safetym executable files are protected by checksums and/or signatures. So if you manage to alter their content, the system will refuse to run them. EXE and DLL files should be the unmodified result of running some tool, first candidate is the linker that gets invoked when building with Visual Studio. There is a concept of "Internationalization" that lets you put regional stuff into separate DLLs (say one per language). In that sense, you can change a language-specific DLL, without really changing the app itself. If that is what you need, look it up! There also is a concept of a "settings file" that lets you put some initial values in a file. If that is what you need, look it up! :)
Luc Pattyn
try { [Search CP Articles] [Search CP Forums] [Forum Guidelines] [My Articles] } catch { [Google] }
-
You are not supposed to modify the content of executable files such as EXE and DLL. How do you expect to replace a string by a longer string in there and keep all pointers/references correct ? For your own safetym executable files are protected by checksums and/or signatures. So if you manage to alter their content, the system will refuse to run them. EXE and DLL files should be the unmodified result of running some tool, first candidate is the linker that gets invoked when building with Visual Studio. There is a concept of "Internationalization" that lets you put regional stuff into separate DLLs (say one per language). In that sense, you can change a language-specific DLL, without really changing the app itself. If that is what you need, look it up! There also is a concept of a "settings file" that lets you put some initial values in a file. If that is what you need, look it up! :)
Luc Pattyn
try { [Search CP Articles] [Search CP Forums] [Forum Guidelines] [My Articles] } catch { [Google] }
Well in regular Win Apps (non .NET) you can change resources just fine with a resource editor without having to recompile the exe. But so I guess in .NET you can't. What's the point of the resources then (besides reusability)? And why are there some resources in the exe that are visible in resource editor and others not?
-
Well in regular Win Apps (non .NET) you can change resources just fine with a resource editor without having to recompile the exe. But so I guess in .NET you can't. What's the point of the resources then (besides reusability)? And why are there some resources in the exe that are visible in resource editor and others not?
A resource editor has to preserve the correctness and consistency of an EXE or DLL file. Why Microsoft has choosen to offer that as a separate tool in the past, and not to do that anymore, I don't know. I don't care much what the tool is called; you hit a button, and it happens. Today it is the same button all the time... Most if not all of the advantages of resources remain intact: you can store non-code items in a DLL (rather than embed them in the middle of your code), hence reuse it across several projects, and, thru internationalization, replace it as you see fit. A variant is "personalization" where you would be selling almost the same application to several big customers; if well organized you just need to replace some images, icons, strings that may all reside in a single DLL. If unhappy, fire your complaints towards Microsoft... :)
Luc Pattyn
try { [Search CP Articles] [Search CP Forums] [Forum Guidelines] [My Articles] } catch { [Google] }
-
Sorry, but I got very basic noob question: When I add a string to resources of a .NET win app on "Resources" tab in Properties of the project and I can use the string in code like so: "Properties.Resources.str" instead of hard coding the string in, right? Why can't I see the string in the executable itself (with a resource editor)? I need to be able to change the string in there without recompiling. Thanks a lot!
If you need to read in the value of a string that's subject to configuration, why not store\read from the registry?
-
A resource editor has to preserve the correctness and consistency of an EXE or DLL file. Why Microsoft has choosen to offer that as a separate tool in the past, and not to do that anymore, I don't know. I don't care much what the tool is called; you hit a button, and it happens. Today it is the same button all the time... Most if not all of the advantages of resources remain intact: you can store non-code items in a DLL (rather than embed them in the middle of your code), hence reuse it across several projects, and, thru internationalization, replace it as you see fit. A variant is "personalization" where you would be selling almost the same application to several big customers; if well organized you just need to replace some images, icons, strings that may all reside in a single DLL. If unhappy, fire your complaints towards Microsoft... :)
Luc Pattyn
try { [Search CP Articles] [Search CP Forums] [Forum Guidelines] [My Articles] } catch { [Google] }
Chill out, man! I'm not firing complains toward anybody, especially you since you don't know... If unhappy, fire back your complaints through UN... That was helpful. :zzz:
-
If you need to read in the value of a string that's subject to configuration, why not store\read from the registry?
Thanks for reply. Sure I can store things anywhere really. There's always a set of different approaches to anything. I just want to get the answer to this particular question. That's all.