I’ve been meaning to get around to sorting out the plethora of App.config in a large, multi project C# solution, but it wasn’t anywhere near the top of the pile of problems that needed solving. I just keep hacking values into the *.exe.config file after the build to make things work.

In a spare (and rare) 20 minutes, while drinking a coffee, I thought I’d have a quick look and discovered a really simple solution. For some reason this technique had completely passed me by. Imagine you’ve got a C# solution made up of 3 projects which build into 3 separate executables, each requiring a common config file. If you have simply added a config file to each project and try to keep them in sync you quickly end up in config hell. So rather that add a new config file to each project, simply create one in one of the projects and then link it in the others.

Here’s how, in our imaginary 3 project solution

Solution
     Project1
     Project2
     Project3

  • Right click on Project1 and select Add->New Item->Application Configuration File and it will create a the file App.config in Project1.
  • Right click on Project2 and select Add->Existing Item and browse to Project1’s App.config file, but don’t hit the Add button. Select the Add button drop down and select Add as link.
  • Repeat for Project3

So now when you open any of the projects App.config files you will be using the same file. More importantly, when you build the solution, each projects bin/Debug (Release) directory will have it’s own, but identical copy of the config file (Project*.exe.config) leaving you the freedom to deploy the executables with their own or a common config file. Essentially, building the solution duplicates the config files from a single master version.

Itch successfully scratched.

Advertisements

Ever had this problem trying to remote desktop (RDP) to a Windows Server 2003? I got very frustrated by this today. All the Administrator group sessions had been used up, the selfish remoters had gone home and left themselves logged in, so I wasn’t able to admin the server. Arrrrggg!

Yes, all I needed to do was to be able to get to the Terminal Services Manager and forcably terminate their sessions, but I couldn’t get in – the keys were effectively locked in the safe. The server I was trying to admin had a limit of 2 admin RDP sessions – the default limit for Server 2003 I think.

It turns out there is a simple answer to get around this (aren’t they all simple when you know them). The number of sessions on the server is calculated on the RDP client admin sessions, but console connections aren’t included. So the work around is;

Run a cmd session on your client machine and start a console based terminal service to the machine you want to connect to.

mstsc /v:xxx.xxx.xxx.xxx /f -console

where xxx.xxx.xxx.xxx is the IP or resolvable server name

You can then use Control Panel->Administrative Tools->Terminal Services Manager to disconnect the selfish remoters and connect with the RDP client as normal.

Don’t forget to logoff yourself when you’ve finished though.