Upcoming Silverlight Firestarter Events

Jim O’Neil, Northeast Developer Evangelist for Microsoft, recently blogged about the upcoming Silverlight Firestarter series. It just so happens that I have been investigating using Silverlight 4 for an upcoming project re-write and there just happens to be an event date here in Rochester! What Luck!

You can get the details at Jim’s blog (http://blogs.msdn.com/b/jimoneil/archive/2010/12/23/firestarter-silverlight-for-windows-7.aspx) and follow the link there to register for yourself!

Hope to see you there!

Securing Corporate data on your laptop?

There has been a lot of talk lately about traveling internationally and potentially having your laptop confiscated by the U.S. Department of Homeland Security without cause or suspicion (example). They can also share the contents of your laptop with any other agency they like, without consent, and without a guarantee that they won’t further distribute or retain that data.

I’ll focus here on the business implications of this and not tread into the murkier issues of personal privacy. Suffice it to say, if you’ve done something illegal, you reap what you sow (but there should at least be reasonable suspicion).

Almost all business users have corporate documents on their machine (sales presentations, financials, etc.) unless your using a Content Management System (CMS) like SharePoint. What would happen if your upcoming Quarterly Earnings Report was on your confiscated machine and it got leaked early?

An easy way to protect this data is with encryption. Nobody can look at the data without your consent because you would need to provide the password to decrypt the file. Problem is, they can still see the files and force you to decrypt them.

Enter TrueCrypt. With TrueCrypt, you can create an encrypted volume that is nothing more than a file on your machine that you can name whatever you want (“foo.dat” for instance). After creating the encrypted volume, you can mount it as a regular drive letter on your machine and any program can access it as usual. All encryption/decryption happens on the fly in memory, so the data is constantly protected and leaves no traces in temporary files anywhere.

If you are really paranoid, you can create a hidden partition within the encrypted volume. That way, even if you are forced to reveal your password to the main volume (where you stored some innocent/random files) they won’t be able to tell that there was an inner encrypted volume that had the real data on it.

Of course, if you have a laptop, you need to dismount any TrueCrypt volumes before suspending/hibernating or else anyone who forces you to unlock your computer will immediately have access to the encrypted volumes.

Safe Travels!

Moving a TFS Source Controlled Project

Recently, I needed to reorganize the folder that contained all of the projects under source control for a solution. The solution was started several years ago and the number of projects has steadily grown over the years and started polluting the root solution directory. I wanted to clean this up and move projects into sub-folders for their functional area, such as plug-ins, data/business, and common.

This seemed like a fairly trivial thing to do, but I quickly ran into problems. Most of these problems seemed to be related to the fact that the projects were under source control with TFS. After some trial an error, I came up with the following process:

• Load the solution that contains the projects that are moving.
• Remove the Source Control Bindings for any of the projects that are going to move. This can be accomplished by going to File > Source Control > Change Source Control. In the resulting window, select the projects that are going to move and click the “Unbind” button in the toolbar. This will update the solution file.
• Close the solution.
• Open the Source Control Explorer and navigate to the parent folder that contains the project to be moved.
• Right-click on the project folder and select “Move…”. In the resulting window, browse to the new location for the project.
• Navigate into the new project file location and checkout the “{projectName}.vspscc” file. If you don’t do this now, you will receive an error when you re-add the source control bindings later.
• Close Visual Studio.
• Using Windows Explorer, navigate to the root folder for the solution and delete the “{solutionName}.suo” file. This prevents Visual Studio from getting confused the next time you open the solution.
• Edit the “{solutionName}.sln” file and update the path to the new project file location. Just search for the project name and the update the portion of the line the points to the “*.*proj” file.
• Open the solution. At this point, any projects that reference the moved projects will be updated (checked out) to reflect the new location.
• Update the Source Control Bindings to rebind the projects that were removed at the beginning of the process (the unbound projects will be located at the bottom of the list) by selecting the project and clicking the “bind” button in the toolbar.
• At this point, the project will be highlighted with a red underline stating that there is an issue. This is because we haven’t checked our changes in yet so the server path doesn’t exist. This will be corrected soon.
• Rebuild your solution to make sure there are no side-effects. When I did this, I had to update a few references to shared DLL’s in the moved projects because the reference path was no longer valid.
• Commit your changes.

That’s it. Simple, right? ;)

There are some things you could do differently. For instance, instead of editing the solution file by hand, you could remove the project from the solution, perform the TFS move, then re-add the project to the solution. However, you will need to re-add the reference to the moved project in any projects that depended on it originally. For me, it was faster to just edit the solution file manually because this doesn’t remove project references and Visual Studio will update the dependant projects for me.

Happy Coding!