We Keep Coding

What is R60, R72, and MINE file?

I was building a DataAccessLayer using C# in VS 2012, and in my project, there are three files which I don't know how to deal with.
DataAccessLayer.csproj.mine
DataAccessLayer.csproj.r60
DataAccessLayer.csproj.r72
What are they? How should I deal with them?

They are files created from your repository that the code is saved in. You did an update and when you try to commit your files you will get a commit failed probably. When you diff the files, it will use the .mine .r60 .r72 files to bring up the differences between each revision (.r60, r72) and your file (.mine) and allow you to do something like Keep all changes in mine.
In order to get rid of the commit failed error messages, find the original file, update it with the correct changes, and when finished right click it and Mark as resolved and commit. This will get rid of those files.

Those files are related to version control (.mine is your file, .rX come from revision number X). You should try to merge them using your version controlling tool if you have one. If you don't have one and got those files by copying a project, you can possibly delete the .r files and rename DataAccessLayer.csproj.mine in DataAccessLayer.csproj (unless you already have DataAccessLayer.csproj - just keep it and delete the other then). Edit: And if it causes problems, try merging them manually (using a text editor for example) before keeping the final file.

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!

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.

How to get the installation directory (installed with MSI, created with VS2010) at a custom uninstall action?

So I've created a simple msi-setup for my application using a setup project and added a couple of custom actions that take care of stuff like extracting files from archives. Now, there are two extra files in my program files -directory which means that the MSI won't remove the directory at the uninstall by itself. My solution to this was to create a custom action that removes the rest of the files.
Now this works just fine and dandy, as long as the default directory is used at installation. But what if the user chooses to change it? I'd assume there has to be a very simple way to read the directory at the custom action, but I'm not quite sure what that is.
As far as I've found out by googling, there are properties such as TARGETDIR related to the MSI-package. However, some sites also say that I should be setting this property by myself, at the installation stage.
All this has left me quite confused. Basically I see two ways to resolve this:
1) Make sure the application does not create files by itself, and the MSI will take care of it. This would mean a bit more work because I'm not responsible for those extra files.
2) Find out the installation directory at the custom action while uninstalling the application, and remove the last bits by myself. This is the quick-and-dirty way as I see it, and would definitely suffice for now. But how to accomplish this?
Also while I'm here I might as well ask this one more related question. As I mentioned earlier, I extract some files at the install. Now, I'd like to get rid of these archives once I've extracted them. The problem is, if I do this, MSI will think my installation is broken and copy them back each time I launch the application. So how to avoid this?

There is no need to use a custom action to remove the files. MSI has built in support for this scenario in two steps:
Use a search to locate the files you want to remove. Here is a tutorial
http://msdn.microsoft.com/en-us/library/aa371564(VS.85).aspx
Then you can schedule a file removal operation to actually delete the files.
http://msdn.microsoft.com/en-us/library/aa371201(VS.85).aspx
Regarding your second question:
Don't add the archives to the File table. Instead create some self extracting archives and use binary custom actions to unpack them.
http://msdn.microsoft.com/en-us/library/aa368085(VS.85).aspx

How to create Application.exe.config in application directory

So I recently updated my application to support a new feature. In the past if the configuration file was deleted by the user it wasn't a big deal. This new feature requires it to exist, and one of the requirements is that, the file exists in the application's installation directory.
I have notice when the file is deleted ( depending on variables I have not figured out ) I get a .NET notification that the configuration file is missing or corrupt. Currently my program then crashes ( I still have to figure out how to duplicate this behavior ) which is the reason for this question.
I am familar with ConfigurationManager. I am having trouble writting the file once the default values are loaded. Forcing a Save for some reason does not seem to recreate the file, at least not in the installation directory, which is a requirement.
I am looking for guidence on how to handle this corner case in an elegant manner. I would post code, honestly its just all failed attempts, which while my attempts do generate a file the contents are not the settings I am looking for.
I am willing to post anything that might be able to help.

Stop using the built-in config support and just use write/read to a file called something.exe.config using the standard XML classes and if that gets deleted, just re-create it from values hard-coded in the executable.
The config file support is supposed to make things easier, if you need to do stuff where it makes things difficult, don't use it.

Something like
var wcfm = new WebConfigurationFileMap();
Configuration newConfig = WebConfigurationManager.OpenMappedWebConfiguration(wcfm, "/");
newConfig.Save();
doesn't work?

You dont. Under normal conditions the program can not write into it's install directory - this is a standard windows security issue and the reason why app application data should reside ni external (from the exe's point) driectories.
If an admin deletes the config file, crash, ask for reinstall. There is nothing you can RELIABLY do, as you can not assume you can write into the folder at runtime. A message followed by an event log entry is the best approach here. Users are not supposed to delete parts of the application.