locked
Batch rebuild links wrong dependent project RRS feed

  • Question

  • I've converted a VS 2008 solution with two C++ projects, a static lib and an exe, to VS2010, and the conversion has created a project to project dependency between the static lib project and the exe project. If I rebuild either the release exe or the debug exe then they both succeed without any problems. But if I do a batch rebuild all then the release build attempts to link to the debug version of the dependent project... This is from the linker output:

      Searching libraries
          Searching ..\..\tools\w2k\lib\Release\si_tools.lib:
          Searching ... lots of default libs...

    si_tools is a lib linked using "Additional Dependencies", and it gets the "Release" part of the path from the $(Configuration) specified in "Additional Library Directories"

    Later on in the link phase I then get:

          Searching ... more default libs ...
          Searching C:\2010Build\system\w2k\lib\Debug \si_system.lib:
          Searching c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\lib\libcpmt.lib:

    si_system.lib is the project that the exe depends on, but it's linking the Debug version of it rather than the Release version. The dependency is only specified in Framework and References.

    Why is it using the Debug version of the dependency, and why only on a batch rebuild?? This is from the Release-only rebuild:

    Searching libraries
    2>      Searching ..\..\tools\w2k\lib\Release\si_tools.lib:
    2>      Searching ... lots of default libs...
    2>      Searching C:\2010Build\system\w2k\lib\Release \si_system.lib

    Now it's the Release version and everything works! Incidentally, the Full Path of the lib in the Reference Properties section of the exe's Framework and References dialog specifies the correct version of the lib (i.e. C:\2010Build\system\w2k\lib\Release\si_system.lib)

    Finally... if the current configuration is Release and I do a batch rebuild all then the debug exe fails to link with

    "error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2'"

    because the Debug exe is linking against the Release lib. If the current configuration is Debug and I do a batch rebuild all then the release build fails with

    error LNK2019: unresolved external symbol "void __cdecl std::_Debug_message(wchar_t const *,wchar_t const *,unsigned int)" (?_Debug_message@std@@YAXPB_W0I@Z) referenced in function "void __cdecl std::_Debug_pointer<char>(char const *,wchar_t const *,unsigned int)" (??$_Debug_pointer@D@std@@YAXPBDPB_WI@Z)

    because the Release exe is linking against the Debug lib.

     

    Any ideas!?

     

     

     

    Tuesday, December 21, 2010 3:10 PM

