私は他の誰かの仕事をデバッグしており、解決策は非常に大きいです。すべてをビルドしようとすると、ソリューション内のいくつかのプロジェクトがビルドされず、スキップされます。ビルドプロセス中に出力ウィンドウを表示すると、次のように表示されます。
1> ------すべての再構築をスキップ:プロジェクト:pr1lib ------
これらのビルドがスキップされた理由を特定するにはどうすればよいですか?追加の出力が見つかりません。
これはVS2008で行われ、ソリューションはc#およびc ++コードで構成されます。
ソリューションを右クリックし、[プロパティ]、[構成プロパティ]の順に選択します。ここで、ビルドするプロジェクトを選択できます。
[編集]:
。
*この問題が発生したとき、メインプロジェクトには「Any CPU」しかなく、子DLLも「any CPU」に設定されていましたが、そのプロファイルを削除して「x86」のみを残しました。 dllだけにx86を選択すると、動作し始めます
[/編集]
私はちょうど同じ問題を抱えていました-「プロジェクトのアンロード」と「プロジェクトのリロード」が問題を解決しました!
ビルド、再構築、およびクリーン操作はスキップされていました。アンロードとリロードは役に立たず、Visual Studioも再起動しませんでした。
ソリューションからプロジェクトを削除して追加し直すと、スキップされなくなりました。削除するには、ソリューションエクスプローラーでプロジェクトを右クリックし、[削除]> [OK]をクリックします。追加するには、ソリューションエクスプローラーでソリューションを右クリックし、[追加]> [既存のプロジェクト]を選択して、プロジェクトを選択します。
構成がx64で、x64コンパイラがインストールされていない場合、プロジェクトはスキップされます。
Visual Studio 2008では、64ビットコンパイラがインストールされなかったことが原因の可能性があります。
コントロールパネル->プログラムと機能-> Microsoft Visual Studio 2008 Professional-> [ダブルクリック]
Visual Studioダイアログ上
次へ->機能の追加/削除->(Under)Visual C++->(選択)x64 compiler and Tools
ちょっと、これを直しただけです。それが役立つかもしれないと思った。おそらく、対応するコンパイラーをVisual Studioと共にインストールしていません。これは今日私に起こりました-デフォルトでは、VS 2008インストーラーはx64 C++コンパイラーをインストールしません。
SP1がある場合は、VSインストールを変更する前にSP1をアンインストールしてください。完了したら、SP1を再度インストールします。
私の解決策は前述したものと同じです:削除->既存のプロジェクトを追加
しかしこの解決策はプロジェクト間の参照がなくなるを意味します。
参照の再追加を避けるために:およびバージョン管理システムを使用する場合 GITやTFSなどのように、次の手順で目標を達成することができます。
操作の前にすべての変更がコミット/チェックインされていることを確認してください
ソリューションから削除し、既存のプロジェクトを追加して、すべてのプロジェクトを実行します
.slnファイルが変更されていることに注意してください
新しい.slnファイルを保持しますが、バージョン管理システムですべての.cspojファイルへの変更を元に戻します
VS 2010にも問題があります。提案されたソリューションの:ビルド構成の編集、クリーニング、ターゲットフレームワークの変更/再変更は機能しません。ただし、プロジェクトのアンロードと再ロードは行います。
ビルドメニューに移動し、「構成マネージャー」を選択します。これにより、選択した構成でビルドするように構成されているプロジェクトが表示されます。
同じ問題を抱えていたので、プロジェクトの設定はItanium CPU用であることがわかり、Intelに変更すると修正されました。
私は15.9.11に更新しました...いくつかのビルドの後、同じ問題:ほとんどのプロジェクトがスキップされます(問題なく2回前にビルドされます)。私の場合、ソリューションのアンロード/リロードは常に役立ちますが、すぐに再び発生します。
VS2017の大きなバグを除いて...理由はわかりません
構成マネージャーをチェックし、すべてのチェックマークがビルドに設定されています。
たぶん、それはnugetパッケージと関係があるかもしれませんが、それは単なる推測です
ソリューションにはc ++/vcxprojのみがあり、csprojはありません。 64と32の両方がインストールされます
ソリューションエクスプローラーで[ソリューション]を右クリックし、メニューの下部にある[プロパティ]をクリックします。プロパティウィンドウで、左ペインの構成プロパティ-> 構成をクリックすると、右ペインにプロジェクトのリストが表示されます。ビルドチェックボックスがチェックインされていることを確認してください。ポップアップウィンドウ。
ソリューションにNuGetプロジェクト(* .nuproj)ファイルが含まれている場合は、それをアンロードしてからソリューションを再構築してください。
上記のどれもうまくいかなかった後、これは私にとってはうまくいきました。
VS2005で同じ問題が発生していましたが、すべての構成は正しいものでした。 Clean projectコマンドもスキップしていました。
最後に、アンロード/リロードが魔法をかけました。
私はここで他の可能性の中で文書化する価値があるかもしれない奇妙なものを持っていました。
ソリューションに Shared Project を追加し、他の2つまたは3つのプロジェクトで使用されるコードを追加しました。ご存知のように、共有プロジェクトは単なるコードであり、実際には伝統的な意味でのプロジェクトではありません。共有プロジェクトを「ビルド」することはできません。他のプロジェクトに埋め込まれたコードです。
しかし、どういうわけか私のソリューションファイルは、共有プロジェクトがビルドを必要とする独自のものであるかのように更新されました。私は、ビルドしようとしていて、共有プロジェクトのコードを変更していなかったときはいつでも、「何も変更されていないので、ビルドをスキップする」と考えていました
_solution.sln
_ファイルで共有プロジェクトを見つけました:
_Project("{D954291E-2A0B-460D-934E-DC6B0785DB48}") = "Api.Common", "Api.Common\Api.Common.shproj", "{EC580471-D78A-4509-AC46-BD565553AD60}"
_
..これは問題ありません。うまくいかないのは、このプロジェクトがGlobalSection(ProjectConfigurationPlatforms) = postSolution
にも登場するということです:
_ {EC580471-D78A-4509-AC46-BD565553AD60}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
{EC580471-D78A-4509-AC46-BD565553AD60}.Debug|Any CPU.Build.0 = Debug|Any CPU
{EC580471-D78A-4509-AC46-BD565553AD60}.Release|Any CPU.ActiveCfg = Release|Any CPU
{EC580471-D78A-4509-AC46-BD565553AD60}.Release|Any CPU.Build.0 = Release|Any CPU
_
_.sln
_ファイルからこれらの4行を削除しました。
私に似たことが起こりました。私は問題が何であったかはわかりませんが、Clean、Build、Rebuildなどではありません。私はVisual Studio 2017とnetstandard2.0
アセンブリ。私にとっての問題は、どういうわけかプロジェクトのタイプが間違っていたということでした。多分、Solutionファイルに残っているnetcoreapp
クラスライブラリから始めたので、思い出せません。とにかく、私はプロジェクトをバックアップし、新しいnetstandard
クラスライブラリプロジェクトを作成し、バックアップされたビットを考慮して、それを修正しました。 HTH誰か。
4.ファイルを保存します5.ビジュアルスタジオを開きます
ビジュアルスタジオ2017
構成マネージャーに構成を追加した後
プロジェクトを右クリック->プロジェクトのみ->ビルドのみ/再ビルドのみ/クリーンのみ
他のすべての設定が正しい場合。
Telerikの逆コンパイラからプロジェクトを生成し、それを再コンパイルしようとした後、非常によく似た問題がありました。プロジェクトを再構築しようとすると、プロジェクトはスキップされました。上記の多くの提案を試しましたが、私にとっては、プロジェクトプロパティで選択された.NET Frameworkでした。
ソリューションファイルでプロジェクトを右クリックし、プロパティ、アプリケーションタブを選択して、ターゲットフレームワークを4.0から3.5に変更します。
その後、再構築すると、アセンブリ参照の欠落エラーが大量に発生しました。これは、まだ参照を追加していないので理にかなっています。
同様の問題がありました。何らかの理由でソリューションエクスプローラーに読み込めないプロジェクトが1つありました。そのプロジェクトを読み込んだとき、それは魅力のように機能しました。
X64コンパイラがインストールされていない場合、VS 2008はx64ターゲットをスキップします。 VS 2008はデフォルトではありません。当たり前のようなもの。
ソリューションとプロジェクトでx86を使用するように設定されたターゲットプラットフォームを使用している場合、プロジェクトで実際に選択されているとは限らないことがあります。
再確認するには、プロジェクトプロパティに移動し、[ビルド]> [プラットフォーム]設定でそのプラットフォームを選択できるかどうかを確認します。選択できない場合は、構成マネージャーに移動してその構成を作成する必要があります。
最初に「クリーン」を行うことを確認してください。通常、Visual Studioは、古くなっていない(関係する限り)プロジェクトを再構築せず、既存のオブジェクトコードを再利用します。
クリーンを実行すると、以前にコンパイルされたすべてのコードがクリアされ、VSはプロジェクトをスキップしません(構成マネージャーがビルドするプロジェクトを選択していると仮定します...前の回答を参照)。
お役に立てば幸いです。
Visual Studio 2017の1つの小さな更新を更新した後、インストーラーはコンピューターを再起動するように通知しますが、再起動しませんでした。VisualStudio 2017でプロジェクトまたはソリューションをビルドすると、上記の同じ問題が発生します。キーを使用して、コンピューターを再起動しました。:>
新しいPC上のいくつかのWindows CEプロジェクトでこの問題が発生しました。 「プロジェクトのアンロード」と「プロジェクトのリロード」は問題を修正するように見えましたが、実際にはVisual Studioは単に別のプラットフォームに切り替えて構築していました。
私のWinCEプラットフォームはアクティブなプラットフォームとして表示されていましたが、Visual Studioはそれを「本当に」見ていませんでした。解決策は、 管理者特権でWinCE SDKを再インストールする :
msiexec /log SDKInstallLog.txt /package <the path to your .msi file>
Visual Studio 2017 15.9.4でこの問題が発生しましたが、しばらく検索してしばらくすると、ソリューションの1つで、プロジェクトの.csprojファイルがTFSにマージされた後に破損することがわかりました。 (問題のあるプロジェクトをソリューションからアンロードすることで、他のプロジェクトを構築できます)。問題を解決した方法は、マージの前後で.csprojファイルを比較し、修正したことです。そして、修正によって、私は自分のプロジェクトのタイプが.netStandardだったので、ConfigurationPropertyGroup、新しい.csprojファイルのその他すべてを使用して、以前の.netstandardスタイルのバージョンと同様にします。
私はこのトラブルに巻き込まれました:
VS 2017を最新バージョン15.9.11に更新し、私のプロジェクトのいくつかは.net core 2.2に更新されました。最初にすべてのプロジェクトをロードして、ビルド/クリーニング/再構築を試みましたが、すべてスキップされました。以下に従って解決しました。
それですべてが実行に戻り、すべてのプロジェクトを正常にビルドできました。