首页 文章

Visual Studio 2010始终认为项目已过时,但一切都没有改变

提问于
浏览
188

我有一个非常类似的问题,如here所述 .

我还将C / CLI和C#项目的混合解决方案从Visual Studio 2008升级到Visual Studio 2010.现在,在Visual Studio 2010中,一个C / CLI项目总是会过时 .

即使它刚刚被编译和链接并且F5被击中,也会出现消息框"The project is out of date. Would you like to build it?" . 这非常烦人,因为DLL文件非常低层,并且迫使解决方案的几乎所有项目都重建 .

我的pdb设置被设置为默认值(suggested solution of this problem) .

是否有可能获得Visual Studio 2010强制重建或认为项目是最新的原因?

任何其他想法为什么Visual Studio 2010表现如此?

27 回答

  • 3

    我没有't know if anyone else has this same problem, but my project'的属性将 "Configuration Properties" -> C/C++ -> "Debug Information Format" 设置为"None",当我将其切换回默认的"Program Database (/Zi)"时,每次都停止重新编译项目 .

  • 3

    无论如何,.NET项目总是被重新编译 . 部分原因是为了使IDE保持最新(例如IntelliSense) . 我记得几年前在微软论坛上提出这个问题,这就是我给出的答案 .

  • 221

    我花了很多时间把头发撕掉了 . 构建输出不一致;从一个构建到下一个连续构建,不同的项目将是"not up to date" . 我最终发现罪魁祸首是 DropBox (3.0.4) . 我将我的源文件夹从... \ DropBox连接到我的项目文件夹(不确定这是否是原因),但DropBox在构建期间以某种方式"touches"文件 . 暂停同步,一切都是最新的 .

  • 2

    大多数构建系统使用数据时间戳来确定何时应该进行重建 - 根据依赖项的上次修改时间检查任何输出文件的日期/时间戳 - 如果任何依赖项更新,则重建目标 .

    如果任何依赖项以某种方式获得无效的数据时间戳,这可能会导致问题,因为任何构建输出的时间戳都难以超过所谓的将来创建的文件的时间戳:P

  • 6

    我从解决方案(和磁盘)中删除了一个cpp和一些头文件,但仍然有问题 .

    事实上,编译器使用的每个文件都位于临时目录的* .tlog文件中 . 删除文件时,不会更新此* .tlog文件 . 这是增量构建使用的文件,用于检查您的项目是否是最新的 .

    手动编辑此.tlog文件或清理项目并重建 .

  • 6

    我在Visual Studio 2005中遇到了类似的问题,我的解决方案包含以下依赖项中的五个项目(首先构建在顶部):

    Video_Codec depends on nothing
    Generic_Graphics depends on Video_Codec
    SpecificAPI_Graphics depends on Generic_Graphics
    Engine depends on Specific_Graphics
    Application depends on Engine.
    

    我发现即使在完全清理然后重建解决方案之后,Video_Codec项目也需要完整的构建 .

    我通过确保C / C和链接器的 pdb 输出文件与其他工作项目使用的位置匹配来解决此问题 . 我也开启了RTTI .

  • 7

    在我的情况下,其中一个项目包含多个IDL文件 . 无论IDL文件名如何,MIDL编译器都会为每个文件生成一个名为“dlldata.c”的DLL数据文件 . 这导致Visual Studio在每次构建时编译IDL文件,即使不更改任何IDL文件也是如此 .

    解决方法是为每个IDL文件配置一个唯一的输出文件(MIDL编译器总是生成这样的文件,即使省略了/ dlldata开关):

    • 右键单击IDL文件

    • 选择属性 - MIDL - 输出

    • 输入DllData File属性的唯一文件名

  • 1

    对我来说,问题出现在一个WPF项目中,其中一些文件的“Build Action”属性设置为“Resource”,而“Copy to Output Directory”设置为“Copy if newer” . 解决方案似乎是将“复制到输出目录”属性更改为“不复制” .

    msbuild知道不将'Resource'文件复制到输出中 - 但如果它们不在那里仍会触发构建 . 也许这可以被视为一个错误?

    这里的答案非常有帮助,暗示如何让msbuild将bean放在为什么一直在构建所有东西!

  • 1

    另一个在Visual Studio 2015 SP3上,但几年前我在Visual Studio 2013上遇到过类似的问题 .

    我的问题是,某个错误的cpp文件被用于预编译头文件(因此我有两个cpp文件创建了预编译头文件) . 现在为什么Visual Studio将错误的cpp上的标志更改为'创建预编译的标头'而没有我的请求我没有任何线索,但确实发生了......也许是一些插件或者什么?

    无论如何,错误的cpp文件包含version.h文件,该文件在每次构建时都会更改 . 因此Visual Studio重建所有 Headers ,因此整个项目 .

    好吧,现在它恢复了正常的行为 .

  • 4

    我在VS2013(更新5)中遇到了这个问题,可以有两个原因,你可以通过在“工具” - >“项目和解决方案” - >“构建和运行”下启用“详细”构建输出来找到这两个原因 .

  • 59

    今天发生在我身上 . 我能够找到原因:该项目包含一个磁盘上不再存在的头文件 .

    从项目中删除文件解决了问题 .

  • 2

    我正在使用Visual Studio 2013 Professional和Update 4,但没有找到任何其他建议的解决方案,但是,我确实设法解决了我的团队项目的问题 .

    以下是我为解决问题所做的工作 -

    • 创建了一个新的类对象(Project - > Add Class)

    • 通过解决方案资源管理器重命名该文件,并在询问我是否要自动重命名所有引用以匹配时单击是

    以下是我为解决问题所做的工作 -

    • 转到团队资源管理器主页

    • 单击“源代码管理资源管理器”

    • 钻入所有类/项目文件所在的文件夹

    • 在列表中找到ORIGINAL文件名并通过右键单击将其删除

    • Build

    如果是这种情况,那么只需要确保删除幻像文件而不是要保留在项目中的实际文件 .

  • 1

    我有一个类似的问题,但在我的情况下没有文件丢失,pdb输出文件的定义方式有错误:我忘了后缀.pdb(我发现了调试日志技巧) .

    要解决我在vxproj文件中更改的问题,请执行以下操作:

    <ProgramDataBaseFileName>MyName</ProgramDataBaseFileName>
    

    <ProgramDataBaseFileName>MyName.pdb</ProgramDataBaseFileName>
    
  • 0

    仅适用于Visual Studio / Express 2010 . 查看VS2012,VS2013等的其他(更简单)答案

    要查找the missing file(s),请使用文章Enable C++ project system logging中的信息在Visual Studio中启用调试日志记录,并让它告诉您导致重建的原因:

    • 打开 devenv.exe.config 文件(位于 %ProgramFiles%\Microsoft Visual Studio 10.0\Common7\IDE\%ProgramFiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\ 中) . 对于Express版本,配置文件名为 V*Express.exe.config .

    • </configSections> 行之后添加以下内容:

    <system.diagnostics>
      <switches>
        <add name="CPS" value="4" />
      </switches>
    </system.diagnostics>
    
    • 重新启动Visual Studio

    • 打开DbgView并确保它捕获调试输出

    • 尝试调试(在Visual Studio中点击F5)

    • 在调试日志中搜索表单的任何行:

    devenv.exe信息:0:项目'Bla \ Bla \ Dummy.vcxproj'不是最新的,因为缺少构建输入'Bla \ Bla \ SomeFile.h' .

    (我只是按下Ctrl F并搜索 not up to date )这些将是导致项目永久"out of date"的引用 .

    要更正此问题,请从项目中删除对缺少文件的任何引用,或更新引用以指示其实际位置 .

    注意:如果使用2012或更高版本,则代码段应为:

    <system.diagnostics>
      <switches>
       <add name="CPS" value="Verbose" />
      </switches>
    </system.diagnostics>
    
  • 1

    我们也遇到了这个问题,并找到了如何解决它 .

    问题如上所述“磁盘上不再存在该文件” .

    这不太正确 . 该文件确实存在于磁盘上,但.VCPROJ文件正在其他位置引用该文件 .

    您可以通过转到“包含文件视图”并依次单击每个包含文件来“发现”这一点,直到找到Visual Studio找不到的文件 . 然后添加该文件(作为现有项)并删除无法找到的引用,一切正常 .

    一个有效的问题是:如果Visual Studio不知道包含文件的位置,它如何构建?

    我们认为.vcproj文件在Visual Studio GUI中没有显示某个有问题的文件的相对路径,这解释了即使包含的树视图不正确,项目实际构建的原因 .

  • 164

    接受的答案帮助我找到了解决这个问题的正确途径,因为我必须开始合作 . 但是,我不得不处理大量错误的包含标头 . 使用详细的调试输出,删除一个导致IDE冻结30秒,同时输出调试spew,这使得进程非常缓慢 .

    我不耐烦了,写了一个快速而肮脏的Python脚本来检查(Visual Studio 2010)项目文件,并一次输出所有丢失的文件,以及它们所在的过滤器 . 你可以找到它请点击这里:https://gist.github.com/antiuniverse/3825678(或者这个fork that supports relative paths

    例:

    D:\...> check_inc.py sdk/src/game/client/swarm_sdk_client.vcxproj
    [Header Files]:
      fx_cs_blood.h   (cstrike\fx_cs_blood.h)
      hud_radar.h   (cstrike\hud_radar.h)
    [Game Shared Header Files]:
      basecsgrenade_projectile.h   (..\shared\cstrike\basecsgrenade_projectile.h)
      fx_cs_shared.h   (..\shared\cstrike\fx_cs_shared.h)
      weapon_flashbang.h   (..\shared\cstrike\weapon_flashbang.h)
      weapon_hegrenade.h   (..\shared\cstrike\weapon_hegrenade.h)
      weapon_ifmsteadycam.h   (..\shared\weapon_ifmsteadycam.h)
    [Source Files\Swarm\GameUI - Embedded\Base GameUI\Headers]:
      basepaenl.h   (swarm\gameui\basepaenl.h)
      ...
    

    源代码:

    #!/c/Python32/python.exe
    import sys
    import os
    import os.path
    import xml.etree.ElementTree as ET
    
    ns = '{http://schemas.microsoft.com/developer/msbuild/2003}'
    
    #Works with relative path also
    projectFileName = sys.argv[1]
    
    if not os.path.isabs(projectFileName):
       projectFileName = os.path.join(os.getcwd(), projectFileName)
    
    filterTree = ET.parse(projectFileName+".filters")
    filterRoot = filterTree.getroot()
    filterDict = dict()
    missingDict = dict()
    
    for inc in filterRoot.iter(ns+'ClInclude'):
        incFileRel = inc.get('Include')
        incFilter = inc.find(ns+'Filter')
        if incFileRel != None and incFilter != None:
            filterDict[incFileRel] = incFilter.text
            if incFilter.text not in missingDict:
                missingDict[incFilter.text] = []
    
    projTree = ET.parse(projectFileName)
    projRoot = projTree.getroot()
    
    for inc in projRoot.iter(ns+'ClInclude'):
        incFileRel = inc.get('Include')
        if incFileRel != None:
            incFile = os.path.abspath(os.path.join(os.path.dirname(projectFileName), incFileRel))
            if not os.path.exists(incFile):
                missingDict[filterDict[incFileRel]].append(incFileRel)
    
    for (missingGroup, missingList) in missingDict.items():
        if len(missingList) > 0:
            print("["+missingGroup+"]:")
            for missing in missingList:
                print("  " + os.path.basename(missing) + "   (" + missing + ")")
    
  • 15

    如果您使用的是命令行MSBuild命令(而不是Visual Studio IDE),例如,如果您要定位AppVeyor或者只是更喜欢命令行,则可以将此选项添加到MSBuild命令行:

    /fileLoggerParameters:LogFile=MyLog.log;Append;Verbosity=diagnostic;Encoding=UTF-8
    

    正如文件here(警告:通常的MSDN详细程度) . 构建完成后,在构建期间创建的日志文件中搜索字符串 will be compiledMyLog.log .

  • 12

    我有这个问题,发现了这个:

    http://curlybrace.blogspot.com/2005/11/visual-c-project-continually-out-of.html

    Visual C Project不断过时(winwlm.h macwin32.h rpcerr.h macname1.h缺失)问题:在Visual C .Net 2003中,我的一个项目总是声称已经过时了,即使没有任何改变,并且在上一次构建中没有报告任何错误 . 打开相应项目的BuildLog.htm文件显示了这些文件的PRJ0041错误列表,其中没有一个出现在我的系统上:winwlm.h macwin32.h rpcerr.h macname1.h每个错误都是这样的:MyApplication:警告PRJ0041:找不到文件'MyApplication.rc'缺少的依赖'macwin32.h' .
    您的项目可能仍在构建,但在找到此文件之前可能会继续显示过期 . 解决方案:在项目的.rc文件中包含afxres.h而不是resource.h . 项目的.rc文件包含“#include resource.h” . 由于资源编译器不支持预处理器#ifdef块,它将撕裂并尝试查找它应该忽略的包含文件 . Windows.h包含许多这样的块 . 包括afxres.h而不是修复PRJ0041警告并消除“项目已过期”错误对话框 .

  • 4

    Visual Studio 2013 - “由于缺少PDB而强制重新编译所有源文件” . 我打开详细的构建输出来找到问题:我在“工具”→“项目和解决方案”→“构建和运行”下启用了“详细”构建输出 .

    我有几个项目,所有C,我在项目设置下设置选项:( C / C→调试信息格式)到问题项目的程序数据库(/ Zi) . 但是,这并没有阻止该项目的问题 . 问题来自解决方案中的其他C项目之一 .

    我将所有C项目设置为"Program Database (/Zi)" . 这解决了这个问题 .

    同样,报告问题的项目不是问题项目 . 尝试将所有项目设置为“程序数据库(/ Zi)”以解决问题 .

  • 3

    如果更改项目的Debugging Command参数,这也将触发项目需要重建的消息 . 即使目标本身不受Debugging参数的影响,项目属性也已更改 . 如果你重建,消息应该消失 .

  • 0

    在Visual Studio 2012中,我能够比在公认的解决方案中更容易地实现相同的结果 .

    我更改了菜单工具→选项→项目和解决方案→构建和运行→* MSBuild项目构建输出详细程度“中的选项”从Minimal到Diagnostic .

    然后在构建输出中,我通过搜索“不是最新的”找到了相同的行:

    项目'blabla'不是最新的 . 项目项'c:\ foo \ bar.xml'将'复制到输出目录'属性设置为'始终复制' .

  • 0

    对我来说,项目中“Header Files”上存在一个不存在的头文件 . 删除此条目(右键单击>从项目中排除)后,首次重新编译,然后直接重新编译

    ==========构建:0成功,0失败,5最新,0跳过==========

    并没有做任何未经修改的重建尝试 . 我认为是VS2010实现的check-before-build(不确定是否记录,可能是)触发“AlwaysCreate”标志 .

  • 0

    Visual Studio Forum引用的另一个简单解决方案 .

    更改配置:菜单工具→选项→项目和解决方案→VC项目设置→解决方案资源管理器模式以显示所有文件 .

    然后,您可以在Solution Explorer中查看所有文件 .

    找到黄色图标标记的文件,然后将其从项目中删除 .

    没关系 .

  • -3

    我今天遇到了这个问题,但有点不同 . 我的解决方案中有一个CUDA DLL项目 . 在一个干净的解决方案中编译是好的,但否则失败并且编译器始终将CUDA DLL项目视为不是最新的 .

    我尝试了this post的解决方案 .

    但是我的解决方案中没有丢失的头文件 . 然后我发现了我的理由 .

    我改变了项目's Intermediate Directory before, although it didn' t引起麻烦 . 现在,当我将CUDA DLL项目的中间目录更改回$(配置)\时,一切正常 .

    我猜CUDA Build Customization和非默认的中间目录之间存在一些小问题 .

  • 2

    有很多潜在的原因 - 如上所述 - 您需要首先通过将MSBuild详细程度设置为“Diagnostic”来诊断它们 . 大多数情况下,陈述的理由是自我解释的,你可以立即采取行动,但偶尔MSBuild会错误地声称某些文件被修改并需要复制 .

    如果是这种情况,您需要禁用NTFS隧道或将输出文件夹复制到新位置 . Here it is in more words.

  • 0

    在我弄清楚原因之前,这发生在我身上多次然后消失了 . 在我的情况下它是:

    Wrong system time in the dual boot setup!

    结果,我的双启动与Ubuntu是根本原因!!我一直懒得修理Ubuntu以免弄乱我的硬件时钟 . 当我登录Ubuntu时,时间会向前跳5个小时 .

    运气不好,我用错误的系统时间构建了一次项目,然后纠正了时间 . 因此,所有构建文件都有错误的时间戳,VS会认为它们都已过时并会重建项目 .

  • 1

    我有类似的问题,并按照上面的说明(接受的答案)找到丢失的文件,但不是没有挠头 . 以下是我所做的总结 . 为了准确起见,这些文件不会丢失,因为项目不需要构建它们(至少在我的情况下),但它们是对磁盘上不存在的文件的引用,这些文件并不是真正需要的 .

    这是我的故事:

    • 在Windows 7下,该文件位于 %ProgramFiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\% . 有两个类似的文件 devenv.exe.config.configdevenv.exe.config . 你想稍后改变一个 .

    • 在Windows 7下,您无权编辑程序文件中的此文件 . 只需将其复制到其他地方(桌面)更改它,然后将其复制回程序文件位置 .

    • 我试图弄清楚如何将DebugView连接到IDE以查看丢失的文件 . 好吧,你不需要做任何事情 . 只需运行它,它将捕获所有消息 . 确保在 Capture 菜单中选择 Capture Events 菜单选项,默认情况下应该选择该选项 .

    • DebugView不会一次显示所有丢失的文件(至少它不适合我)!您将运行DebugView,然后在Visual Studio 2010中运行该项目 . 它将提示 project out of date 消息,选择是以构建,DebugView将显示缺少的第一个文件或导致重建 . 在记事本中打开项目文件(不是解决方案文件)并搜索该文件并将其删除 . 最好关闭项目并在执行此删除时再次重新打开它 . 重复此过程,直到DebugView不再显示任何文件丢失 .

    • 从DebugView工具栏按钮或编辑→过滤器/突出显示选项中将消息过滤器设置为不是最新的一种有用的方法 . 这样,它显示的唯一消息是其中包含“不是最新”字符串的消息 .

    我有很多文件是不必要的引用,删除它们都修复了上述步骤后的问题 .

    Second way to find all the missing files at once

    还有第二种方法可以同时查找这些文件,但它涉及(a)源代码控制和(b)与Visual Studio 2010的集成 . 使用Visual Studio 2010,将项目添加到源中的所需位置或虚拟位置控制 . 它将尝试添加所有文件,包括那些在磁盘上不存在但在项目文件中引用的文件 . 转到像Perforce这样的源代码管理软件,它应该用不同的配色方案标记磁盘上不存在的这些文件 . Perforce通过黑色锁定显示它们 . 这些是你缺少的参考文献 . 现在你有一个列表全部,你可以使用记事本从项目文件中删除所有这些,你的项目不会抱怨过时 .

相关问题