We Keep Coding

C# Change File Location For Next Time Program Runs

I am relatively new to C#, however I do have some basic knowledge of code from courses in high school and university. However, there is one thing I have not been able to figure out over the years. I am currently making a Form Application for a database system that stores information in a List using Visual Studios 2010.
On my main form; when the save button is pressed, the information is then serialized into an XML file. When the information is loaded, the information is then deserialized and put into the List for use in the code. All this is working correctly.
This process of saving and loading is done based on a string which contains the file path. This string is the location of a folder on my desktop (I put it there for easy access), and I am able to change the string in the code to basically move where the information is stored.
However, I have a separate "Admin" form which is able to change this file path string. When the user clicks the button to change the file path, I get the input from a text box, check its formatting, move the current file to the new location and update the location for the save method so changes can be saved before the program is closed. From there, the program reacts the same way as if I had changed the string from inside the code.
The problem occurs when I close the program. I do not know how to tell the program when it runs again that the location has been changed from the default and look for the file in the new location. The program reacts just like the file was missing (like it should) when it looks in the default location.
So basically, how do I tell the program that the save location was changed from when it was last run so it knows to load the info from a new location?
I have tried looking for an answer since high school (about 2 years ago) and have not found a solution. As a result I usually just keep the save location as the default (which I set it to) and don't try to change it. But this time, its important that the save location can be customized. My experience with Visual Studios is limited, as everything I know is from messing around with the program and looking up stuff when needed.
If needed, I can post snippets of my code. Thank you in advance!

It seems like what you really want is to save some user-defined settings for recall at run-time. Here is a MSDN link describing some basic conventions for storing / retrieving these settings.
https://msdn.microsoft.com/en-us/library/bb397750(v=vs.110).aspx
A *.config file would suffice (depending on the scale of the application).
Otherwise, you may want to go down the route of storing these settings in a database (if the scale is rather large, or if user-authentication is required for the application).
Here is another previous question dealing with this same subject (regarding App.config files):
What is App.config in C#.NET? How to use it?

I recommend using a config file where the .exe is, and write the location there, then read it in on program startup.
In particular .net provides this class which can manage your config file for you (assuming you have an app.config in your solution, otherwise create one)
https://msdn.microsoft.com/en-us/library/system.configuration.configurationmanager.appsettings(v=vs.110).aspx

Can I edit Resource file at runtime

I have a WCF service, it response with JSON. I need to create a language file, which I can edit on production server. no problem if I will need to recycle App pool.
I was about to use Resource file, but I was worry that it is not editable by end user.
I don't need to edit it pragmatically, the end user will edit it by opening the file in notepad without recompiling the application.
What do you suggest?

Yes you can using the ResXResourceWriter class.
If you need to generate the Designer.cs file as well see this question Programmatically generate Designer.cs for resx file (ResXResourceWriter/ResXResourceReader)
If you need to modify the existing resx files see this question Modifying .resx file in c#

According to MSDN, you can add new resource at runtime:
You can incrementally add resources for new cultures after you have
deployed an application. Because subsequent development of
culture-specific resources can require a significant amount of time,
this allows you to release your main application first, and deliver
culture-specific resources at a later date.
http://msdn.microsoft.com/en-us/library/sb6a8618%28v=vs.110%29.aspx
I think editing current resource will also work.

Your users should be able to edit the files with no problems, the resource files are XML files that can be opened in notepad or any text editor, they could even open it in Excel and get multiple columns that they can easily edit.
This will require recycling your App pool but you're open to that.
[edit]
You don't need to be recompile as I mentioned before if your resource files are marked as content, but your App pool will be recycled to pick up changes

I am not sure but it seems that user can't edit resource file using a notepad at runtime, and the application should rebuild in order changes takes effect.
Setting file with user scope can do the job.

defining location of files at deployment time

I have an app that has search functionality. The search algorithm is compiled to a separate dll. In the C# code for the search algorithm, I am using strings held in a settings file to point to the directory where the search index resides. But once the search code is compiled, the settings file is somehow incorporated in the dll. I want to have multiple versions of this code running on my server with each pointing to a different location for the index. And I want the operator to change a file to have each version point to something else as they find necessary. Both config files and settings files end up getting incorporated in the dll. How do I then accomplish this? What is the right industry standard way of doing this?

It's strange that the settings file is compiled... are you sure about that? Setting, config and resx files should be copied to the output directory, it's even a property you can modify on solution explorer. Then you should get it's values by doing
System.Configuration.ConfigurationManager.AppSettings.Get("YourKey")
But I think this won't know about user changes until app is restarted. If you want settings to be dynamic you should either store them on a database, or on a file that you open, read and close every time you need it.
Hope this helped!

