Lỗi: Không thể truy cập tệp bin / Gỡ lỗi /… vì nó đang được sử dụng bởi một quy trình khác

Khi tôi gỡ lỗi dự án của mình, tôi gặp lỗi sau:

"Không thể sao chép tệp" obj \ Debug \ My Dream.exe "sang" bin \ Debug \ My Dream.exe ". Quá trình này không thể truy cập tệp 'bin \ Debug \ My Dream.exe' vì tệp đang được người khác sử dụng quá trình."

Sử dụng Process Explorer, tôi thấy rằng MyApplication.exe đã hết nhưng quy trình Hệ thống vẫn sử dụng nó mặc dù tôi đã dừng gỡ lỗi trước đó. Bất cứ khi nào tôi thay đổi mã của mình và bắt đầu gỡ lỗi, điều đó sẽ xảy ra. Nếu tôi sao chép dự án vào USB và gỡ lỗi, nó chạy OK.

Tại sao? Tôi có thể sửa lỗi này bằng cách nào?

Tôi sử dụng Window 7 Professional. Với Xp tôi chưa bao giờ gặp lỗi này.

Rất tiếc, đây là một vấn đề cũ, một cái gì đó vẫn xuất hiện trong Visual Studio thỉnh thoảng. Nó đã cắn tôi một vài lần và tôi đã mất hàng giờ khởi động lại và chiến đấu với VS. Tôi chắc rằng nó đã được thảo luận ở đây trên SO nhiều hơn một lần. Nó cũng đã được nói đến trên các diễn đàn MSDN. Không có một giải pháp thực tế nào, nhưng có một số cách giải quyết. Bắt đầu nghiên cứu tại đây .

Điều đang xảy ra là VS đang có được một khóa trên một tệp và sau đó không giải phóng nó. Trớ trêu thay, khóa đó ngăn chính VS xóa tệp để nó có thể tạo lại khi bạn xây dựng lại ứng dụng. Giải pháp rõ ràng duy nhất là đóng và khởi động lại VS để nó giải phóng khóa trên tệp.

Cách giải quyết ban đầu của tôi là mở thư mục bin / Debug và đổi tên tệp thực thi. Bạn không thể xóa nó nếu nó bị khóa, nhưng bạn có thể đổi tên nó. Vì vậy, bạn có thể chỉ cần thêm một số vào cuối hoặc một cái gì đó, cho phép bạn tiếp tục làm việc mà không cần phải đóng tất cả các cửa sổ của mình và đợi VS khởi động lại. Một số người thậm chí đã tự động hóa điều này bằng cách sử dụng sự kiện tạo trước để nối một chuỗi ngẫu nhiên vào cuối tên tệp đầu ra cũ. Đúng, đây là một vụ hack khổng lồ , nhưng vấn đề này trở nên khó chịu và suy nhược đến mức bạn sẽ làm bất cứ điều gì.

Sau này, tôi đã biết, sau khi thử nghiệm nhiều hơn một chút, vấn đề dường như chỉ xuất hiện khi bạn xây dựng dự án với một trong những nhà thiết kế mở. Vì vậy, giải pháp có hiệu quả lâu dài với tôi và ngăn tôi không bao giờ gặp lại một trong những lỗi ngớ ngẩn đó là đảm bảo rằng tôi luôn đóng tất cả các cửa sổ thiết kế trước khi xây dựng một dự án WinForms. Vâng, điều này cũng hơi bất tiện, nhưng nó chắc chắn sẽ đánh bại việc quần phải khởi động lại VS hai lần một giờ hoặc hơn.

Tôi cho rằng điều này cũng áp dụng cho WPF, mặc dù tôi không sử dụng nó và chưa từng gặp sự cố ở đó.

Tôi cũng chưa thử tái tạo nó trên VS 2012 RC. Tôi không biết liệu nó đã được sửa ở đó hay chưa. Nhưng kinh nghiệm của tôi cho đến nay là nó vẫn bật lên ngay cả sau khi Microsoft tuyên bố đã sửa nó. Nó vẫn ở đó trong VS 2010 SP1. Tôi không nói rằng các lập trình viên của họ là những kẻ ngốc, tất nhiên không biết họ đang làm gì. Tôi cho rằng chỉ có nhiều nguyên nhân gây ra lỗi và / hoặc rất khó để tái tạo một cách đáng tin cậy trong phòng thí nghiệm. Đó cũng là lý do mà tôi chưa đích thân đệ trình bất kỳ báo cáo lỗi nào về nó (mặc dù tôi đã +1 những người khác), bởi vì tôi dường như không thể tái tạo nó một cách đáng tin cậy, giống như Người tuyết khả ái.

_{<end rant không nhắm vào ai cụ thể>}

Tôi đã từng gặp lỗi này trước đây, ngay cả trong Visual Studio 2008. Nó đã trở lại và phổ biến hơn trong Visual Studio 2012.

Đây là những gì tôi làm.

Dán cái này vào sự kiện xây dựng trước của dự án rắc rối:

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

Máy tính (nhấp chuột phải) -> quản lý -> Dịch vụ & Ứng dụng -> dịch vụ -> Bật trải nghiệm Ứng dụng

Đã làm cho tôi!

Tôi đã gặp vấn đề tương tự trong Visual Studio 2013. Tôi không chắc điều gì đã gây ra điều này cho dự án của mình, nhưng tôi đã có thể khắc phục bằng cách làm sạch giải pháp và xây dựng lại nó.

1. Xây dựng> Giải pháp sạch
2. Xây dựng> Giải pháp xây dựng lại

Ít nhất trong trường hợp của tôi, tôi nhận thấy rằng visual studio 2012 đang tạo ít nhất hai tiến trình ma msbuild.exe, không bị hủy sau khi xây dựng. Những thây ma này dường như đang gây ra hiện tượng khóa tệp.

Diệt msbuild.exe's là giải pháp một lần, nó cần được thực hiện trên cơ sở bản dựng.

Nhưng sau đó tôi đã phát hiện ra rằng tôi có thể vô hiệu hóa xây dựng song song một lần và mãi mãi - vào Công cụ> Tùy chọn> Dự án và Giải pháp> Xây dựng và Chạy> "số lượng tối đa các bản dựng dự án song song" - theo mặc định, nó có giá trị là 8, tôi đã chuyển sang 1. Hoạt động như sự quyến rũ.

Tất nhiên bây giờ các bản dựng chậm hơn một chút, nhưng tốt hơn là an toàn. Ít nhất đối với dự án nhỏ cụ thể này, tôi không cần nhiều hơn một luồng xây dựng.

Tôi hiểu đây là một câu hỏi cũ. Thật không may, tôi đã gặp phải vấn đề tương tự với .net core 2.0ứng dụng của mình visual studio 2017. Vì vậy, tôi đã nghĩ đến việc chia sẻ giải pháp phù hợp với tôi. Trước giải pháp này, tôi đã thử các bước dưới đây.

1. Đã khởi động lại studio trực quan
2. Đã đóng tất cả các ứng dụng
3. Làm sạch giải pháp của tôi và xây dựng lại

Không có bước nào ở trên không khắc phục được sự cố.

Và sau đó tôi mở quy trình Task Managerđã chọn của mình dotnetvà sau đó nhấp vào nút Kết thúc tác vụ. Sau đó, tôi đã mở Visual Studio của mình và mọi thứ đều hoạt động tốt.

Xem câu trả lời của tôi tại đây nếu bạn đang gặp sự cố này trong khi chạy thử nghiệm đơn vị. Câu trả lời được sao chép bên dưới:

