DLL conflicts

  • Thread starter Thread starter pbd22
  • Start date Start date
P

pbd22

Hi.

If i have multiple DLLs that require the same library references to
run (for example, all using the MyCompany.Security) namespace and
referencing the same User class, how do I avoid a conflict when I am
finally adding the DLLs to my project?

I hope I explained myself well.

Thanks.
 
re:
!> If i have multiple DLLs that require the same library references to
!> run (for example, all using the MyCompany.Security) namespace and
!> referencing the same User class, how do I avoid a conflict when I am
!> finally adding the DLLs to my project?

Why do you think that would create a DLL conflict ?



Juan T. Llibre, asp.net MVP
Foros de VS 2010 y ASP.NET 4.0, en español
http://asp.net.do/foros/forums/
=================================
 
re:
!> If i have multiple DLLs that require the same library references to
!> run (for example, all using the MyCompany.Security) namespace and
!> referencing the same User class, how do I avoid a conflict when I am
!> finally adding the DLLs to my project?

Why do you think that would create a DLL conflict ?



Juan T. Llibre, asp.net MVP
Foros de VS 2010 y ASP.NET 4.0, en español
http://asp.net.do/foros/forums/
=================================
 
re:
!> If i have multiple DLLs that require the same library references to
!> run (for example, all using the MyCompany.Security) namespace and
!> referencing the same User class, how do I avoid a conflict when I am
!> finally adding the DLLs to my project?

Why do you think that would create a DLL conflict ?

Juan T. Llibre, asp.net MVP
Foros de VS 2010 y ASP.NET 4.0, en españolhttp://asp.net.do/foros/forums/
=================================
Click to expand...

Well, maybe i have the wording wrong. But, when I compile a library
"into"
another library and then call the complied library from a class that
also references the library compiled into the DLL I, of course, get a
conflict.
There are two instances of the same class. So, I guess I am asking -
what is the most graceful way of handling such conditions?
 
re:
!> If i have multiple DLLs that require the same library references to
!> run (for example, all using the MyCompany.Security) namespace and
!> referencing the same User class, how do I avoid a conflict when I am
!> finally adding the DLLs to my project?

Why do you think that would create a DLL conflict ?

Juan T. Llibre, asp.net MVP
Foros de VS 2010 y ASP.NET 4.0, en españolhttp://asp.net.do/foros/forums/
=================================
Click to expand...

Well, maybe i have the wording wrong. But, when I compile a library
"into"
another library and then call the complied library from a class that
also references the library compiled into the DLL I, of course, get a
conflict.
There are two instances of the same class. So, I guess I am asking -
what is the most graceful way of handling such conditions?
 
re:
!> when I compile a library "into" another library and then call the complied library
!> from a class that also references the library compiled into the DLL I, of course,
!> get a conflict. There are two instances of the same class. So, I guess I am asking -
!> what is the most graceful way of handling such conditions?

Merge your classes into a single source file and eliminate duplicate class names.
Also, you can simply make sure you don't use the same class name in multiple source files.





Juan T. Llibre, asp.net MVP
Foros de VS 2010 y ASP.NET 4.0, en español
http://asp.net.do/foros/forums/
=================================
re:
!> If i have multiple DLLs that require the same library references to
!> run (for example, all using the MyCompany.Security) namespace and
!> referencing the same User class, how do I avoid a conflict when I am
!> finally adding the DLLs to my project?

Why do you think that would create a DLL conflict ?

Juan T. Llibre, asp.net MVP
Foros de VS 2010 y ASP.NET 4.0, en españolhttp://asp.net.do/foros/forums/
=================================
Click to expand...

Well, maybe i have the wording wrong. But, when I compile a library
"into"
another library and then call the complied library from a class that
also references the library compiled into the DLL I, of course, get a
conflict.
There are two instances of the same class. So, I guess I am asking -
what is the most graceful way of handling such conditions?
 
re:
!> when I compile a library "into" another library and then call the complied library
!> from a class that also references the library compiled into the DLL I, of course,
!> get a conflict. There are two instances of the same class. So, I guess I am asking -
!> what is the most graceful way of handling such conditions?

Merge your classes into a single source file and eliminate duplicate class names.
Also, you can simply make sure you don't use the same class name in multiple source files.





Juan T. Llibre, asp.net MVP
Foros de VS 2010 y ASP.NET 4.0, en español
http://asp.net.do/foros/forums/
=================================
re:
!> If i have multiple DLLs that require the same library references to
!> run (for example, all using the MyCompany.Security) namespace and
!> referencing the same User class, how do I avoid a conflict when I am
!> finally adding the DLLs to my project?

Why do you think that would create a DLL conflict ?

Juan T. Llibre, asp.net MVP
Foros de VS 2010 y ASP.NET 4.0, en españolhttp://asp.net.do/foros/forums/
=================================
Click to expand...

Well, maybe i have the wording wrong. But, when I compile a library
"into"
another library and then call the complied library from a class that
also references the library compiled into the DLL I, of course, get a
conflict.
There are two instances of the same class. So, I guess I am asking -
what is the most graceful way of handling such conditions?
 
I like the idea of one DLL that contains all the classes and will
likely do that. But, I think the problem is that I have a web service
that must consume classes that are also consumed by the Web
project that calls the web service. In this case, I cannot use the
same "master" DLL for both the web service and the web project.
I think your second suggestion of renaming the classes (called by
the web service) is the only way forward that I can think of (and a
minor pain in the butt).

Thanks again.
 
Back
Top