I enabled BitLocker™ encryption on one of my drives today and couldn’t seem to find a way of checking the status of the process. It turned out to be relatively easy.

Start a PowerShell command window as Administrator and enter the following command:

manage-bde -status L:

This will output a small hunk of information about the encryption status of the drive you selected.

C:\Windows\system32> manage-bde -status l:
BitLocker Drive Encryption: Configuration Tool version 6.3.9600
Copyright (C) 2013 Microsoft Corporation. All rights reserved.

Volume L: [iSCSI]
[Data Volume]

    Size:                 926,87 GB
    BitLocker Version:    2.0
    Conversion Status:    Encryption in Progress
    Percentage Encrypted: 12,7%
    Encryption Method:    AES 128
    Protection Status:    Protection Off
    Lock Status:          Unlocked
    Identification Field: Unknown
    Automatic Unlock:     Disabled
    Key Protectors:
        Numerical Password


Just thought I'd put this here for my own future reference.

Update: *dough* I should have just checked my System Tray for this little fellow:


Clicking it gave me this neat little window:


Oh well. It’s always fun playing around with PowerShell I guess.


I'm really happy with Visual Studio 2012, and I do think it's by far the biggest leap forward for any iteration of VS. However, one new feature that bugs me is the "Auto Preview" where any file I click on in the Solution Explorer is opened for me in a special preview tab. 

This can be prevented if you hold down the ALT-key while clicking around the Solution Explorer, but IMO it should have been the other way round (i.e. don't preview unless you ALT-click).

Luckily this can be easily turned off by going to Tools -> Options -> Tabs and Windows and de-selecting the Solution Explorer under 'Preview Tab'



For us .NET/Visual Studio developers, NuGet is definitely the best thing since sliced bread (okay, maybe not, but it sure is great!). If you don’t yet know what NuGet is, it’s basically a package- and dependency manager for Visual Studio and .NET. And if you haven’t started using it yet, you’re doing something wrong Winking smile

One thing that kind of always bothered me about dependencies is that it’s always been best-practice to have all your libraries checked in to SCM along with your solution. Typically by dumping them in a \Libs folder and referencing them from there.

But source control systems are generally not very optimized for handling binary files, and the size of your repository (and thereby performance) is negatively impacted by dragging around all these DLL files.

With NuGet this is a thing of the past! Using the command line NuGet.exe tool, you can point it at a local config file that tells it which packages to download for you (those of you who already use NuGet are probably already familiar with the packages.config file that lives under each project in your solution).

The only executable file I now have as part of my solution is the latest-and-greatest NuGet.exe which I place in a Tools folder in the root of my solution.

So, to get all this set up in your project, your first step is to create a Tools folder at the solution level of your project. Next, go ahead and grab the latest NuGet.exe from here and put it in your newly created folder.

Now, to each of the projects in your solution, add the following pre-build command:

$(SolutionDir)Tools\Nuget.exe install $(ProjectDir)packages.config -o $(SolutionDir)Packages

Also make sure that the \Packages folder is ignored by yout SCM system of choice (mine is Mercurial) in the same way that you always ignore the Bin and Obj folders.

To test, just delete the \Packages folder from your solution directory and try to do a build. NuGet should now automatically download all the dependencies you have and place them back in \Packages. It takes a little while to run the first time, so don’t panic if nothing happens for a few seconds. If it works and the build succeeds, go ahead and commit everything to source control. You can now continue working without the burden of large unsightly DLLs littering your source repository.