Can TFS Projects Reference Each Other?

问题:

I've recently begun working in an enterprise software environment with hundreds of different applications all confined to their own "silos." One of my tasks is to try to standardize things a bit, and the first attempt will be a standard event logging. Currently, the company's "standard" is "everyone should use Enterprise Library for logging." What this translates to in reality is that different developers working on different projects implement different logging in different ways, and just most of the time use that library.

To that end, I'm looking to abstract out the actual logging tool behind a "company standard" internally-developed interface. The idea is to move the focus of what a "standard" is away from the implementing tool and towards how it's used. Applications would then use the internal library and not concern themselves with the tool behind the scenes (save for maybe an app.config section, though I already know how to abstract that out with log4net).

However, a problem I'm facing right now is that all of these applications are in separate TFS projects. If I create a project that contains a common library for logging, is there any way for the other projects to reference it? I don't want to distribute the library among each project because they'll get out of sync quickly.

If TFS can't do this, does anybody have any other suggestions?

回答1:

TFS does not have the concept of "shared" folders (e.g. like we had with Visual SourceSafe). Workspaces give you some flexibility but that breaks down as soon as you attempt to map the same "shared" folder to more than one project. There are only a couple of options that come to mind that may address your specific situation:

1. Branch the Logging project into each team project that needs it. When you make changes to the Logging project, you'll need to either A) merge the Logging project changes to each project that it has been branched to ("push") or B) request that each project team making use of the Logging changes perform a merge to get the latest changes ("pull").

2. As part of the automated build processes for the Logging project, publish the binaries to a well-known location. Have each project that requires the Logging binaries setup a pre-build event that copies the latest version of the Logging binaries into their solution - or - rather than a pre-build event, you could also have the automated build process get the current Logging binaries and add it to the solution (performing check-outs/ins as needed).

There may be other solutions (there usually are) but that's all that's coming to mind off hand.

Hope this helps.

回答2:

Jeff's suggestion is the closest to what we would recommend. Consider internal APIs a seperate team project which serve other projects as clients. Those project feed the backlog and the release cycles. You can have CI, Beta, and Release builds as you see fit. Consuming/consumer projects then do is use their selected build as they can appropriately accomodate in their own release cycle. Because your TFS builds will push to a drop location made available, people pull rather than you pushing new releases. Pull is selecting and those assemblies should be checked-in and version controlled within the consuming project. This is no different than you would do with a true 3rd party assembly, in fact you should consider these in the same light.

When consuming applications have the need or bandwidth to upgrade to your newer versions of the internal assemblies, they pull.

回答3:

What we have had success doing is creating a separate TFS project with a solution which contains projects for libraries like logging. When we build this solution we deploy the assemblies onto a shared drive on a server. When we need to use one of these libraries we simply add a reference to the assembly by browsing to its location on the server. If you need to make a change to one of these libraries you can do so at anytime. The next time one of the projects which makes use of the assembly is built it will be updated with the new version.

回答4:

In TFS 2018:

If your solution contains projects (.csproj) that are under another TFS 2018 project repository, you can still reference these DLLs by following these 2 steps:

1. The reference includes must be relative to the same root. Your workspace source mappings must mimic the same structure in source control. ie. (in the .csproj file using the project reference)

    <ProjectReference Include="..\..\..\OtherTFSProject\src\ProjectDLL\ProjectDLL.csproj">
      <Project>{e8ed9a74-a9e9-47de-ab08-0b554a950606}</Project>
      <Name>ProjectDLL</Name>
    </ProjectReference>

2. In TFS2018, when you create a build, you must add a workspace mapping in the "Get Sources" phase of the build to the other TFS project repository. I recommend you add mappings at the lowest folders as the build will compile all projects under the directory you choose. In the example above you would choose

$\OtherTFSProject\src\ProjectDLL

I haven't found online documentation for this issue. I hope this helps!

回答5:

Just deploy all the core libraries to GAC, that ways application will get latest from GAC whenever you update. You can easily push your GAC to all "servers/workstations" using a command. Just remember to keep the signature of all Public method in your DLLs constant otherwise developers will get error when you change the library (if they are referencing that method)