VisualStudioはビルド時に出力ファイルをロックします

VS 2010には単純なWinFormsソリューションがあります。ビルドするたびに、出力ファイル（bin \ debug \ app.exe）がロックされ、後続のビルドは次のようなメッセージで失敗します。 "The process cannot access the file 'bin\Debug\app.exe' because it is being used by another process." プロジェクトをビルドする唯一の方法は、後にVSを再起動することです。すべてのビルド、これは非常に厄介です。

この古いブログ投稿http://blogs.geekdojo.net/brian/archive/2006/02/17/VS2005FileLocking.aspxを見つけました-問題は本当に古いようです。ここで何が起こっているのか、または少なくともいくつかの回避策を知っている人はいますか？

更新

私は実際にファイルを実行しません。ロックはデバッグ後ではなくビルド後に発生します（つまり、VSの起動-ビルド-ビルド-失敗！）そして、ウイルス対策をオフにしてみました。それは役に立ちません。

アップデート2

Process Explorerは、ファイルをロードしたdevenv.exeを表示します（ハンドルではなくDLLで）。ビルド中の不具合によりアンロードが妨げられたようですが、（最初の）ビルドは「1成功、o失敗」以外のメッセージなしで完了します/

同じ問題がありましたが、解決策が見つかりました（Keyvan Nayyeriに感謝し ます）：

しかし、これを解決する方法は？プロジェクトの種類に基づいてさまざまな方法がありますが、Visual Studioアドイン開発者に推奨する簡単な解決策の1つは、プロジェクトのビルドイベントに簡単なコードを追加することです。

プロジェクトのビルド前のイベントコマンドラインに次のコード行を追加できます。

if exist "$(TargetPath).locked" del "$(TargetPath).locked"
if exist "$(TargetPath)" if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"

ウイルスの問題ではありません。Visual Studio2010のバグです。問題は、ビジュアルスタジオのGUIデザイナーの使用に関連しているようです。

ここでの回避策は、ビルド前のイベントで、ロックされた出力ファイルを別の一時ファイルに移動することです。一時ファイル名をランダムに生成することは理にかなっています。

del "$(TargetPath).locked.*" /q 
if exist "$(TargetPath)"  move "$(TargetPath)" "$(TargetPath).locked.%random%"
exit /B 0

一定の一時ファイル名を使用する場合は、ロックを延期するだけです。

その回避策は1回だけ機能します

 if exist "$(TargetPath).locked" del "$(TargetPath).locked"
    if exist "$(TargetPath)" if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"

また、正確に2回機能する2つの一時ファイルを使用したソリューションも見つけました。

問題は私にも起こりました。

私のシナリオは次のとおりです：Windows 7を実行しています（ただし、Windows XPでも発生する可能性があります）。WPFユーザーコントロールを使用してプロジェクトで作業している間は、ユーザーコントロールのXAMLファイルを開くまで常にビルドできました-そこから、ビルドが1つあると、ファイルがロックされます。

また、管理者としてVisual Studio（Devenv.exe）を実行していることに気付きました。管理者権限なしでVisual Studioを実行し始めたので、問題は解決しました。。

それがあなたにも役立ったかどうか教えてください。幸運を。

これは、貪欲なウイルススキャンソフトウェア、またはapp.exeが適切にシャットダウンされていない場合に発生します。プロセスがまだ実行されていないことを確認してください。

お使いのマシンのウイルススキャナーはどうですか？ファイルへのハンドルを保持しているプロセスを確認できますか（Process Explorerを使用して確認してください）？

プロセスリストに「app.exe」が表示されている可能性があります。つまり、デバッグした最後のバージョンがまだ実行されていますか？複数のスレッドを持つアプリケーションを開発する場合、joinすべてではない場合に発生する可能性があります。

同じ問題が発生しましたが、ビルドする前にVSでFormまたはUserControlを開いたときにのみ、VSがexeをロックすることがわかりました。ソリューションは非常に簡単でした。ソリューションをビルドする前にForm / UserControlを閉じるだけで、機能しました。

偉大上の基本Stormenetの答えは、私はすべてのケースで動作するはず小さなスクリプトを設置します。

ビルド前のイベントテキストボックスに入力するコードは次のとおりです

$(SolutionDir)\BuildProcess\PreBuildEvents.bat  "$(TargetPath)"  "$(TargetFileName)"  "$(TargetDir)"  "$(TargetName)"

ファイルにコピーするスクリプトは次の$(SolutionDir)\BuildProcess\PreBuildEvents.bat とおりです（もちろん、このパスを変更できます）。

