Visual Studio - UserName / Password management to control deployment / source / source sharing

Question

I would like the simplified methodology to work locally (work was done on several machines), deploy and fix version control, where important information is up to and including (password, username, port (s)), host names, database name) automatically missing (or deleted) and imported based on what situation?

Sensitive data was listed in order of importance, so if the password solutions are good, the better the chain. Another nice thing would be for there to be a dummy sample file for someone else to try the project on its own machine with its own host, simply by filling in the missing parts of the dummy file.

What are my options for this feature? I thought about adding the appropriate parameters to the local machine.config file, but then the information is stored in the machine file, and not somewhere encrypted in the file of my user documents. In addition, it does not lend itself well to a local stub file for new programmers to connect and play.

I think the cleanest solution is a local .config file in the root of the project that is not added to version control.

If there is a way to encrypt it in such a way that the server computer is the only one that has a key to decrypt the file (and not a project capable of doing this) that will be deployed, that would be awesome. Then I could store the data in the initial control, share the source with other people interested in studying the project, without getting the actual information needed to make changes or view private information.

Answer 1

We use several .config files: one for dev, one for integration, one for QA, one for pre-production, and one for production. Each file has a suffix (e.g..:. Prod).

The files contain all the necessary software for connecting to databases and servers, with the exception of the production .config file, where the connection strings, users, and passwords are replaced by placeholders.

When we send a new version of the software to the production team, we send an updated but “neutralized” .config file. The production team then adds the missing information.

I think encrypting the file (or information) is not a solution: you would have a new problem: how to hide the keys used for encryption ...

(Note: we use conversions to create the correct .config file for each environment.)