none
Visual C++ 2010 Build question/issue

    Question

  • Hello,

    We have 2008 project (native library) that was converted to 2010. It builds fine. It even links fine. The problem is that it thinks something (we're not sure what) needs to be executed again for the build. Possibly a dependency somewhere? We've scanned the project file and it looks fine.

    So instead of seeing this:

    ========== Build: 0 succeeded, 0 failed, 1 up-to-date, 0 skipped ==========

    We keep seeing this:

    1>------ Build started: Project: cop, Configuration: Debug Win32 ------

    1> cop.vcxproj -> C:\projects\cop\cop.lib

    ========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

    Note: This above does NOT relink or recompile anything in the library.

    This looks benign but it causes other projects that depend on this to be rebuilt everytime which isn't correct.

    Let us know if there's something we're missing that we need to check.

    Thanks,

    Ted

     

     

    Monday, May 03, 2010 2:21 AM

All replies

  • Make sure all files in the folder are writtable.

     


    «_Superman_»
    Microsoft MVP (Visual C++)
    Monday, May 03, 2010 4:01 AM
  • Everything in the intermediate directory is writeable and the target directory is writeable as well.

    Any other suggestions?

    Thanks,

    Ted

    Monday, May 03, 2010 4:40 AM
  • You could try creating a new solution in VS2010 and add all files to it, if that is possible.

     


    «_Superman_»
    Microsoft MVP (Visual C++)
    Monday, May 03, 2010 4:42 AM
  • One more odd thing is the log file output (cop.log) looks good:

     

       1>InitializeBuildStatus:
         Creating "Debug\cop.unsuccessfulbuild" because "AlwaysCreate" was specified.
        ClCompile:
         All outputs are up-to-date.
         All outputs are up-to-date.
        Lib:
         All outputs are up-to-date.
         cop.vcxproj -> C:\projects\cop\cop.lib
    
    Monday, May 03, 2010 4:57 AM
  • Not really an option - too many files etc.

    Are there any options to increase the amount of information in the log file?

    Thanks,

    Ted

    Monday, May 03, 2010 5:11 AM
  • Tools -> Options -> Projects and Solutions -> Build and Run -> MSBuild project build log file verbosity
    Monday, May 03, 2010 5:14 AM
  • It's now verbose but we don't see anything or can't tell what it's finding. It does determine that the library is current. Doesn't explain why i thinks something else is not up-to-date and what that is.

    Since VC++ is now using msbuild, is there an msbuild forum? Maybe those folks can tell what's going on.

    Thanks,

    Ted

    Monday, May 03, 2010 3:28 PM
  • Okay, this appears to be an issue with msbuild. We're not sure if it's a bug or not - based on looking at the microsoft connect web site. But here was one relevant comment. We found this comment by searching for MSB8012 based on the conversion warning we received when it automatically upgraded the library project file:

    Hi Bob,

    About the original bug the warning is generated because in Visual Studio 2010 we have moved the C++ build system to be based on MSBuild. In earlier versions of Visual Studio when you changed the output file property the "TargetName" "TargetExt" properties were changed in background by the product itself. In this release we dont have that functionality and we have now become more transparent and warn the user to make sure that the output file property does match with the "OutDir" "TargetName" and "TargetExt" properties.

    Your can change %(lib.outputfile) by going to project properties "Configuration Properties->Librarian->Output File".

    Regarding your response copying final linked output should be achievable with VS2010. I think it might be a sideeffect of the warning that are getting generated during build.

    Can you verify that is the case?

    Thanks,
    Amit Mohindra

    Visual C++ Team

    --------------

    A couple other folks on the microsoft connect complained that this is a bug in vs2010 etc.

    We're not sure the above comment will fix the above but we're looking at it to see.

    Thanks,

    Ted

     

    Monday, May 03, 2010 4:37 PM
  • The torture-fest is over....

    In the Header File filter in the project was a non-existent header file (there were 200+ existing ones). We're not sure what MS Build was thinking but it did two things wrong in our opinion:

    1. If a file in a dependency list doesn't exist, how about telling the user? Even with diagnostic output on, MS build does not output anything about the missing file.

    2. If a file doesn't exist in the dependent list, we don't consider that a "Build Succeeded" either. Which makes you wonder what the Header File filter is for now since the dependencies are grabbed automatically anyways?

    Since we're not into finding needles in haystacks, we're just going to remove the Header File filter. That fixed four other converted projects with the same issue.

    Hopefully this will help any users the bump into this...feel free to file a bug on MS Build for this...we're too lazy...

    Thanks,

    Ted

    Monday, May 03, 2010 11:09 PM
  • Hello Ted,

    Based on my understanding, MSBuild build engine itself does not handle the dependenct list. The engine only pass the input file and any other option to the compiler or other tool set to finish the build job, the build engine will gather the output of the compiler or other tool set and display it in the Output Window. If the compiler or the tool set doesn't handle this, most likely MSBuild will not handle this.

    You can submit this as a feature request on out connect website:

    https://connect.microsoft.com/VisualStudio

    Regards,
    Rong-Chun Zhang
    MSDN Subscriber Supportin Forum
    If you have any feedback on our support, please contact msdnmg@microsoft.com


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Wednesday, May 05, 2010 11:38 AM
  • If you run into up to date issue in VS2001, you may want to take a look of this blog http://blogs.msdn.com/vcblog/archive/2010/03/02/visual-studio-2010-c-project-upgrade-guide.aspx. This is a section on how to diagnose the problem.

     

    Up to date check change

    When you hit F5, you may run into the situation that Up to check dialog always coming up even after a fresh rebuild. You can refer to this blog to troubleshoot the problem. Most likely, the issue is caused by the fact that some files are listed as part of the project files but are missing on the disk. Because these files are part of the project files, the new up to date check mechanism will check for their existence. If the files are not on the disk, the up to date check will assume that a new build is needed. The fix is to remove the files from the project files if they are not on the disk.

    Li Shao, MSFT 


    Li Shao
    Wednesday, May 05, 2010 4:51 PM
  • Hi Li,

    Yes, that explains it.

    But.....

    Where do you tell us which file(s) are missing?

    Let's take a real world example: Our customer has a project file with 2000+ souce files in it. We converted it and now it exhibits the (bad) behavior we're talking about because of the change in 2010. How do we find the files?

    Please help!

    Thanks,

    Ted

    Wednesday, May 05, 2010 5:11 PM
  • First, I meant to say VS2010 instead of VS2001... :-)

    In the blog, thers is a link to another blog: http://blogs.msdn.com/vsproject/archive/2009/07/21/enable-c-project-system-logging.aspx which provides a tool to help with the analysis.

    Li Shao, MSFT


    Li Shao
    Wednesday, May 05, 2010 5:20 PM
  • First, I meant to say VS2010 instead of VS2001... :-)

    Thank God for that.

    You got me worried there. :)

     


    «_Superman_»
    Microsoft MVP (Visual C++)
    Wednesday, May 05, 2010 5:29 PM
  • Hi Li,

    We're running a native C project (no .NET). Will this still work? Looks like it's for .NET only?

    Thanks,

    Ted

    Wednesday, May 05, 2010 5:39 PM
  • Yes, it is VS2010 :-).

    Ted, this tool should work on native C project as long as you have .net framework installed on the machine. It may need .net framework to run the tool.

    Li Shao, MSFT


    Li Shao
    Wednesday, May 05, 2010 5:56 PM
  • Hello Ted,

    Have you got any progress on this issue?

    Regards,
    Rong-Chun Zhang
    MSDN Subscriber Supportin Forum
    If you have any feedback on our support, please contact msdnmg@microsoft.com


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Monday, May 10, 2010 10:18 AM
  • Yes, so as it stands:

    Visual C++ 2010 changes the output behavior to Build Succeed (instead of Up-to-Date) if a file is missing from the dependency (we think this is a bug - MS doesn't - interesting to see what the other users think)

    Visual C++ 2010 has a tool which allows you to view which file(s) are missing from a project. Following the steps from this blog:

    First, I meant to say VS2010 instead of VS2001... :-)

    In the blog, thers is a link to another blog: http://blogs.msdn.com/vsproject/archive/2009/07/21/enable-c-project-system-logging.aspx which provides a tool to help with the analysis.

    Li Shao, MSFT

    We were able to find the missing files using this. It's tedious but better than finding a needle in a haystack. In our opinion, the build output should be set to failed and message with the path of the missing file dependency should be displayed.

    Thanks,

    Ted

    Monday, May 10, 2010 3:50 PM
  • Hi Ted,

    We have a bug to track the issue of output the information in output window and/or build log. Hopefully this issue will be fixed for furture releases.

    Li Shao, MSFT


    Li Shao
    Monday, May 10, 2010 7:02 PM
  • Hi Ted,

    We have a bug to track the issue of output the information in output window and/or build log. Hopefully this issue will be fixed for furture releases.

    Li Shao, MSFT


    Li Shao

    Link?
    Wednesday, August 18, 2010 4:54 PM
  • 1. I have a VS2010 solution with about 19 projects in it, each building a static library.

    2. I created a new static library project and in the "Librarian->Additional dependencies" inserted the .lib names of the other 50 static libraries ( to make one big static library of the whole thing )

    3. I copy the "command line" into a "command prompt" : lib.exe <copied command line from VS2010> and enter - the new big .lib file is correctly created. It works just fine and takes about 15 seconds.

    4. In VS2010 "Solution Explorer" I right-mouse click on the new project and select "build". In less than an eye-blink the output window displays success (nothing actually happened) and the log file has stuff in it about "AlwaysCreate" and unsuccessful build.

    What should I do?

    : Library, Configuration: Debug Win32 ------

    ========== Build: 1 succeeded, 0 failed, 23 up-to-date, 0 skipped ==========

     

    Build started 9/18/2010 10:54:30 AM.
         1>Project "D:\Bob\cvs\build\lib\Library\Library.vcxproj" on node 2 (build target(s)).
         1>InitializeBuildStatus:
             Creating "Debug\Library.unsuccessfulbuild" because "AlwaysCreate" was specified.
           FinalizeBuildStatus:
             Deleting file "Debug\Library.unsuccessfulbuild".
             Touching "Debug\Library.lastbuildstate".
         1>Done Building Project "D:\Bob\cvs\build\lib\Library\Library.vcxproj" (build target(s)).

    Build succeeded.

    Time Elapsed 00:00:00.05

     

    Saturday, September 18, 2010 6:07 PM
  • If it's not a non-existent header file in the project(s), then I would look at the intermediate directory of the project(s). We've seen cases where everything looks good but the intermediate directory isn't to vs2010's liking and it does the same thing. If you're still stuck then you can use the logging tool described above. That did help us.

    This whole concept of dependency errors etc. causing a "Build succeeded" doesn't really make sense to us and they should just display an error message telling you what's wrong.

    Hope this helps,

    Ted

    Saturday, September 18, 2010 7:40 PM
  • The only purpose for the new project is to collect all the .lib's from the other 19 static library projects. The project was made by VS2010 (Add->New Project ...) so the folder and it's meager contents are all created by VS2010. It has 0 header files, 0 source files, 0 extern files. The only thing added is the list of .lib's to the Additional dependencies as I said above.

    So I tried the "DebugView" as described above to get logging info, and this is the result.  Nothing visible is related to anything of mine. 

    Any further thoughts? Maybe VS2010 doesn't allow an empty project that only runs lib to coelasce a bunch of individual lib's.

    BTW, For decades Unix has followed the principle that if the command succeeded don't print anything. If the command fails, print an error. A policy that has been effective for decades. Printing success!! on failure sure doesn't follow that principle and would be a bug in the unix world. I know some would like confirmation that their command succeeded, but when all commands strictly adhere to the policy, and when the user realizes this, a great benefit of reduced clutter in the output window is recognized.

    When "MyProject->Project only->Rebuild only MyProject" DebugView shows this: 

    [5512] devenv.exe Information: 0 :
    [5512] Resolving service 'Microsoft.VisualStudio.Shell.Interop.SVsShell' through the service provider System.__ComObject.
    [5512] devenv.exe Warning: 0 :
    [5512] Attempting to get tool for file of type '', resulted in rule name of '', and no tool provider responded. Going with Custom Build Tool
    [5512] devenv.exe Warning: 0 :
    [5512] Attempting to get tool for file of type 'None', resulted in rule name of '', and no tool provider responded. Going with Custom Build Tool
    [5512] devenv.exe Information: 0 :
    [5512] IVCConfigurationImpl.StartBuild called.  This should mean the Solution Build Manager has started a build already.
    [5512] devenv.exe Information: 0 :
    [5512] VCConfigBuildJob.Start called.
    [5512] devenv.exe Information: 0 :
    [5512] Entering BuildProjectBase.StartAsyncBuild.
    [5512] devenv.exe Information: 0 :
    [5512] Resolving service 'Microsoft.VisualStudio.Shell.Interop.SVsBuildManagerAccessor' through the service provider System.__ComObject.
    [5512] devenv.exe Information: 0 :
    [5512] BuildProjectBase.BeforePendBuildRequest: SolutionBuildManagerIsPresent == True, designTimeBuild == False
    [5512] devenv.exe Information: 0 :
    [5512] Resolving service 'Microsoft.VisualStudio.Shell.Interop.SVsBuildManagerAccessor' through the service provider System.__ComObject.
    [5512] devenv.exe Information: 0 :
    [5512] Resolving service 'Microsoft.VisualStudio.Shell.Interop.SVsBuildManagerAccessor' through the service provider System.__ComObject.
    [5512] devenv.exe Information: 0 :
    [5512] Resolving service 'Microsoft.VisualStudio.Shell.Interop.SVsBuildManagerAccessor' through the service provider System.__ComObject.
    [5512] devenv.exe Information: 0 :
    [5512] BuildProjectBase.StartAsyncBuild pending build request for targets: rebuild, ...
    [5512] devenv.exe Information: 0 :
    [5512] BuildProjectBase.AfterPendBuildRequest called.
    [5512] devenv.exe Information: 0 :
    [5512] Resolving service 'Microsoft.VisualStudio.Shell.Interop.SVsBuildManagerAccessor' through the service provider System.__ComObject.
    [5512] devenv.exe Information: 0 :
    [5512] BuildProjectBase.AfterPendBuildRequest: registering loggers with mux logger
    [5512] devenv.exe Information: 0 :
    [5512] Resolving service 'Microsoft.VisualStudio.Shell.Interop.SVsBuildManagerAccessor' through the service provider System.__ComObject.
    [5512] devenv.exe Information: 0 :
    [5512] Resolving service 'Microsoft.VisualStudio.Shell.Interop.SVsBuildManagerAccessor' through the service provider System.__ComObject.
    [5512]
    [5512] *** HR originated: -2147024774
    [5512] ***   Source File: d:\iso_whid\x86fre\base\isolation\com\copyout.cpp, line 1302
    [5512]
    [5512]
    [5512] *** HR propagated: -2147024774
    [5512] ***   Source File: d:\iso_whid\x86fre\base\isolation\com\enumidentityattribute.cpp, line 144
    [5512]
    [5512]
    [5512] *** HR originated: -2147024774
    [5512] ***   Source File: d:\iso_whid\x86fre\base\isolation\com\copyout.cpp, line 1302
    [5512]
    [5512]
    [5512] *** HR propagated: -2147024774
    [5512] ***   Source File: d:\iso_whid\x86fre\base\isolation\com\enumidentityattribute.cpp, line 144
    [5512]
    [5512] devenv.exe Information: 0 :
    [5512] BuildProjectBase+BuildCompletedCallbackManager.BuildCompleted about to call TryFlush on all loggers (thread 11).
    [5512] devenv.exe Information: 0 :
    [5512] All loggers report clear (thread 11).
    [5512] devenv.exe Information: 0 :
    [5512] BuildProjectBase+BuildCompletedCallbackManager.BuildCompleted invoking BuildProjectBase's client callback.
    [5512] devenv.exe Information: 0 :
    [5512] VCConfigBuildJob.BuildCompleted called.
    [5512] devenv.exe Information: 0 :
    [5512] Resolving service 'Microsoft.VisualStudio.Shell.Interop.SVsBuildManagerAccessor' through the service provider System.__ComObject.
    [5512] devenv.exe Information: 0 :
    [5512] BuildProjectBase.EndBuildInsideOrOutsideVisualStudio: SolutionBuildManagerIsPresent == True, oneOffBuild == False
    [5512] devenv.exe Information: 0 :
    [5512] Resolving service 'Microsoft.VisualStudio.Shell.Interop.SVsBuildManagerAccessor' through the service provider System.__ComObject.
    [5512] devenv.exe Information: 0 :
    [5512] Resolving service 'Microsoft.VisualStudio.Shell.Interop.SVsBuildManagerAccessor' through the service provider System.__ComObject.
    [5512] devenv.exe Information: 0 :
    [5512] VCConfigBuildJob.RemoveJob called.

    Sunday, September 19, 2010 1:14 AM
  • I'm having a similar problem: two of my projects are always considered "out of date" (although they haven't been modified) and the output window states that "AlwaysCreate" was specified. I switched on system logging and found the following lines within the log:

     

    [4884] up to date is missing: '[...]\Debug\DVApp.dll'
    
    [4884] up to date is missing: '[...]\someplace\DEBUG\SPACCESS.DLL'
    [4884] up to date is missing: '[...]\someplace\Debug\SpAccess.lib' 

    These are output files that used to be created by previous versions of my solution. "DVApp" has been a DLL but now it's a static lib. "SpAccess" used to be built in "someplace" but now it's being bult elsewehere. Obviously the projects still expect these files to be present where they used to be although this is obsolete. After I created empty dummy files at the given locations the problem vanished.

    I found no means of correcting this in the projects' property pages. I opened the .vcxproj files in notepad but couldn't find the corresponding setting there.

    Regards,
    hgx

    Monday, November 22, 2010 10:50 AM
  • I've had the same problem, and following the devenv.exe.config steps and using the DebugView tool got me past it.  It was an obsolete header reference in one of my folders (and like Ted, I have lots of files and the needle-in-the-haystack problem.)

    The VS team at Microsoft really ought to get this information in the Output window!  It's silly for MSBuild to know this information, but keep it secret from the typical user.

     

    Wednesday, January 26, 2011 4:43 PM
  • Wonderful! Thanks a lot Li Shao, this solved at least my ever annoying problem.

    - Charan

    Friday, April 29, 2011 11:48 PM
  • Actually my problem was that I had a header file from DDK, which was included in Resources just as a reference, and I was not using it to build my project. And when I copied the project to other machine which did not have DDK installed, I used to get this error. So I right clicked that file in Solution Explorer and in I set its Item Type as "Does not participate in build". And wow! the problem solved.

    But thanks again, It was annoying me a lot before.

    - Charan

    Friday, April 29, 2011 11:58 PM
  • This thread has gone far from the original question, but was so helpful to me that I would like to add to it. I ran into this problem thrice.

     

    The first time it was because we had a weird character or blank line in a custom build step.

    The second time it was because we had header files listed in our project that didn't exist. (There is some C# code on the internet I can't seem to locate right now that can help you find things like this).

    The third time it was system specific and was because of something (??) wrong with my intermediate directory, deleting the intermediate directory resolved the issue.

     

    I hope this helps someone,

     

    Mark MacVicar

    Wednesday, July 27, 2011 6:23 PM
  • Ok, I understood. Now that you're  seeing:

    

    What shall we put instead of "$(OutDir)$(TargetName)$(TargetExt)"? 

    Wednesday, October 17, 2012 8:55 PM
  • I also want to add to this thread as I found it very useful to me, but found yet another way to get this to happen not yet documented here.

    In my case, all of my .c and .h files in my project existed, but I had a stray project property pointing to a file that didn't exist.

    I had set up my project to build the browse information, but under "Configuration Properties->Browse Information->General" I set the "Output File" to $(IntDir)$(TargetName).sbr

    Unfortunately, the .sbr extension is meant for the per-compile unit browse information and not the final file.  So the build process went looking for this $(TargetName).sbr file and could not find it so decided to perform the build.  Changing this "Output File" property to be $(IntDir)$(TargetName).bsc solved this problem (.bsc is the proper extension for this filename).

    Monday, October 22, 2012 6:25 PM