Xây dựng Visual Studio không thành công: không thể sao chép tệp exe từ obj \ debug sang bin \ debug


193

Cập nhật: Một dự án mẫu tái tạo lỗi này có thể được tìm thấy ở đây tại Microsoft Connect . Tôi cũng đã thử nghiệm và xác minh rằng giải pháp được đưa ra trong câu trả lời được chấp nhận dưới đây hoạt động trên dự án mẫu đó. Nếu giải pháp này không phù hợp với bạn, có lẽ bạn đang gặp vấn đề khác (thuộc về một câu hỏi riêng).


Đây là một câu hỏi được hỏi trước đó, cả ở đây trên Stack Overflow và những nơi khác, nhưng không có gợi ý nào tôi tìm thấy cho đến nay đã giúp tôi, vì vậy tôi chỉ cần thử hỏi một câu hỏi mới.

Kịch bản: Tôi có một ứng dụng Windows Forms đơn giản (C #, .NET 4.0, Visual Studio 2010). Nó có một vài biểu mẫu cơ sở mà hầu hết các biểu mẫu khác thừa hưởng từ nó, nó sử dụng Entity Framework (và các lớp POCO) để truy cập cơ sở dữ liệu. Không có gì lạ mắt, không đa luồng hoặc bất cứ điều gì.

Vấn đề: Tất cả đều ổn trong một thời gian. Sau đó, tất cả hoàn toàn bất ngờ, Visual Studio đã thất bại trong việc xây dựng khi tôi chuẩn bị khởi chạy ứng dụng. Tôi nhận được cảnh báo "Không thể xóa tệp '... bin \ Debug \ [ProjectName] .exe'. Truy cập vào đường dẫn '... bin \ Debug \ [ProjectName] .exe' bị từ chối." và lỗi "Không thể sao chép tệp 'obj \ x86 \ Debug \ [ProjectName] .exe' thành 'bin \ Debug \ [ProjectName] .exe'. Quá trình không thể truy cập tệp 'bin \ Debug \ [ProjectName] .exe 'bởi vì nó đang được sử dụng bởi một quy trình khác. " (Tôi nhận được cả cảnh báo và lỗi khi chạy Rebuild, nhưng chỉ có lỗi khi chạy Build - không nghĩ rằng điều đó có liên quan?)

Tôi hiểu hoàn toàn tốt những gì thông báo cảnh báo và lỗi nói: Visual Studio rõ ràng đang cố gắng ghi đè tệp exe trong khi nó đồng thời có khóa trên đó vì một số lý do. Tuy nhiên, điều này không giúp tôi tìm ra giải pháp cho vấn đề ... Điều duy nhất tôi thấy làm việc là tắt Visual Studio và khởi động lại. Xây dựng và khởi chạy sau đó hoạt động, cho đến khi tôi thực hiện thay đổi trong một số biểu mẫu, sau đó tôi lại gặp vấn đề tương tự và phải khởi động lại ... Khá là bực bội!

Như tôi đã đề cập ở trên, đây dường như là một vấn đề đã biết, vì vậy có rất nhiều giải pháp được đề xuất. Tôi sẽ chỉ liệt kê những gì tôi đã thử ở đây, vì vậy mọi người biết những gì cần bỏ qua:

  • Tạo một giải pháp sạch mới và chỉ cần sao chép các tệp từ giải pháp cũ.
  • Thêm phần sau vào phần sau vào sự kiện xây dựng trước của dự án:

    if exist "$(TargetPath).locked" del "$(TargetPath).locked"
       if not exist "$(TargetPath).locked" if exist "$(TargetPath)" move "$(TargetPath)" "$(TargetPath).locked"
    
  • Thêm phần sau vào thuộc tính dự án (tệp .csproj):

    <GenerateResourceNeverLockTypeAssemblies>true</GenerateResourceNeverLockTypeAssemblies>

Tuy nhiên, không ai trong số họ làm việc cho tôi, vì vậy bạn có thể thấy lý do tại sao tôi bắt đầu hơi thất vọng. Tôi không biết nơi nào khác để tìm, vì vậy tôi hy vọng ai đó có thứ gì đó để cho tôi! Đây có phải là một lỗi trong VS không, và nếu vậy thì có một bản vá? Hoặc tôi đã làm điều gì sai, tôi có một tài liệu tham khảo tròn hoặc tương tự, và nếu vậy làm thế nào tôi có thể tìm ra?

Mọi góp ý đều được đánh giá cao :)

Cập nhật: Như đã đề cập trong bình luận bên dưới, tôi cũng đã kiểm tra bằng Process Explorer rằng đó thực sự Visual Studio đang khóa tệp.


4
Bạn đã kiểm tra nếu ứng dụng của bạn đóng đúng cách? Trình quản lý tác vụ có hiển thị cho bạn [ProjectName] .exe trong danh sách các quy trình không?
miensol

2
Tôi đã có điều này trước đây và tôi chỉ đơn giản đổi tên tệp thành .old vv và chạy lại bản dựng. Không chính xác là một sửa chữa tôi biết, nhưng nó đã làm việc cho tôi.
codbadger

