CODEWITHSUNDEEP
.netvisual-studioproject-managementrelease
Christophe Lambrechts
Christophe Lambrechts

Reputation: 538

Different projects using own .NET based framework

I'm looking for information about proper release management when working with your own developed code libraries. We are working with Visual Studio 2010, develop in .NET and use TFS. Let me sketch the situation.

We are working with a team on different projects that result all in there own program/product. So we started thinking about reusing code and putting them in a kind of framework or library. For this we created a separate solution with different projects and dependencies between them. We call this the 'platform'.

The solution of the 'platform' has for example the following projects:

In reality we have already 20 projects and more dependencies between the projects, but this should make things clear.

Let's say we now have two projects A and B. They look as follow:

Project A

Project B

How do we manage this kind of structures? I for see several problems and have no real answer to them.

I also tried to search the internet and had some internal discussions, but no real answer where provided. What I find on Stack Overflow is about definition differences between libraries and frameworks and on MSDN you can read a lot about DLL's and the GAC.

Any best practices, tools, experiences, ... are welcome.

Upvotes: 2

Views: 244

Answers (2)

IvanL
IvanL

Reputation: 2485

I would create NuGet packages for the "platform" and seperate them out in logical blocks with a clear dependency structure such that when you need for example "Utils" you can install this package and the "Logging" package installs right along. It also covers version management.

See http://docs.nuget.org/docs/creating-packages/creating-and-publishing-a-package

Then since it's an internal framework you want to take a look at setting up your own NuGet feed: http://docs.nuget.org/docs/creating-packages/hosting-your-own-nuget-feeds

It might be an initial commitment to set this up but on the long run you'll most certainly reap the benefits of this approach.

Upvotes: 1

McGarnagle
McGarnagle

Reputation: 102753

I would use a hierarchical directory structure that contains all your code, and release versions of the library DLLs; use relative paths to reference other DLLs or projects. This should give you the flexibility to maintain and update the dependencies as needed.

Do we include DLL's or code in the projects A and B of the platform?

Check everything in to TFS. Each project can decide whether to resolve its dependencies by reference to the DLL or the project file.

Do we check-in DLL's and make copies to the different projects? Can branching be beneficial?

Check in DLLs, but keep them in a Shared Resources folder at a low level in the source control structure:

/Shared
    /DLLs
        /Platform
            /Logging
                /V1.0.0.0
                    /Debug
                    /Release
                /V2.0.0.0
            /ChartControl
/Source
    /Platform
        /Logging
        /ChartControl
    /Projects
        /ProjectA
        /ProjectB

What about versions? Let's say Project A uses Logging V.1.0.0.0 and that works fine with the ChartControl that also uses Logging V.1.0.0.0. On a certain day we decide to use a new version of ChartControl, that also uses a new version of Logging V.2.0.0.0. How do I made sure Project A isn't forced to also start using Logging V.2.0.0.0?

If you need to have different projects reference different versions of the same library, then check in each release version. So ChartControl can reference /Shared/DLLs/Logging/V1.0.0.0, while Project A can reference V2.0.0.0. (I'd tend to caution against this though, as it could get messy; what if the new logging version uses a different file/database format?)

We could decide to release the platform as one part, everything or nothing. But how do we manage the builds of all these DLL's. Updating version numbers in all projects manually is a lot of work and extracting them from all different bin folders even more.

To automate build tasks, definitely look into continuous-integration servers (Cruise Control, QuickBuild, Jenkins, etc).

How do we integrate the 'platform' in our projects. Do we create a reference folder and place all DLL's in there, to reference them in the solution?

I think this is the correct approach. Referencing the DLLs enables you to adhere to a separate development/test/release process for the platform.

How do we keep track of dependencies? And if one release for the whole platform how do we toss out unneeded DLL's. Project B has for example no interest in the Utils, but indirectly has in Logging.

Each project owner has to keep track of its own dependencies; only the owner of Project B knows whether or not to reference Utils.

If we release the platform as one, then small changes will result in a complete new set of DLL's. For example a change in the Utils project will also result in new version for Logging, Localization, ... unless there were no changes.

This should be ok though, right? It's a question of policy; should each project be forced to integrate the newest release of the platform, or is it ok for them to work against an older version. I think you're suggesting the latter is true. The projects A, B, etc are the end product, so it's up to the owners of those projects to decide when to integrate the new DLLs.

Upvotes: 0

Related Questions