I don’t keep anything on my laptop and haven’t done for some time. Of course there is the very simple problem of losing a device or a hard disk, but now, with the advent of multiple virtual machines and physical devices, I find myself working on a large number of different machines that may or may not be on my physical laptop. That means I need a home for source code that is available from many machines and backed up somewhere safe.

Visual Studio certainly has taken steps toward supporting storage off-box with the advent of the online TFS offering www.visualstudio.com. That’s fine if you have a version of Visual Studio that supports TFS and if you’re happy to check in and check out your code. But wouldn’t it be nice if you just hit save and let the source code be synced to the cloud in the background?

The two new products SkyDrive Pro (for SharePoint to local machine sync) and the SkyDrive application (for SkyDrive to machine sync) work in the background to keep your machine and the master repository in sync whenever online but allows file access while offline. These two products make it simple to offload file storage elsewhere to a safe shared platform.

So that’s great for documents but what about source code? What we need is to create projects locally and have them synced to the cloud automatically.

First step install SkyDrive and sync it to your local machine and add a folder called “Source” (or whatever)

Now we need to change the default behaviour of Visual Studio to create projects into that folder by default.

Now it’s simple enough to create a new project and have it synced directly to SkyDrive, however you’ll notice the little SkyDrive sync icon changes every time you build.

What TFS does really well (and SkyDrive doesn’t) is to carefully filter between source code and binary output files when syncing the source tree to the repository. Visual Studio is remarkably stubborn about needing to have output files under the source tree which causes excessive syncing traffic. But it can be changed with some effort.

Create a new User Environment Variable (in Win 8 Start Menu just type env and click Settings in side charm). The variable is called OBJDIR and will point to somewhere on your machine to hold all the binary output and debug files.

Now restart Visual Studio and open the new project you created, then right click on the project and “Unload Project” from the Visual Studio solution

Then edit the project file in the XML editor

Under the top default <PropertyGroup>
element put the following elements

<PropertyGroup>
<OutputPath>$(OBJDIR)\$(SolutionName)\bin\$(Configuration)\</OutputPath>
<BaseIntermediateOutputPath>$(OBJDIR)\$(SolutionName)\obj\$(Configuration)\</BaseIntermediateOutputPath>
<IntermediateOutputPath>$(BaseIntermediateOutputPath)\</IntermediateOutputPath>

One more step is to ensure that you take out any other <OutputPath> directives from the project file as we have defined our own one at the top level. For example you should remove this <OutputPath>bin\Debug\</OutputPath> and this <OutputPath>bin\Release\</OutputPath>

Now when you build in Visual Studio the source files remain in the folder synced by SkyDrive and an “obj” folder will appear under your OBJDIR\SolutionName folder with the raw binary assemblies on the local machine and, most importantly, the little sync icon no longer comes up on every build (but gladly it does when you save the source code).

I still use TFS for saving away source code and managing multiple concurrent developers but now I’ve changed the default behaviour of Visual Studio so all my neat little tools and blog post source code are safely tucked away in my SkyDrive and available on any machine (virtual or physical or cloud) that I choose to work on.

Category:
Application Development and Integration
Tags:
, , , , , , , ,

Join the conversation! 5 Comments

  1. Great post. I haven’t done this yet, but when I get time I will try it.

    Reply
  2. Thanks, it works. Is there a way to make this bin path as default for new projects?

    Reply
  3. Instead of $(SolutionName) use $(MSBuildProjectName). Works better if solution have more than one project.

    Reply
  4. I’ve been using OneDrive for a while, but I took a slightly different approach. Using the command “mklink /D /J C:\Source C:\Users\Adam\OneDrive\Source”. So I work out of the path C:\Source, but the physical files are stored to OneDrive\Source.

    SymLinks work like low-level filesystem shortcuts. Most apps have no idea that they’re not physical storage locations on the filesystem (unless for some reason they’re specifically checking that, which I have yet to encounter).

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: