Tech Off Thread

3 posts

Strange VS2008 VC++ behaviour

Back to Forum: Tech Off
  • User profile image
    jon_potter

    Hey,

    I've been having a weird problem with VC++ lately and was just wondering if anyone else had seen this and more importantly knew how to resolve it!

     

    I have quite a large solution, with multiple projects (if that matters). I also have multithread building enabled. What has been happening lately is if, for example, I make a change to a single source file and then build the project, the compiler will be launched twice for the same file. This then causes an error because (unsurprisingly) the second instance of the compiler isn't able to write to the .sbr file while the first instance is, which causes the build to fall over.

     

    Here's an example of what I see:

     

    1>------ Build started: Project: testproject, Configuration: Debug x64 ------
    1>Compiling...
    1>testfile.cpp
    1>testfile.cpp
    1>.\testfile.cpp(1) : fatal error C1083: Cannot open compiler generated file: 'x64\Debug\testfile.sbr': Permission denied
    1>Creating browse information file...
    1>Microsoft Browse Information Maintenance Utility Version 9.00.21022
    1>Copyright (C) Microsoft Corporation. All rights reserved.
    1>Build Time 0:05
    1>Build log was saved at "file://c:\Users\Jon\Documents\Visual Studio Projects\testproject\trunk\testproject\testproject\x64\Debug\BuildLog.htm"
    1>testproject - 1 error(s), 0 warning(s)
    ========== Build: 0 succeeded, 1 failed, 48 up-to-date, 0 skipped ==========

    I've checked the obvious (that the source file isn't included in the project twice somehow) and it's definitely not. This seems to happen with all files in the project, not just one, and also doesn't seem to happen ALL the time (although it is very frequent).

     

    Anyone got any ideas?

     

    Thanks!

     

  • User profile image
    Amit  MSFT

    Hi,

     

    If you open the .vcxproj file  you might find a duplicate item group entry for <ClCompile  Include="<path>\testfile.cpp" />. if a duplicate exists then as a workaround you can remove the duplicate entry from the project file. In VS2008 the IDE did allow having files with duplicate names and on upgrade we issue a warning that your original .vcproj has duplicate entries but we donot remove it from the newly created .vcxproj file. This might be causing the file to be passed twice on the compiler commandline.

     

    Note that above is just a rough diagnosis of the issue as understood from the explanation above and might not be the real cause of the issue you are experiencing. The issue might be totally separate in which case please feel free to share  a repro project file if it appropriate and does not contain any proprietary information at amitmo at microsoft dot com which will help us debug the issue. You can also open a bug through connect with repro information and we can investigate and keep you updated on that thread. Connect Bugs can be filed here: https://connect.microsoft.com/VisualStudio?wa=wsignin1.0

     

    Thanks

    Amit Mohindra [MSFT]

  • User profile image
    Philip​Sansone

    I have this same problem.  I also have a mid to large solution in VS2008 with several projects and on occasion I see something like this...

    8>------ Build started: Project: TestBedLauncher, Configuration: Debug Win32 ------8>

    Compiling...

    8>testBedLauncher.cpp

    8>testBedLauncher.cpp

    8>.\testBedLauncher.cpp : fatal error C1083: Cannot open compiler generated file: 'testBedLauncher_Debug\testBedLauncher.sbr': Permission denied

     

    Amit:  We don't have .vcxproj file's since were using VC2008.  The file in question is listed in the .vcproj only once.

     

    If I turn off the multiprocessor build option, the problem goes away.  Is there a hotfix or something for this?

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.