Hatteras won’t Share? NO FAIR!

This has come up on my blog before, but since it came up in the forums again, I thought I’d point people at the subject again and solicit more feedback.


Here’s the forum poster’s question:

In VSTS, is there an equivalent to Share available?  We have applications which are developed across multiple platforms (web, desktop, mobile) which many of the class files are just shared accross the different project types to allow code reuse.


We will have a seperate project for Full Framework and Compact Framework.  ClassA exists in both projects.  If either project makes changes, the other should see those changes.  In Visual Sourcesafe 6 we handled this by sharing ClassA.  I am still struggling to see how this can work in Team Systems.

The first sentence of my answer is: “There's no support for the VSS 'Share' feature in VSTS Source Control.” The details are in the forum post, of course.


What do you folks think about this decision? How does lack of the Share feature affect you?

  1. I can’t live without Share!

  2. I can make some changes to my code structure, and live without Share.

  3. I don’t need the Share feature; my projects don’t share code in a fashion that requires branching or sharing.

  4. I use branching already, so I don’t need share

  5. I don’t use Share because my developers would be constantly stepping on each other’s toes with shared changes

  6. Two or more of the above

  7. None of the above

Finally, to shamelessly borrow from Wil Wheaton, I’ll going to start signing posts (instead of title them) with a random line from a song that’s on my mind. Kudos (but no cash, fabulous prizes, or world renown) for spotting the song/artist without Google's help; they won't be very obscure for the most part anyway.


Today is the greatest day I’ve ever known.


Comments (9)
  1. Martin says:

    First thought was "No sharing? But we use it constantly in VSS". Then, a few days ago I was trying to figure out why a project does not build. Guess what? A shared class has changed. And it was not the first time that I had to spend time on such an issue. I could have pinned all shared files, but pinning files with VSS is not very user-friendly and we usually aviod it. On the other hand: How can I figure out if a file has been changed in another branch? When it’s shared, I can simply look at the file’s history. How can I see in VSTS if a file has been changed in any other branch?

  2. geoff.appleby says:

    Umm…1. Sort of. I’m yet to learn all abotu branching and see if it helps us get around the problem. To speak in clearcase speak, we often link components from one vob into another – but in all cases we keep it marked readonly in all vobs but the original. You can only change it in one spot, but access it to compile it into your code in several.

    Smahing pumpkins, today.

  3. CRathjen says:

    In TFS you can use either locking or permissions to make the original branch writable and the rest read-only – this also greatly simplifies merging to the children branches, of course 🙂 But you’d still have to merge from the originals to the others as appropriate (on some sort of schedule, or maybe create a utility to register for changes and merge them automatically).

  4. James says:

    I am fine with VSTS not sharing. I see it like multiple inheritance. Sure it has it’s uses, but I’ve seen more problems as a result of sharing. For example, I had to address runtime complications converting and comparing enumerations that are physically the same, but exist in two different namespaces because the projects they were shared in had default namespaces set.

  5. P Cannon says:

    I am very disappointed that Microsoft has removed the share feature of VSTS. I work in a large corporation with a team of fifteen developers. We have been using Microsoft development tools since before I was hired six years ago. We are experienced in agile development techniques and exercise our code with the freeware tools N-Unit and FX Cop.

    Currently, we are evaluating beta copies of VS 2005 & VSTS. I am excited to see Microsoft’s direction with their development tools, but I do not think that all the new features are worth the price they are asking for the system.

    I am very happy with the changes made to VS 2005 and adopted it as my main development platform. VS 2005 with N-Unit, FX Cop, the file based VSS, and some intuitive extensibility programming could easily complete with VSTS. Add Project Server, Sharepoint Services, and Mercury Test Director, which we already own, and you have a more cost effective solution for out enterprise development.

    We are using the share feature in VSS. It is integral to our ability to publish our IT services across multiple platforms and multiple version of Visual Studio. With the removal of this feature I am currently lobbying for an alternate solution to VSTS. I cannot believe only a few operations are using VSS in this manner. We have faith that Microsoft will put out a competent, quality product. Unfortunately, this first version might not hit the mark, or at least not fit our development needs.

  6. OJohnson says:

    Option 1, unless you can direct me to information that will allow me to solve this problem…

    A class can now be developed that will run on virtually any device. The problem is that the project containing the class file contains references to assemblies for specific project types, (web, smart client, etc.). I want to use this same class file in projects in multiple solutions. If a change is made to the class file I want it to propegate to all projects without requiring any manual intervention. How can I do this without share?

  7. CRathjen says:

    I see the sharing feature described here as being "removed" from VSTS. To clarify, it was never a part of Vesion Control in VSTS.

    I’d love to hear more specifics on how people using sharing, because I believe there are better approaches for the common scenarios.

    I can see where, if your shared code is only part of an assembly, then it’s awkward to share that class file across multiple projects. Packing the shared code into its own self-contained assembly isn’t always feasible.

    I’d want to hear more about the "publish IT services" scenario before I comment on that.

  8. CRathjen says:

    Martin, sorry I missed your comment earlier (silly moderation feature).

    You can use the branches and/or merges command to see how a file is related to other branches, and then use the history command to see when the file has changed. Merge /preview between two branches would also inform you if there are changes to merge or tell you that there are none.

    The branches/history approach can be done via the UI. You could ‘sort of’ preview merge changes with the merge wizard by electing to do a selective merge, then seeing what changesets are available (or none), and cancelling the merge.

Comments are closed.

Skip to main content