Home/ Questions/Q 970159
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-16T02:45:41+00:00

I’ve recently begun working in an enterprise software environment with hundreds of different applications

  • 0

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?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0