Huh? Are you serious? Or do I completely misunderstand what you want to do?
arnold_w wrote:If you think about it, this would be very useful to avoid having a (separate) file that remembers the user's preferences (e.g. list of recently used documents, use spaces instead of spaces, etc). When you exit the application, you would just update the array that contains the user preferences (of course, since the executing file it locked, you first rename the executing file, then create a new file with the original file name and then self-destruct the original file).
It sounds to me as if you want to save one user's preferences in the executable file itself, writing back a modified .exe after removing the old one. Right? If that is it, it is the craziest proposal I have seen for a while!
Re. user preferences: We are not in the Linux world. Using separate files (type ".ini" or ".rc_something") is NOT the proper way to do it. User preferences are stored in under HKCU in the registry. How do you plan to handle different users of the same executable - or do you plan to give each user his own executable for his own private modification?
Under any circumstances: Consider executables as non-writable files - most of all in a managed world. You have left the management of modules to dotNet, and you cannot poke around with a long stick into that management. What you are suggesting is a sort of self-modifying code. Leave that to the assembler guys! Self-modifying code is completely unmanagable! (not only in the sense of dotNet, but generally speaking)
Sure, you are only modifying parameters to some funcitons, but it is not seen as external input at run time, it is hidden within the code itself. So it appears as the code has been changed from one run to another, with no external input. That is functionally identical to the code modifying itself.
In a managed runtime, you do not control the memory location of the managed modules - that is an essential part of the management (that you have left to others). Although you can build a single, fully compiled .exe-file from C#, this is really not the standard way: Assemblies are distributed in a "half-compiled" form, as CIL (Common Intermediate Language), where the final compilation steps are done when the assembly is first used. Until this last complilation is done (this is where differnet instruction sets etc. are taken into consideration), memory addresses are not known. At run time, the addresses may vary from one machine/CPU to another.
So there is no "linker script" for the entire application the way you seem to expect. It is all done dynamically. When you create a self-contained .exe, you are really doing part of the run time handling in advance. But since the "real" dotNet assumes that this is done dynamically, there are no provisions for e.g. controlling memory addresses from outside. Memory placement is handled in other ways, so there is no need to. Or reason to. It doesn't belong in a managed environment.
If you feel that your proposed solution is the only viable alternative, then I don't think managed code is for you. Consider assembly code, or possibly pure C.