How to efficiently 'share' assemblies between multiple dev projects

I have recently spun off a new version of my application for a different
project and plan to do some more shortly. I have essentially split it into
three parts:

1) Common Company Framework (small/very stable) stored in drive/framework
2) Common Application Framework (large/stable) stored in drive/common
3) New Applications / Skins (small/unstable) stored in drive/project

Both my projects are still under some semblance of development so I wanted
to be able to essentially work on the framework and common objects as need
be. I'm the sole developer so I'm not worried about stomping on anybodies
toes. I know there will be re-work to each as I tweak the middle layer and
even the framework. As I see fit I want to add/remove from the common layer
to make sure it remains common and shared and doesn't have any 'application
specific' code in it.

I have gone ahead and setup my solution to contain the projects for all the
bits and pieces and then done references to them all. The problem occurs
when I rebuild solution 3 I sometimes come up with the following error.

"Error: The dependency 'eProgramMgr.DataAccess.Core, Version=1.0.1999.24143,
Culture=neutral' in project 'eProgramMgr.Modules.DataExtract' cannot be
copied to the run directory because it would conflict with dependency
'eProgramMgr.DataAccess.Core, Version=1.0.2004.16500, Culture=neutral'.
"

I'm wondering what is the most effective way to manage this through visual
studio? Should I have two copies open, one with the common and framework
and then a 2nd with only the new app but only using references and not
having the projects open? When do I set the reference's copy to local
property to false?

thx

jack


.

Relevant Pages

  • Re: Where to stor config file?
    ... tiers. ... They were based off a Common Base Business Framework that kept things common ...
    (microsoft.public.dotnet.general)
  • With Respect To an Investment Application
    ... All these modules are resting on a common ... framework, which does routing, workflow, logging etc. ... country to country. ... There are two main domain objects, User and Customer. ...
    (comp.lang.java.programmer)
  • Re: Where to stor config file?
    ... Now based on those tiers that you have seen, ... They were based off a Common Base Business Framework that kept things common and consistant. ... each application had its own Bussiness Entity library which was derived from the Common Base Business Framework. ...
    (microsoft.public.dotnet.general)
  • Re: Thread safety
    ... > Image is abstracting you from a bunch of method calls. ... > This generally isn't a huge problem across the framework, but is common ... > API's are created that are wrapping an unmanaged API. ...
    (microsoft.public.dotnet.general)
  • Re: Events vs. Delegates
    ... Daniel said that modifying add/remove behaviour isn't common but it is ... I'd also bet the framework component's itself are just about the only ... I must admit I haven't until now but I ... functionality perhaps you can just ask for this specific mode of operation ...
    (microsoft.public.dotnet.languages.csharp)
Loading