How to efficiently 'share' assemblies between multiple dev projects

[Jack Addington]

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

[Chris Dunaway]

Are you referencing the .dll directly? I think you should use a single
solution and reference the projects rather than the .dll's directly.

Here is a link to the MS Pattern and Practices article about Team
Development. I know you said you are coding alone, but the article
describes in detail about Project and file references. It might help
you.

http://tinyurl.com/jg5a

[Jack Addington]

Thanks for you quick reply - the article was very helpful - I was on the
right approach earlier and going to a file reference is bad (I think). I
will try restructuring everything again but I'm still worried about the
versioning errors I was getting.
"Chris Dunaway" <du******@gmail.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...

Are you referencing the .dll directly? I think you should use a single
solution and reference the projects rather than the .dll's directly.

Here is a link to the MS Pattern and Practices article about Team
Development. I know you said you are coding alone, but the article
describes in detail about Project and file references. It might help
you.

http://tinyurl.com/jg5a

[Chris Dunaway]

Sometimes you have no choice but to use file references, namely when
you are using third party libraries.

As to the versioning errors, when you have all the projects in the
solution, they will be built in the correct order and the errors should
go away.

[Chris Dunaway]

One more thing, in your Assembly.vb file you should not use the
automatic versioning. In other words don't use 1.0.* for your version
number. You should explicitly set all version numbers yourself.

According to Jeffrey Richter's book, "Applied Microsoft .Net Framework
Programming", using the auto versioning can cause just the versioning
errors you were getting.

[Jack Addington]

I think that is my exact problem. - thanks so much

"Chris Dunaway" <du******@gmail.com> wrote in message
news:11**********************@g49g2000cwa.googlegr oups.com...

One more thing, in your Assembly.vb file you should not use the
automatic versioning. In other words don't use 1.0.* for your version
number. You should explicitly set all version numbers yourself.

According to Jeffrey Richter's book, "Applied Microsoft .Net Framework
Programming", using the auto versioning can cause just the versioning
errors you were getting.

[Jack Addington]

Chris,

I am still having issues. I got rid of all the versioning issues but my 2nd
solution isn't using the updates I create in the shared assemblies.

This is my setup

Original Solution /w projects/assemblies:

App (Starting Project)
AppFrameWork
SharedAssemblyA
SharedAssemblyB
SharedAssemblyC
SharedAssemblyD

I had orignally tried creating a new Solution B and had run into the issues
mentioned in this thread so I tried a SaveAs for SolA to SolB and replaced
the App specific assemblies

AppB (Starting Proj)
AppFrameWorkB
SharedAssemblyA
SharedAssemblyB
SharedAssemblyC
SharedAssemblyD

I created all the references I need in AppB and the application runs. But
when I make changes to SharedAssembly B they don't get picked up when I run
the app nor do debug breakpoints. I can do a rebuild and see it update/fix
compiler errors. I tried setting the project dependencies on the AppB to
include all the assemblies but it still doesn't seem to do much.

If I go back to the original solutionA and compile then I pickup the
changes.

Any thoughts?

"Chris Dunaway" <du******@gmail.com> wrote in message
news:11**********************@g49g2000cwa.googlegr oups.com...

One more thing, in your Assembly.vb file you should not use the
automatic versioning. In other words don't use 1.0.* for your version
number. You should explicitly set all version numbers yourself.

According to Jeffrey Richter's book, "Applied Microsoft .Net Framework
Programming", using the auto versioning can cause just the versioning
errors you were getting.