Re: Command line 'devenv' not picking up dependencies on managed p
riek_at_virtualscopics.com
Date: 09/27/04
- Next message: fdelacruz_at_esdsac.com: "TabControl Automation Problem"
- Previous message: Developer: "Re: Can't load form: unspecified error"
- In reply to: Matt Zinkevicius: "Re: Command line 'devenv' not picking up dependencies on managed p"
- Messages sorted by: [ date ] [ thread ]
Date: 27 Sep 2004 12:57:36 -0700
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
Matt Zinkevicius wrote:
> 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
>
> "Andrew" wrote:
>
> > 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" <swarb70sok@hotmail.com> wrote in message
news:<eRDNIBxbEHA.808@tk2msftngp13.phx.gbl>...
> > > 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" <swarb70sok@hotmail.com> wrote in message
> > > news:%23VHUFhYbEHA.1292@TK2MSFTNGP11.phx.gbl...
> > > > 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.
> > > >
> > > >
> >
- Next message: fdelacruz_at_esdsac.com: "TabControl Automation Problem"
- Previous message: Developer: "Re: Can't load form: unspecified error"
- In reply to: Matt Zinkevicius: "Re: Command line 'devenv' not picking up dependencies on managed p"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
