Pertanyaan File output kunci Visual Studio pada build


Saya memiliki solusi WinForms sederhana di VS 2010. Setiap kali saya membangunnya, file output (bin \ debug \ app.exe) berakhir terkunci, dan build berikutnya gagal dengan pesan seperti "The process cannot access the file 'bin\Debug\app.exe' because it is being used by another process." Satu-satunya cara untuk membangun proyek ini adalah me-restart VS setelah setiap build, yang mana sangat canggung.

Saya telah menemukan posting blog lama ini http://blogs.geekdojo.net/brian/archive/2006/02/17/VS2005FileLocking.aspx - sepertinya masalahnya benar-benar sudah tua. Adakah yang tahu apa yang terjadi di sini, atau setidaknya beberapa solusi?

Memperbarui

Saya sebenarnya tidak menjalankan berkas. Penguncian terjadi setelah membangun, bukan setelah debug (yaitu mulai VS - build - build - fail!) Dan saya mencoba mematikan antivirus. Itu tidak membantu.

Perbarui 2

Process Explorer menunjukkan devenv.exe setelah memuat file (dalam DLL, bukan dalam Handles). Sepertinya beberapa kesalahan saat membangun mencegah pembongkaran, tetapi build (pertama) selesai tanpa pesan lain kemudian "1 berhasil, o gagal" /


75
2018-01-04 21:13


asal


Jawaban:


Punya masalah yang sama, tetapi menemukan solusi (terima kasih kepada Keyvan Nayyeri):

Tetapi bagaimana mengatasi ini? Ada berbagai cara berdasarkan jenis proyek Anda tetapi satu solusi sederhana yang saya sarankan untuk pengembang add-in Visual Studio adalah dengan menambahkan kode sederhana ke acara pembangunan proyek mereka.

Anda dapat menambahkan baris kode berikut ke baris perintah pre-build proyek Anda.

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

64
2018-04-29 15:10



Ini bukan masalah virus. Ini adalah bug visual studio 2010. Sepertinya masalahnya terkait dengan penggunaan perancang gui studio visual.

Solusinya di sini adalah memindahkan file output yang dikunci ke yang lain sementara dalam acara pre-build. Masuk akal untuk menghasilkan nama file sementara secara acak.

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

Jika menggunakan nama file sementara yang tetap, Anda hanya akan menunda kunci:

Solusi itu bekerja tepat satu kali

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

Saya juga menemukan solusi dengan 2 file sementara yang berfungsi tepat 2 kali.


24
2017-10-14 15:14



Masalahnya terjadi pada saya juga.

Skenario saya adalah ini: Menjalankan windows 7 (Tapi mungkin juga terjadi di Windows XP) dan saat mengerjakan proyek dengan Kontrol Pengguna WPF Saya bisa membangun semua waktu, Sampai membuka file XAML dari Kontrol Pengguna - Dari sana, saya ' ve punya satu build, dan kemudian file-file tersebut terkunci.

Juga, saya perhatikan bahwa saya menjalankan Visual Studio (Devenv.exe) sebagai Administrator, Saya sudah mulai menjalankan Visual Studio tanpa hak Administrator dan masalah itu hilang!.

Beri tahu saya jika itu membantu Anda juga. Semoga berhasil.


5
2018-05-24 18:26



Saya telah melihat ini pada perangkat lunak pemindaian virus yang rakus, atau jika app.exe tidak mati dengan benar. Pastikan prosesnya tidak berjalan.


3
2018-01-04 21:23



Bagaimana dengan pemindai virus di mesin Anda? Dapatkah Anda melihat proses yang memegang pegangan ke file Anda (gunakan Process Explorer untuk mencari tahu)?

Mungkin ada "app.exe" terlihat dalam daftar proses Anda, yaitu versi terakhir yang Anda debatkan masih berjalan? Ketika Anda mengembangkan aplikasi yang memiliki beberapa utas, ini mungkin terjadi jika Anda tidak melakukannya joinmereka semua.


3
2018-02-17 10:09



Saya memiliki masalah yang sama dan saya menemukan, bahwa VS hanya mengunci exe ketika saya membuka Formulir atau UserControl di VS sebelum membangun. Solusinya cukup mudah, saya hanya harus menutup Form / UserControl sebelum saya membangun solusi dan berhasil.


3
2017-09-09 09:51



Ada juga masalah yang diketahui 533411 di mana penggunaan nomor build pembaruan secara otomatis dapat menyebabkan masalah penguncian. Solusi dari laporan bug

Solusi sementara akan menonaktifkan pembaruan versi perakitan setelah pembangunan kembali. Di file AssemblyInfo.cs, hapus wildcard dari atribut AssemblyVersion, misalnya:
  ganti ini:
      [perakitan: AssemblyVersion ("1.4. *")]
      [perakitan: AssemblyFileVersion ("1.4")]
  dengan ini:
      [perakitan: AssemblyVersion ("1.4.0.0")]
      [perakitan: AssemblyFileVersion ("1.4.0.0")]


2
2017-10-14 16:06



Saya memiliki masalah ini dan mengatasinya dengan beberapa kode khusus. Lihat disini: Visual Studio 2010 membangun masalah kunci file

Kompilasi utilitas dalam jawaban yang diterima dan rujuk selama langkah build seperti yang dijelaskan untuk mengatasi masalah. Saya masih mematikan VS 2010 saat makan siang untuk membersihkan pekerjaan pagi hari.

Alasan untuk kode kustom adalah bahwa solusi yang sering direkomendasikan hanya bekerja sekali dan kemudian file berganti nama juga dikunci, mencegah penggantian nama. Di sini kami hanya menambahkan info data-waktu ke file sehingga versi berganti nama tidak dapat konflik.


2
2018-03-04 15:52



Berdasar pada yang hebat Jawaban Stormenet, Saya memasang skrip kecil yang seharusnya berfungsi dalam semua kasus.

Berikut ini adalah kode untuk dimasukkan ke dalam kotak teks pre-build event

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

Pre build event

Berikut ini skrip untuk menyalin di file $(SolutionDir)\BuildProcess\PreBuildEvents.bat  (tentu saja Anda dapat memodifikasi jalur ini):

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%"

2
2018-04-09 09:04