@miensol: Vâng, có vẻ như đóng cửa đúng cách. Tôi nhận được "Chương trình '[1848] [ProjectName] .vshost.exe: Managed (v4.0.30319)' đã thoát với mã 0 (0x0)." @Barry: đổi tên tệp exe trong bin \ Debug hoạt động, nhưng như bạn đã nói nó không thực sự là một giải pháp và sẽ khá khó chịu khi phải làm mỗi lần. Tốt hơn một chút so với khởi động lại Visual Studio mặc dù ...
Julian

2
@Naliluj: Tôi đã xem qua này bài báo từ một diễn đàn Microsoft giải thích rằng nó có thể liên quan đến các tập tin tài nguyên. Nếu bạn đang sử dụng tệp resx, điều này có thể đưa ra gợi ý.
Patrick

1
Đối với hậu thế, tôi đã gặp vấn đề này và nó đã được giải quyết bằng cách thêm phần tử <GenerateResourceNeverLockTypeAssemblies> true </ GenerateResourceNeverLockTypeAssemblies> vào tệp csproj của tôi.
Đây là

Câu trả lời:


117

Điều này nghe có vẻ ngu ngốc, nhưng tôi đã thử tất cả các giải pháp này, chạy VS2010 trên Windows 7. Không ai trong số họ làm việc ngoại trừ việc đổi tên và xây dựng, điều RẤT TUYỆT VỜI ít nói nhất. Cuối cùng, tôi đã tìm ra thủ phạm và tôi thấy khó tin. Nhưng tôi đã sử dụng đoạn mã sau trong AssociationInfo.cs ...

[assembly: AssemblyVersion("2.0.*")]

Điều này khá phổ biến, nhưng vì một số lý do, việc thay đổi phiên bản thành 2.0.0.0 khiến mọi thứ hoạt động trở lại. Tôi không biết đó có phải là một thứ cụ thể của Windows 7 không (tôi chỉ mới sử dụng được 3-4 tuần), hoặc nếu nó là ngẫu nhiên, hay cái gì, nhưng nó đã sửa nó cho tôi. Tôi đoán rằng VS đang xử lý từng tệp mà nó tạo ra, vậy nó sẽ biết cách tăng thứ? Tôi thực sự không chắc chắn và chưa bao giờ thấy điều này xảy ra trước đây. Nhưng nếu có người khác cũng kéo tóc ra, hãy thử xem.


12
Đó là một ý tưởng điên rồ, tôi sẽ cung cấp cho bạn điều đó;) Điều thậm chí còn điên rồ hơn, là nó thực sự có hiệu quả! Tôi đã thử nghiệm điều này nhiều lần và tôi có thể xác nhận rằng khi sử dụng phiên bản lắp ráp như "2.0. *" Tôi gặp lỗi, nhưng khi tôi sử dụng "2.0.0" thì nó hoạt động như một bùa mê! Tôi kêu gọi nhiều người thử nghiệm điều này, và nếu bạn thấy nó hoạt động, hãy bỏ phiếu cho câu trả lời này, bởi vì đây là điều cần được biết đến! Hy vọng Microsoft chọn ra điều này ... Cảm ơn bạn drharris :)
Julian

2
điều này không hiệu quả với tôi, khi tôi khởi động lại VS đôi khi tôi không gặp lỗi. Mỗi lần tôi gặp lỗi này, tôi phải khởi động lại VS 2010
Sharique

6
fyi ... điều này không làm việc cho tôi. Các cài đặt của tôi luôn luôn là: [assembly: AssociationVersion ("1.0.0.0")] [assembly: AssociationFileVersion ("1.0.0.0")]
tbone

4
Nếu bạn hiện có [lắp ráp: Hội đồng ("1.0.0.0")], hãy thay thế bằng [lắp ráp: Hội đồng ("2.0.0.0")] (tức là '2' thay vì '1'). Nó làm việc cho tôi. Mặc dù tôi chưa kiểm tra, nhưng có thể chỉ cần thay đổi phiên bản thành bất kỳ thứ gì khác ngoài những gì bạn có bây giờ có thể khắc phục vấn đề này.
Frederick The Fool

1
Làm việc cho dll quá! VS cho biết không thể sao chép dll và sau khi thay đổi BÓNG [lắp ráp: Lắp ráp] và [lắp ráp: Lắp rápFileVersion ()] từ 1.0. * Sang 2.0.0.0, nó đã hoạt động.
AZ.

14

Vì tôi không nhận được bất kỳ phản hồi nào nữa về vấn đề này, tôi nghĩ tôi chỉ chia sẻ những gì kết thúc là giải pháp của mình:

Theo đề xuất của Barry trong một bình luận cho bài viết gốc, việc đổi tên thủ công '... bin \ Debug [ProjectName] .exe' thành một cái gì đó khác (ví dụ '[ProjectName] 1.exe' ) là một cách giải quyết (I ' Tuy nhiên, tôi không được phép tự xóa tệp và tôi phải nói rằng tôi thấy hơi kỳ lạ vì người ta tin rằng khóa tương tự ngăn chặn xóa cũng sẽ ngăn đổi tên ...). Đó không phải là một giải pháp tốt, nhưng nó hợp lý nhanh chóng (ít nhất là sau khi bạn thực hiện vài lần, nó gần như trở thành một thói quen), và ít nhất là nhanh hơn so với khởi động lại Visual Studio, đó là những gì tôi đã làm lúc đầu.

Trong trường hợp ai đó thắc mắc, tôi cũng có thể nói thêm rằng tôi chỉ thấy vấn đề này một cách ngẫu nhiên. Nó thường xảy ra sau khi tôi thực hiện một số thay đổi trong chế độ thiết kế của biểu mẫu (nhưng không phải lúc nào cũng vậy). Nó thường không xảy ra nếu tôi chỉ thay đổi mã logic nghiệp vụ hoặc mã không liên quan đến hình ảnh (nhưng đôi khi nó không ...). Thật đáng thất vọng, nhưng ít nhất tôi có một bản hack phù hợp với mình - hãy hy vọng rằng dự án tiếp theo của tôi cũng không gặp phải vấn đề này ...

@Barry: nếu bạn muốn nhận được tín dụng cho bình luận của mình, xin vui lòng gửi nó dưới dạng câu trả lời và tôi chắc chắn sẽ chấp nhận nó :)


Tôi đã bình chọn điều này vì đây là những gì tôi đã làm trong quá khứ. Tôi đồng ý, đó là một giải pháp bẩn nhưng nó hoạt động. VS đã có vấn đề này trong một vài lần lặp lại. Tôi đang tải dự án của tôi từ một thư mục mạng là tốt. Nó hoàn toàn đáng tin cậy, nhưng nó không thành vấn đề. Nó không thành vấn đề nếu nó là ánh xạ ổ đĩa hoặc UNC. Vâng, MS thực sự cần phải sửa cái này. Họ có một lỗi kín cho nó nói rằng không thể sao chép. Què!
Josh Robinson

14

Tôi tìm thấy một giải pháp đơn giản, chỉ cần vô hiệu hóa Dịch vụ lập chỉ mục Windows cho thư mục dự án và thư mục con


2
Cái này cũng có tác dụng với tôi. Tôi không chắc chắn rằng tôi hiểu lý do tại sao, vì quá trình thám hiểm cho thấy devenv.exe đang giữ tay cầm khóa. Tuy nhiên, tắt chỉ mục đã khắc phục vấn đề.
Fopedush

1
@Fopedush Tôi gặp phải vấn đề này với cùng một giải pháp, mặc dù lúc đó tôi không thấy câu hỏi này. Câu trả lời này có một số giải thích về lý do tại sao nó giúp.
Darren Hale

1
Điều này đã làm điều đó cho tôi.
Martin Capodici

12

Tôi có cùng một vấn đề (MSB3021) với dự án WPF trong VS2008 (trên Windows 7 x32). Vấn đề xuất hiện nếu tôi cố chạy lại ứng dụng quá nhanh sau lần chạy trước. Sau vài phút tệp exe tự mở khóa và tôi có thể chạy lại ứng dụng. Nhưng một khoảng dừng dài như vậy làm tôi tức giận. Điều duy nhất thực sự giúp tôi là chạy VS với tư cách Quản trị viên.


1
Tôi đã tìm thấy báo cáo lỗi gần đây về vấn đề chính xác này: connect.microsoft.com/VisualStudio/feedback/details/558848/. Báo cáo lỗi đó cung cấp một dự án mẫu có thể tái tạo lỗi. Giải pháp được đề xuất bởi drharris cũng hoạt động ở đó (xem cách giải quyết được đăng trong liên kết ở trên để biết giải pháp từng bước cho dự án mẫu).
Julian

Đây là giải pháp duy nhất làm việc cho tôi là tốt. Cảm ơn @Nailuj!
Cầu thủ chạy cánh

Điều này chắc chắn dễ dàng hơn so với khởi động lại VS.
Elvedin Hamzagic

1
"Không tìm thấy trang" cho vấn đề kết nối, có phải họ đã xóa nó khỏi sự bối rối = S Đã bao giờ có một giải pháp / cách giải quyết được đăng cho vấn đề này chưa?
Coops

9

Khi tôi gặp phải vấn đề này, đó là vấn đề mà dự án tôi đang cố gắng xây dựng được đặt là dự án Khởi động trong giải pháp làm cho .exe trong thư mục obj bị khóa (nó cũng xuất hiện trong trình quản lý tác vụ của bạn,) nhấp chuột phải vào một dự án khác trong giải pháp của bạn và chọn thiết lập dự án khởi động. Điều này sẽ giải phóng khóa, loại bỏ nó khỏi trình quản lý tác vụ và sẽ cho phép bạn xây dựng.