rolling out and reading base data in an WP7 app

I'm creating an WP7 app that shows an inspirational text for every day and allows you to mark some of this texts as favorites. You can see the text for today, jump to an day in the calendar oder browse your favorites.
All texts are known prior roll out / installation, I don't want to lazy load them via cloud/web, I want to "install" them together with the app.
How should I store them? Should I use one of the open source databases for WP7 and create all rows on installation? Should I just hardcode them and save the favorites in an IsolatedStorage file?
EDIT: Is it possible to have the read only data in a XML file in the Visual Studio Project and mark it as a ressource? Will this later roll out the file automatically? Does this make sense?

If your concern is speed of loading / efficiency of reading the files then you'll have to test to see what works best. I'd start with what's simplest to implement and then change if necessary.
What is right for your app will depend on the total size of data and the size of individual pieces of text. As well as considering where you store the data, be sure to also consider the format you store it in as deserialization/parsing is also an overhaed you should consider.
Remember to test this on an actual device as the performance you see on the emulator is not likely to be realistic of what your users will see.
Update
If it's readonly data you probably want to add it as multiple content files (set the build Action) within the XAP.
The format of the files and how you divide the data between them will depend on the data and the app.
Having multiple files means you don't have to load all the data at once. (I assume you don't need to do that.) Just open the file you need.
Update 2
For an example of loading a resource file from the XAP see: http://blogs.msdn.com/b/silverlight_sdk/archive/2010/08/27/loading-a-static-xml-file-to-your-windows-phone-silverlight-app.aspx

Settings For Individual Programmers In A Config File

I'm wondering if there is a way to create settings in a config file for individual programmers. The situation I'm encountering is that there are some programmers who want settings turned on and several that want them turned off. Our config files are in SVN source control, so using a shared config file means we are always overwriting each others settings. We are doing this for an ASP.NET web application project. My initial thoughts would be to create a config file outside of source control, but how do I make it so that each programmer has his own copy?
Here is some further clarification. We have a link in the main web.config file that points to an environment-based file (e.g. file used for dev, staging and live).
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<appSettings configSource="EnvironmentConfigs\appSettings.config" />
...
</configuration>
Inside the appSettings.config file, we have settings for dev, staging and live. What I'd like to do is create another config file called user.config and have the individual programmer settings staored there (not in source control of course). What do I need to do in order to have visual studio read from this new file?

The settings file does not need to be versioned in SVN, or each developer can select their settings file to not be overwritten or committed. See the SVN settings file, it could even be added as a global ignore.

Each developer can set up their own build congifuration in Visual Studio. This build configuration should be linked to a build script, which replaces sections of the Web.Config/App.Config/*.Config files specifically as the developer wants.
This way, when they want to make changes to the config files to suit themselves, they should change the replacements in the build script rather than changing the config file directly.
This article covers some of the points i've mentioned: http://www.diaryofaninja.com/blog/2010/05/09/automated-site-deployments-with-teamcity-deployment-projects-amp-svn

Remove the config file from source control and set the svn:ignore property on it. Then it won't be committed. Then, also create another file, like, Production.web.config, that has the production values in it, so you still keep those around too.
That's what I do!

Don't commit config file changes unless they are new settings that to be sent to everyone.
Otherwise, checkout, edit, and leave it checked out. You'll know if someone else has added/modified the file when you get latest version. At which time you merge your settings with their changes, but leave it checked out on your machine.

We do not store application configuration files in source control. Instead, in source control, we store a configuration file template, usually named something like web.config.template. Each developer has their own 'values' file, usually named web.config.values-bem for instance. Each developer also sets up a post-commit hook which takes the template file, and processes it, replacing 'variables' with their values from the specified values file.
For instance, my config values file has the following definition in it:
DB_SERVER=.\SQLEXPRESS
In the web.config.template file, this exists:
connectionString="server=#DB_SERVER#[DEV1];Persist Security Info=True;Password=#DB_PW#;User ID=#DB_USER#;database=#DB_NAME#;Enlist=false;Max Pool Size=100" />
So when the process runs (a python script), it replaces all instances of #DB_SERVER# with the setting I have in my values file. The template script allows for default values to be specified right in the template as well, so you can make changes to the template file and not break other developers' environments (usually). (The default values are next to the variable, in square brackets.)
This solution allows each developer to have their own settings, but still have a web.config.template file that's versioned, and each developer avoids 'inflicting' configuration changes on other developers.
This works well for us. If you want to use the same scheme, you can check out the code for it on my github: https://github.com/bmontgomery/FileReplace. I can help you with the hook scripts as well if you're interested in that.