Visual Studio khóa tệp đầu ra khi xây dựng

Tôi có một giải pháp WinForms đơn giản trong VS 2010. Bất cứ khi nào tôi xây dựng nó, tệp đầu ra (bin \ debug \ app.exe) sẽ bị khóa và các bản dựng tiếp theo không thành công với thông báo như "The process cannot access the file 'bin\Debug\app.exe' because it is being used by another process." Cách duy nhất để xây dựng dự án là khởi động lại VS sau mọi bản dựng, rất khó xử.

Tôi đã tìm thấy bài đăng blog cũ này http://blogs.geekdojo.net/brian/archive/2006/02/17/VS2005FileLocking.aspx - có vẻ như vấn đề đã thực sự cũ. Có ai biết điều gì đang xảy ra ở đây, hoặc ít nhất là một số cách giải quyết?

Cập nhật

Tôi không thực sự chạy tệp. Khóa xảy ra sau khi xây dựng, không phải sau khi gỡ lỗi (tức là bắt đầu VS - xây dựng - xây dựng - thất bại!) Và tôi đã thử tắt chống vi-rút. Nó không giúp ích gì.

Cập nhật 2

Process Explorer hiển thị devenv.exe đã tải tệp (trong DLL, không phải trong Handles). Có vẻ như một số trục trặc trong quá trình xây dựng đã ngăn chặn việc tải, nhưng bản dựng (đầu tiên) hoàn thành mà không có bất kỳ thông báo nào khác sau đó "1 thành công, o không thành công" /

Gặp vấn đề tương tự, nhưng đã tìm ra giải pháp (nhờ Keyvan Nayyeri ):

Nhưng làm thế nào để giải quyết điều này? Có nhiều cách khác nhau dựa trên loại dự án của bạn nhưng một giải pháp đơn giản mà tôi khuyên các nhà phát triển phần bổ trợ Visual Studio là thêm một mã đơn giản vào các sự kiện xây dựng của dự án của họ.

Bạn có thể thêm các dòng mã sau vào dòng lệnh tạo sự kiện trước trong dự án của mình.

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

Nó không phải là một vấn đề vi rút. Đó là lỗi của Visual Studio 2010. Có vẻ như vấn đề liên quan đến việc sử dụng thiết kế gui studio trực quan.

Cách giải quyết ở đây là di chuyển tệp đầu ra bị khóa sang một tệp tạm thời khác trong sự kiện trước khi xây dựng. Nó có ý nghĩa khi tạo tên tệp tạm thời một cách ngẫu nhiên.

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

Trong trường hợp sử dụng các tên tệp tạm thời liên tục, bạn sẽ chỉ hoãn các khóa:

Cách giải quyết đó hoạt động chính xác một lần

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

Tôi cũng đã tìm ra giải pháp với 2 tệp tạm thời hoạt động chính xác 2 lần.

Vấn đề cũng xảy ra với tôi.

Kịch bản của tôi là sau: Đang chạy windows 7 (Nhưng cũng có thể xảy ra trong Windows XP) và trong khi làm việc trên một dự án với WPF User Control, tôi có thể xây dựng mọi lúc, cho đến khi mở tệp XAML của User Control - Từ đó, tôi ' đã có một bản dựng, và sau đó các tệp đã bị khóa.

Ngoài ra, tôi nhận thấy rằng tôi đang chạy Visual Studio (Devenv.exe) với tư cách Quản trị viên, tôi đã bắt đầu chạy Visual Studio mà không có đặc quyền của Quản trị viên và sự cố đã biến mất! .

Hãy cho tôi biết nếu nó cũng giúp bạn. Chúc may mắn.

Tôi đã thấy điều này trên một phần mềm quét vi-rút tham lam hoặc nếu app.exe không tắt đúng cách. Đảm bảo rằng quá trình này vẫn không chạy.

Điều gì về máy quét vi rút trên máy của bạn? Bạn có thể thấy bất kỳ quy trình nào đang giữ các xử lý đối với tệp của bạn (sử dụng Process Explorer để tìm hiểu) không?

Có thể có "app.exe" hiển thị trong danh sách quy trình của bạn, tức là phiên bản cuối cùng bạn đã gỡ lỗi vẫn đang chạy? Khi bạn phát triển các ứng dụng có nhiều luồng, điều này có thể xảy ra nếu bạn không làm jointất cả chúng.

Tôi gặp vấn đề tương tự và tôi phát hiện ra rằng VS chỉ khóa exe khi tôi mở Biểu mẫu hoặc UserControl trong VS trước khi xây dựng. Giải pháp khá dễ dàng, tôi chỉ cần đóng bất kỳ Biểu mẫu / UserControl nào trước khi tôi xây dựng giải pháp và nó đã hoạt động.