1
Điều này làm việc mỗi lần cho tôi. Nó dường như được thực hiện với quy trình vshost được tạo và bắt đầu cho các dịch vụ
jaywayco

8

Tôi đã thử tất cả các đề xuất khác trong các câu trả lời ở đây, không có gợi ý nào trong số đó. Cuối cùng, tôi đã sử dụng Trình giám sát quy trình để phát hiện ra rằng .exe của tôi mà VS2010 không thể xây dựng đã bị khóa bởi quy trình Hệ thống (PID = 4). Tìm kiếm SO cho các tình huống liên quan đến điều này mang lại câu trả lời này .

Tóm tắt: nếu bạn tắt dịch vụ Trải nghiệm ứng dụng (như tôi đã làm) thì hãy bật lại và khởi động nó. Hai năm tăng nặng kết thúc.


+1 Trước đây tôi đã thử mọi thứ khác (1. trình quản lý tác vụ, 2. trình thám hiểm quy trình tức là xử lý chặt các cửa sổ nào sẽ không cho tôi làm, 3. Vô hiệu hóa phần mềm chống vi-rút, 4. ngoại trừ APP_DATA / Local / Microsoft / Visual Studio khỏi dịch vụ Lập chỉ mục Windows. ) nhưng mẹo này lại: Dịch vụ "Trải nghiệm ứng dụng" là dịch vụ duy nhất giúp tôi đập đầu vào tường. Tôi kích hoạt nó và vấn đề đã biến mất. Điều thú vị là, sau khi tôi vô hiệu hóa nó một lần nữa, mọi thứ vẫn ổn. Tôi không có vấn đề gì nữa. Nhưng chắc chắn đây là điều duy nhất sắp xếp nó cho tôi.
Tomás

Làm việc cho tôi quá !!! Điều duy nhất khác cũng hoạt động là xóa thư mục bin trước khi chạy ứng dụng, nhưng bạn phải xóa luôn trước khi chạy, rất khó chịu.
E_Blue

6

Tôi cũng gặp một vấn đề rất giống với vấn đề này và thấy lý do trong trường hợp của tôi là tôi đã tạo thư mục bin \ debug có sẵn dưới dạng thư mục dùng chung trong VMware và VMware, Explorer trong máy khách VM hoặc thậm chí có thể chống vi-rút chương trình theo khách (mặc dù tôi không nghĩ rằng tôi đã cài đặt một cái) đang giữ một tay cầm cho (các) tệp.


Tôi đã cài đặt Avast và sáng nay tôi gặp một lỗi MVC ngẫu nhiên nói rằng dll của tôi có virus. Sau lỗi, tôi không thể xây dựng dự án MVC của mình nữa. Tôi đã thêm một ngoại lệ vào Avast File System Shield và mọi thứ đang hoạt động trở lại.
Bụi bẩn


4

Tôi khuyên bạn nên tải xuống Process Explorerđể tìm hiểu chính xác quá trình khóa tệp. Nó có thể được tìm thấy tại:

http://technet.microsoft.com/en-us/sysiternals/bb896653.aspx


Tôi đồng ý - không nhất thiết là VS đang khóa tệp. Người kiểm tra virus có thể phạm tội này. Hãy thử tắt trình kiểm tra vi-rút của bạn để xem có giúp được không.
Polyfun

Xin lỗi, tôi quên đề cập rằng tôi đã làm điều đó. Và nó nói rằng đó là Visual Studio (devenv.exe) có khóa trên tệp ([ProjectName] .vshost.exe). Vì vậy, điều đó cũng không giúp tôi nhiều.
Julian

@ShellShock: vô hiệu hóa phần mềm chống vi-rút của tôi (Avast) cũng không giúp được gì.
Julian

Đối với tôi, bằng cách sử dụng Sysiternals ProcessExplorer, tôi có thể thấy một tay cầm cho tệp đó, nhưng khi tôi nhấp vào nó, không có ứng dụng nào được hiển thị đang giữ nó và khi tôi cố gắng đóng tay cầm, tôi nhận được "Quá trình mở lỗi: xử lý là không hợp lệ." lỗi trong ProcessExplorer. Vậy mà khóa vẫn tồn tại.
xương đòn

4

Sử dụng Visual Studio tôi không bao giờ có thể đưa ra một dự án đơn giản để tái tạo lỗi.

Giải pháp của tôi là vô hiệu hóa quy trình Visual Studio Hosting.

Đối với những người quan tâm, tôi đã đính kèm một dấu vết xử lý cho xử lý vi phạm:

0:044> !htrace 242C
--------------------------------------
Handle = 0x000000000000242c - OPEN
Thread ID = 0x0000000000001cd0, Process ID = 0x0000000000001a5c

