A pleasant walk through computing


Announcing DeftConfig


Web.config and app.config shouldn't be stored. They should be generated. DeftConfig helps with that.

NuGet Package

GitHub Repository


The .Net configuration story has never been particularly good. It's improving significantly in .Net Core, but there's a lot of .Net Framework code that's built and going to be built.

The fundamental problems with .Net Framework config files are:

  1. They require a physical file. A configuration can't be created in memory.
  2. They don't work well with multiple environments, even using XML Transformations as intended.
  3. They don't lend themselves to managing sensitive settings such as passwords, especially in a Continuous Integration environment.

DeftConfig makes it easier to use the "base config" approach to managing configuration files using XML Transformations. It follows a convention for how it finds the transformation file.

  1. Look for a file in the format web(or app).base.[Configuration].config. Example: web.base.Release.config
  2. Check the user profile's %APPDATA%\DeftConfig\{Project GUID} folder
  3. Check the project folder
  4. If not found, use web/app.base.Sample.config

This approach allows for storing a production config, with sensitive settings, in a Windows Continuous Integration server's appropriate user profile rather than version control. The server folder can be restricted via permissions.

It also allows multiple developers to have their own, local Debug config; it also doesn't get stored in source control.

Finally, DeftConfig recommends maintaining a sample config that will help new developers understand what configurations need to be changed, and can provide a safe, default working experience.

The package is just two components:

  1. An MSBuild targets file that applies the transformation and outputs the .config file.
  2. A utility to help configure the project, including adding an .ignore file for either Git or TFVC.

Important I don't guarantee DeftConfig will work in your environment. You need to take the right steps to protect your source code, including backups, version control, and testing.


DeftConfig achieves several goals. Web.config is used in the examples below, but DeftConfig applies equally to app.config.

  1. Don't store web.config or web.Debug/Release.config in source control.
  2. Don't store web.Debug.config in source control, allow independent developer configurations.
  3. Use web.base.config file for XmlTransform source, and apply web.base.[Configuration].config transform file.
  4. Make Windows-based Continuous Integration easier and more secure by searching for transform files in a user profile folder first, then in the project file.
  5. Make it easier for new developers to use non-destructive settings.


All isn't lemonade and corn dogs when using DeftConfig. There are a few challenges that you need to be aware of.

  1. NuGet packages often modify the web.config file (EntityFramework, for example). It will be critical for developers who add packages to copy any changes from the local web.config into web.base.config.
  2. If you change only one of the config files, then do a standard build (F6), web.config won't be updated. You'll need to do a Rebuild. (This is not an issue with TFS Build server, which always does a rebuild).


  1. Install the NuGet package. This adds the DeftConfig.targets file, and an executable named DeftConfigInitializer is copied to the project root folder.
  2. Run DeftConfigInitializer, which will
  3. Create a user profile folder for config files, if desired.
  4. Convert existing *.config files to use the *.base.config method.
  5. Add a .gitignore or .tfignore file so that the standard *.config files are ignored by default.
  6. Delete DeftConfigInitializer, if desired.

Typical project files before DeftConfig

and after running DeftConfigInitializer

The Debug and Release configs are still in the project folder, except they've been converted to "base" files.


Any settings that were previously in web.config are now in web.base.config.

Here are the recommended way of using the files, with an example. The original web.config had these appSettings. Notice that the production and dev credentials are being stored. Developers have been commenting/uncommenting.


The base config should retain values that are not transformed, and shouldn't have values for settings that will be tranformed. This is also a good place to document the settings. Copy those credential appSettings elsewhere, we'll need them later.


The Sample config file is stored in source control. It acts as a default configuration. If a Configuration (Debug/Release) config file can't be found, the Sample will be used. These could be default values for a developer, or dummy values.


The Debug file is for developer settings. Since it's not stored in source control, each developer can have her own settings.


Like the Debug file, the Release file is also not stored in source control. As shown below, if using a Windows-based continuous build system, it will be stored in the user profile of the automated build agent. This keeps sensitive credentials out of source control.

Building a Configuration

As noted above, the safest way to build is to right-click the Solution and choose Rebuild. But in most cases you'll be able to just F6 or F5.

Which configuration is used is determined by the selected Configuration.

Many development shops have a separate testing or staging environment. To configure that with DeftConfig, you'd simply add the configuration such as "Stage" using Configuration Manager, then manually create the web.base.Stage.config transform file (probably using copy/paste).

Where and How Transform Files are Searched

The initializer utility will optionally create a folder in the user's profile. The folder is named using the project's GUID, since the project name could change. The path is:

C:\Users\[user]\AppData\Roaming\DeftConfig\{PROJECT GUID}

Strictly speaking, the path is %AppData%\DeftConfig\{PROJECT GUID}

The DeftConfig build target checks for a matching config file in the following order. The diagram assumes the Release configuration is being built for MyAppProject.

Why Isn't Web.config Removed From the Project?

Only files that are part of the project (that is, they're in the .csproj or .vsproj file) will be copied when using the project's Publish feature.

However, just because there's an entry in the project file for web.config doesn't mean it has to be in the folder when you get the code from source control. It just has to be there when Publish is run.

This is why I recommend adding web.config to a Git or TFS ignore file in the project folder. Web.config will always be created as part of the build process, so it doesn't need to be stored in source control.

DeftConfigInitializer will do this automatically if you choose.

Using Git

# Visual Studio 2015 Note: a pattern in the first line is ignored by Changes. Visual Studio Bug.
# DeftConfig - Ignore/allow certain config files when using *.base.[Build].config transform method



Using TFVS

#TFVS Ignore



TFS 2015: Publish ASP.NET Using Robocopy

Team Foundation Server 2015 Update 2 includes Release Management. However, I found myself in a position where a client hadn't upgraded yet, and during development I still wanted to publish ASP.NET MVC and WebApi projects to a test server. I did this through a combination of Build tasks running the msbuild publish command line, and Robocopy.

Also, while TFS Build includes steps for staging artifacts, an ASP.NET project doesn't simply move all files to a bin folder. Many files are taken directly from the project source folders, requiring me to use the MSBuild Publish command line switches.

The TFS Build Definition

In my Build, I'm going to do the following steps:

  1. Get the source code
  2. Get the NuGet packages
  3. Build and Test <= if anything fails up to this point, I don't want to publish
  4. Use msbuild to publish locally (to the Build agent workspace)
  5. Use Robocopy to copy the files to another computer running IIS

The first three steps are pretty standard, so I won't cover them. If you don't know how to set up a build, you'll need to read up on that. The last two are the fun ones.

Publishing ASP.NET from command line

In Visual Studio, it's easy (and nice) to publish an ASP.NET project to the file system. But what if you want to publish in an ad-hoc manner? It can be done, but the info is hard-won.

msbuild ProjectFile.csproj /p:Configuration=Release ^
/p:Platform=AnyCPU ^
/t:WebPublish ^
/p:WebPublishMethod=FileSystem ^
/p:DeleteExistingFiles=True ^

Or if you are building the solution file:

msbuild Solution.sln /p:Configuration=Release ^
/p:DeployOnBuild=True ^
/p:DeployDefaultTarget=WebPublish ^
/p:WebPublishMethod=FileSystem ^
/p:DeleteExistingFiles=True ^

In my Build definition, I add a Visual Studio Build step. (I could probably also use an MS Build step, but I haven't tested that.)

In the Solution field, enter the path to the web project you're going to build. The MSBuild Arguments are shown below. Note the variables used for both the build configuration and the destination folder. I'm publishing locally first.

/p:Configuration=$(BuildConfiguration) /p:DeployOnBuild=True /p:DeployDefaultTarget=WebPublish /p:WebPublishMethod=FileSystem /p:publishUrl="$(build.artifactstagingdirectory)\deploy\web"

Note If I was also publishing a WebApi project in the same definition, I'd have a separate build step, and the publishUrl might be $(build.artifactstagingdirectory)\deploy\api

Copy the site to its destination using Robocopy

Why am I not using the publishUrl, above, to publish to the destination server? In many cases, I could, and that's fine. But what if I expect a destination file to be in use, and isn't normally updated? For example, I had a site using the NHunspell.dll. That file would often be in use, and wasn't changing. If I used publishUrl, the publish would always fail.

Microsoft's Robocopy ("Robust Copy"), included in all Windows editions, will skip and retry files it can't copy. This will still show as an error, but I'll set the step to "continue on error". It's not a perfect solution, but fine for many environments.

Add a Command Line step to the definition.

  • Tool = robocopy.exe
  • Arguments = "$(build.artifactstagingdirectory)\deploy\web" "\\iis-server\wwwroot$\my-web-site" /e /r:2 /w:5

The Robocopy arguments say:

  1. Copy from the local deploy\web folder to the remote server folder
  2. /e = Copies subdirectories. Note that this option includes empty directories.
  3. /r:2 = Retry busy files twice.
  4. /w:5 = Wait five seconds between retry attempts.

When the step runs, Robocopy outputs a nice report of what happened, very useful when viewing the build log.

Wrap Up

While not ideal, the above is a useful workaround for publishing ASP.NET build artifacts to a remote machine. It also shows the flexibility that can be obtained through using other tools.


How to use MsBuild MsDeployPublish to target local file system?

An ASP.NET MVC Site That’s Easy to Deploy from a TFS Build


Combining VeraCrypt, Google Backup & Sync, and Sql Server Part 2

This is a two-part post. Read Part 1 here

It's important to protect business data. Employee access and use of data should be managed by the IT department. But a contractor is often entrusted with data on their own computers. We certainly don't want our laptop to be stolen and have to tell the client that source code or databases with sensitive data just got lost, and, no, it wasn't encrypted.

In Part 1, I discussed how I used VeraCrypt for my encryption. Below is how I solved problems relating to Google Backup and Sync, and Microsoft SQL Server.

The Trouble with Google Backup and Sync (the application formerly known as Google Drive)

I use Google Drive's desktop application to synchronize client files as well as personal. I think that's reasonable, since I can and should expect Google to be secure. Now that I have my test.vc file mounted as F, it's outside of the local Google folder. How do I get it into Drive?

If you're still using the Drive application, one way is to use a symbolic link, which I won't go into here. I've done this for other folders, but didn't want or need to in this case. The reason is that Google has replaced the Drive app with Backup and Sync. Backup and Sync allows backing up any folder on my computer, including other drive letters.

The computer is then available on the web version of Drive (but not the Android app, yet, why not???).

Great! So, what's the problem? Well, Backup and Sync is by default configured to run on login, which makes sense. I like to configure VeraCrypt to run on login, too. The problem is, by the time I get my password entered and the file mounted, Backup and Sync is already reporting that the F drive is unavailable, do I want to stop syncing the F drive? (no)...and the only thing I can do is restart Backup and Sync.

There's a simple solution to this that I wish had worked out for me. It will for most people. A VeraCrypt drive can be configured to act as a Removable drive. And Backup and Sync will be notified if a removable drive comes back online.

Let's show that. In Backup and Sync, stop backing up the F drive. In VeraCrypt, select the F drive and Dismount.

Now, select test.fc and click Mount again, but before submitting the password click Mount Options.

In the options, check "Mount volume as removable medium" and finish mounting the volume.

The F drive will now show as a Removable drive, just as if you'd plugged in a USB external or flash drive.

You might also be prompted to start backing up the USB device. Choose Not Now.

Let's prove we can unmount and remount without restarting Backup and Sync.

In Backup and Sync Preferences, choose to backup the F drive. Let the drive finish syncing (this might take a while, the app likes to reprocess everything). Then, in VeraCrypt, dismount it. You'll get a warning message. Don't take any action.

Now remount the F drive, making sure you set it as removable in the options. Backup and Sync will see the drive is reconnected, and start syncing it.

This is great, and I thought I was finished. If you don't run SQL Server, you probably are, but....

The Strangeness of SQL Server (or a VeraCrypt Bug?)

I develop using SQL Server Express. The SQL service runs automatically at start up and attempts to start any configured databases. See where this is leading?

If I put database files in my F drive, they won't be available to SQL Server on startup and the database will be marked as "Pending", meaning it can't be started. I'd have to restart the SQL service.

There's a solution, but first, what happens if I try to create a SQL database on my removable F drive? Create a "Data" folder first.

Research this error and everyone says it's a permissions problem. I labored for hours under that belief, trying various correct-but-not-successful permissions settings.

Close the error. Pause Backup and Sync. Dismount the F drive, remount it without making it removable. Try creating the Test database again.

Yep, it works fine. What gives? Maybe SQL Server doesn't like installing databases on removable media? That's not the case. It's supported, and I was able to create a database just fine on a USB drive I plugged in.

No, the problem appears to be with VeraCrypt and how it configures itself as a removable drive. I haven't looked into this, though.

This means I can't configure my VeraCrypt drive as removable, which screws up my Backup and Sync solution, above.

Fight, Fight, Schedule Tasks!

It seems like I can't have what I want, which is to start my computer, log in, mount my encrypted drive, and not have to fuss with either Backup and Sync or SQL Server. But I can.

Here's my solution.

  • Set my encrypted volume back to regular (not removable).
  • Turn off both Backup and Sync and SQL Server from automatically starting
  • Use Windows Task Scheduler to delay-start them when I log in, giving me time to mount the encrypted container.

Backup and Sync Task

In Backup and Sync's Preferences > Settings, turn off "Open Backup and Sync on system startup".

Next, open Task Scheduler. Select the Task Scheduler Library, and choose Create Task. Here are the settings. Notice the "log on" trigger, and the one minute delayed start.

SQL Server Task

Open Services, find the SQL Server instance you're running, and set the startup to Manual.

The biggest challenge I faced in creating the scheduled tasks was permissions. The task should have been able to run with my account and elevated privileges. It would, when I was logged in. But it failed on reboot. The solution was to use the local Administrator's group. I don't know why. Here are the settings. Triggers, Conditions and Settings are the same as above.

Death by 998 Cuts

I've now removed two irritations in my daily work flow. It took a while, but is time well spent. I also learned some things. Hopefully this helps you, too.


Save yourself some grief. Set up Backup and Sync to ignore .mdf and .ldf files. They can't be backed up while in use, and will always be throwing errors. If you really need the data, set up SQL backups.