Linked Files in Visual Studio Solutions

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.

Figure 1: Linked files in a Visual Studio solution

See full-sized image.

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:

• Using custom dictionaries in Visual Studio
• Shared assembly info in Visual Studio projects
• Best practices for .NET assembly versioning

Stay tuned!

Comments

• Anonymous
  April 02, 2009
  In my previous post , I introduced the concept of linking files in Visual Studio solutions. A good use

• Anonymous
  April 03, 2009
  Yesterday I introduced the concept of linked files in Visual Studio solutions with a follow-up on my

• Anonymous
  April 03, 2009
  Whenever a new .NET assembly project is created in Visual Studio, a file named AssemblyInfo is created

• Anonymous
  April 05, 2009
  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.

• Anonymous
  May 25, 2009
  Normal 0 false false false EN-US X-NONE X-NONE MicrosoftInternetExplorer4 /* Style Definitions */ table.MsoNormalTable