0x000000007722040a: ntdll!ZwCreateFile+0x000000000000000a
0x0000000074b4bfe3: wow64!whNtCreateFile+0x000000000000010f
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x00000000772184c8: ntdll!LdrpInitializeProcess+0x00000000000017e2
0x0000000077217623: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bea0
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773d0066: ntdll_773b0000!NtCreateFile+0x0000000000000012
0x000000007541b616: KERNELBASE!CreateFileW+0x000000000000035e
0x0000000075b42345: KERNEL32!CreateFileWImplementation+0x0000000000000069
0x000000006a071b47: mscorwks_ntdef!StgIO::Open+0x000000000000028c
--------------------------------------
Handle = 0x000000000000242c - CLOSE
Thread ID = 0x0000000000000cd4, Process ID = 0x0000000000001a5c

0x000000007721ffaa: ntdll!ZwClose+0x000000000000000a
0x0000000074b3f2cd: wow64!whNtClose+0x0000000000000011
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x000000007724d177: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bfe4
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773cf992: ntdll_773b0000!ZwClose+0x0000000000000012
0x0000000075b42642: KERNEL32!BaseRegCloseKeyInternal+0x0000000000000041
0x0000000075b425bc: KERNEL32!RegCloseKey+0x000000000000007d
*** WARNING: Unable to verify checksum for mscorlib.ni.dll
0x0000000068f13ca3: mscorlib_ni+0x0000000000233ca3
0x0000000069bc21db: mscorwks_ntdef!CallDescrWorker+0x0000000000000033
0x0000000069be4a2a: mscorwks_ntdef!CallDescrWorkerWithHandler+0x000000000000008e
--------------------------------------
Handle = 0x000000000000242c - OPEN
Thread ID = 0x00000000000006cc, Process ID = 0x0000000000001a5c

0x0000000077220e0a: ntdll!NtOpenKeyEx+0x000000000000000a
0x0000000074b5d1c9: wow64!Wow64NtOpenKey+0x0000000000000091
0x0000000074b5313b: wow64!whNtOpenKeyEx+0x0000000000000073
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x000000007724d177: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bfe4
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773d0fca: ntdll_773b0000!NtOpenKeyEx+0x0000000000000012
0x0000000075b42721: KERNEL32!LocalBaseRegOpenKey+0x000000000000010c
0x0000000075b428c9: KERNEL32!RegOpenKeyExInternalW+0x0000000000000130
0x0000000075b427b5: KERNEL32!RegOpenKeyExW+0x0000000000000021
--------------------------------------
Handle = 0x000000000000242c - CLOSE
Thread ID = 0x0000000000000cd4, Process ID = 0x0000000000001a5c

0x000000007721ffaa: ntdll!ZwClose+0x000000000000000a
0x0000000074b3f2cd: wow64!whNtClose+0x0000000000000011
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x000000007724d177: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bfe4
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773cf992: ntdll_773b0000!ZwClose+0x0000000000000012
0x0000000075b42642: KERNEL32!BaseRegCloseKeyInternal+0x0000000000000041
0x0000000075b425bc: KERNEL32!RegCloseKey+0x000000000000007d
0x0000000068f13ca3: mscorlib_ni+0x0000000000233ca3
0x0000000069bc21db: mscorwks_ntdef!CallDescrWorker+0x0000000000000033
0x0000000069be4a2a: mscorwks_ntdef!CallDescrWorkerWithHandler+0x000000000000008e
--------------------------------------
Handle = 0x000000000000242c - OPEN
Thread ID = 0x0000000000001cd0, Process ID = 0x0000000000001a5c

0x0000000077220e0a: ntdll!NtOpenKeyEx+0x000000000000000a
0x0000000074b5d1c9: wow64!Wow64NtOpenKey+0x0000000000000091
0x0000000074b5313b: wow64!whNtOpenKeyEx+0x0000000000000073
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x00000000772184c8: ntdll!LdrpInitializeProcess+0x00000000000017e2
0x0000000077217623: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bea0
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773d0fca: ntdll_773b0000!NtOpenKeyEx+0x0000000000000012
0x0000000075b42721: KERNEL32!LocalBaseRegOpenKey+0x000000000000010c
0x0000000075b428c9: KERNEL32!RegOpenKeyExInternalW+0x0000000000000130
--------------------------------------
Handle = 0x000000000000242c - CLOSE
Thread ID = 0x0000000000000cd4, Process ID = 0x0000000000001a5c

0x000000007721ffaa: ntdll!ZwClose+0x000000000000000a
0x0000000074b3f2cd: wow64!whNtClose+0x0000000000000011
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x000000007724d177: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bfe4
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773cf992: ntdll_773b0000!ZwClose+0x0000000000000012
0x0000000075b42642: KERNEL32!BaseRegCloseKeyInternal+0x0000000000000041
0x0000000075b425bc: KERNEL32!RegCloseKey+0x000000000000007d
0x0000000068f13ca3: mscorlib_ni+0x0000000000233ca3
0x0000000069bc21db: mscorwks_ntdef!CallDescrWorker+0x0000000000000033
0x0000000069be4a2a: mscorwks_ntdef!CallDescrWorkerWithHandler+0x000000000000008e
--------------------------------------
Handle = 0x000000000000242c - OPEN
Thread ID = 0x0000000000001cd0, Process ID = 0x0000000000001a5c