REM This script is invoked before compiling an assembly, and if the target file exist, it moves it to a temporary location
REM The file-move works even if the existing assembly file is currently locked-by/in-use-in any process.
REM This way we can be sure that the compilation won't end up claiming the assembly cannot be erased!

echo PreBuildEvents 
echo  $(TargetPath) is %1
echo  $(TargetFileName) is %2 
echo  $(TargetDir) is %3   
echo  $(TargetName) is %4

set dir=C:\temp\LockedAssemblies

if not exist %dir% (mkdir %dir%)

REM delete all assemblies moved not really locked by a process
del "%dir%\*" /q

REM assembly file (.exe / .dll) - .pdb file - eventually .xml file (documentation) are concerned
REM use %random% to let coexists several process that hold several versions of locked assemblies
if exist "%1"  move "%1" "%dir%\%2.locked.%random%"
if exist "%3%4.pdb" move "%3%4.pdb" "%dir%\%4.pdb.locked%random%"
if exist "%3%4.xml.locked" del "%dir%\%4.xml.locked%random%"

REM Code with Macros
REM   if exist "$(TargetPath)"  move "$(TargetPath)" "C:\temp\LockedAssemblies\$(TargetFileName).locked.%random%"
REM   if exist "$(TargetDir)$(TargetName).pdb" move "C:\temp\LockedAssemblies\$(TargetName).pdb" "$(TargetDir)$(TargetName).pdb.locked%random%"
REM   if exist "$(TargetDir)$(TargetName).xml.locked" del "C:\temp\LockedAssemblies\$(TargetName).xml.locked%random%"

ビルド番号を自動的に更新することでロックの問題が発生する可能性がある既知の問題533411もあります。バグレポートからの回避策

一時的な回避策は、再構築後にアセンブリバージョンの更新を無効にすることです。AssemblyInfo.csファイルでは、例えば、のAssemblyVersion属性からワイルドカードを削除します。
これを置き換える：
[アセンブリ：のAssemblyVersion（ "1.4 *"）]
：[アセンブリAssemblyFileVersion（ "1.4"）]
：これで
[アセンブリ：のAssemblyVersion （ "1.4.0.0"）]
[アセンブリ：AssemblyFileVersion（ "1.4.0.0"）]

私はこの問題を抱えていて、いくつかのカスタムコードで解決しました。こちらをご覧ください：Visual Studio2010ビルドファイルロックの問題

問題を回避するために説明されているように、受け入れられた回答でユーティリティをコンパイルし、ビルドステップ中にそれを参照します。私はまだ朝の仕事を片付けるために昼食時にVS2010をオフにします。

カスタムコードの理由は、よく推奨されるソリューションが1回しか機能せず、名前が変更されたファイルもロックされ、名前が変更されないためです。ここでは、名前が変更されたバージョンが競合しないように、データ時間情報をファイルに追加するだけです。

私にとってうまくいったのは、Visual Studio 2012を終了し、問題のあるプロジェクトのBINフォルダーとOBJフォルダーを削除して、VisualStudioを再度開くことだけでした。

問題は解決しました...次回まで。

$（TargetPath）がCOMを使用するDLLを指している場合は、デフォルトのコンストラクターがあることを確認してください。デフォルトのコンストラクターがそこで推測されない理由がわかりません。このシナリオでは、デフォルトのコンストラクターを追加することでうまくいきました。

Visual Studioを閉じ、再度開いて、最新のソリューションを再読み込みすると、問題が回避されます。（Visual Studio 2013 Ultimate）

VS2017でxamarinアプリを開発しているのと同じことに遭遇しました。

たまたま、WindowsDefenderがdevenv.exeでexe / dllをロックしていました。

WinDefenderに移動して追加できます

devenv.exe
msbuild.exe

プロセス除外リストに追加します。

これは私が見つけた解決策です

1. 以下に示すように、プロジェクト設定でVisualStudioホスティングプロセスのチェックを外します

2. exeファイルを強制終了します。これは、タスクマネージャーからのapplicationname.vshost.exeになります

3. これで、アプリケーションを再構築して実行できます。

注：このオプションを問題なく再度有効にすることができます。

McAfee LiveSafeのリアルタイムスキャンを無効にすることで、この問題を解決することができました。OPで説明されているように、.exeファイルがロックされ、ファイルを削除する方法がないため、ソリューションをビルドできませんでした。マカフィー機能を無効にした後、問題はなくなりました。

それからもちろん、マカフィーを完全にアンインストールしました。マカフィーは、私のPCが新しく、プログラムがすでにインストールされているためにのみインストールされました。

新しい空のソリューションを作成し、それにすべての古いファイルを追加しました。これはどういうわけか問題を解決しました。