Develop Reference

How should I handle secret values in a project in source control?

My question is essentially the same as this one but for a Windows Store App, c# and Visual Studio. I want to have an easy way to keep secret values in the project, in a file that can be ignored in (not checked in to) source control. How should I structure my project to store the app secret in a way that makes building/source control easy?
My first idea was to store it in an XML file (not checked in), and load it at runtime, but this leaves it available to the user who installs it, so it should be done at build time. How can I store a couple secret values and have visual studio replace them in my code when my project is built?

In my company we decide to you following solution. In config file we link sections with "secret" values in external configs.
External configs are on source control. First it wasn't but after a problem when our build server lost a disk we decide it it safer to store it on a place which has backup. The folder in source control (can be also on file server) is really restricted to read and write to only people who needs this. Build process checkouts "project" folder plus "configuration" folder and do build. After build "configuration" folder is deleted. Access to build server is also restricted.

One option is to store the secrets in source control, but store them in an encrypted form. In your development or build environments, use a environment variable to store the key, and decrypt on the fly. That way you get the benefits of source control while keeping your info safe.
It is possible to do this even if you are using app.config or web.config, you just need to modify the configuration from code at startup.
Erick

Updated
If you put a secret in an untrusted area (e.g. public source control), it is vulnerable. Even if it's encrypted, with enough diligence it can be retrieved.
The only way to really keep it out of reach is to have an external service that interacts with the 3rd party API. That has its own trade-offs (e.g. user authentication as you mentioned in comments). Especially if your developers need to utilize the 3rd party API when testing, I see no other alternative that will limit the secret's exposure.

Create a new class file in your project that has slots for all of your secret values, and holds dummy/test values for all of them. Check that into source control with the rest of your project, so that anybody building it without access to the secrets will get some sort of test version.
Then, create a copy of that class file with the real secret values, and put it somewhere outside of source control. Write a batch script in the pre-build event that looks for this class file, and if found, replaces the dummy file that is included in the project with it.
This way, your project can still be in source control and anybody can check it out, build it, and run it in the test mode. Your secret file/values are stored on your build server only, so only when you build the project there will it have the real values.
Do remember to back up your secrets file somewhere. And also remember that .NET code can be decompiled easily, so your secrets may not be as secret as you hope them to be - any user with a .NET reflector can see all of the code in your release assembly, including your secret class.

Embed serialized data into executable

I'm currently working on a small project where I have a list of lists of objects, which I need to store between program executions. The scale of the project is in my opinion not large enough to start developing an external DB-solution, so I would like to store the data inside the executable, so the end-user does not have to keep track of multiple files. Is this possible at all? I've been thinking about embedding the file as a resource, but as I have read, it is not possible to edit this resource file without recompiling the project, so this is not a solution. Alternatively I have read about Alternate Data Streams, but I don't know if it is a good idea to edit the executable this way?
So all in all I need the executable to store data between executions, without the need for managing other files.
I hope you are able to help me.

I believe Application Settings are the way to go here.
More explained at Best practice to save application settings in a Windows Forms Application

Where to store user preferences for a C# Windows app

Can anyone provide a best-practices example for where to store user preferences for a C# Windows app?
So far I've heard a number of options:
Some people are saying to store it in
SQLite. Is SQLite bundled with .NET
2.0 and immediately available for use to me?
Others have said to use the built-in
Application Settings... but I've
heard that the per-user settings here
disappear if you upgrade the app (an
obvious problem).
I've also considered just storing it
in a .xml file somewhere on disk...
but where it the "correct" place to
store that .xml file for the user?

SQLite is not included with .NET2, but you could ship it with your application
The built-in settings system works fine for simple apps - you do need to add a couple of lines of boilerplate to deal with version changes but it's not complicated.
You could put your xml file here:
Environment.GetFolderPath(
Environment.SpecialFolder.LocalApplicationData)
There is a lot of 'it depends' about your question, as you don't say how much of what types of data you need to store, nor if you have any other reasons to care where it goes.

The per-user settings "disappearing" can be solved thus: .NET ApplicationSettingsBase Should I call Upgrade() every time I load?

Storing user application settings in isolated storage seems to be a best practice.
http://msdn.microsoft.com/en-us/library/system.io.isolatedstorage(v=vs.80).aspx
Storing settings as an xml file is perfectly fine.

how to store settings for deployable c# application?