Dựa trên câu trả lời tuyệt vời của Stormenet , tôi đưa ra một tập lệnh nhỏ có thể hoạt động trong mọi trường hợp.

Đây là mã để đặt trong hộp văn bản sự kiện xây dựng trước

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

Đây là tập lệnh để sao chép trong tệp $(SolutionDir)\BuildProcess\PreBuildEvents.bat (tất nhiên bạn có thể sửa đổi đường dẫn này):

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

Ngoài ra còn có một sự cố đã biết 533411 trong đó việc sử dụng tự động cập nhật số bản dựng có thể gây ra sự cố khóa. Giải pháp thay thế từ báo cáo lỗi

Giải pháp tạm thời sẽ là vô hiệu hóa cập nhật phiên bản lắp ráp sau khi xây dựng lại. Trong tệp AssemblyInfo.cs, hãy xóa thẻ đại diện khỏi thuộc tính AssemblyVersion, ví dụ:
thay thế cái này:
[assembly: AssemblyVersion ("1.4. *")]
[Assembly: AssemblyFileVersion ("1,4")]
bằng cái này:
[assembly: AssemblyVersion ("1.4.0.0")]
[assembly: AssemblyFileVersion ("1.4.0.0")]

Tôi đã gặp sự cố này và đã giải quyết nó bằng một số mã tùy chỉnh. Xem tại đây: Visual Studio 2010 xây dựng sự cố khóa tệp

Biên dịch tiện ích trong câu trả lời được chấp nhận và tham chiếu nó trong bước xây dựng như được mô tả để giải quyết vấn đề. Tôi vẫn tắt VS 2010 vào bữa trưa để dọn dẹp công việc buổi sáng.

Lý do cho mã tùy chỉnh là giải pháp thường được đề xuất chỉ hoạt động một lần và sau đó các tệp được đổi tên cũng bị khóa, ngăn việc đổi tên. Ở đây, chúng tôi chỉ thêm thông tin thời gian dữ liệu vào tệp để các phiên bản đã đổi tên không thể xung đột.

Điều duy nhất phù hợp với tôi là thoát Visual Studio 2012, xóa thư mục BIN và OBJ cho dự án gặp sự cố và mở lại Visual Studio.

Vấn đề đã được giải quyết ... Cho đến lần sau.

Nếu $ (TargetPath) của bạn trỏ đến một DLL sử dụng COM, hãy đảm bảo rằng bạn có một phương thức khởi tạo mặc định. Không chắc tại sao hàm tạo mặc định không được suy ra ở đó. Việc thêm hàm tạo mặc định đã làm việc cho tôi trong trường hợp này.

Tôi đóng cửa studio trực quan, mở lại và tải lại giải pháp gần đây nhất giải quyết được vấn đề. (Visual Studio 2013 Ultimate)

Tôi đã gặp điều tương tự khi phát triển ứng dụng xamarin trong VS2017.

Tình cờ là Bộ bảo vệ Windows đang khóa exe / dll bằng devenv.exe.

Bạn có thể vào Win Defender và thêm

devenv.exe
msbuild.exe

vào danh sách loại trừ quy trình.

Đây là giải pháp tôi tìm ra

1. Bỏ chọn Quy trình lưu trữ Visual Studio trong cài đặt dự án như hình dưới đây

2. Diệt exe. nó sẽ là tên ứng dụng.vshost.exe của bạn từ taskmanager

3. Bây giờ bạn có thể xây dựng lại ứng dụng của mình và chạy.

Lưu ý: Bạn có thể bật lại tùy chọn này mà không gặp vấn đề gì.

Tôi đã cố gắng khắc phục sự cố này bằng cách tắt tính năng quét thời gian thực McAfee LiveSafe. Tệp .exe của tôi sẽ bị khóa như OP mô tả và tôi sẽ không có cách nào để xóa tệp, điều đó có nghĩa là tôi không thể xây dựng giải pháp. Sau khi tắt tính năng McAfee, sự cố đã không còn.

Sau đó, tất nhiên tôi đã tiếp tục gỡ cài đặt hoàn toàn McAfee, chỉ được cài đặt vì PC của tôi là mới và nó đi kèm với chương trình đã được cài đặt.

Tôi đã tạo một giải pháp trống mới và thêm tất cả các tệp cũ vào nó. Điều này bằng cách nào đó đã giải quyết được vấn đề.