0x0000000077220e0a: ntdll!NtOpenKeyEx+0x000000000000000a
0x0000000074b5d1c9: wow64!Wow64NtOpenKey+0x0000000000000091
0x0000000074b5313b: wow64!whNtOpenKeyEx+0x0000000000000073
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x00000000772184c8: ntdll!LdrpInitializeProcess+0x00000000000017e2
0x0000000077217623: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bea0
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773d0fca: ntdll_773b0000!NtOpenKeyEx+0x0000000000000012
0x0000000075b42721: KERNEL32!LocalBaseRegOpenKey+0x000000000000010c
0x0000000075b428c9: KERNEL32!RegOpenKeyExInternalW+0x0000000000000130

--------------------------------------
Parsed 0x358E stack traces.
Dumped 0x7 stack traces.
0:044> !handle 242c ff
Handle 242c
  Type          File
  Attributes    0
  GrantedAccess 0x120089:
         ReadControl,Synch
         Read/List,ReadEA,ReadAttr
  HandleCount   2
  PointerCount  3
  No Object Specific Information available

nếu bạn thấy ở đầu câu hỏi, có một liên kết đến Microsoft Connect với một báo cáo lỗi và một dự án mẫu tái tạo lỗi: connect.microsoft.com/VisualStudio/feedback/details/558848/ tựa
Julian

Vô hiệu hóa quá trình lưu trữ làm việc cho tôi. Nó tiếp tục hoạt động sau khi kích hoạt lại. Tôi đã dành 4 giờ để cố gắng khắc phục vấn đề này khi thử hàng trăm giải pháp. Đây là người duy nhất thậm chí từ xa dường như làm việc.
vẽ Chapin

4

NẾU VẤN ĐỀ CỦA BẠN KHÔNG ĐƯỢC GIẢI QUYẾT YET:

Lỗi của Visual studio là:

"Quá trình không thể truy cập tệp 'bin \ Debug ** app.exe **' vì nó đang được sử dụng bởi một quy trình khác."

Vì vậy, hãy chuyển đến trình quản lý tác vụ của windows (Ctrl + Shift + Esc), tìm tên ứng dụng của bạn và buộc nó đóng bằng Endprocces.


3

Đây là một khả năng khác:

Sau khi nhận được lỗi này trong vs2012 / win7, tôi đã đi và cố gắng xóa tệp trong thư mục bin và trình thám hiểm chỉ ra rằng tệp này được XAML UI Designer sử dụng.

Tôi đã đóng tất cả các tab tôi đã mở trong VS, đóng VS, sau đó đảm bảo tiêu diệt tất cả các quy trình MSBuild trong taskmanager. Cuối cùng, sau khi khởi động lại VS tôi đã có thể xây dựng giải pháp.


và một nguyên nhân có thể khác:

Tôi đã nhận thấy một nguyên nhân có thể khác cho vấn đề này. Sau khi thực hiện một số tái cấu trúc mã, chuyển các dự án vào và ra khỏi một giải pháp, các tham chiếu dự án của tôi không còn tham chiếu các dự án trong giải pháp như mong đợi.

Studio hình ảnh sai lệch này để nghĩ rằng nó có thể xây dựng một số dự án đồng thời, do đó tạo ra các khóa tập tin.

EDIT: Tôi đã xảy ra điều này trong một vài lần thậm chí gần đây với VS2012 và nó đã khắc phục nó một khi tôi đặt thứ tự xây dựng thành các phụ thuộc chính xác, giết bất kỳ quy trình msbuild nào mà VS vẫn chạy, sau đó khởi động lại VS. Tôi giết các tiến trình msbuild để chắc chắn, nhưng đóng VS cũng sẽ giết chúng.

Những gì tôi thường làm để gây ra điều này là tái cấu trúc một dự án sao cho nó dựa vào một dự án khác trong giải pháp mà nó không được tham chiếu trên bản dựng trước. Điều này đôi khi có vẻ nhầm lẫn VS và nó không cập nhật thứ tự xây dựng.

Để kiểm tra thứ tự xây dựng: Nhấp chuột phải vào Giải pháp trong Solution Explorer và chọn "Project Build Order ..." và xác minh rằng các phụ thuộc được ghi chú đúng cho từng dự án.


Gần đây chúng tôi đã trải nghiệm điều này trên một dự án WinPhone 8. Không thể giải thích, nguyên nhân là do sử dụng loại Tuple. Loại bỏ mã đã sử dụng một Tuple, vấn đề đã biến mất. Thêm mã trở lại vấn đề trả lại.
Seamus

Tôi gặp vấn đề tương tự với VS2012, việc đóng VS không thực hiện được mánh khóe - phải giết tất cả các tác vụ msbuild.exe bằng tay
mizzle

Tôi đang sử dụng VS 2013 và tôi đã có thể giết quá trình "XDesProc.exe * 32" (Trình thiết kế giao diện người dùng Microsoft Visual Studio XAML) trong trình quản lý tác vụ trước mỗi bản dựng và điều đó đã tạo ra mánh khóe. Không cần phải khởi động lại VS vì trình thiết kế UI XAML dường như tải lại mỗi khi bạn mở tệp * .xaml trong chế độ xem thiết kế.
Tim Sexton