All replies

  • Hi, this is a known issue. We have a connect bug to track this issue. You can take a look of this link: http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=556158. Just in case you cannot access the link, this is the content of the connect issue. Essentially, we are not going to fix the batch build. Chuck has provided some workaround for this.

    Posted by GregM on 12/9/2010 at 6:10 AM
    I tried to reproduce the functionality of Batch Build using a macro, but you can't have multiple Build() commands in a macro unless you tell the Build() command to wait until the build is finished before proceeding. When you do that, VS becomes mostly unresponsive until the entire build is finished because there's a macro running, and you shouldn't interrupt a running macro.
    Posted by Anders Dalvander on 9/30/2010 at 4:04 AM
    What is the purpose of Batch Build if it doesn't work with multiple configurations?

    I'm very disappointed in seeing this defect closed as "won't fix".

    "These issues have existed in Batch Build for some time." Only in VS2010 though.

    This really needs to be fixed in VS2010SP1.
    Posted by RossInglis on 9/29/2010 at 3:12 AM
    This is a major pain.

    I'm converting numerous VS2008 projects (where I use batch build all the time - and it works just fine) to VS2010.
    The conversion process converts all 'Link Library Dependencies' options into project references, 90% of which then
    fail to link because of this bug.

    The only solution is to rip out all the broken references, and go through all the projects adding specific links to
    the local project libraries.
    Posted by Doug Harrison on 8/7/2010 at 4:21 AM
    Disappointed to see this closed as "won't fix". It's an important feature, and it needs to work.
    Posted by Microsoft on 6/22/2010 at 9:41 AM
    Unfortunatley we did not have time during the previous cycle to address the issues with Batch Build. These issues have existed in Batch Build for some time. But, they are not a very popular feature, nor have they worked. Therefore it was decided that we should spend our time on other features that were critical to the success of the release and other teams that were delivering during the release.

    The C1853 error is another issue. It most likley has to do with the mixing of headers generated for C++ vs. those generated for C. See the following article:

    http://support.microsoft.com/kb/126717

    You are probably seeing this only at certain times based on a problem with incremental build. I would highly recommend that you open another Connect issue on this so that the C++ team can take a look. You will need to provide them with your project files and logs so that can look and see what is going on.

    I hope that during a future cycle we will be able to take a look at this feature and either provide a fix for the broken behavior, or remove the feature from the product since it does not work.

    I am resolving this issue as "Won't Fix", since at this time, all I can offer are work-arounds for what is known broken behavior.

    Thanks,

    Chuck England
    Visual Studio
    Program Manager - MSBuild
    Posted by Crend King on 6/15/2010 at 8:27 PM
    I followed Chuck's sample project and wrote my own. However, the fatal error C1853 about precompiled header file frequently happens. Every time the error pch file is random (64-bit cases more than 32-bit cases). I have to either manually delete the pch file, Clean/Rebuild the error project or the whole solution. This renders the precompiled header useless. Is there anything I can do to remedy?

    Also, is there any way to save all modified files before building the MSBuild project?

    Thanks!
    Posted by Crend King on 6/10/2010 at 10:03 AM
    I don't mind writing some XML, and extension might be the easiest way. However, why wouldn't some one from the VS or MSBuild team do such work, but rather push to end users? If the core function of the extension is to patch the bug, the effort will be in vain after official fix is released (maybe in SP1).
    Posted by Microsoft on 6/9/2010 at 1:10 PM
    Thanks for taking the time to send us this feedback.

    It is unfortunate, but Batch Build is currently broken.

    Here are some possible work-arounds:

    Create a batch file that invokes the MSBuild command line for each of the configurations that you wish to build. You can wire this up to the Tools menu to give the convenience of build in the IDE. Unfortunately, this mean hand-editing the XML based MSBuild file in Visual Studio to setup the configurations that you want to build.

    You could also opt for an MSBuild traversal project. This is similar to what we do here for building on the command line and on build servers. Again, you could wire this up to the Tools menu by calling the msbuild command line and point to the .proj file you create. And example might look something like:

    <Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <ItemGroup>
        <Project Include="MySolution.sln">
         <Configuration>Release</Configuration>
         <Platform>Any CPU</Platform>
        </Project>
        <Project Include="MySolution.sln">
         <Configuration>Debug</Configuration>
         <Platform>x86</Platform>
        </Project>
    </ItemGroup>

    <Target Name="Build">
        <MSBuild Projects="@(Project)" Properties="Configuration=%(Project.Configuration);Platform=%(Project.Platform)" BuildInParallel="true" />
    </Target>

    </Project>

    In this example, I have it setup to build MySolution.sln for the solution configuration "Release|Any CPU" and for "Debug|x86". Note that you would need to make sure that your solution configurations are setup correctly for this to work. If you built projects in this way, you would be using project configurations. In this case, you would need to make sure that any project references between projects have the same configuration, or that there is an appropriate solution configuration to pull the information from.

    It is also possible to write a Visual Studio extension that could seamlessly replace the existing Batch Build behavior. To do this, you would need the Visual Studio SDK (a quick download and install; it's free) In this case you would need to design your own UI, and call the build system on your own. This is quite a bit of work, and you really need to know VS and build to get it “right”.

    Once last possible option is to use the new “free” version of the Team Build product (TFS Basic). Team Build allows you to setup multiple builds that can be built simultaneously. It also provides a continuous integration server via Gated Checkins. It is really easy to setup as well.

    Thanks,

    Chuck England
    Visual Studio Platform
    Program Manager - MSBuild
    Posted by kuhnboy on 6/7/2010 at 12:25 PM
    I just noticed this by accident because we have a COTS vendor that supplies two different versions of an assembly (one for debug and one for release) and choosing the configuration from the menu and building separately works fine, but batch builds only use one or the other (the currently selected configuration only).
    Posted by AndrewAye on 5/14/2010 at 2:56 AM
    Would love to hear the fix for this as well - don't want to have to go through the hassle of creating a continuous build environment for my project because of this bug.
    Though as a feature request - a batch solution build would be awesome (a co-worker made a plugin for 2008 that did it but was forced to make it lock of VS during the build process).
    Posted by Microsoft on 5/2/2010 at 10:29 PM
    Thanks for your feedback.

    We are routing this issue to the appropriate group within the Visual Studio Product Team for triage and resolution.
    These specialized experts will follow-up with your issue.
    Posted by Crend King on 5/1/2010 at 2:53 PM
    Bug 554339 (https://connect.microsoft.com/VisualStudio/feedback/details/554339/visual-studio-2010-bug-in-platformname-handling-in-batch-build) seems suffer the same bug. You may use it as a reference.
    Posted by Microsoft on 5/1/2010 at 4:06 AM
    Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)
    Li Shao, MSFT

    Li Shao
    Friday, December 24, 2010 1:30 AM