.NET Project References (easy one) 
Author Message
 .NET Project References (easy one)

I have a project called "Common" which builds a file called "common.dll"...
This dll contains a bunch of common classes of which my other projects make
use. "Common" makes use of some third party components that handle
compression, FTP, etc. Let's call these components 'zip.dll' and
'ftp.dll'... These 3rd party DLLs have been added as references to Common.
The "Copy Local" property has been set to true. When I build Common,
'zip.dll' and 'ftp.dll' are copied to my output directory, just as you'd
expect.

Now, I have lots of other projects that depend on "Common". These projects
have the "Common" project in their References section, and of course "Copy
Local" is set to true. When these projects build, 'common.dll' is copied to
their output directories (just as you'd expect), but 'zip.dll' and 'ftp.dll'
are not. Why? I need to ensure that when I build these projects, ALL
necessary assemblies (including third party assemblies called by common.dll)
are copied to the output directory of the project. How should I do this?

Should I add 'zip.dll' and 'ftp.dll' references to my outer projects
*despite* the fact that these outer projects never reference these
components directly? Please be so kind as to eliminate the cluelessness that
overwhelms me like a bear overwhelms the dear. Thank you.

David



Tue, 13 Jul 2004 01:19:38 GMT  
 .NET Project References (easy one)
Oh, no!

I've figured out from reading the documentation that even if you set "Copy
Local" to true, it will be overridden with 'false' if the assembly you're
referencing already exists in the GAC. In my case, the third party assembly
exists in the GAC because the installation program for the component stuck
it there! I can't delete it from the GAC without getting an error message. I
can't uninstall the 3rd party component because then the 3rd party's
licensing system fails to operate properly if uninstalled. :(

This isn't the end of the world, but it means that when I want to deploy my
application, I can't do a simple XCOPY of the exes and dlls in my project
directory. Instead, I'll have to constantly remember that this one zip
component is in the GAC and I'll have to manually copy it...

David

"Rev. Dr. Hulio Manuel Sanchez-Cruz, MCSD, PhD, MD, DDS, CPA, RN"

Quote:

> I have a project called "Common" which builds a file called
"common.dll"...
> This dll contains a bunch of common classes of which my other projects
make
> use. "Common" makes use of some third party components that handle
> compression, FTP, etc. Let's call these components 'zip.dll' and
> 'ftp.dll'... These 3rd party DLLs have been added as references to Common.
> The "Copy Local" property has been set to true. When I build Common,
> 'zip.dll' and 'ftp.dll' are copied to my output directory, just as you'd
> expect.

> Now, I have lots of other projects that depend on "Common". These projects
> have the "Common" project in their References section, and of course "Copy
> Local" is set to true. When these projects build, 'common.dll' is copied
to
> their output directories (just as you'd expect), but 'zip.dll' and
'ftp.dll'
> are not. Why? I need to ensure that when I build these projects, ALL
> necessary assemblies (including third party assemblies called by
common.dll)
> are copied to the output directory of the project. How should I do this?

> Should I add 'zip.dll' and 'ftp.dll' references to my outer projects
> *despite* the fact that these outer projects never reference these
> components directly? Please be so kind as to eliminate the cluelessness
that
> overwhelms me like a bear overwhelms the dear. Thank you.

> David



Tue, 13 Jul 2004 01:43:23 GMT  
 .NET Project References (easy one)
David,
    How hard was is to create an FTP component? I've been stuck on
Asyncrhonous calls and threading for about a week now. I've been able to
send USER and PASS and other commands to the server and get some responses,
but not the whole response.

Jason

"Rev. Dr. Hulio Manuel Sanchez-Cruz, MCSD, PhD, MD, DDS, CPA, RN"

Quote:

> I have a project called "Common" which builds a file called
"common.dll"...
> This dll contains a bunch of common classes of which my other projects
make
> use. "Common" makes use of some third party components that handle
> compression, FTP, etc. Let's call these components 'zip.dll' and
> 'ftp.dll'... These 3rd party DLLs have been added as references to Common.
> The "Copy Local" property has been set to true. When I build Common,
> 'zip.dll' and 'ftp.dll' are copied to my output directory, just as you'd
> expect.

> Now, I have lots of other projects that depend on "Common". These projects
> have the "Common" project in their References section, and of course "Copy
> Local" is set to true. When these projects build, 'common.dll' is copied
to
> their output directories (just as you'd expect), but 'zip.dll' and
'ftp.dll'
> are not. Why? I need to ensure that when I build these projects, ALL
> necessary assemblies (including third party assemblies called by
common.dll)
> are copied to the output directory of the project. How should I do this?

> Should I add 'zip.dll' and 'ftp.dll' references to my outer projects
> *despite* the fact that these outer projects never reference these
> components directly? Please be so kind as to eliminate the cluelessness
that
> overwhelms me like a bear overwhelms the dear. Thank you.

> David



Tue, 13 Jul 2004 02:07:21 GMT  
 .NET Project References (easy one)
Ah... but look at the bright side... no more DLL Hell! Microsoft solved that
problem in .Net right? RIGHT!!!

fadi

"Rev. Dr. Hulio Manuel Sanchez-Cruz, MCSD, PhD, MD, DDS, CPA, RN"

Quote:

> Oh, no!

> I've figured out from reading the documentation that even if you set "Copy
> Local" to true, it will be overridden with 'false' if the assembly you're
> referencing already exists in the GAC. In my case, the third party
assembly
> exists in the GAC because the installation program for the component stuck
> it there! I can't delete it from the GAC without getting an error message.
I
> can't uninstall the 3rd party component because then the 3rd party's
> licensing system fails to operate properly if uninstalled. :(

> This isn't the end of the world, but it means that when I want to deploy
my
> application, I can't do a simple XCOPY of the exes and dlls in my project
> directory. Instead, I'll have to constantly remember that this one zip
> component is in the GAC and I'll have to manually copy it...

> David

> "Rev. Dr. Hulio Manuel Sanchez-Cruz, MCSD, PhD, MD, DDS, CPA, RN"

> > I have a project called "Common" which builds a file called
> "common.dll"...
> > This dll contains a bunch of common classes of which my other projects
> make
> > use. "Common" makes use of some third party components that handle
> > compression, FTP, etc. Let's call these components 'zip.dll' and
> > 'ftp.dll'... These 3rd party DLLs have been added as references to
Common.
> > The "Copy Local" property has been set to true. When I build Common,
> > 'zip.dll' and 'ftp.dll' are copied to my output directory, just as you'd
> > expect.

> > Now, I have lots of other projects that depend on "Common". These
projects
> > have the "Common" project in their References section, and of course
"Copy
> > Local" is set to true. When these projects build, 'common.dll' is copied
> to
> > their output directories (just as you'd expect), but 'zip.dll' and
> 'ftp.dll'
> > are not. Why? I need to ensure that when I build these projects, ALL
> > necessary assemblies (including third party assemblies called by
> common.dll)
> > are copied to the output directory of the project. How should I do this?

> > Should I add 'zip.dll' and 'ftp.dll' references to my outer projects
> > *despite* the fact that these outer projects never reference these
> > components directly? Please be so kind as to eliminate the cluelessness
> that
> > overwhelms me like a bear overwhelms the dear. Thank you.

> > David



Tue, 13 Jul 2004 03:35:49 GMT  
 .NET Project References (easy one)
Just a different kind of .dll hell.  dll proliferation hell.


Quote:
> Ah... but look at the bright side... no more DLL Hell! Microsoft solved
that
> problem in .Net right? RIGHT!!!

> fadi

> "Rev. Dr. Hulio Manuel Sanchez-Cruz, MCSD, PhD, MD, DDS, CPA, RN"

> > Oh, no!

> > I've figured out from reading the documentation that even if you set
"Copy
> > Local" to true, it will be overridden with 'false' if the assembly
you're
> > referencing already exists in the GAC. In my case, the third party
> assembly
> > exists in the GAC because the installation program for the component
stuck
> > it there! I can't delete it from the GAC without getting an error
message.
> I
> > can't uninstall the 3rd party component because then the 3rd party's
> > licensing system fails to operate properly if uninstalled. :(

> > This isn't the end of the world, but it means that when I want to deploy
> my
> > application, I can't do a simple XCOPY of the exes and dlls in my
project
> > directory. Instead, I'll have to constantly remember that this one zip
> > component is in the GAC and I'll have to manually copy it...

> > David

> > "Rev. Dr. Hulio Manuel Sanchez-Cruz, MCSD, PhD, MD, DDS, CPA, RN"



- Show quoted text -

Quote:
> > > I have a project called "Common" which builds a file called
> > "common.dll"...
> > > This dll contains a bunch of common classes of which my other projects
> > make
> > > use. "Common" makes use of some third party components that handle
> > > compression, FTP, etc. Let's call these components 'zip.dll' and
> > > 'ftp.dll'... These 3rd party DLLs have been added as references to
> Common.
> > > The "Copy Local" property has been set to true. When I build Common,
> > > 'zip.dll' and 'ftp.dll' are copied to my output directory, just as
you'd
> > > expect.

> > > Now, I have lots of other projects that depend on "Common". These
> projects
> > > have the "Common" project in their References section, and of course
> "Copy
> > > Local" is set to true. When these projects build, 'common.dll' is
copied
> > to
> > > their output directories (just as you'd expect), but 'zip.dll' and
> > 'ftp.dll'
> > > are not. Why? I need to ensure that when I build these projects, ALL
> > > necessary assemblies (including third party assemblies called by
> > common.dll)
> > > are copied to the output directory of the project. How should I do
this?

> > > Should I add 'zip.dll' and 'ftp.dll' references to my outer projects
> > > *despite* the fact that these outer projects never reference these
> > > components directly? Please be so kind as to eliminate the
cluelessness
> > that
> > > overwhelms me like a bear overwhelms the dear. Thank you.

> > > David



Tue, 13 Jul 2004 05:34:10 GMT  
 .NET Project References (easy one)

Quote:
> Ah... but look at the bright side... no more DLL Hell! Microsoft solved
that
> problem in .Net right? RIGHT!!!

> fadi

S'right.  Microsoft has turned .NET into a PARADISE for DLL's.  Heh.

    Jerry



Tue, 13 Jul 2004 05:49:48 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. VS.NET: Adding one .cs file to more then one project

2. OLEDB.NET - an easy one (i hope)

3. Problem Referencing a project in C# .NET Solution

4. .NET project locking/loading DLL created by other .NET project

5. .NET project locking/loading DLL created by other .NET project

6. how to share the codes in two projects of one solution in visual studio .net

7. Create one singleton object in other interface's method (in one project)

8. multiple sdi project into one mdi project

9. conver a VC.net solution/projects back to VC6 workspace/project

10. Need help on maintaining session between VB.NET project and C# project

11. Visual.Net New Project Wizard for C projects

12. Easy Reference Question

 

 
Powered by phpBB® Forum Software