I want to store settings for my C# application, such that default setttings can be easily shipped with my binaries and the end-user can change them using a simple text editor(or in some other simple way).
I seem to face several alternatives : a .config file, .settings file or a .resx file. What are the pros and cons of these?
Edit1: End-users are computer professionals mainly, so editing these files should not be much of a problem.
Edit2: The settings are something like connection strings, and some other parameters (mostly one-time stuff). Building some kind of GUI/API for changing them is not really an option. Also my application will not edit any of these values, so persistence through code is not required.

Yes, Project + Properties, Settings tab was designed to do this. Add your settings here, change the Scope to Application. That generates a app.exe.config file in your build direcctory, deploy it along with your EXE. Use Properties.Settings.Default.SettingName in your code to obtain the setting value. Your user will normally need admin privileges to edit the .exe.config file on the target machine to change the setting value.
The small print: settings do not work well for DLL assemblies, you have to merge the .config files by hand. When using the debugger, settings are retrieved from the app.vshost.exe.config file.
The .settings file is a helper file used by the IDE, ignore it. .Resx files store resources, they get compiled and embedded in a binary form in an assembly. They are not editable by the user.

I think you can have two ways of doing this.
For regular users, you can make a custom GUI that will make it simple for them to use.
For advanced users, they can edit the configurations using a text editor if it's stored in a text file (ini file, config file, etc..) or you can make an API.

The .settings file is typically used for user-specific preferences and configuration information (whereas the .config file is used for global settings for the application or anything that modifies the .Net runtime. Simply putting parameters in a .config file can alter the behavior of your application even without you writing a single line of code for it).
Check out the Settings article on MSDN for more: http://msdn.microsoft.com/en-us/library/aa730869(VS.80).aspx

Since the file will be modified by the users, I think using app.config is not a good idea. What if they break the file structure? Or set an invalid value? Probably your application will crash directly.
One of the solutions would be to use a custom XML file. You will then validate it when your application starts. XSD will probably be the more elegant way to do it, but you can also parse it directly and validate it in code. If the file is invalid, instead of crashing, you will try to solve the problem, and if impossible, display a pretty error to the user, explaining that there is an error in XML at line n, position n, which is [error description here].

If the end user is really going to be editing them, I'm not sure I would want them editing my app.config file.
You have another couple alternatives that you haven't included. You could use an old-school .INI file that is simpler for an end user to understand. You could also use the registry. I would recommend the INI file, unless your users are very savvy, in which case use the .config file.

The answer depends on the deployment method. For instance, if you are using ClickOnce and offer updates, you might encouter problems using Application Settings.
I believe the best way to go is to create a GUI, something that is most certainly suitable for novice users. Given that you already excluded that option, use John's suggestion (ini files).

C# Application Configuration Data

Hey, I want to store application configuration data. Currently, I'm using INIs but they are too old and now I want to try something new. I'm on .NET platform using C#.
What solutions do I have? app.configs?
The scenario here is like that, I want to let other programs read the configuration data.

Yes, the various .config files (app.config, web.config, etc..) have replaced INI and, to a certain extent, the Registry as the preferred means of storing configuration data for your application.
Any program, .Net or otherwise, can read those files. .Net has the ConfigurationManager class and other languages can simply do XML parsing to get the values they need.

The standard approach with .NET is to use app.config files for application settings and user.config files for user specific settings (the location varies between XP and Vista though).
There's nothing to stop other programs reading the configuration data, you just need to have a configuration setting in the second (or third) application that tells it where to look.

The app.config would be the preferred way of doing things in .NET. Should work fine to read from other applications as well, as long as you give them the right path to the file. And it's just an XML file, so you can read it from non .NET apps as well.

If you're using Visual Studio, you can use Application Settings for this purpose. Just open the automatically added Settings.settings or create another one. They will be automatically available in Properties.Settings.Default and are stored as XML. You can also have multiple settings files for different purposes.
This is a Visual Studio concept rather than a .NET concept.

I often use an SQL table to hold my application settings. I create a singleton class, ususally called AppSettings, that I load with data from the table. The AppSettings class is then used to get the config values instead of directly accessing the config files. For ASP.Net apps, I instantiate the AppSettings class in the Application_Start event in Global.asax.cs.
Doing this gives me a way to allow the user to control some of the app settings, e.g. an email address for notifications. It also can simplify things when maintaining prod, QA, and dev versions of the app (assuming you have separate database instances for each)