locked
How to see the command line? ("Forcing rebuild of all source files due to a change in the command line since the last build. " problem) RRS feed

  • Question

  •  VS2010, building a native C++ project, only ever building in VS2010. Problem: every half-dozen builds or so, MSBuild decides the command line has changed, logs the "Forcing rebuild of all source files due to a change in the command line since the last build." message, and rebuilds my entire project.

     

     I am doing nothing different when this happens -- every time, I just edit a .cpp file and hit build, but sometimes it thinks the command line has changed, for some reason. I am not touching the project file/settings, and looking at other similar questions, no, I am not running devenv from the command line, and this is the standard MSVC compiler. I'm not sure if this is related to number of builds, or some sort of elapsed-time issue; I can't make it happen to order, but I also can't stop it from happening..

     

     How can I find out what the command line _is_? Maybe that way I could at least see why MSBuild thinks it's changed.

     

     -- dan

     

     

    Thursday, August 25, 2011 5:32 PM

Answers

  • Hi djmitchella,

    >> Yes, as I said, I'm only ever building from within VS2010, I'm not using devenv from the command line.

    If you use VS IDE to build your project and then got this error. You can try the following solutions:

    1. If we reboot the operating system to safe mode, do we have the problem? This can help to isolate whether any other applications are interfering with Visual Studio. Note that some features (like IIS) are not available under safe mode. Please check whether this can apply or not. In addition to safe mode, we can also suggest “clean boot”: http://support.microsoft.com/kb/310353.

     

    2. If we create a new user account, do we have the problem? This can help to isolate user profile corruption related causes.

     

    3. If we disable Add-ins (e.g. “Tools” | “Add-in Manager”) and run “devenv.exe /safemode”, do we still have the problem? This can eliminate the possibility that third party Add-ins are causing problems.

     

    4. If we use “devenv.exe /resetsettings”, does it solve the problem? It restores Visual Studio default settings.

     

    5. If the problem remains, we can use Visual Studio Setup Wizard (via Control Panel) to repair Visual Studio. It can restore the Visual Studio Installation into its original state.

    >> Can you tell me how to see the command lines that msbuild is comparing?

     If you mean the command line you type in the Pre-build event or Post-build event, we can open the project file and we can see the command line in the <PreBuildEvent> and <PostBuildEvent> .

    In addition, we can use /verbosity:level switch to display the build information in the build log. for exmaple, you can specify detailed verbosity like this:

    msbuild myproject.vcxproj /v:d

    Reference:

    MSBuild Command Line Reference:

    http://msdn.microsoft.com/en-us/library/ms164311.aspx

     

    Command-line arguments for MSBuild used by Visual Studio 2010

    http://social.msdn.microsoft.com/Forums/da-DK/msbuild/thread/4c40e8a5-05ef-4ceb-b7c9-d35736fc2bd0

     

    Best regards,

    Lucy


    Lucy Liu [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    • Marked as answer by lucy-liu Tuesday, September 6, 2011 3:24 AM
    • Unmarked as answer by djmitchella Tuesday, September 6, 2011 1:19 PM
    • Marked as answer by djmitchella Tuesday, September 6, 2011 1:29 PM
    Tuesday, August 30, 2011 7:41 AM

All replies

  • Hi djmitchella,

    If we use VS IDE to build this project, do we have the same issue?

    If this issue still exists, please try to create a new project, see whether this issue still exists? Sometimes corrupted project settings can cause problems. These are project specific.

    In addition, if you still cannot solve this issue, please provide some steps or sample code to reproduce this project, we will try our best to help solve this issue.

     

    Best regards,

    Lucy

     

     


    Lucy Liu [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Monday, August 29, 2011 9:43 AM
  • >If we use VS IDE to build this project, do we have the same issue?

     

     Yes, as I said, I'm only ever building from within VS2010, I'm not using devenv from the command line.

     

     No, I can't reproduce this in a standalone project -- and I can't easily give you the code that I'm using, because the projects it fails in are in a 109-project solution, and the project on which it fails most frequently has ~500 source/header files and about 1200 resource files -- this is why it's so annoying to have Visual Studio rebuild it unnecessarily, because it's a lot of time wasted. (and this is also why I don't want to try recreating the entire project file if I can avoid it).

     

     Actually, after booting up this morning, Visual Studio has decided that the command line has failed for 13 of those projects; I have no idea what's different between those ones and the other ones that it ignored, but it's said:

      All outputs are up-to-date.
      Forcing rebuild of all source files due to a change in the command line since the last build.

     fairly often. And, as I said, this can happen on a project midway through the day if VS is feeling sufficiently unhappy.

     

     Can you tell me how to see the command lines that msbuild is comparing? If this is a case-sensivitity issue like the other similar bug, then if I could see the command lines it's comparing, I could try and work out where it might be going wrong and make sure that case is definitely the same everywhere. Or does that message not actually relate to command lines at all? Or could it be failing because the command line is too long?

     

     -- dan

    Monday, August 29, 2011 2:16 PM
  • Hi djmitchella,

    >> Yes, as I said, I'm only ever building from within VS2010, I'm not using devenv from the command line.

    If you use VS IDE to build your project and then got this error. You can try the following solutions:

    1. If we reboot the operating system to safe mode, do we have the problem? This can help to isolate whether any other applications are interfering with Visual Studio. Note that some features (like IIS) are not available under safe mode. Please check whether this can apply or not. In addition to safe mode, we can also suggest “clean boot”: http://support.microsoft.com/kb/310353.

     

    2. If we create a new user account, do we have the problem? This can help to isolate user profile corruption related causes.

     

    3. If we disable Add-ins (e.g. “Tools” | “Add-in Manager”) and run “devenv.exe /safemode”, do we still have the problem? This can eliminate the possibility that third party Add-ins are causing problems.

     

    4. If we use “devenv.exe /resetsettings”, does it solve the problem? It restores Visual Studio default settings.

     

    5. If the problem remains, we can use Visual Studio Setup Wizard (via Control Panel) to repair Visual Studio. It can restore the Visual Studio Installation into its original state.

    >> Can you tell me how to see the command lines that msbuild is comparing?

     If you mean the command line you type in the Pre-build event or Post-build event, we can open the project file and we can see the command line in the <PreBuildEvent> and <PostBuildEvent> .

    In addition, we can use /verbosity:level switch to display the build information in the build log. for exmaple, you can specify detailed verbosity like this:

    msbuild myproject.vcxproj /v:d

    Reference:

    MSBuild Command Line Reference:

    http://msdn.microsoft.com/en-us/library/ms164311.aspx

     

    Command-line arguments for MSBuild used by Visual Studio 2010

    http://social.msdn.microsoft.com/Forums/da-DK/msbuild/thread/4c40e8a5-05ef-4ceb-b7c9-d35736fc2bd0

     

    Best regards,

    Lucy


    Lucy Liu [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    • Marked as answer by lucy-liu Tuesday, September 6, 2011 3:24 AM
    • Unmarked as answer by djmitchella Tuesday, September 6, 2011 1:19 PM
    • Marked as answer by djmitchella Tuesday, September 6, 2011 1:29 PM
    Tuesday, August 30, 2011 7:41 AM
  • Hi djmitchella,

    I believe the Command line in the log could be find at VC project Properties Page, Configuration Properties->C/C++ -> Command line. I noticed that MSBuild will stay alive after a build. Back ground build may optimize the project property. Compare the Command lines before and after you see the forcing build may reveal something.

    Best Regards,


    Forrest | MSDN Community Support | Feedback to us
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Thursday, September 1, 2011 9:29 AM
  • If you use VS IDE to build your project and then got this error. You can try the following solutions:  

    1. If we reboot the operating system to safe mode, do we have the problem? This can help to isolate whether any other applications are interfering with Visual Studio. Note that some features (like IIS) are not available under safe mode. Please check whether this can apply or not. In addition to safe mode, we can also suggest “clean boot”: http://support.microsoft.com/kb/310353.

     


     

    2. If we create a new user account, do we have the problem? This can help to isolate user profile corruption related causes.

     

    3. If we disable Add-ins (e.g. “Tools” | “Add-in Manager”) and run “devenv.exe /safemode”, do we still have the problem? This can eliminate the possibility that third party Add-ins are causing problems.

     

    4. If we use “devenv.exe /resetsettings”, does it solve the problem? It restores Visual Studio default settings.

     

    5. If the problem remains, we can use Visual Studio Setup Wizard (via Control Panel) to repair Visual Studio. It can restore the Visual Studio Installation into its original state.


    1: Which applications do you know can be problematic? I'm only running Outlook and the usual set of NT services; if you have any information about which ones in particular can clash, I can try those ones -- is Outlook known to cause problems? (if so, how on earth can it be doing that?)

    2: Nope, this happens for other developers working on the same solution file

    3: I have no addins running

    4: Which settings are likely to cause problems? Do I need to rebuild all my keyboard mappings, for instance? What about font settings? What about the stuff in Microsoft.Cpp.Win32.User -- do I have to stop using that?

    5: I'll give this a look if nothign else works, thanks.

     

    >If you mean the command line you type in the Pre-build event or Post-build event,

     No, I mean whatever it is that msbuild has decided has changed. I know how to see those settings, I know how to see the command line that the IDE reports it's using. What I want to know is, when msbuild says "Forcing build due to a change in the command line", what are the two command lines that msbuild are comparing when it's finding this change?

    >msbuild myproject.vcxproj /v:d

     Yes, I know this, that's how I got the "Forcing build due to a change in the command line" message in the logs. I'll turn it up to diagnostic level in case that's any more informative, I guess. Nope, all it says there is:

      Forcing rebuild of all source files due to a change in the command line since the last build. (TaskId:81)

     

     as usual. The various .tlog files contain the command line exactly as I'd expected, and it isn't changing, so I guess this is just a bug that I'll have to live with -- I was hoping for something in the logs saying "comparing command lines: .... -vs- ...." so I could look for differences, but that information doesn't appear to be available. Is it possible that the command line is somehow too long and that's the problem? The typical "cl" line is ~1,900 characters; could that be the issue?

    Tuesday, September 6, 2011 1:56 PM
  • Hi Lucy,

    I'm having a very similiar issue my solution but it occurs during the linking phase.  I can build repeatedly several times in VS2010 and nothing happens as expected since nothing has changed.  As soon as I try to build using msbuild, some of my projects relink.  It's always the same projects that relink each time.  This solution has several projects which are multi-targeted - Win32 and x64. There is a strange pattern though - it only happens when I have selected Win32.  It works as expected with x64.

    I've logged the output from msbuild and examined it.  Similiar to djmitchella I found "Forcing rebuild of all source files due to a change in the command line since the last build." just before linking occurs.  I'm also trying to determine what has changed in the 'command line'.  Can you provide more detailed information on how the 'change' is detected?

    Also, one other observation - each time I re-run msbuild, I find that I get 8 new tlog files in the intermediate build directory only for my Win32 build.  The file count never changes in the x64 build.

    Gary

    Monday, November 7, 2011 4:33 PM
  • We had this same problem in VS2012. It tuned out the issue was that we had "/MP" listed under "Additional Options" in the project properties, but had also selected "Multi-processor Compilation: Yes (/MP)". VS must remove duplicate command-line options at some point in the process, but it apparently does the comparison to the previous command line before that.

    Our 2010 version of the project had /MP duplicated too, but it didn't cause this problem there.

    Thursday, April 18, 2013 12:17 PM
  • I had a very similar problem, with a slight difference though (but I thank you, dlafleur, as you gave me the track to follow in order to work around this issue!):

    In "Additional Options", not only I had /MP listed but also %(AdditionalOptions)

    Removing only /MP from "Additional Options" was not enough for build to behave correctly. The slight difference is I had to remove also the statement %(AdditionalOptions)

    Seems like there is a bug in the logic leading to the conclusions reported in the log message ""Forcing rebuild of all source files due to a change in the command line since the last build.", and this bug is triggered when Additional Options is filled in.

     

    Thursday, May 30, 2013 10:03 AM
  • Including %(AdditionalOptions) in the additional options field seems like it would create infinite recursion. The code must be smart enough to prevent that, but it probably does recurse at least once, which is enough to duplicate whatever options are inherited from the project defaults, which probably does trigger the same bug.

    After my last post I filed a bug report with Microsoft about this, and they accepted it:

    http://connect.microsoft.com/VisualStudio/feedback/details/785786/duplicating-mp-option-forces-rebuild-every-time

    Sounds like your case might be worth adding to the description?

    Thursday, May 30, 2013 12:16 PM
  • I was experiencing this problem and this was exactly what was going on.  At some point someone added the /MP as a manual command-line switch (it was unsupported back in the VS2005 days) and now that it is officially supported by the options, it was listed twice causing a rebuild every time.
    Monday, December 9, 2013 8:40 PM