Baru-baru ini saya mulai mendapatkan pesan ini secara acak:
File metadata '... \ Release \ project.dll' tidak dapat ditemukan di Visual Studio
Saya punya solusi dengan beberapa proyek di dalamnya. Mode build saat ini adalah Debug dan semua konfigurasi project disetel ke Debug. Tetapi ketika saya mencoba menjalankan proyek utama - kadang-kadang memberi saya beberapa kesalahan, yang semuanya adalah "File metadata '... \ Rilis \ projectX.dll' tidak dapat ditemukan" - dan, lihat, tertulis tentang RELEASE folder, meskipun mode saat ini adalah Debug. Mengapa? Saya mencoba untuk mencari referensi ke "Release \ projectX.dll" di dalam semua file solusi, dan saya menemukannya di file ResolveAssemblyReference.cache.
Saya melakukan pencarian yang baik melalui Internet dan menemukan beberapa orang dengan masalah yang sama, tetapi tidak ada solusi, atau setidaknya tidak ada solusi yang berfungsi.
Saya mencoba menghapus referensi ke proyek-proyek itu dan membacanya, tetapi dalam beberapa waktu saya mulai mendapatkan kesalahan ini lagi.
Sepertinya bug. Mengapa mencari proyek yang direferensikan di folder Rilis ketika saya selalu menggunakan mode Debug?
PS. Bagi mereka yang menemui masalah ini: Saya tidak bisa menyelesaikannya dengan cara yang mudah. Itu hilang hanya setelah saya menginstal ulang Windows :(
sumber
Jawaban:
Semua orang benar ... coba semuanya ... (dalam urutan waktu yang terbuang percuma)
sumber
.dll
dan.exe
. Untuk menghindari hal ini, buka.csproj
file dari setiap namespace dengan file teks, dan temukan jalur lama di file tersebut. keluarkan ini, bersihkan dan buat kembali solusinya. Ini berhasil untuk saya. Saya menghabiskan satu hari penuh untuk mengatasi masalah ini.Saya memiliki masalah yang sama persis. Solusi studio visual besar dengan 50+ proyek.
Semua referensi ditambahkan sebagai proyek. Urutan pembangunan proyek sudah benar (klik kanan pada proyek dan pilih urutan pembangunan).
Namun ketika membangun beberapa proyek tingkat yang lebih tinggi, proyek "akar" yang mereka andalkan tidak dibangun.
Masalahnya adalah bahwa proyek-proyek ini tidak dipilih untuk dibangun di bawah konfigurasi saat ini (tidak tahu bagaimana ini terjadi).
Untuk memeriksanya pilih "Pengelola Konfigurasi" (Bangun menu) dan periksa apakah proyek yang bermasalah disetel untuk dibangun.
sumber
Saat Anda mengatakan Anda menghapus referensi ke proyek tersebut dan menambahkannya kembali, bagaimana Anda menambahkannya kembali, tepatnya? Apakah Anda menggunakan tab "Jelajahi" dalam dialog "Tambahkan Referensi" di Visual Studio? Atau, apakah Anda menggunakan tab "Proyek" (yang mencantumkan proyek tetangga dalam solusi Anda)?
Edit : Jika Anda menggunakan tab "Jelajahi", dan secara manual menambahkan referensi ke .dll Anda yang terletak di folder / Release, maka Visual Studio akan selalu mencari .dll di lokasi itu, terlepas dari mode apa Anda saat ini dalam (Debug atau Rilis).
Jika Anda menghapus file .dll aktual dari folder Rilis (baik secara manual atau dengan melakukan "Solusi Bersih"), referensi Anda akan rusak karena .dll tidak ada.
Saya sarankan untuk menghapus referensi ke ProjectX.dll, dan menambahkannya lagi - tetapi kali ini, gunakan tab "Proyek" di dialog "Tambahkan Referensi". Saat Anda menambahkan referensi dengan cara ini, Visual Studio tahu di mana mendapatkan .dll yang sesuai. Jika Anda dalam mode Debug, ini akan mendapatkannya dari folder / Debug. Jika dalam mode Rilis, folder / Rilis. Kesalahan versi Anda akan hilang, dan Anda juga tidak akan (secara tidak benar) merujuk ke Rilis .dll saat dalam mode Debug.
sumber
Jawaban saya bukan hanya ringkasan dari semua solusi, tetapi menawarkan lebih dari itu.
Bagian 1):
Dalam solusi umum:
Saya mengalami 4 kesalahan semacam ini ('file metadata tidak dapat ditemukan') bersama dengan 1 kesalahan yang mengatakan 'File Sumber Tidak Dapat Dibuka (' Kesalahan tidak ditentukan ')'.
Saya mencoba menyingkirkan kesalahan 'file metadata tidak dapat ditemukan'. Untuk itu, saya membaca banyak posting, blog, dll dan menemukan solusi ini mungkin efektif (merangkumnya di sini):
Mulai ulang VS dan coba buat lagi.
Buka 'Solution Explorer' . Klik kanan pada Solution. Pergi ke Properties . Buka 'Pengelola Konfigurasi' . Periksa apakah kotak centang di bawah 'Bangun' dicentang atau tidak. Jika salah satu atau semuanya tidak dicentang, periksa dan coba buat lagi.
Jika solusi di atas tidak berfungsi, ikuti urutan yang disebutkan pada langkah 2 di atas, dan meskipun semua kotak centang dicentang, hapus centangnya, centang lagi, dan coba buat lagi.
Urutan Bangun dan Ketergantungan Proyek:
Buka 'Solution Explorer' . Klik kanan pada Solution. Buka 'Ketergantungan Proyek ...' . Anda akan melihat 2 tab: 'Dependencies' dan 'Build Order' . Urutan build ini adalah tempat solusi dibangun. Periksa dependensi proyek dan urutan build untuk memverifikasi apakah beberapa proyek (katakanlah 'project1') yang bergantung pada yang lain (katakanlah 'project2') mencoba untuk membangun sebelum yang satu itu (project2). Ini mungkin penyebab kesalahan.
Periksa jalur .dll yang hilang:
Periksa jalur .dll yang hilang. Jika jalur berisi spasi atau karakter jalur tidak valid lainnya, hapus dan coba buat lagi.
Jika ini penyebabnya, maka sesuaikan urutan build.
Seksi 2):
Kasus khusus saya:
Saya mencoba semua langkah di atas dengan berbagai permutasi dan kombinasi dengan restart VS beberapa kali. Tapi, itu tidak membantu saya.
Jadi, saya memutuskan untuk menyingkirkan kesalahan lain yang saya temukan ('File Sumber Tidak Bisa Dibuka (' Kesalahan Tidak Disebutkan ')').
Saya menemukan sebuah blog: http://www.anujvarma.com/tfs-errorsource-file-could-not-be-opened-unspecified-error/#comment-1539
Saya mencoba langkah-langkah yang disebutkan di blog itu dan saya menyingkirkan kesalahan 'File Sumber Tidak Bisa Dibuka (' Kesalahan Tidak Disebutkan ')' dan yang mengejutkan saya menyingkirkan kesalahan lain ('file metadata tidak dapat ditemukan') juga.
Bagian (3):
Pesan moral dalam cerita:
Coba semua solusi seperti yang disebutkan di bagian (1) di atas (dan solusi lainnya) untuk menghilangkan kesalahan. Jika tidak ada yang berhasil, sesuai blog yang disebutkan pada bagian (2) di atas, hapus entri dari semua file sumber yang tidak lagi ada di kontrol sumber dan sistem file dari file .csproj Anda .
sumber
Saya pernah mengalami masalah ini sebelumnya dan satu-satunya cara yang saya temukan untuk mengatasinya adalah dengan menjalankan Clean Solution dan kemudian restart Visual Studio.
sumber
Bagi saya biasanya kerangka target tidak aktif (4.5.2 bukannya 4.6) Jika Anda memperbaiki kerangka kerja target proyek agar sesuai dengan kerangka kerja target solusi dan membangun, .dll baru akan dibuat.
sumber
Buka kembali Visual Studio sebagai Administrator.
sumber
Sebagian besar jawaban mengatakan bahwa Anda perlu menghapus pustaka solusi Anda, ini benar tetapi ketika Anda menambahkan kembali pustaka, kesalahan akan ditampilkan lagi. Anda perlu memverifikasi apakah semua pustaka yang direferensikan memiliki kerangka kerja .net yang kompatibel dengan kerangka kerja .net solusi Anda. Kemudian perbaiki semua kesalahan dalam kode Anda dan buat kembali solusinya.
sumber
Apakah Anda sudah memeriksa pengaturan Manajer konfigurasi? Di sudut kanan atas dialog pengaturan proyek.
Kadang-kadang terjadi bahwa di antara semua entri rilis entri debug masuk. Jika demikian, ketergantungan otomatis yang dibuat oleh grafik ketergantungan solusi menjadi bingung.
sumber
Saya juga melihat kesalahan ini dalam solusi di mana saya memiliki banyak proyek (biasanya proyek netTiers di mana saya telah memperbarui satu atau lebih subproyek untuk menargetkan kerangka 4.0). Ini bisa menjadi masalah untuk dihapus. Seringkali itu dapat diselesaikan, bagaimanapun, dengan terlebih dahulu memperbaiki semua kesalahan lainnya dalam sub-proyek (misalnya, referensi yang hilang), membangun kembali sub-proyek tersebut secara individual, kemudian menghapus / menambahkan kembali referensi apa pun ke sub-proyek tersebut di Visual Studio. Secara pribadi, saya kurang beruntung menyelesaikan kesalahan ini dengan membersihkan solusinya sendiri.
sumber
Kami baru-baru ini mengalami masalah ini setelah memutakhirkan ke Office 2010 dari Office 2007 - kami harus mengubah referensi secara manual dalam proyek kami ke versi 14 dari Interops Office yang kami gunakan di beberapa proyek.
Semoga itu bisa membantu - butuh beberapa hari bagi kami untuk mengetahuinya.
sumber
Dalam kasus saya, itu disebabkan oleh dua hal (VS 2012):
1) Salah satu project dikonfigurasi untuk AnyCPU, bukan x86
2) Proyek yang direferensikan entah bagaimana memiliki kotak centang "Build" yang tidak dicentang.
Periksa Build | Anda Pengelola Konfigurasi untuk mendapatkan gambaran umum tentang apa yang sedang dibangun dan untuk platform mana. Juga pastikan Anda memeriksanya untuk Debug & Rilis karena mereka mungkin memiliki pengaturan yang berbeda.
sumber
Dalam kasus saya, saya mengalami beberapa kesalahan dalam kode saya. Visual Studio menunjukkan kesalahan yang Anda miliki, bukan kesalahan sebenarnya, seperti kesalahan sintaks atau nama kelas yang tidak diketahui. Coba bersihkan solusi dan bangun proyek demi proyek. Dengan cara ini Anda akan menemukan kesalahan yang sebenarnya.
Sekali lagi, inilah yang menyebabkan kesalahan bagi saya .
sumber
Saya mengalami masalah ini dan butuh waktu lama untuk mengetahuinya. Masalah muncul ketika saya menghapus proyek dari solusi dan menggantinya dengan paket nuget.
Solusi tampaknya baik-baik saja tetapi file .csproj masih berisi proyek tersebut beberapa kali sebagai referensi.
Tampaknya VS tidak membersihkan file itu dengan benar. Itu masih merujuk pada proyek yang dihapus di bawah tenda. Ketika secara manual menghapus referensi dari file csproj semuanya bekerja lagi! wohoo
sumber
Masalah ini disebabkan oleh file pdb atau CodeContracts.
Untuk mengatasinya:
Bersihkan folder keluaran Anda dan buat kembali solusinya.
Konfigurasi ulang CodeContracts atau nonaktifkan untuk build sementara.
sumber
Kami cukup sering mengalami masalah itu, tetapi hanya dengan referensi ke proyek C ++ / CLI dari proyek C #. Jelas bug jauh di dalam Visual Studio yang Microsoft putuskan untuk tidak diperbaiki, karena 'terlalu kompleks' dan mereka menjanjikan perbaikan sistem build C ++ yang sekarang ditargetkan untuk Visual Studio 2010.
Itu terjadi beberapa waktu lalu, dan mungkin perbaikannya bahkan masuk ke Visual Studio 2008; Saya tidak menindaklanjutinya lagi. Namun, solusi tipikal kami adalah
sumber
Saya sendiri memiliki masalah yang sama.
Visual Studio 2013 hanya memberi tahu saya bahwa itu tidak dapat merujuk ke sana, dan tidak dapat menemukan metadata. Ketika saya membuka solusi saya (yang memiliki banyak proyek di dalamnya) dikatakan bahwa saya menggunakan proyek yang lebih rendah dari versi kerangka salah satu proyek saya.
Jadi saya mengganti semuanya ke versi 4.5, dan berhasil lagi.
sumber
Sepertinya saya ingat pernah mengalami masalah serupa beberapa bulan lalu. Saya menyelesaikannya sementara dengan menyalin DLL yang direferensikan ke folder Rilis, sehingga memenuhi harapan Visual Studio. Kemudian, saya menemukan referensi ke DLL Rilis dalam kode saya yang sebenarnya. Anda harus mencoba melakukan pencarian di seluruh proyek untuk \ release \ project.dll.
Selain itu, saya telah memperhatikan bahwa proyek uji unit Visual Studio terkadang menempatkan atribut "DeploymentItem" pada setiap metode pengujian yang menunjuk ke DLL target Anda, dan jika Anda beralih antara Debug dan Rilis, Visual Studio dapat menjadi bingung jika DLL tidak lagi di lokasi yang diharapkan. Menurut pengalaman saya, atribut ini dapat dihapus dengan aman jika Anda tidak menempatkannya di sana sendiri sebagai bagian dari skenario "penerapan tunggal".
sumber
Saya mengalami masalah ini dan itu karena metode yang tidak valid di perpustakaan yang menyinggung (dll) yang tidak mengembalikan nilai, misalnya
Ketika saya melakukan ini semua dikompilasi :)
sumber
Terkadang VS2010 mengalihkan konfigurasi saya dari Semua CPU ke Platform Campuran. Ketika ini terjadi saya mendapatkan pesan kesalahan ini.
Untuk mengatasinya saya beralih kembali ke Any CPU:
1. Klik kanan pada solusi dan pilih properti.
2. Klik pada Properti Konfigurasi dan kemudian tombol Manajer Konfigurasi ....
3. Di bawah Platform solusi aktif pilih Semua CPU
sumber
Saya menemukan bahwa ini biasanya terjadi pada saya ketika saya masih memiliki deklarasi metode dalam sebuah antarmuka, yang diimplementasikan oleh kelas, tetapi kemudian saya telah menghapus dan lupa untuk menghapusnya dari antarmuka juga. Saya biasanya hanya menyimpan seluruh solusi setiap 30 menit dan kemudian kembali ke versi sebelumnya jika saya tidak dapat menemukan kesalahan.
sumber
Saya akhirnya menghapus referensi saya (saya telah menambahkannya dengan benar menggunakan tab proyek, dan mereka biasanya membangun dengan baik), mengedit file .csproj saya secara manual dan menghapus entri aneh yang tidak termasuk - dan mengatur output saya untuk debug dan rilis, x86 dan x64 dan semua cpu menjadi "\ bin" - Saya membuatnya sekali, kemudian menambahkan kembali referensi (sekali lagi, menggunakan tab proyek), dan semuanya mulai bekerja lagi untuk saya. Tidak perlu me-restart Visual Studio sama sekali.
sumber
Bagi saya ini disebabkan oleh target Build yang telah ditulis ulang untuk tidak menampilkan dll. Menghapus ini untuk kembali ke target Build default memperbaiki masalah.
sumber
dalam kasus saya, saya sedang mengerjakan master cabang. jadi saya memeriksa cabang utama, menjalankan build, lalu memeriksa cabang saya. Itu memperbaiki masalah. Jika Anda sudah berada di master, saya sarankan Anda memeriksa komit sebelumnya dan kemudian membangunnya.
sumber
Tampaknya ini terjadi saat Anda melakukan pembayaran solusi dengan beberapa proyek yang memiliki referensi di antara mereka, dan Anda belum membangunnya sebelumnya. Jika Anda memiliki referensi langsung ke dll, alih-alih merujuk proyek, Anda akan mendapatkan pesan ini. Anda harus selalu menggunakan tab Proyek dalam dialog Tambahkan Referensi untuk menambahkan referensi ke proyek dalam solusi yang sama. Dengan cara ini, VS dapat mengetahui urutan yang benar untuk membangun solusi
sumber
hal yang sama terjadi pada saya hari ini seperti yang dijelaskan oleh Vidar.
Saya memiliki kesalahan Build di Helper Library (yang direferensikan oleh proyek lain) dan alih-alih memberi tahu saya bahwa ada kesalahan di Helper Library, kompiler muncul dengan daftar kesalahan tipe MetaFile-not-found. Setelah mengoreksi kesalahan Build di Helper Library, kesalahan MetaFile hilang.
Apakah ada pengaturan di VS untuk meningkatkan ini?
sumber
Saya memiliki masalah yang sama. Saya perhatikan bahwa konteks db saya (EF4) yang terletak di dll proyek tidak dikenali karena beberapa alasan. Saya menghapusnya dan membuat yang lain sebagai gantinya. dan itu menyelesaikannya untuk saya.
sumber
Punya masalah yang sama hari ini.
Aplikasi saya, aplikasi Windows Forms, secara tidak sengaja memiliki referensi ke dirinya sendiri. Aneh.
Setelah dihapus, kesalahan itu hilang.
Referensi ditambahkan setiap kali saya menyeret kontrol pengguna, yang terletak di proyek Windows Forms itu sendiri, ke formulir.
sumber
Saya memiliki masalah yang sama. Menghapus dan menambahkan dll secara manual tidak membantu. ClassLibraries tidak mengkompilasi semua proyek dan hilang di folder ... \ bin \ Debug untuk proyek [karena saya membersihkan solusi karena kesalahan]. Karena perpustakaan kelas tidak dikompilasi, itu berarti mungkin ada beberapa kesalahan di suatu tempat di salah satu sub proyek tersebut .
Solusi: Karena dll saya ada di sana untuk folder ... \ bin \ Rilis , saya mencoba membangun kembali pada mode Rilis dan menemukan kesalahan pada satu baris di salah satu sub proyek. Memecahkan kesalahan dan membangun kembali solusi menyingkirkan kesalahan pembuatan.
sumber
Bagi saya Visual Studio telah membuat projectname.v11 jenis "Visual Studio Solution User Options". Saya menghapus file ini dan memulai ulang dan semuanya baik-baik saja.
sumber