assemblies. The
managed code references.
"r
...@virtualscopics.com" wrote:
> 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" <swarb70...@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=03f601c333c...
> > > > also this one ...
> http://groups.google.co.uk/groups?hl=en&lr=&ie=UTF-8&selm=03c901c3556...
> > > > 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" <swarb70...@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.
|