Dựa trên câu trả lời của Sébastien, tôi đã thêm một bước xây dựng trước vào dự án thử nghiệm của mình để tự động giết bất kỳ vstest.*tệp thực thi nào vẫn đang chạy. Lệnh tạo trước sau đây phù hợp với tôi:

taskkill /f /im vstest.*
exit 0

Các exit 0lệnh là ở cuối để ngăn chặn xây dựng thất bại khi không có vstest.*thực thi chạy.

Gần đây, tôi đã gặp sự cố với Visual Studio 2012 với cùng một mô tả lỗi: "Quy trình không thể truy cập tệp vì nó đang được sử dụng bởi một quy trình khác ..."

Để khắc phục điều này, trước hết bạn cần hiểu ứng dụng vẫn sử dụng nó. Tôi đã tắt tất cả các quy trình như "MSBuild" và "MSBuild host". Nhưng điều này là không đủ. Nếu bạn đã cài đặt "Hợp đồng mã" và bật thì đôi khi phải mất các tệp DLL của bạn để kiểm tra và treo khi thao tác này.

Vì vậy, bạn cần phải dừng tất cả các quá trình của "CCCheck.exe" và chỉ có vậy.

Cuối cùng, để hiểu rằng quá trình đang sử dụng DLL của bạn, bạn luôn có thể cố gắng chỉ Xóa thư mục "obj" trong Trình quản lý tệp của mình và thao tác này sẽ thất bại, bạn có thể thấy "Cửa sổ thông báo" với mô tả về hoạt động treo. Ngoài ra, là một biến thể, bạn có thể thử sử dụng ứng dụng "Sys Internals Suite".

Đã làm cho tôi. Task Manager -> Tên dự án -> Kết thúc nhiệm vụ. (tôi đã có 3 quy trình giống nhau với tên dự án của tôi);

VS 2013; Thắng 8;

Đảm bảo rằng mọi lần chạy ứng dụng trước đó (ví dụ: bắt đầu mà không có tùy chọn gỡ lỗi) thực sự bị dừng. Tôi đang làm việc trên một ứng dụng WPF, khởi động mà không cần gỡ lỗi và đã giảm thiểu nó khi tôi liên tục gặp lỗi. Sau khi đóng ứng dụng, hành vi VS đã trở lại bình thường.

Tôi đã bị cản trở bởi sự cố này trong Visual Studio 2017. Sự cố bắt đầu khoảng hai hoặc ba tuần trước và đã ảnh hưởng nghiêm trọng đến năng suất của tôi. Clean và Rebulid không hoạt động; thậm chí khởi động lại máy của tôi không thực hiện công việc.

Một cách để giải quyết vấn đề là làm sạch hội đồng vi phạm và xây dựng (thay vì xây dựng lại) dự án bạn muốn chạy ngay sau đó. Điều này hoạt động khoảng 30% thời gian.

Tuy nhiên, có lẽ giải pháp đáng tin cậy nhất mà tôi đã tìm thấy là mở Dấu nhắc lệnh dành cho nhà phát triển và sử dụng msbuildtrực tiếp. Tôi đã làm việc này trong ba ngày qua và cho đến nay vấn đề vẫn chưa xảy ra một lần.

Trong trường hợp của tôi là tôi đã bật "Hiển thị tất cả các tệp". Visual Studio 2017

Chạy đi taskmanager.
Xác định vị trí netcorevà xóa nó.
Sau đó, bạn có thể xóa tệp theo cách thủ công hoặc bằng cách chạy Clean.

Đây là suy đoán thuần túy, và không phải là câu trả lời.

Tuy nhiên, tôi đã gặp vấn đề này trong một thời gian.

Tôi đã đến sau một thời gian để nghi ngờ có sự tương tác giữa VS và các biện pháp phòng ngừa AV của tôi.

Sau khi một số chơi, có vẻ như nó có thể đã biến mất khi tôi sửa đổi chống virus của tôi để tất cả mọi thứ dưới

