Technology Toolbox

Your technology Sherpa for the Microsoft platform

Jeremy Jameson - Founder and Principal



Linked Files in Visual Studio Solutions

This post originally appeared on my MSDN blog:

Since I no longer work for Microsoft, I have copied it here in case that blog ever goes away.

A couple of years ago, I wrote a post introducing my system for structuring Visual Studio solutions. However, I apparently forgot to post a follow-up providing additional details, such as configuring assembly versioning and what I like to call "shared assembly information."

Before I can cover these details, I need to first ensure that you are familiar with the concept of linking files in Visual Studio solutions, why this is a powerful feature, and when to use it.

If you ever used Visual SourceSafe (VSS), you likely used its feature for sharing files across multiple projects. For example, you could check-in a file at the root of your solution, and then drag-and-drop it into other projects (i.e. "subfolders") in your solution. Thus, whenever a change was made to the file (regardless of which particular VSS project the change was made in), the next time you "got latest" the change would be reflected in all locations. This was a common way of, for example, having all of your .NET assemblies in the same Visual Studio solution specify the same assembly version.

Note that Team Foundation Server (TFS) does not provide an equivalent "share file" feature. Fortunately, however, you no longer need such a feature.

Back in the days of the original Visual Studio .NET and the following version, Visual Studio .NET 2003, whenever you added an existing file to a project, it copied the file into the corresponding location in the project.

However, in Visual Studio 2005, the Add Existing Item feature provided the ability to choose to either Add the item or Add As Link (via the little down arrow on the button in the dialog box).

In other words, once you upgraded to Visual Studio 2005, it was no longer necessary to rely on any "sharing" features of your source control system in order to have multiple projects always reference the latest version of a file.

Note that when you Add an item in Visual Studio 2005 or Visual Studio 2008, the behavior is the same as earlier versions (meaning the file is copied into the corresponding location within the project). When you choose to Add As Link, however, you simply reference the file in-place. [Don't worry, relative paths ensure that everyone on your team is free to choose whatever root folder they wish for their individual workspaces.]

To illustrate this concept, I quickly built out a "demo" solution, as shown below.

Linked files in a Visual Studio solution
Figure 1: Linked files in a Visual Studio solution

The corresponding folder structure on disk resembles the following:

  • Fabrikam
    • Demo
      • Dev (branch)
        • Lab1 (branch)
          • AssemblyVersionInfo.cs
          • CustomDictionary.xml
          • Fabrikam.Demo.sln
          • Fabrikam.Demo.snk
          • SharedAssemblyInfo.cs
          • AdminConsole
            • AdminConsole.csproj
            • Program.cs
            • Properties
              • AssemblyInfo.cs
          • CoreServices
            • CoreServices.csproj
            • Logging
              • Logger.cs
            • Properties
              • AssemblyInfo.cs

Note that AssemblyVersionInfo.cs, CustomDictionary.xml, Fabrikam.Demo.snk, and SharedAssemblyInfo.cs reside in the same folder as the Visual Studio solution file and are subsequently "linked into" the two Visual C# projects. Thus whenever a change is made to one of these files, the next build of each project will reflect that change.

With this foundation in place, I'll explain some other recommended best practices over a series of follow-up posts, including:

Stay tuned!


  1. # re: Linked Files in Visual Studio Solutions

    April 5, 2009 3:53 PM

    I encountered a problem with this last week. I had two source files shared into one of my projects from another team's project. They decided they no longer needed those files and deleted them; after I did a get I no longer had copies of the files on disk and the solution explorer showed them as broken links.

    In future I will be sure to place the actual files in a Shared Source folder and link them into both project folders, rather than linking from one project folder to another.

  2. # CA1704 Code Analysis Warning and Using Custom Dictionaries in Visual Studio

    April 1, 2009 9:17 PM
  3. # Shared Assembly Info in Visual Studio Projects

    April 2, 2009 7:19 PM
  4. # Best Practices for .NET Assembly Versioning

    April 2, 2009 7:59 PM
  5. # A custom preprocessor for sharing XAML between Silverlight and WPF

    May 25, 2009 2:33 AM

Add Comment

Optional, but recommended (especially if you have a Gravatar). Note that your email address will not appear with your comment.
If URL is specified, it will be included as a link with your name.

To prevent spam from being submitted, please select the following fruit: Strawberry

Please add 6 and 5 and type the answer here: