A pleasant walk through computing


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.

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

This is a two-part post. Read Part 2 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.

Below, I discuss how I used VeraCrypt for my encryption. In Part 2, I show how I solved problems relating to Google Backup and Sync, and Microsoft SQL Server.

For Windows users, there are a few encryption solutions.

BitLocker BitLocker is available on these editions:

  • Ultimate and Enterprise editions of Windows Vista and Windows 7
  • Pro and Enterprise editions of Windows 8 and 8.1
  • Pro, Enterprise, and Education editions of Windows 10
  • Windows Server 2008 and later

^source: Wikipedia^

To use BitLocker, your computer hardware must have a compatible Trusted Platform Module.

I won't go into how to configure BitLocker. Suffice to say, if you have this option available, I think you should use it unless you have a reasonable security objection. And if that's the case, you're already looking into alternatives.

I do not use BitLocker because my hardware doesn't support it.

Windows Encrypting File System (EFS) EFS is available on all Windows editions from 2000 onward, Professional and above. When configured, decryption happens transparently. It's important to export and separately store the encryption password. There are security issues with EFS, but for my purposes I thought it would be an acceptable solution.

I tried setting a client folder to use EFS, but ran into a significant problem: a showstopper, in fact. If found that I couldn't create a new Visual Studio ASP.NET project from a template.

Since I'm primarily a web developer, this simply wouldn't work.

More Information If you want to read more about BitLocker and EFS, try this article.

VeraCrypt VeraCrypt is the successor to TrueCrypt, which I used many years ago before the author abruptly shut down the project. VeraCrypt has been security-audited, and I'm glad to be using it (again). It can be installed on any edition of Windows, as well as Linux and Mac OS X.

VeraCrypt has two main configuration scenarios:

  • Using a container file, create a virtual encrypted drive with its own drive letter.
  • Encrypt an entire partition or drive.

Arguably, as with BitLocker, the best thing to do is encrypt the entire drive and deal with the extra passphrase prompt when booting up. However, I opted for the quicker option of container file.

VeraCrypt Walkthrough

Here's a simple walkthrough to install and configure VeraCrypt the way I did.

Download and install the latest Windows version.

Open the application and click Create Volume

Choose "Create an encrypted file container" and Next.

Choose "Standard VeraCrypt volume" and Next.

Enter a new filename and path, which you can also set via the dialog. It doesn't matter what the filename or extention are. It doesn't even need an extension.

Warning If you choose an existing file, it will be overwritten. Don't do that. Create a new filename.

Choose your encryption options. The defaults are fine.

Choose the maximum size of the drive. Remember, any size you choose here subtracts from your available physical drive space. If you ever need a larger encrypted drive, you'll need to create one and move all the files. For this exercise, choose 50MB.

Note I know the screenshot shows 5MB, but it needs to be higher to create the database later.

Enter your password or passphrase. I like passphrases, because they can be long but easy to remember. Here's one:


Choose the NTFS filesystem, then start moving your mouse around until the bar turns green. Click Format. I'll take awhile, depending on the size of the drive, and you'll be prompted by Windows to allow it.

Exit the wizard.

You've configured the container file that will hold your encrypted data. Now you'll mount the file. In the main window, choose the file you just created, select a drive letter, and click Mount. The file will be mounted and you'll have a new Windows drive letter.

Now, any files you add to the F drive are encrypted. If someone were to steal your machine, they'd have to know your Windows password and your test.vc password. If they pulled out the the hard drive and installed it on another computer, all they'd see is a file named test.vc amongst all the other files, and they couldn't open it without VeraCrypt and knowing the password.

The F drive is only available when you're logged in, and when you log in fresh you must start VeraCrypt and mount test.vc.