Since the Compact Framework doesn't have support for App.Config file, we created our own implementation that follows the full framework model. It requires that the config file be named “MyApp.exe.config” (which is how it works on the desktop) with a subset of the desktop functionality and it's worked well for some time. Until recently that is.
Yesterday I set out to create some unit tests for some of our OpenNETCF.Rss namespace objects. Well the FeedEngine object requires information from an app.config file on construction, so I figured it would be simple - I'd just add an app.config file to the test project and mark it as a DeploymentItem. After a little investigation I found that the calling assembly for a device unit test is SmartDeviceTestHost.exe, which by default runs out of \Program Files\SmartDeviceTest on the target device. That means that to use your own app config file from a unit test it would need to be named SmartDeviceTestHost.exe.config.
Interestingly (or frustratingly, depending on when you asked me yesterday), this test host deploys *its own* version of a config file with the same name with some info on what framework it’s running against. The test framework just heavy-handedly overwrites any existing file rather than merging its contents into the existing one, and it overwrites *after* it deploys all of the test pieces, so you can’t just merge its contents into your own app config and use it.
As a workaround I actually modified the OpenNETCF implementation for app config files. I didn't really want to, but the only other solution I could think of was to write code that would open the MS-deployed version and do a manual merge in the unit test code before the test is run, and that seemed like a much uglier route. The OpenNETCF Configuration implementation now looks for a file named MyApp.exe.config.unittest before looking for MyApp.exe.config and uses the "unittest"-suffixed version if it’s there. I then modified my TestBase class (from which all of my unit tests derive) to add this:
[TestInitialize]
public virtual void TestInitialize()
{
CopyTestConfigFile();
}
private void CopyTestConfigFile()
{
// copy the config file to the test host folder
string src = Path.Combine(TestContext.TestDeploymentDir, "SmartDeviceTestHost.exe.config");
string dest = Path.Combine(TestHostFolder, "SmartDeviceTestHost.exe.config.unittest");
if ((File.Exists(src)) && (!File.Exists(dest)))
{
File.Copy(src, dest);
}
}
public string TestHostFolder
{
get
{
return Path.GetDirectoryName(
Path.GetDirectoryName(
Path.GetDirectoryName(
Assembly.GetCallingAssembly().GetName().CodeBase)));
}
}
Now I simply add SmartDeviceTestHost.exe.config to the unit test project, mark it as a deployment item and voila - it works as expected. Just how it should have yesterday morning when I set out to write a couple simple tests.
And for the record - the current "solution" for debugging device unit tests (which involves putting in a Debugger.Break() call in the unit test and then doing an "attach to process" from another instance of Studio) is an unweildy pain in the ass. It takes no less than a minute just te get a unit test running and in a state that you can step through code. That might not sound like a lot, but try this: put a breakpoint in your code and when the debugger hit is, wait a full minute before you step or look at the Locals window. Now do this every time you want to debug.