3

Khởi động lại IIS- có thể là một quá trình gắn liền với trình gỡ lỗi


3

Vô hiệu hóa chương trình chống vi-rút và thử. Tôi cũng đang đối mặt với vấn đề đó ... nhưng trong trường hợp của tôi, phần mềm chống vi-rút đã chặn ứng dụng của tôi khi tôi tắt phần mềm chống vi-rút.


3

Tôi phải đối mặt với lỗi tương tự.

Tôi đã giải quyết vấn đề bằng cách xóa tất cả nội dung của các thư mục bin của tất cả các dự án / thư viện phụ thuộc.

Lỗi này chủ yếu xảy ra do thay đổi phiên bản.



1

Làm những việc đơn giản trước.

Kiểm tra xem một phần giải pháp của bạn không bị khóa bởi một quy trình đang chạy.

Chẳng hạn, tôi đã chạy "InstallUtil 'trên dịch vụ windows của mình (mà tôi thường kiểm tra đơn vị từ bảng điều khiển).

Điều này đã khóa một số dll của tôi trong thư mục bin của dự án dịch vụ windows. Khi tôi làm lại, tôi đã có ngoại lệ trong vấn đề này.

Tôi đã dừng dịch vụ windows, xây dựng lại và nó đã thành công.

Kiểm tra Trình quản lý tác vụ Windows cho Ứng dụng của bạn, trước khi thực hiện bất kỳ bước nâng cao nào trong vấn đề này.

Vì vậy, khi bạn nghe thấy tiếng bước chân, hãy nghĩ rằng ngựa không phải ngựa vằn! (từ bạn sinh viên y khoa)


1

Tôi đã có vấn đề tương tự. Nó nói không thể sao chép từ bin \ debug sang obj .....

Khi tôi xây dựng dự án web, tôi thấy dll của mình nằm trong thư mục bin chứ không phải trong bin \ debug. Trong quá trình xuất bản vs đã tìm kiếm các tệp trong bin \ debug. Vì vậy, tôi đã mở tệp dự án web trong trình soạn thảo và tìm kiếm các phiên bản của bin \ debug và tôi đã tìm thấy tất cả các dll được đề cập là bin \ debug \ myl Library.dll. Tôi đã xóa tất cả \ gỡ lỗi khỏi đường dẫn và xuất bản lại. Lần này vs đã có thể tìm thấy tất cả các dll trong thư mục bin và xuất bản thành công.

Tôi không biết làm thế nào đường dẫn này đã thay đổi trong tệp dự án web.

Tôi đã dành hơn 5 giờ để gỡ lỗi này và cuối cùng tự mình tìm ra giải pháp.

Đây là câu trả lời đúng .


1

Nếu không có cách nào ở trên hoạt động và bạn đang phát triển ứng dụng console:

Hãy thử gõ bất kỳ ký tự nào vào Program.cs, sau đó xóa nó. Tôi không biết tại sao điều này hoạt động, nhưng nó dường như giải quyết vấn đề 'Không thể sao chép' mỗi lần.


1

Điều này khá phổ biến gây ra bởi Avast.

Tôi thường có thể chạy các dự án của mình trong Bản phát hành bất kể, nhưng khi chạy trong gỡ lỗi, nó sẽ thường xuyên bị lỗi.

Tôi chỉ thêm một loại trừ cho thư mục dự án của tôi và vấn đề dường như biến mất. Tôi cho rằng điều này cũng có thể là do phần mềm chống vi-rút khác.


1

Đổi tên tệp .exe và .pub làm việc cho tôi, nhưng thực sự tẻ nhạt. Tôi cũng gặp phải vấn đề là tôi không thể chỉnh sửa trong phiên gỡ lỗi. Cuối cùng, tôi đã đi đến Trang Cài đặt Bảo mật Nâng cao, theo:

https://msdn.microsoft.com/query/dev10.query?appId=Dev10IDEF1&l=EN-US&k=k% 28 % 3dV4.0% 22% 29 & rd = đúng

Tôi bỏ chọn sau đó chọn lại hộp kiểm "Bật cài đặt bảo mật ClickOnce". Nó đã trở thành vấn đề miễn phí trong một số ngày nay ....


1

Đối với tôi điều này đã được gây ra bởi việc mở một dấu nhắc lệnh trong thư mục được nhắm mục tiêu (C:\users\username\source\repos\project\project\bin\debug\app.publish ).

Không chắc chắn tại sao DEBUGGING yêu cầu quyền truy cập vào thư mục xuất bản, nhưng việc đóng cửa sổ lệnh đã giải quyết vấn đề cho tôi.


1

Trong trường hợp ai đó đang gặp phải vấn đề này trong khi cố gắng gỡ lỗi Kiểm tra đơn vị hoặc Chạy thử nghiệm đơn vị, tôi đã phải hủy hai quy trình sau để giải phóng tệp:

các quá trình để giết.


0

Tôi đã thử một số giải pháp mà bạn cung cấp, nhưng thỉnh thoảng tôi vẫn nhận được lỗi này. Tôi khẳng định rằng quy trình của tôi không chạy và khi tôi cố xóa tệp thực thi bằng trình duyệt internet, nó sẽ bị xóa khỏi danh sách tệp, nhưng sau đó tôi nhấn F5 và voila, tệp đã trở lại. Nó đã không bị xóa ở tất cả.

Nhưng nếu tôi xóa tệp thông qua TotalCommander, tệp exe thực sự bị xóa và tôi có thể xây dựng dự án thành công.

Tôi đang sử dụng windows 7 x64 và tổng chỉ huy 7.56a 32 bit.


0

Không có câu trả lời nào khác phù hợp với tôi nhưng việc đóng tất cả các tab đang mở trong Visual Studio dường như đã giải quyết được vấn đề.


0

Tôi biết đây là một câu hỏi rất cũ, nhưng gần đây tôi đã gặp phải lỗi "không thể sao chép từ obj sang bin" trong VS 2012. Mỗi lần tôi cố gắng xây dựng lại một dự án nào đó, tôi nhận được thông báo. Giải pháp duy nhất là làm sạch trước mỗi lần xây dựng lại.

Sau khi điều tra nhiều, hóa ra tôi đã có một tuyên bố cảnh báo pragma chưa hoàn chỉnh trong một trong các tệp của mình mà không ngăn được quá trình biên dịch thành công, nhưng bằng cách nào đó, VS đã nhầm lẫn trong việc giữ (các) tệp bị khóa.

Trong trường hợp của tôi, tôi đã có phần sau ở đầu tệp:

#pragma warning(

Đó là nó. Tôi đoán rằng tôi đã cố gắng làm điều gì đó một thời gian trước và bị phân tâm và không bao giờ kết thúc quá trình, nhưng các cảnh báo của VS về dòng cụ thể đó đã bị mất trong shuffle. Cuối cùng, tôi nhận thấy cảnh báo, loại bỏ dòng và xây dựng lại công trình mỗi lần kể từ đó.


0

Khi tôi đối mặt với một vấn đề tương tự, điều duy nhất có vẻ hiệu quả là:

  • Nhấp chuột phải vào dự án, đi tới Cài đặt và đảm bảo rằng cả hai bản dựng Gỡ lỗi và Phát hành đều nhắm đến cùng các cài đặt hoặc có các cài đặt trong đó ứng dụng cố gắng tải hoặc lưu.
  • Xóa thư mục C: \ Users (YourUserAccount) \ AppData \ Local (YourAppName).
  • Đảm bảo rằng không có tệp nào tôi có trong đó được coi là "Bị chặn". Nhấp chuột phải vào các tệp được bao gồm trong dự án của tôi, tôi nhận ra rằng một biểu tượng thực sự bị chặn và bị coi là xấu vì nó được tải xuống từ internet. Tôi đã phải nhấp vào nút Bỏ chặn (ví dụ: kiểm tra xem: http://devierkoeden.com/Images/Articles/Docateweb/CustomModules/Part1/BlockedFiles.png - "Tệp này đến từ một máy tính khác và có thể bị chặn để trợ giúp bảo vệ máy tính này. ").

0

Đối với Dịch vụ Windows sử dụng WCF, tôi đã kết thúc quá trình máy chủ WFC và nó đã hoạt động. Tôi ghét nó khi điều này xảy ra, và nó xảy ra ngẫu nhiên.


0

Giải pháp của tôi không liên quan gì đến các phiên bản, quy trình bị khóa, khởi động lại hoặc xóa tệp.

Vấn đề thực sự là do quá trình xây dựng bị lỗi và không đưa ra lỗi chính xác. Vấn đề thực tế là một lỗ hổng thiết kế:

// Either this should be declared outside the function, or..
SomeObject a = new SomeObject(); 

Task.Factory.StartNew(() =>
{
   while (true)
   {
      a.waitForSomething();
   }
});

// ...this should not be called
a.doSomething(); 

Sau khi thay đổi phạm vi "a" thành bên ngoài chức năng hoặc không sử dụng "a" sau Task.Factory.StartNew(); , tôi đã có thể xây dựng lại.

Điều này xảy ra khi sử dụng VS2012 Update 4 trên Windows7x64 sp1.

Thông báo lỗi:

C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Microsoft.Common.target (3390,5): lỗi MSB3030: Không thể sao chép tệp "obj \ x86 \ Debug \ xxx.exe" vì không tìm thấy .


0

Tôi đã tìm thấy với VS2013 tôi nhận được lỗi này thường xuyên. Một cái gì đó có vẻ hoạt động hợp lý là thực hiện Giải pháp Rebuild trước khi thử chạy ứng dụng. Tôi thấy rằng việc thực hiện SẠCH đôi khi hoạt động, nhưng Giải pháp Rebuild dường như hoạt động ổn định hơn.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.