C: \ Users [tên người dùng] \ AppData \ Local \ Microsoft \ VisualStudio \ 10.0 \ ProjectAssemblies

thư mục không được bao gồm trong bảo vệ thời gian thực.

Có vẻ như bản dựng thực sự ghi DLL ở đây trước, sau đó sao chép nó vào vị trí bản dựng cuối cùng.

Nó có thể là quá muộn. Nhưng, tôi gặp phải vấn đề tương tự và trong trường hợp của tôi, dự án đã tự tham chiếu. Do đó, xóa nó khỏi Tài liệu tham khảo hoạt động như một cái duyên !!!

Tôi đã tìm thấy cách nhanh nhất mà không cần đóng biểu mẫu hoặc khởi động lại VisualStudio là truy cập trang biên dịch của dự án và nhấp vào nút "Tùy chọn biên dịch nâng cao ...". Sau đó, thực hiện bất kỳ thay đổi nào đối với một trong các tùy chọn (giả sử thay đổi Tạo thông tin gỡ lỗi từ Đầy đủ thành chỉ pdb), rồi bấm OK. Nó hoạt động mọi lúc và sẽ phải làm cho đến khi MS sửa lỗi này (tôi chưa bao giờ gặp sự cố này cho đến khi tôi chuyển từ VS2012 sang VS2013)

Một lưu ý khác, nếu bạn không thể làm sạch dự án hoặc giải pháp, nó sẽ không xây dựng. Các tệp chắc chắn bị khóa bởi VS (không phải là vấn đề chống vi-rút, ít nhất là không phải trong trường hợp của tôi)

Tôi đã thử tất cả các đề xuất này cũng như các đề xuất khác được tìm thấy ở nơi khác và điều duy nhất phù hợp với tôi là khởi động lại máy tính của mình. Sau đó, tôi đã thực hiện một giải pháp sạch sẽ tiếp theo là xây dựng lại. Tôi đang sử dụng Visual Studio 2013 để tham khảo.

Tôi đã gặp phải vấn đề tương tự này và những gì tôi tìm thấy là có thực sự đang chạy nhiều ứng dụng biểu mẫu Windows trong nền. Điều này xảy ra khi ứng dụng của bạn có hai biểu mẫu và bạn đóng biểu mẫu thứ hai không phải là biểu mẫu chính của bạn, do đó ứng dụng sẽ không hoàn toàn thoát.

Tôi thường chạy ứng dụng của mình

• thông qua exe của nó hoặc
• chạy mà không cần gỡ lỗi

Giải pháp là đóng phiên bản khác của ứng dụng biểu mẫu Windows . Đây là một cách để luôn đóng phiên bản ứng dụng của bạn.

Lệnh xây dựng trước

(if exist "$(TargetDir)*old.pdb" del "$(TargetDir)*old.pdb") & (if exist "$(TargetDir)*.pdb" ren "$(TargetDir)*.pdb" *.old.pdb)

Đã giúp đỡ

[Đã giải quyết] Lỗi: Không thể truy cập tệp bin / Gỡ lỗi /… vì nó đang được sử dụng bởi một quy trình khác:

Tôi đang nói rằng bạn gặp lỗi này khi bạn đang cố gắng chạy hai biểu mẫu cửa sổ cái khác, chẳng hạn như lần đầu tiên tải một biểu mẫu, sau đó đôi khi nó sẽ tự động biến mất và biểu mẫu thứ hai được tải lên màn hình.

Về cơ bản, bạn cần đóng biểu mẫu đầu tiên đang chạy ở chế độ nền và nguyên nhân chính gây ra lỗi này.

Để đóng biểu mẫu đầu tiên, bạn phải thêm hai dòng mã này trong trình xử lý sự kiện tải biểu mẫu thứ hai.

    Form1 form = new Form1();
    form.Close();

Điều này sẽ giải quyết lỗi một cách hoàn hảo.

