Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. Design and Architecture
  4. Library Architecture for Multiple Applications and Multiple Developers [modified]

Library Architecture for Multiple Applications and Multiple Developers [modified]

Scheduled Pinned Locked Moved Design and Architecture
csharpdesignworkspacedelphidotnet
2 Posts 2 Posters 3 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • B Offline
    B Offline
    brmorris
    wrote on last edited by
    #1

    Hi, I've been surfing around for articles on best approaches to library architecture for multiple applications used by multiple developers and so far have come up with very little so I thought I may as well just ask some questions. Our company has been developing solutions for a number of years using Borlands Delphi and a FAT Client-style architecture where most of the code gets compiled and linked into one executable per application (There were historical reasons behind this style that I won't go into). So structuring our code library has been fairly easy, using a Visual Source Safe as our primary source control, we simply share the code into the application folder, then we reference all the code as relative path. However, since starting development in C# (and the dotNet Framework) its obvious that this approach was not going to cut it. So then development started and progressed down the path of separate, specific assemblies for each specific algorithm/datastore/UI etc. Now I/We have the problem of structuring these assemblies/libraries so that multiple applications reference them both in development and deployment. Deployment isn't much of a worry as we are placing all the assemblies in a folder on the target platform but our major problem is referencing these assemblies during development. Ie in Solution/Project files, VSS and also in our Build System (FinalBuilder) I'll give you an example. LibraryA and LibraryB are two assemblies that contain algorithms for two separate/different situations. They have there own Project and Solution files, their own specific tests, are in their own separate folders with our source control and are built separately within our Build System. Now Application1 needs to use both LibraryA and LibraryB. Application1 is laid out in the same way that both libraries are (VSS, BuildSystem etc) but there needs to be a reference to both assemblies within the Project file. And it needs to be available at Design time (within VS) and during automated Build time (FinalBuilder). I know about the GAC and as a company we have decided against using it. Our preliminary idea is to use a Global assembly area of our own, that each developer has (using an environment variable) and it contains all the assemblies within our library, so all references are directed at this location. So our Build System just needs to ensure that these assemblies are available when building each application. Other ideas that have been discussed was to setup our Build System to build all dependent proje

    C 1 Reply Last reply
    0
    • B brmorris

      Hi, I've been surfing around for articles on best approaches to library architecture for multiple applications used by multiple developers and so far have come up with very little so I thought I may as well just ask some questions. Our company has been developing solutions for a number of years using Borlands Delphi and a FAT Client-style architecture where most of the code gets compiled and linked into one executable per application (There were historical reasons behind this style that I won't go into). So structuring our code library has been fairly easy, using a Visual Source Safe as our primary source control, we simply share the code into the application folder, then we reference all the code as relative path. However, since starting development in C# (and the dotNet Framework) its obvious that this approach was not going to cut it. So then development started and progressed down the path of separate, specific assemblies for each specific algorithm/datastore/UI etc. Now I/We have the problem of structuring these assemblies/libraries so that multiple applications reference them both in development and deployment. Deployment isn't much of a worry as we are placing all the assemblies in a folder on the target platform but our major problem is referencing these assemblies during development. Ie in Solution/Project files, VSS and also in our Build System (FinalBuilder) I'll give you an example. LibraryA and LibraryB are two assemblies that contain algorithms for two separate/different situations. They have there own Project and Solution files, their own specific tests, are in their own separate folders with our source control and are built separately within our Build System. Now Application1 needs to use both LibraryA and LibraryB. Application1 is laid out in the same way that both libraries are (VSS, BuildSystem etc) but there needs to be a reference to both assemblies within the Project file. And it needs to be available at Design time (within VS) and during automated Build time (FinalBuilder). I know about the GAC and as a company we have decided against using it. Our preliminary idea is to use a Global assembly area of our own, that each developer has (using an environment variable) and it contains all the assemblies within our library, so all references are directed at this location. So our Build System just needs to ensure that these assemblies are available when building each application. Other ideas that have been discussed was to setup our Build System to build all dependent proje

      C Offline
      C Offline
      Chris Kaiser
      wrote on last edited by
      #2

      Why don't each of you just assemble your own custom solutions of the pieces you need and allow the build machine to do the same?

      This statement was never false.

      1 Reply Last reply
      0
      Reply
      • Reply as topic
      Log in to reply
      • Oldest to Newest
      • Newest to Oldest
      • Most Votes


      • Login

      • Don't have an account? Register

      • Login or register to search.
      • First post
        Last post
      0
      • Categories
      • Recent
      • Tags
      • Popular
      • World
      • Users
      • Groups