Visual Studio bug / limitation

[Bill Burris]

When compiling my solution which contains 15 projects (2 Window Apps, 2
Services, 11 class libraries, C#, MC++, & C++), I was receiving warnings
about symbols defined in multiple places. Selecting Rebuild Solution did
not make the problem go away. After selecting Clean Solution, followed by
Rebuild Solution, the problem went away.

I had always assumed that rebuild meant starting over, recompiling all code,
and linking with the recompiled code. It appears that this is not the case
with Visual Studio .NET 2003.

It looks like the rebuild process doesn't always bother obtaining the latest
versions of dlls, if one already exists in the working directory. If Class
A references Class C, B also references C, and D references both A & B,
Visual Studio sometimes ends up with 2 different versions of class C when
building D.

Hopefully the VS team at Microsoft will take a close look at how the build
and rebuild process copies dlls from one project to another, to prevent this
mixing of old and new versions of dlls in the same assembly.

In the bad old days, I would build all my C++ code into one big exe. .NET
has inspired me to split my code up into many small library dlls which I use
in more then one application. I am developing the libraries at the same
time as the applications which use them, so I need to re-compile several
times a day. Sometimes I waste a lot of time banging my head on the monitor
wondering what is causing all the warnings and errors, in code that
previously compiled without problems.

Bill

 

[Jeffrey Tan[MSFT]]

Hi Bill,

From the link below, you can see that Rebuild Solution will "clean" the
solution first, and then build all project files and components.
"Cleaning" a solution or project deletes any intermediate and output files,
leaving only the project and component files, from which new instances of
the intermediate and output files can then be built.
So I think rebuild solution will indeed do as you want.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vsintro7/ht
ml/vxtskprepareandmanagebuilds.asp

If you still have this problem, can you show me the steps to reproduce this
problem?

For your dll reference problem, VS.net will copy the project "directly"
referred class's dll into its output directory.
For exmaple, If A refers B project(which generates dll B), while B also
refers C project(which also generates dll C). Then when compile project B,
it will copy dll C to its output directory. But when you compile project A,
it only copies dll B not copy dll C to its output directory.(Because dll C
is not directly referred)

Hope this helps,
Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

--------------------
| From: "Bill Burris" <[email protected]>
| Subject: Visual Studio bug / limitation
| Date: Fri, 14 Nov 2003 14:45:00 -0700
| Lines: 31
| X-Priority: 3
| X-MSMail-Priority: Normal
| X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
| Message-ID: <uFy#[email protected]>
| Newsgroups: microsoft.public.dotnet.languages.csharp
| NNTP-Posting-Host: kzin.phys.ualberta.ca 129.128.162.60
| Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP10.phx.gbl
| Xref: cpmsftngxa06.phx.gbl microsoft.public.dotnet.languages.csharp:199468
| X-Tomcat-NG: microsoft.public.dotnet.languages.csharp
|
| When compiling my solution which contains 15 projects (2 Window Apps, 2
| Services, 11 class libraries, C#, MC++, & C++), I was receiving warnings
| about symbols defined in multiple places. Selecting Rebuild Solution did
| not make the problem go away. After selecting Clean Solution, followed by
| Rebuild Solution, the problem went away.
|
| I had always assumed that rebuild meant starting over, recompiling all
code,
| and linking with the recompiled code. It appears that this is not the
case
| with Visual Studio .NET 2003.
|
| It looks like the rebuild process doesn't always bother obtaining the
latest
| versions of dlls, if one already exists in the working directory. If
Class
| A references Class C, B also references C, and D references both A & B,
| Visual Studio sometimes ends up with 2 different versions of class C when
| building D.
|
| Hopefully the VS team at Microsoft will take a close look at how the build
| and rebuild process copies dlls from one project to another, to prevent
this
| mixing of old and new versions of dlls in the same assembly.
|
| In the bad old days, I would build all my C++ code into one big exe. .NET
| has inspired me to split my code up into many small library dlls which I
use
| in more then one application. I am developing the libraries at the same
| time as the applications which use them, so I need to re-compile several
| times a day. Sometimes I waste a lot of time banging my head on the
monitor
| wondering what is causing all the warnings and errors, in code that
| previously compiled without problems.
|
| Bill
|
|
|

 

[Bill Burris]

If you still have this problem, can you show me the steps to reproduce this
problem?

Its a little difficult to reproduce the problem. I had a project which was
in another solution. I added it to my soloution, removed all the references
which refered to my dlls, then added references to the corresponding
projects. I then did a rebuild solution. This is when the error with
symbols being defined in multiple places occured. Selecting Clean Solution
followed by Rebuild Solution eliminated the problem. I had assumed that
Rebuild Solution would clean out the old dlls or overwrite them, but it
seems it dosn't work this way.

In my backup files I eliminate all the bin and obj directories to reduce the
size from 130 M down to 2 M, so I don't have the old stuff laying around to
reproduce the problem.

I just have to remember to do a clean before rebuild after merging old
projects into new solutions, since the rebuild command dosn't always do it.

For your dll reference problem, VS.net will copy the project "directly"
referred class's dll into its output directory.
For exmaple, If A refers B project(which generates dll B), while B also
refers C project(which also generates dll C). Then when compile project B,
it will copy dll C to its output directory. But when you compile project A,
it only copies dll B not copy dll C to its output directory.(Because dll C
is not directly referred)

In this situation, project A needs a references to project B & project C,
before it will compile. Therefore both dll B & dll C will be copied.

I have got around this problem by defining an interface in project D.
Project B would then reference project D. Project C would reference project
D. Some class in D would implement (inherit) the interface.

This just simplifies creating independent library dlls. The top level exe
which uses these, still needs references to A, B, C, & D.

When B needs to call C and C needs to call back into B, interfaces defined
in a third dll are required to eliminate the circular reference. This was
one of the major sources of problems when converting my C++ to C# and
splitting it up into multiple library dlls. Since then my new C++ code uses
interfaces (abstract base classes). Learning C# has made me a better C++
programmer.

Bill

 

[Bill Burris]

I hate useing single letters as names, it is usually hard to keep track of
things in my head. Since my last message had errors here is the corrected
version of 2 paragraphs.

In this situation, project A needs references to project B & project C,
before it will compile. Therefore both dll B & dll C will be copied.

I have got around this problem by defining an interface in project D.
Project B would then reference project D. Project C would reference project
D. Some class in project C would implement (inherit) the interface.

Bill

 

[Jeffrey Tan[MSFT]]

Hi Bill,

Thanks for your feedback.
I have stored this issue in our internal database, we will wait more
detailed community reproduce steps for this issue.
If you met this issue again, then you can contact PSS support at:
http://support.microsoft.com/default.aspx?pr=cntactms
Then, there will be special microsoft engineer working for you. If this
issue is confirmed as our product issue, then this support will be a free
support.
Thanks for your understanding

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

--------------------
| From: "Bill Burris" <[email protected]>
| References: <uFy#[email protected]>
<[email protected]>
<[email protected]>
| Subject: Re: Visual Studio bug / limitation
| Date: Mon, 17 Nov 2003 11:55:57 -0700
| Lines: 28
| X-Priority: 3
| X-MSMail-Priority: Normal
| X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
| Message-ID: <[email protected]>
| Newsgroups: microsoft.public.dotnet.languages.csharp
| NNTP-Posting-Host: kzin.phys.ualberta.ca 129.128.162.60
| Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP11.phx.gbl
| Xref: cpmsftngxa06.phx.gbl microsoft.public.dotnet.languages.csharp:199924
| X-Tomcat-NG: microsoft.public.dotnet.languages.csharp
|
| | >
| > > For exmaple, If A refers B project(which generates dll B), while B
also
| > > refers C project(which also generates dll C). Then when compile
project
| B,
| > > it will copy dll C to its output directory. But when you compile
project
| > A,
| > > it only copies dll B not copy dll C to its output directory.(Because
dll
| C
| > > is not directly referred)
| > >
|
| I hate useing single letters as names, it is usually hard to keep track of
| things in my head. Since my last message had errors here is the corrected
| version of 2 paragraphs.
|
| In this situation, project A needs references to project B & project C,
| before it will compile. Therefore both dll B & dll C will be copied.
|
| I have got around this problem by defining an interface in project D.
| Project B would then reference project D. Project C would reference
project
| D. Some class in project C would implement (inherit) the interface.
|
| Bill
|
|
|
|