Một giải pháp đơn giản là bạn vào thư mục bin \ Debug, xóa tất cả các tệp trong thư mục đó, sau đó xây dựng lại. Nếu nó không hoạt động, hãy đóng Visual Studio, sau đó chuyển đến thư mục bin \ Debug bằng cách sử dụng trình khám phá tệp, ở bộ mã bên trái, nhấp vào Tệp> Mở Dấu nhắc lệnh> Mở Dấu nhắc lệnh với tư cách Quản trị viên> Nhập lệnh này "DEL / F / Q / A * "> sau đó xây dựng lại

Tôi thấy câu trả lời của Cody Gray hữu ích một phần, ở chỗ nó đã hướng tôi đến nguồn gốc thực sự của vấn đề mà một số bạn cũng có thể đang gặp phải: quá trình thực thi thử nghiệm của visual studio vẫn mở theo mặc định và duy trì khóa các tệp.

Để dừng hành vi chủ yếu là vô ích đó, hãy làm theo hướng dẫn từ https://connect.microsoft.com/VisualStudio/feedback/details/771994/vstest-executionengine-x86-exe-32-bit-not-closing-vs2012-11-0 -50727-1-rtmrel

Bỏ chọn menu Kiểm tra -> Cài đặt Kiểm tra -> "Tiếp tục Chạy Công cụ Thực thi Kiểm tra"

Vấn đề của tôi là dotnet bị treo và bất cứ khi nào VS cố gắng tạo một dll mới hoặc truy cập một cái cũ, quá trình dotnet sẽ bám vào dll và ngăn visual studio sao chép dll. Giải pháp chỉ là kết thúc tất cả các tác vụ dotnet trong trình quản lý tác vụ (nó sẽ chỉ thực sự loại bỏ cái chết, nếu bạn đang cố gắng kết thúc một cái mà nó không tắt, điều đó có nghĩa là nó đang hoạt động).

Đóng VisualStudio, ctrl-alt-delete, chọn Trình quản lý tác vụ, tìm và kết thúc tất cả các quy trình MSBuild - VisualStudio về cơ bản có một lỗi khá nghiêm trọng trong đó nó mất quyền kiểm soát trình gỡ lỗi và trình gỡ lỗi duy trì khóa tệp .pdb trong trình gỡ lỗi / bin thư mục. Sau khi bạn kết thúc tất cả các quy trình MSBuild (trình gỡ lỗi), hãy xóa thư mục / debug / bin và mở lại giải pháp của bạn trong Visual Studio. Bạn tốt để đi ngay bây giờ. Microsoft cần phải sửa lỗi tào lao này.

Tôi đã mở một câu hỏi riêng về VS 2017 có hành vi tương tự sau một lần cập nhật. Mặc dù sự cố dường như được tạo ra bởi chương trình chống vi-rút.

Tôi đã thêm thư mục bin vào danh sách loại trừ chống vi-rút, khởi động lại máy và bây giờ nó có vẻ hoạt động.

Tôi đã giải quyết vấn đề này ..

gần gỡ lỗi, bạn thấy menu thả xuống với một số cấu hình. Mặc định có CPU Bất kỳ. Chọn x86 và chạy chương trình nó sẽ hoạt động. Nếu x86 không có ở đó, hãy chuyển đến trình quản lý cấu hình và thêm x86

Khác, ugh, nhưng nó dễ dàng và hiệu quả với tôi trong VS 2013. Hãy nhấp vào dự án. Trong bảng thuộc tính phải có một mục nhập có tên Tệp Dự án với một giá trị

(tên dự án của bạn) .vbproj

Thay đổi tên dự án - chẳng hạn như thêm -01 vào cuối. Tệp .zip ban đầu đã bị khóa vẫn còn đó, nhưng không còn được tham chiếu ... để công việc của bạn có thể tiếp tục. Lần tới khi máy tính được khởi động lại, khóa đó sẽ biến mất và bạn có thể xóa tệp lỗi.