here のように、私は非常によく似た問題を抱えています。
また、C++/CLIとC#プロジェクトの混合ソリューションをVisual Studio 2008からVisual Studio 2010にアップグレードしました。現在、Visual Studio 2010では、1つのC++/CLIプロジェクトが常に古くなっています。
直前にコンパイルおよびリンクされていても F5 「プロジェクトは期限切れです。ビルドしますか?」というメッセージボックスがヒットします。が表示されます。 DLLファイルの階層は非常に低く、ソリューションのほとんどすべてのプロジェクトを強制的に再構築するため、これは非常に面倒です。
私のpdb設定はデフォルト値に設定されています( この問題の推奨される解決策 )。
Visual Studio 2010が再構築を強制する、またはプロジェクトが最新であると考える理由を取得することは可能ですか?
Visual Studio 2010がそのように動作する他のアイデアはありますか?
Visual Studio/Express 2010のみ。 VS2012、VS2013などの他の(簡単な)回答を参照してください
見つからないファイル を見つけるには、記事 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>
次の形式の行についてデバッグログを検索します。
devenv.exe情報:0:ビルド入力「Bla\Bla\SomeFile.h」がないため、プロジェクト「Bla\Bla\Dummy.vcxproj」は最新ではありません。
(Ctrl + Fを押してnot up to date
を検索しただけです)これらは、プロジェクトを永続的に「期限切れ」にする原因となる参照になります。
これを修正するには、不足しているファイルへの参照をプロジェクトから削除するか、参照を更新して実際の場所を示します。
注:2012以降を使用している場合、スニペットは次のようになります。
<system.diagnostics>
<switches>
<add name="CPS" value="Verbose" />
</switches>
</system.diagnostics>
Visual Studio 2012では、受け入れられたソリューションよりも簡単に同じ結果を達成することができました。
メニューのオプションを変更しましたTools→Options→Projects and Solutions→Build and Run→* MSBuild project build 最小から診断までの「冗長出力」。
次に、ビルド出力で「最新でない」を検索して同じ行を見つけました。
プロジェクト「blabla」は最新ではありません。プロジェクトアイテム「c:\ foo\bar.xml」には「出力ディレクトリにコピー」属性が「常にコピー」に設定されています。
これは今日私に起こりました。原因を突き止めることができました。プロジェクトには、ディスク上に存在しなくなったヘッダーファイルが含まれていました。
プロジェクトからファイルを削除することで問題は解決しました。
また、この問題に遭遇し、それを解決する方法を見つけました。
問題は、上記の「ファイルがディスク上に存在しなくなった」というものでした。
これはまったく正しくありません。ファイルはディスク上に存在しますが、.VCPROJファイルは他の場所のファイルを参照しています。
「インクルードファイルビュー」に移動し、各インクルードファイルを順番にクリックして、Visual Studioで見つけることができないものを見つけることで、これを「発見」できます。次に、そのファイルを(既存のアイテムとして)追加し、見つからない参照を削除します。すべては問題ありません。
有効な質問は次のとおりです。インクルードファイルの場所がわからない場合、Visual Studioはどのようにビルドできますか?
.vcprojファイルには、Visual Studio GUIに表示されない問題のあるファイルへの相対パスがあり、これは、インクルードのツリービューが正しくなくてもプロジェクトが実際にビルドされる理由を説明しています。
受け入れられた答えは、私が取り組まなければならなかった台無しにされたプロジェクトのためにこの問題を解決する方法を見つけるための正しい道を助けてくれました。ただし、非常に多くの不正なインクルードヘッダーに対処する必要がありました。詳細なデバッグ出力では、デバッグ出力を削除すると、デバッグスピーの出力中にIDEが30秒間フリーズし、プロセスが非常に遅くなりました。
我慢できなくなったので、(Visual Studio 2010)プロジェクトファイルをチェックし、不足しているすべてのファイルを、それらが置かれているフィルターと共に一度に出力するために、Pythonスクリプトを作成しました。ここで要点として見つけることができます: https://Gist.github.com/antiuniverse/3825678 (またはこの 相対パスをサポートするフォーク )
例:
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 + ")")
ソリューション(およびディスク)からcppといくつかのヘッダーファイルを削除しましたが、まだ問題がありました。
つまり、コンパイラが使用するすべてのファイルは、tempディレクトリの* .tlogファイルに格納されます。ファイルを削除しても、この* .tlogファイルは更新されません。これは、プロジェクトが最新かどうかを確認するためにインクリメンタルビルドで使用されるファイルです。
この.tlogファイルを手動で編集するか、プロジェクトをクリーンアップして再構築します。
VS2013(Update 5)でこの問題が発生しましたが、その理由は2つあります。どちらも、「ツール」->「プロジェクトとソリューション」->「ビルドと実行」で「詳細」ビルド出力を有効にすることで見つけることができます。
"Forcing recompile of all source files due to missing PDB "..."
これは、コンパイラオプションでデバッグ情報の出力を無効にした場合に発生します(プロジェクト設定:「C/C++」->「デバッグ情報フォーマット」を「なし」、「リンカー」->「デバッグ情報を生成」 「いいえ」:)。デフォルトで「C/C++」->「Program Database File Name」(「$(IntDir)vc $(PlatformToolsetVersion).pdb」)を残した場合、VSはバグのためにファイルを見つけられません(- https://connect.Microsoft.com/VisualStudio/feedback/details/833494/project-with-debug-information-disabled-always-rebuilds )。
修正するには、ファイル名を「」(空のフィールド)にクリアするだけです。
"Forcing rebuild of all source files due to a change in the command line since the last build."
これも既知のVSバグのようです( https://connect.Microsoft.com/VisualStudio/feedback/details/833943/forcing-rebuild-of-all-source-files-due -to-a-change-in-the-command-line-since-the-last-build )であり、新しいバージョンで修正されたようです(VS2013ではありません)。回避策はありませんが、もしそうなら、ぜひここに投稿してください。
私は同様の問題を抱えていましたが、私の場合はファイルが欠落していなかったため、pdb出力ファイルの定義方法にエラーがありました:サフィックス.pdbを忘れました(デバッグログのトリックで見つけました)。
変更した問題を解決するために、vxprojファイルで次の行を追加しました。
<ProgramDataBaseFileName>MyName</ProgramDataBaseFileName>
に
<ProgramDataBaseFileName>MyName.pdb</ProgramDataBaseFileName>
他の誰かが同じ問題を抱えているかどうかはわかりませんが、私のプロジェクトのプロパティでは"Configuration Properties" -> C/C++ -> "Debug Information Format"
が「なし」に設定されていて、デフォルトの「プログラムデータベース(/ Zi)」に戻すと、プロジェクトの再コンパイルが停止しました時間。
Visual Studio 2013-「PDBがないためにすべてのソースファイルの再コンパイルを強制する」。詳細なビルド出力をオンにして問題を特定しました。[ツール]→[プロジェクトとソリューション]→[ビルドと実行]で[詳細]ビルド出力を有効にしました。
いくつかのプロジェクトがあり、すべてC++で、プロジェクト設定の下にオプションを設定しました:(C/C++→デバッグ情報フォーマット)問題のプロジェクトのプログラムデータベース(/ Zi)。しかし、これはそのプロジェクトの問題を止めるものではありませんでした。問題は、ソリューション内の他のC++プロジェクトの1つから発生しました。
all C++プロジェクトを「Program Database(/ Zi)」に設定します。これにより問題が修正されました。
繰り返しますが、問題を報告するプロジェクトは問題プロジェクトではありませんでした。すべてのプロジェクトを「プログラムデータベース(/ Zi)」に設定して、問題を修正してください。
Visual Studio Forum で参照される別の簡単なソリューション。
構成の変更:メニューツール→オプション→プロジェクトとソリューション→VC++プロジェクト設定→ソリューションエクスプローラーモードtoすべてのファイルを表示.
その後、ソリューションエクスプローラーですべてのファイルを表示できます。
黄色のアイコンでマークされたファイルを見つけて、プロジェクトから削除します。
大丈夫です。
私は同様の問題を抱えていて、上記の指示(受け入れられた答え)に従って欠落しているファイルを見つけましたが、頭を傷つけることはありませんでした。ここに私がやったことの要約があります。正確に言うと、これらのファイルはプロジェクトのビルドに必要ではないため(少なくとも私の場合)欠落しているファイルではありませんが、実際には必要のないディスク上に存在しないファイルへの参照です。
これが私の話です。
Windows 7では、ファイルは%ProgramFiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\%
にあります。 2つの類似したファイルdevenv.exe.config.config
とdevenv.exe.config
があります。後で変更します。
Windows 7では、プログラムファイルにあるこのファイルを編集する権限がありません。他の場所(デスクトップ)にコピーして変更し、プログラムファイルの場所にコピーし直します。
DebugView をIDEに接続して、欠落しているファイルを確認する方法を見つけようとしていました。まあ、あなたは何もする必要はありません。実行するだけで、すべてのメッセージがキャプチャされます。 Capture
メニューでCapture Events
メニューオプションが選択されていることを確認してください(デフォルトでは選択されるはずです)。
DebugViewは、欠落しているすべてのファイルを一度に表示しません(少なくとも私にとってはそうではありませんでした)! DebugViewを実行し、Visual Studio 2010でプロジェクトを実行します。project out of date
メッセージが表示され、ビルドするためにYesが選択されます。DebugViewにはfirstファイルが表示されます。または再構築の原因。メモ帳でプロジェクトファイル(ソリューションファイルではない)を開き、そのファイルを検索して削除します。この削除を行っている間にプロジェクトを閉じて、再び開くことをお勧めします。 DebugViewが見つからないファイルを表示しなくなるまで、このプロセスを繰り返します。
メッセージフィルターを最新ではない DebugViewツールバーボタンまたは編集→フィルター/ハイライトオプションに設定すると便利です。この方法で表示されるメッセージは、「最新でない」文字列を含むメッセージのみです。
不要な参照である多くのファイルがあり、それらをすべて削除すると、上記の手順に従って問題が修正されました。
すべての不足しているファイルを一度に見つける2番目の方法
これらのファイルを一度に検索する2番目の方法がありますが、(a)ソース管理と(b)Visual Studio 2010との統合が必要です。sing Visual Studio 201、プロジェクトをソース管理の目的の場所またはダミーの場所。ディスクには存在しないがプロジェクトファイルで参照されているファイルを含む、すべてのファイルを追加しようとします。 Perforce のようなソース管理ソフトウェアに移動すると、ディスク上に存在しないこれらのファイルを別のカラースキームでマークする必要があります。 PERFORCEは、黒いロックでそれらを示します。これらは欠落している参照です。これですべてのリストが作成され、メモ帳を使用してプロジェクトファイルからそれらをすべて削除できます。プロジェクトはout of dateについて文句を言うことはありません。
今日、この問題に出会いましたが、少し違いました。ソリューションにCUDA DLLプロジェクトがありました。クリーンなソリューションでのコンパイルは問題ありませんでしたが、それ以外の場合は失敗し、コンパイラは常にCUDA DLLプロジェクトを最新でないものとして扱いました。
この投稿 から解決策を試しました。
しかし、私のソリューションにはヘッダーファイルがありません。それから私は私の場合に理由を見つけました。
問題を引き起こすことはありませんでしたが、私は以前にプロジェクトの中間ディレクトリを変更しました。 そして、CUDA DLL Projectの中間ディレクトリを$(Configuration)\に戻したとき、すべてが正常に機能するようになりました。
CUDA Build Customizationとデフォルト以外の中間ディレクトリの間にいくつかの小さな問題があると思います。
コマンドラインMSBuildコマンド(Visual Studio IDEではない)を使用している場合、たとえばAppVeyorをターゲットにしている場合、またはコマンドラインのみを使用する場合、MSBuildコマンドラインにこのオプションを追加できます。
/fileLoggerParameters:LogFile=MyLog.log;Append;Verbosity=diagnostic;Encoding=UTF-8
記載されているとおり here (警告:通常のMSDNの冗長性)。ビルドが終了したら、ビルド中に作成されたログファイルwill be compiled
で文字列MyLog.log
を検索します。
私にとっては、プロジェクト内の「ヘッダーファイル」に存在しないヘッダーファイルが存在していました。このエントリを削除した後(右クリック> [プロジェクトから除外])、最初に再コンパイルしてから直接
==========ビルド:0成功、0失敗、5最新、0スキップ==========
そして、修正なしで再構築する試みは行われませんでした。 「AlwaysCreate」フラグをトリガーするVS2010によって実装されるビルド前のチェック(ドキュメント化されているかどうかは不明)だと思います。
Update 4でVisual Studio 2013 Professionalを使用していますが、他の提案では解決策が見つかりませんでしたが、チームプロジェクトの問題を解決できました。
これが私が問題を引き起こすためにしたことです-
問題を解決するために私がしたことは次のとおりです-
この場合は、プロジェクトに残したい実際のファイルではなく、ファントムファイルを削除していることを確認してください。
私の場合、プロジェクトの1つに複数のIDLファイルが含まれています。 MIDLコンパイラは、IDLファイル名に関係なく、それぞれに対して「dlldata.c」というDLLデータファイルを生成します。これにより、Visual Studioは、IDLファイルを変更しなくても、すべてのビルドでIDLファイルをコンパイルしました。
回避策は、IDLファイルごとに一意の出力ファイルを構成することです(/ dlldataスイッチが省略されていても、MIDLコンパイラは常にそのようなファイルを生成します)。
これで髪を引き裂くのに何時間も費やしました。ビルド出力は一貫していませんでした。さまざまなプロジェクトは、ビルドごとに次の連続ビルドまでさまざまな理由で「最新ではない」ことになります。最終的に、犯人はDropBox(3.0.4)であることがわかりました。ソースフォルダーを...\DropBoxからプロジェクトフォルダーにジャンクションします(これが理由であるかどうかはわかりません)が、DropBoxは何らかの方法でファイルに "タッチ"しますduring build。同期の一時停止とすべてが常に最新です。
私にとっては、一部のファイルの「ビルドアクション」プロパティが「リソース」に設定され、「出力ディレクトリにコピー」が「新しい場合にコピー」に設定されているWPFプロジェクトで問題が発生しました。解決策は、「出力ディレクトリにコピー」プロパティを「コピーしない」に変更することであると思われました。
msbuildは、「リソース」ファイルを出力にコピーしないことを知っていますが、ファイルがない場合はビルドをトリガーします。たぶんそれはバグと考えられますか?
ここでは、msbuildがすべてを構築し続ける理由についてBeanを流出させる方法を示唆する回答に非常に役立ちます!
私はこの問題を抱えていて、これを見つけました:
http://curlybrace.blogspot.com/2005/11/visual-c-project-continually-out-of.html
Visual C++プロジェクトは常に最新ではありません(
winwlm.h macwin32.h rpcerr.h macname1.h
がありません)問題:
Visual C++ .Net 2003では、前回のビルドで何も変更されておらず、エラーも報告されていなかったにもかかわらず、私のプロジェクトの1つは常に最新ではないと主張していました。
対応するプロジェクトのBuildLog.htmファイルを開くと、これらのファイルのPRJ0041エラーのリストが表示されましたが、私のシステムではどこにも表示されません:winwlm.h macwin32.h rpcerr.h macname1.h
各エラーは次のようになります。
MyApplication : warning PRJ0041 : Cannot find missing dependency 'macwin32.h' for file 'MyApplication.rc'.
プロジェクトは引き続きビルドされますが、このファイルが見つかるまで古く表示され続ける場合があります。
溶液:
プロジェクトの.rcファイル内に
afxres.h
の代わりにresource.h
を含めます。プロジェクトの.rcファイルには「#include resource.h」が含まれていました。リソースコンパイラはプリプロセッサの
#ifdef
ブロックを尊重しないので、無視する必要があるインクルードファイルを探し出そうとします。 Windows.hには、このようなブロックが多数含まれています。代わりにafxres.hを含めると、PRJ0041警告が修正され、「プロジェクトが最新ではありません」というエラーダイアログが削除されました。
いくつかの潜在的な理由があり、前述のように、MSBuildの冗長性を「診断」に設定して、まずそれらを診断する必要があります。ほとんどの場合、上記の理由は自明であり、すぐに対処できますが、一部のファイルが変更されてコピーが必要であるとMSBuildが誤って主張することがあります。
その場合は、NTFSトンネリングを無効にするか、出力フォルダーを新しい場所に複製する必要があります。 ここではより多くの言葉で。
プロジェクトのデバッグコマンドの引数を変更すると、プロジェクトの再構築が必要というメッセージもトリガーされます。ターゲット自体はデバッグ引数の影響を受けませんが、プロジェクトのプロパティは変更されています。ただし、再構築すると、メッセージは消えます。
常にすべてのファイルをコンパイルし、以前にVS2005からVS2010に(他の人によって)アップグレードされたVC++プロジェクトがありました。プロジェクト内のStdAfx.cppを除くすべてのcppファイルがプリコンパイル済みヘッダーを作成(/ Yc)に設定されていることがわかりました。これを変更して、StdAfx.cppのみがプリコンパイル済みヘッダーを作成するように設定され、残りはプリコンパイル済みヘッダーを使用する(/ Yu)に設定されたため、問題が修正されました。
Visual Studio 2015 SP3の別の問題ですが、数年前にVisual onStudio 2013でも同様の問題が発生しました。
私の問題は、プリコンパイル済みヘッダーに何らかの形で間違ったcppファイルが使用されていたことです(したがって、プリコンパイル済みヘッダーを作成する2つのcppファイルがありました)。今、Visual Studioが間違ったcppのフラグをリクエストせずに「プリコンパイル済みヘッダーを作成する」に変更したのはなぜですか?
とにかく、間違ったcppファイルには、ビルドごとに変更されるversion.hファイルが含まれています。 Visual Studioはすべてのヘッダーを再構築します。そのため、プロジェクト全体が再構築されます。
さて、今は通常の動作に戻りました。
これは私に何度も起こり、その後、理由を理解する前に消えました。私の場合、それは:
デュアルブートセットアップのシステム時間が間違っています!
結局のところ、Ubuntuでのデュアルブートが根本的な原因でした!! Ubuntuを修正してハードウェアクロックを台無しにしないようにするのが面倒です。 Ubuntuにログインすると、時間が5時間進みます。
運が悪かったので、システム時間を間違えてプロジェクトを一度構築し、その後時間を修正しました。その結果、すべてのビルドファイルのタイムスタンプが間違っていたため、VSはそれらがすべて古くなっていると判断し、プロジェクトを再ビルドしました。
ほとんどのビルドシステムは、データタイムスタンプを使用して、再構築のタイミングを決定します-出力ファイルの日付/タイムスタンプは、依存関係の最終変更時刻と照合されます-依存関係のいずれかが新しい場合、ターゲットが再構築されます。
これは、ビルド出力のタイムスタンプが将来作成されるファイルのタイムスタンプを超えることが困難であるため、依存関係のいずれかが何らかの方法で無効なデータタイムスタンプを取得する場合に問題を引き起こす可能性があります:P
Visual Studio 2005でも同様の問題が発生し、私のソリューションは次の依存関係にある5つのプロジェクトで構成されました(最初に最上位に構築されました)。
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もオンにしました。