Command line 'devenv' not picking up dependencies on managed projects correctly.

[Andy]

We have a solution that has a mix of:

legacy unmanaged C++ projects.
new C# projects.
mixed module C++ projects that have both unmanaged and managed C++ in them
to bridge the technologies

If we build the solution interactively.
It builds fine. Dependacies between the mixed projects and the C# projects
are picked up correctly and the C# asemblies are automatically copied to the
output of the dependant project.

Output from the (interactive) build log looks like this ...

------ Build started: Project: <<project name>>, Configuration: Debug
Win32 ------

Copying assemblies to target directory...
<<path to assembly dll>>
1 File(s) copied
Compiling...
StdAfx.cpp

However if we try to build the exact same solution on the command line -
using the following syntax:

devenv <<build_type>> Debug <<path of solution file>> /out <<path to log
file>>

The output from the build log looks like this ...

------ Build started: Project: <<project name>>, Configuration: Debug
Win32 ------

Compiling...
StdAfx.cpp

Note that there is NO "Copying assemblies to target directory". So the
command line build which we use to do an automated build every night fails!
There are a number of workarounds we could use to fix this - explicitly
adding post build steps to the C# projects or a pre-build step to the mixed
projects that depend on them - but we really would rather not do that!

Is this a known bug? Are we doing something wrong? Has anyone else
experienced this?
Any feedback on this issue would be very welcome.

Thanks,

Andy

To reply via email - remove leading 'sw' from address.
Better to post to the group though.

[Andy]

I have done a bit more research on this.
If you look at the command line for compiling one of the files that is
failing to build it looks like the following ...

cl <file_name> /Od /I "..\e_eks\include" /I "..\e_calc" /I "..\filelib" /AI
"Debug" /D "WIN32" /D "_WINDOWS" /D "_DEBUG" /D "_AFXEXT" /D "MIF_EXPORTS"
/D "_WINDLL" /D "_AFXDLL" /D "_MBCS" /FD /EHsc /MDd /Zp1 /GS /Gy /Zc:wchar_t
/GR /Yu"stdafx.h" /Fp"Debug/MetadataInterface.pch" /Fo"Debug/"
/Fd"Debug/vc70.pdb" /W3 /nologo /c /Zi /clr /TP /FU
"e:\DEVELOP\Empower.Metadata\obj\Debug\Empower.Metadata.dll" /FU
"C:\WINNT\Microsoft.NET\Framework\v1.1.4322\System.dll" /FU
"C:\WINNT\Microsoft.NET\Framework\v1.1.4322\System.Data.dll"

The relevant thing in all that is the last three /FU parameters which
reference the assemblies that my project depends on.
Could it be for some reason when you call devenv from the command line this
compile command is not getting constructed correctly?

If that were the case this would be a definite bug - I found a similar post
(on this group) from last June which may/may not be relevant.
http://groups.google.co.uk/groups?hl=en&lr=&ie=UTF-8&selm=03f601c333c0%24cc1b1450%24a101280a%40phx.gbl&rnum=18

also this one ...
http://groups.google.co.uk/groups?hl=en&lr=&ie=UTF-8&selm=03c901c35560%2452e1b190%24a601280a%40phx.gbl&rnum=5

The second one looks like it is exactly the same problem as I am having -
unfortunately the thread dies with the issue unresolved.

If anyone has further info on this I would love to hear from you.

Thanks - hopefully,

Andy

"Andy" <swarb...@hotmail.com> wrote in message
news:%23VHUFhY...@TK2MSFTNGP11.phx.gbl...

[Andrew]

Hello Andy!

I am just in the prcess of writing and automated build for our
solution using VisBuildPro which makes a commandline call to devenv.
We also have a C++ project in this solution that fails to compile in
the command line compile because it can't reference C# assemblies that
are compiled before it.
I have tried compiling this project in the IDE first and then using
the commandline and that works because the reference assemblies have
already been copied to the output folder by the manual compile.
However, it is not quite so simple because if I delete all files from
the output folder except these assemblies it still fails. If I delete
all files (including C# assemblies) except the output dll from the C++
project itself then the commandline compile works! Very Strange.
Have you found out anything new about this problem? Or anyone else?

Cheers
Andrew

"Andy" <swarb...@hotmail.com> wrote in message news:<eRDNIBx...@tk2msftngp13.phx.gbl>...

[Zinkevicius@discussions.microsoft.com Matt Zinkevicius]

Our team just added our first Managed C++ project to our solution and now our
automated command line based build is failing because it can't find the
project referenced assemblies. Same build from the IDE works fine. This seems
like an awfully big bug to not have a fix.

Our current workaround is to set the "Force #using" to the hardcoded project
dll's we need and then add artificial project dependencies to force proper
build order. We hate this hack though and need a real fix.

--Matt

[ri...@virtualscopics.com]

We have a similar problem when compiling mixed C++ code with references
to C# assemblies. We try to build the release version from the
commandline and it does not copy any of the C# reference assemblies to
the output directory, even though Copy Local is set to true. In
addition, after checking it out to a clean directory and having the
command line build fail, if we then open it up in the IDE and try to
build, the build log shows that the xcopy command is incorrect. It is
trying to copy the reference assembly from the Obj\Debug directory
during a Release build. The references we are using are project
references, so there is no link to a specific configuration. Our hack
of a solution was to write a little C# app that opens the solution in
the IDE and builds it. Any other solutions are welcome.

Jon

[Bob]

Echoing Andy, Matt, and Jon's issue: we too are seeing the exact same problem
running devenv with mixed managed & unmanaged C++ and C# assemblies. The C#
assembly builds fail to resolve previously-built C++ managed code references.

We are considering the following:
1) 'Hard coding' file references to the failing projects (against
Microsoft's advice, of course) by first building the problem children in a
seperate solution(no dependencies among each other), then running the main
solution with the file references;
2) Jon's trick of a 'batch execute' of the actual VS.net 2003 IDE (because
running the build interactively appears to work all the time), or
3) Running the IDE once, and keeping these (relatively static) dependency
projects on disk so devenv can find them the next time when building the
solution. This represents a real step BACKWARD in automated builds compared
to VS 6.0.

