reuse business methods as DLL in another project??

[ashrafnairoukh]

Hi all,

I Have Core Project [3 tier Presentation-business-Data] include Core
functionality, I want to reuse the Core Business functions in another
project because the 2 projects using the same database.

Lets Say this is the Case:

CoreProject: Presentation->business->Data->DB

NewProject: Presentation->business->Data->DB

and


Presentation->CoreProject.business->CoreProject.Data->DB

My Question Is: How and where to add the Core business DLL in the new
project? And in case I want to add the Core business DLL reference to
the New Project Presentation there is conflict because of 2 businesses
DLL (the same name).

Thanks

Ashraf

 

[Scott M.]

I'm not sure I understand your question. I understand what you want to do,
but all you need to do is write the re-usable code into its own project and
compile it. Then, register that assembly into the GAC (and you don't
actually *have* to do this but there are benefits).

Once this is done, simply reference the assembly in whatever project(s) you
need to use it in. The assembly name doesn't matter, only the namespaces in
the assemblies. So, you could have 2 .dll's with exactly the same name
referenced in one project and not have a problem because you'd be accessing
classes in different namespaces.

 

[Tigger]

Hi,

I've tried several ways to resolve this sort of problem. My current
preferred method is to have multiple solutions which include all the
projects required to compile.

e.g. in your case you would have 3 projects and 2 solutions

Core Solution
Core Presentation Project
Core Business Project

New Solution
New Presentation Project
Core Business Project

So both solutions reference their own project and a common project.

This way you can use project references in your projects to reference
the dlls of the base layer projects.

In the past I have tried to seperate out the layers into their own
solutions. This requires the publishing of the dlls each solution
creates so that other layers can access them. I found this created a
massive amount of overhead and room for error which was not needed for
a company our size. For larger companies where the layers are developed
by different departments this would be the way to go.

I also tried having one solution with all projects. This gets a bit
cumbersome as the software expands. In our case the global solution
consists of about 30 projects and I dont wish to compile them all
everytime I change code. I use the solution for the release/publish
process to ensure all projects are still working before publishing.

Tony