VB.Net >> How to split a project in many DLL projects

by ABC - Sastien Beaugrand » Mon, 13 Oct 2003 22:08:01 GMT

Hi,

I am working on a project that is getting too big and we would like to split
it in many DLLs Projects.
In that way some dlls should be written in C# and some in VB.NET.

The problem we got to do that is that if we cut a part of code from the main
project (Project1) and if we put it in a new DLL project (Project2) it is
not possible to compile Project2 because it need to declare some classes
that are defined in Project1.

To resolve that problem, in project 2 we add a reference to Project1.

But now, because some functions called by Project1 have been moved to
project2, we need to add a reference to project2 in the main project
(project1).

And we got circular references and it is impossible to build the solution
!!!

So what is the correct way to organize an oo project in many DLLs ?

Thanks
Sebastien



VB.Net >> How to split a project in many DLL projects

by Jay B. Harlow [MVP - Outlook] » Mon, 13 Oct 2003 22:32:32 GMT


Sebastien,
The normal way to avoid circular references between assemblies that require
a circular reference is the Separated Interface Pattern.

http://www.martinfowler.com/eaaCatalog/separatedInterface.html

However this is not always as easy as it appears.

main
Normally what I do is move the code that both Project1 & Project2 depend on
into Project3.

Then Project1 references both Project2 & Project3, while Project2 references
only Project3.

Normally I call this Project3 MySolution.Framework. What I wind up with is
very little code in Project1 as most of it is in Project2 type assemblies
with all the common stuff in Project3 type assemblies.

If you do not start out organizing you classes into projects from the start,
it can be challenging as you are finding to get classes that have no
dependencies into their own assemblies, I know I've been there.

Hope this helps
Jay

"ABC - Sastien Beaugrand" < XXXX@XXXXX.COM > wrote in

split
main

VB.Net >> How to split a project in many DLL projects

by ABC - Sastien Beaugrand » Mon, 13 Oct 2003 23:26:41 GMT

Jay,
Thank you for your answer that will really help me.

By

"Jay B. Harlow [MVP - Outlook]" < XXXX@XXXXX.COM > a rit dans le

solution
require
is
on
references
start,

is
solution

Similar Threads

1. HOW TO: create custom project wizard that generates both a DLL assembly project + a setup project - VS.Net IDE

2. VB6 Project Upgrade - Adds Dll To Projects

Hi,
I have a project that I upgraded to VB.NET, after running the upgrade
wizard I noticed that the Upgrade Wizard added a DLL to the list of my
project items (Not In references, but along with all the other forms &
classes..)
The name of  the file is AxMyUserControlArray.dll -- MyUserControl stands
for the name of one of our in house controls (VB6 control). I assume the
Array is because I might have an control array of that control somewhere
in my project....

I question being when was the DLL added to the project as an item & not a
reference? can I exclude it from the project

thanks in advance


3. Project 2007 srchui.dll and jscript.dll error loading Project Guid

4. Problems debugging multiple projects in IDE when projects are GAC DLLs

I can hardly believe I'm the first one to report this, but having gone
through the newsgroup, it appears that way.

I would like to open a solution in the VS.NET IDE that consists of
multiple DLLs and a test application (an .EXE). The .EXE is my startup
application. All the DLLs are shared components. This means that they
contain a key and are stored in the GAC.

When I go to run the test application in the IDE, it will not execute
because it complains that it cannot find the DLL or one of its
dependencies. Here are several pieces of information you need to be
aware of before going any further...

* I use version 1.1 of the .NET Framework (and VS.NET 2003)

* Many of the DLLs reference the other DLLs in the project and vice
versa. In essence, you have circular references. A class in DLL 'A'
uses a class in DLL 'B' and vice versa. This works, since it is
expected to.

* All DLLs are built in debug mode. No 'Release' versions even exist.

* No reference in any DLL has its "Copy Local" set to true. In other
words, a referenced DLL is never copied.

* All DLLs appear in the "Add References" dialog box under the ".NET"
tab. I set up a folder for each DLL in the registry to make this
happen. The folders appear under
HKEY_LOCAL_MACHINE\Software\Microsoft\.NETFramework\AssemblyFolders

* The references that I use in the projects loaded in the IDE come
from the .NET tab in the "Add References" dialog box.

* I have verified that the GAC does indeed contain all DLLs and only
single versions of those DLLs.

* Every DLL is built to the \bin\Debug directory and each contains the
.pdb file (used by the IDE for debugging).

With everything setup this way, you would think that logically there
couldn't be a problem. When the IDE runs the main application, it will
notice that a DLL is in the GAC and that the Copy Local is set to
false, so the one in the GAC will be used.

Microsoft has written an article that states that you cannot reference
a DLL in the GAC, which is utterly wrong. I can reference it. They
state that you should copy the DLLs to a common directory and
reference them there. I did do this as well but it didn't help. I even
copied all the .pdb files to the common directory and that didn't help
either. I even set the reference paths in all DLLs to contain the
paths to all other DLLs. It didn't matter whether this path was the
common directory or the bin\Debug directory. It never helped.

What I ultimately discovered is that the only way to make it work is
to set the Copy Local to true. This of course had very serious side
effects. Now the DLLs poliferate all over the place. The same DLL will
appear in multiple directories. While working in the IDE and you
update one DLL, that update will NOT appear automatically in the
directories of other DLLs referencing it. You need to manually update
EVERY DLL use this newer version otherwise the debugging will not
execute. You can press the F5 button on all references in the IDE to
update the version and the newer DLL will get copied to those
directories but you still need to rebuild those other DLLs. Worse yet,
some DLLs may not be loaded in the IDE but are still referenced by
DLLs loaded in the IDE. You will need to update those as well.

This becomes a nightmare. The whole purpose of using a shared DLL is
to avoid duplicates. One version should exist and one only. If
Microsoft is making me copy them to some common directory, I can live
with that, if it would work while debugging in the IDE.

What really ticks me off is that having set the paths to all
references, you would expect the IDE to find the other DLLs and their
dependencies. What in the world am I setting that for if it doesn't
use it? There is no reason, having done all I did, that the IDE should
not find every one of the DLLs and the debug files.

Has anyone got a clue what can be done?

Thanks,
Johann Blake

www.closerworlds.com
Mobile Solutions using GPS

5. VB6 Project Upgrade - Adds Dll To Projects - Visual Studio .Net/VS.net

6. Splitting up the project files

Hi,
I have multiple people that working on one VB .net project 
using separate forms and reports. I was wondering if it 
was possible to put some forms and reports in seperate 
folders. I tryed doing this and it would copy the files to 
the root of the project when I would "add an existing 
item" it to the project through the .net Studio. Is there 
a way around this?

Sebastian

7. NEED HELP on Split tasks on VBA Project

8. closing splits in project with vba/macros