HAS/WILL MICROSOFT ADDRESS THESE ISSUES WITH DEVENV DEPENDENCIES???

-= Bob =-

[Bob]

Followup:

I've tried an enormous number of Project settings changes to solve this
problem; none have worked. I've tried changing all the output directories to
a common location, deleting and re-creating the project dependencies, turning
off Local Copy, a pre-build step to explicitly copy the referencing .dlls;
using the Resolve #include Directives setting... all to no avail.

Specifically, we have two C++ projects (ByteSwap and CRC) which build fine.
A third C++ project (RawDataDefinition) depends on both of the others, and
runs later in the build (as desired). When Devenv runs the show,
RawDataDefinition fails starting with the source line:

using namespace IMDHUMS::Utility;

which produces cascading errors starting with:

c:\imd2\project\Download\RawDataReader\Packet.h(54) : error C2039: 'Utility'
: is not a member of 'IMDHUMS'
c:\imd2\project\Download\RawDataReader\Packet.h(54) : error C2871: 'Utility'
: a namespace with this name does not exist

It then fails to locate the methods which were defined in the depending
projects.

We're guessing that the namespace error isn't the actual error, but that the
compiler is failing to make proper reference to the ByteSwap and CRC32 .dlls
which are otherwise correctly referenced in the dependant project's .vcproj
file.

As the others have indicated, the build works fine from within the IDE (and
subsequent command line executions work OK too as long as files from the IDE
build remain on the build machine). We want to build from scratch each night
via a batch process, so interactively running the IDE before the batch build
is not practical; and leaving some output on the machine to allow the batch
build to run is also not a viable option for us.

Your help in working around or isolating this bug (or knowing it's being
worked on within 'Devenv' itself) is appreciated.

-= Bob =-

[Bob]

We think we understand the issue now, and can suggest a work around for it:

PROBLEM:
In Microsoft Visual Studio .NET 2003, the command-line compiler (devenv)
cannot correctly build C++ projects which have any kind of dependency within
the Solution, UNLESS a binary of the project you are trying to build is
ALREADY PRESENT in its $(OutDir) directory. It appears that dependencies to
C++ AND C# will both cause problems.

WORKAROUND:
Use the IDE to build the solution (or project--your choice). Within the
IDE, the dependencies are handled correctly, and you should get a resulting
binary. Then, capture that project's resulting binary (.dll file). Anytime
you want to rebuild the solution using devenv, place those .dlls you captured
into their $(OutDir) BEFORE calling devenv, and the build will succeed.

EXAMPLE:

SOLUTION.sln consists of C++ Projects A and B, which have no dependencies,
C# Project D, and C++ Project C which depends on A, B, and D. Build
SOLUTION.sln in the IDE, then capture the file C.dll.

To rebuild SOLUTION.sln from the command line, before you run devenv, copy
C.dll to its output directory (what the project has stored for $(OutDir)),
and make sure it is writable. Then run devenv for SOLUTION.sln and it should
succeed.

ISSUE:
Yes, this violates several first rules of automatic rebuilds (no capturing
the output to use as input), but it's the only thing we have found which
works. The RESULTING build is OK (the C.dll file is refreshed fine), so it's
just an inconvenience. Essentially, this is a "Chicken and Egg" type of
problem, where the "Chicken" has to exist before the "Egg" can be produced.

Changes to the C++ module later may require that you rebuild it in the IDE
again and check it into your source code control system before the next build
will work--I imagine that would be neccessary if you change any interfaces or
manifest details in Project C. Stay alert for those.

Thanks to Jon for his help looking for other workarounds! This one seems to
be the simplest for us to do and will require us only to delete the .dlls
from source control once (or if) Microsoft chooses to address the problem and
fix the way devenv discovers dependencies within C++ projects in .NET.