LNK4006 errors in VS.NET caused by setting project dependencies

[Roger Stoller]

Hello.

I have run into a wall when trying to use project dependencies. My project
consists of many libraries which depend on many other libraries. As an
example, lets say:

bar() is defined in foo.obj

library A depends on library B
library B depends on library C
library D depends on library C
executable E depends on libraries A and D.

Because of the dependencies I checked, VS.NET includes C.lib on the LIB
command line when creating B.LIB, thus including it in C.LIB, etc. This is
not the bahavior I desire. I just want C built before B, etc. The result
is that when I try to link E, VS.NET tries to link C into the the EXE twice
(once comming from A and once from D). This causes LNK4006 errors that look
something like:

D.lib (foo.obj) : warning LNK4006: "bar() already defined in B.lib
(foo.obj); second definition ignored.

Is there any way to tell VS.NET NOT to include depended-upon libraries on
the LINK and LIB command lines? VS6.0 dependencies worked fine because it
did not do this. There seems to be no way to modify the command line either
so that I can remove these added libraries on the LINK or LIB command lines.

Thanks!

- Roger

[Tian Min Huang]

Hello Roger,

Thanks for your post.

>> Is there any way to tell VS.NET NOT to include depended-upon libraries
on the LINK and LIB command lines?

When we set a project (say B) depend on another one (say C) in Project
Dependencies, Visual Studio .NET IDE believes that project B consumes
executable code generated by project C and set proper link property. Based
on my experience, there is no option to disable this behavior unless we
break their dependency. I am not quite sure why C need to be built before B
since there is not direct/indirect relationship between them.

Please feel free to let me know if you have any problems or concerns.

Have a nice day!

Regards,

HuangTM
Microsoft Online Partner Support
MCSE/MCSD

Get Secure! -- www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

[Roger Stoller]

Thanks for your reply.

With VC++ 6.0, dependencies merely specified an order in which to build
projects. The dependencies we specify are due to certain headers (*.hpp
files) that are publish into a common include-file repository. In our build
environment, some libs cannot build until previous libs' headers have been
published. With VS.NET, the code-consumption assumption breaks the build.
I suggest adding some sort of option to change this behavior in your next
update. By the way, I'm using MS Dev Env 2003 version 7.1.3088. I have
also found numerous bugs in the C++ compiler for 80x86 (version 13.10.3077).
Are there any updates to the compiler as well? I can send you a bug list if
you like.

Thank you.

- Roger

"Tian Min Huang" <timh...@online.microsoft.com> wrote in message
news:sh8iVejx...@cpmsftngxa07.phx.gbl...

[Tian Min Huang]

Hello Roger,

Thanks a lot for your feedback and I will report it to our Developer Team.
In addition, you can send me a bug list so that I can check the status of
them. As you know, there may be a hotfix if a bug is critical.

I look forward to hearing from you.

[Ryan]

I am having a very simialr problem. The difference that I
am having is that I want the .lib linked in, but it is
not build in the default directory that .NEtapparently
has hard coded. For example.

I have 2 projects A & B.
B depends on A.
A.lib is build into C:\myDir\A.lib
.NET adds \projectDir\A.lib to B's project settings!
Then when it's time to link project B, A.lib is not found
because it is built into a different directory.

Is this configurable?
I have a very large project, and this is a huge slow down
for us.

Thanks,
Ryan

>.
>