Save settings (text in TextBox) without My.Settings, SaveSetting, DataBase, *.txt ?

[makisiki]

My.Settings = (file)
SaveSetting = (registry)
SQL-DataBase = (file)
config, ini, txt ... = (file)

How do i save the settings without using the above (or Save the Text in the TextBox) ?

I want the application to have only one .exe file and I don't want to write it in the registry.

Is there anything else ?

Thanks.

 

[jmcilhinney]

If you're going to save data then you need to save it to somewhere. You can't magically rewrite your EXE at runtime to contain data. Decide where you want to save the data and we can help you save it there. Ask us how to perform magic and you'll be out of luck.

 

[jmcilhinney]

Basically, everything is a file on a computer. Registry data is stored in files too, with a specific interface provided over the top. Databases provide dedicated interfaces too, while storing their data in files. You basically just need to decide what type of file you're going to use and, for those you have control over, where you're going to store them. Windows does provide various dedicated locations for application files, so you should generally use one of those. Ig you use My.Settings then the default value of User-scoped settings will be stored in the main config file in the same folder as the app and the current values will be stored under the AppData folder. That would be my recommendation. I know you said that you didn't want to do that but what you do want is basically magic.

That said, I suppose the other alternative is to store the data in the cloud somewhere. That is still going to be in a file of some sort but it will not be on the user's machine. That would enable settings to be shared across multiple machines and the ability to move from one machine to another without copying anything but the EXE. Of course, that would likely be significantly more work and probably mean some sort of account for each user.

 

[makisiki]

... I thought there was some possibility to save it directly in an EXE file.

I accept this as an answer
You can't magically rewrite your EXE at runtime to contain data.

Thanks for the quick reply.

 

[cjard]

Normally for these cases we'd have defaults built into the exe, and when those defaults are overridden/changed to something the user wants, we write them to disk, somewhere that we can load them. If you don't want that on the user's computer you could make it on an internet connected server. You could also create the impression of a single exe - the file you give the user has a silent installer when run. They save it somewhere e.g. c:\downloads\my.exe and run it. It unpacks itself to another location and launches that other location; whenever that exe's settings change it can rewrite the one in c:\downloads so that it contains itself and updated settings settings. The exe that is passed around is not the one that runs, but the user may not care about the distinction. You could also pull a similar trick by, when the user changes the settings, write a new exe somewhere temporary that contains the new settings, and then set something that copies the new exe over the top of the existing one at e.g. windows startup. How you fiddle it would probably depend on the specifics of the use case, which you haven't really mentioned

 

[chrisjlocke1]

> I want the application to have only one .exe file

Unfortunately, a program has to store its config somewhere. The recommended location is the registry and VB has easy-to-use methods to do this. Unfortunately, it doesn't make the program portable - run the program on another PC and you lose your config. Writing to a config file is easier, and I tend to place the config file with the .exe file - some users can't navigate to applicationData, etc.
Writing to a database is easy these days - sqlite is small, simple and free. It's easier to use than string slicing with text files. It does mean it breaks your rule of only having an .exe file, but it makes your programming life way easier, which is the main thing!

 

[jmcilhinney]

The recommended location is the registry and VB has easy-to-use methods to do this.

That may have been true back in the days of VB6 but not any more. Those methods still exist but .NET has its own inbuilt configuration system and that is the recommended option. If you use My.Settings, read-only application settings and the default values of read/write user settings are stored in the config file in the same folder as the EXE by default, while the current values of user settings are stored under each user's application data folder.

some users can't navigate to applicationData, etc.

All users can access their own application data folder but only administrators can write to the common application data folder.

 

[chrisjlocke1]

> but .NET has its own inbuilt configuration system

Isn't this (sort of) broken though? If I have a settings file and allow the user to change those settings, they're stored in a file linked to the version of the .exe. If the .exe is updated, the user loses their settings and the default values are used again.
When storing values in the 'my.settings' config file, we had loads of problems whenever we upgraded. Maybe its changed, but using the registry still seems a lot easier.
Also from a 'emergency', it's a lot easier to get a user to amend the registry than it is to edit an XML file. If for some reason a setting needs changing from 1 to 0, double-clicking a reg file is relatively easy.

> All users can access their own application data folder

That's not what I was referring to, but don't worry.

 

[jmcilhinney]

Isn't this (sort of) broken though? If I have a settings file and allow the user to change those settings, they're stored in a file linked to the version of the .exe. If the .exe is updated, the user loses their settings and the default values are used again.
When storing values in the 'my.settings' config file, we had loads of problems whenever we upgraded. Maybe its changed, but using the registry still seems a lot easier.

If you use xcopy deployment then yes, but installers can handle settings during an upgrade. If it didn't work for you then you did it wrong.

Also from a 'emergency', it's a lot easier to get a user to amend the registry than it is to edit an XML file. If for some reason a setting needs changing from 1 to 0, double-clicking a reg file is relatively easy.

How often do you have such an emergency? Designing your software around that seems an odd choice.

Using the Registry has its own issues too. If you prefer to use it then that's fine. If you want to tell others how to use it then that's fine. Telling people that it is the recommended option is just false though.

 

[cjard]

> The recommended location is the registry

.net core apps run on linux, which doesn't have a registry; I'd say the recommended location these days is somewhere else..

..but I also want to point out that this discussion has shifted to beating on the My.Settings system for being ineffective during an upgrade and losing the settings, so you're looking to store the settings inside the exe file which will definitely be replaced during an upgrade, which loses the settings..

..unless the installer knows how to retrieve them and write them to the new exe, which is definitely a custom job and a lot of work, and if you're prepared to go to that extent of work then why not just go to the lesser extent of keeping settings in a file or database that isn't overwritten by an installer (like my.settings, a database, or any of the chosen methods you set out saying you don't want unto use?!)

 

[cjard]

> if for some reason a setting needs changing from 1 to 0, double-clicking a reg file is relatively easy.

Can your users edit the registry as non-administrators and not screw up their computer as easily as opening a text file in notepad and changing a single character? They must be more savvy than my users! I barely trust mine to turn the computer on

 

[chrisjlocke1]

> then you did it wrong

More than likely!

> this discussion has shifted to beating on the My.Settings system for being ineffective

Oops - my fault. Sorry.

> so you're looking to store the settings inside the exe

No, not me - thats the original poster.

> then why not just go to the lesser extent of keeping settings in a file or database

I did suggest that, but I think I said I put the config file 'by' the .exe (as in the same location) not 'in' the .exe. That was my fault not being clear. I tend to use sqlite databases, which from my previous comment about manually editing a file is even worse, but I'm totally derailing this topic now... Ignore me.