MSBuild tidak menyalin referensi (file DLL) jika menggunakan dependensi proyek dalam solusi

Saya memiliki empat proyek dalam solusi Visual Studio saya (semua orang yang menargetkan .NET 3.5) - untuk masalah saya hanya dua yang penting:

1. MyBaseProject <- pustaka kelas ini mereferensikan file DLL pihak ketiga (elmah.dll)
2. MyWebProject1 <- proyek aplikasi web ini memiliki referensi ke MyBaseProject

Saya menambahkan referensi elmah.dll ke MyBaseProject di Visual studio 2008 dengan mengklik "Tambahkan referensi ..." → "Jelajahi" tab → memilih "elmah.dll".

Sifat-sifat Referensi Elmah adalah sebagai berikut:

• Alias ​​- global
• Salin lokal - benar
• Budaya -
• Deskripsi - Modul dan Penangan Kesalahan Kesalahan (ELMAH) untuk ASP.NET
• Jenis File - Perakitan
• Path - D: \ webs \ folder lain \ _myPath \ __ alat \ elmah \ Elmah.dll
• Terselesaikan - Benar
• Versi runtime - v2.0.50727
• Versi yang ditentukan - salah
• Nama Kuat - salah
• Versi - 1.0.11211.0

Di MyWebProject1 saya menambahkan referensi ke Project MyBaseProject oleh: "Tambahkan referensi ..." → "Projects" tab → pilih "MyBaseProject". Properti referensi ini sama kecuali anggota berikut:

• Deskripsi -
• Path - D: \ webs \ CMS \ MyBaseProject \ bin \ Debug \ MyBaseProject.dll
• Versi - 1.0.0.0

Jika saya menjalankan build di Visual Studio file elmah.dll disalin ke direktori bin MyWebProject1 saya , bersama dengan MyBaseProject.dll!

Namun jika saya membersihkan dan menjalankan MSBuild untuk solusi (via D: \ webs \ CMS> C: \ WINDOWS \ Microsoft.NET \ Framework \ v3.5 \ MSBuild.exe / t: ReBuild / p: Konfigurasi = Debug MyProject.sln ) elmah.dll hilang dalam direktori bin MyWebProject1 - walaupun build itu sendiri tidak mengandung peringatan atau kesalahan!

Saya sudah memastikan bahwa .csproj dari MyBaseProject berisi elemen pribadi dengan nilai "true" (yang seharusnya menjadi alias untuk " copy local " di Visual Studio):

<Reference Include="Elmah, Version=1.0.11211.0, Culture=neutral, processorArchitecture=MSIL">
  <SpecificVersion>False</SpecificVersion>
  <HintPath>..\mypath\__tools\elmah\Elmah.dll</HintPath>
    **<Private>true</Private>**
</Reference>

(Tag pribadi tidak muncul di xml .csproj secara default, meskipun Visual Studio mengatakan "salin lokal" benar. Saya beralih "salin lokal" ke false - save - dan atur kembali ke true lagi - save!)

Apa yang salah dengan MSBuild? Bagaimana cara mendapatkan referensi (elmah.dll) disalin ke tempat MyWebProject1?

Saya TIDAK ingin menambahkan tindakan copy postbuild ke perintah postbuild setiap proyek! (Bayangkan saya akan memiliki banyak proyek tergantung pada MyBaseProject!)

Saya tidak yakin mengapa itu berbeda ketika membangun antara Visual Studio dan MsBuild, tapi di sini adalah apa yang saya temukan ketika saya mengalami masalah ini di MsBuild dan Visual Studio.

Penjelasan

Untuk skenario sampel, misalkan kita memiliki proyek X, rakitan A, dan rakitan B. Rakitan A rakitan rakitan B, sehingga proyek X mencakup referensi untuk A dan B. Selain itu, proyek X mencakup kode yang merujuk rakitan A (misalnya A. SomeFunction ()). Sekarang, Anda membuat proyek Y baru yang merujuk proyek X.

Jadi rantai ketergantungan terlihat seperti ini: Y => X => A => B

Visual Studio / MSBuild mencoba untuk menjadi pintar dan hanya membawa referensi ke proyek Y yang dideteksi oleh proyek X; ia melakukan ini untuk menghindari polusi referensi dalam proyek Y. Masalahnya adalah, karena proyek X tidak benar-benar mengandung kode apa pun yang secara eksplisit menggunakan perakitan B (mis. B.SomeFunction ()), VS / MSBuild tidak mendeteksi bahwa B diperlukan oleh X, dan dengan demikian tidak menyalinnya ke direktori bin proyek Y; hanya menyalin rakitan X dan A.

Larutan

Anda memiliki dua opsi untuk menyelesaikan masalah ini, yang keduanya akan mengakibatkan perakitan B disalin ke direktori bin proyek Y:

1. Tambahkan referensi ke rakitan B di proyek Y.
2. Tambahkan kode dummy ke file di proyek X yang menggunakan perakitan B.

Secara pribadi saya lebih suka opsi 2 karena beberapa alasan.

1. Jika Anda menambahkan proyek lain di masa depan yang merujuk proyek X, Anda tidak perlu ingat untuk juga menyertakan referensi ke rakitan B (seperti yang harus Anda lakukan dengan opsi 1).
2. Anda dapat memiliki komentar eksplisit yang mengatakan mengapa kode dummy perlu ada di sana dan tidak menghapusnya. Jadi, jika seseorang menghapus kode secara tidak sengaja (misalnya dengan alat refactor yang mencari kode yang tidak digunakan), Anda dapat dengan mudah melihat dari kontrol sumber bahwa kode tersebut diperlukan dan untuk mengembalikannya. Jika Anda menggunakan opsi 1 dan seseorang menggunakan alat refactor untuk membersihkan referensi yang tidak digunakan, Anda tidak memiliki komentar; Anda hanya akan melihat bahwa referensi telah dihapus dari file .csproj.

Berikut adalah contoh "kode boneka" yang biasanya saya tambahkan ketika saya menghadapi situasi ini.

    // DO NOT DELETE THIS CODE UNLESS WE NO LONGER REQUIRE ASSEMBLY A!!!
    private void DummyFunctionToMakeSureReferencesGetCopiedProperly_DO_NOT_DELETE_THIS_CODE()
    {
        // Assembly A is used by this file, and that assembly depends on assembly B,
        // but this project does not have any code that explicitly references assembly B. Therefore, when another project references
        // this project, this project's assembly and the assembly A get copied to the project's bin directory, but not
        // assembly B. So in order to get the required assembly B copied over, we add some dummy code here (that never
        // gets called) that references assembly B; this will flag VS/MSBuild to copy the required assembly B over as well.
        var dummyType = typeof(B.SomeClass);
        Console.WriteLine(dummyType.FullName);
    }

Saya hanya menghadapinya seperti ini. Buka properti referensi Anda dan lakukan ini:

Set "Copy local = false"
Save
Set "Copy local = true"
Save

dan hanya itu.

Visual Studio 2010 awalnya tidak meletakkan: <private>True</private> di tag referensi dan pengaturan "salin lokal" ke false menyebabkannya membuat tag. Setelah itu akan mengaturnya menjadi benar dan salah.

Jika Anda tidak menggunakan perakitan langsung dalam kode maka Visual Studio sambil berusaha membantu mendeteksi bahwa itu tidak digunakan dan tidak termasuk dalam output. Saya tidak yakin mengapa Anda melihat perilaku yang berbeda antara Visual Studio dan MSBuild. Anda bisa mencoba mengatur output build ke diagnostik untuk keduanya dan membandingkan hasilnya lihat di mana itu menyimpang.

Adapun referensi elmah.dll Anda jika Anda tidak mereferensikannya secara langsung dalam kode Anda bisa menambahkannya sebagai item ke proyek Anda dan mengatur Build Action ke Contentdan Salin ke Direktori Output untuk Always.

Melihat:

Utas forum MSBuild ini saya mulai

Anda akan menemukan solusi / solusi sementara saya di sana!

(MyBaseProject membutuhkan beberapa kode yang mereferensikan beberapa kelas (apa pun) dari elmah.dll untuk elmah.dll disalin ke tempat MyWebProject1!)

Saya memiliki masalah yang sama.

Periksa apakah versi kerangka kerja proyek Anda sama dengan versi kerangka kerja dll yang Anda cantumkan.

Dalam kasus saya, klien saya dikompilasi menggunakan "Framework 4 Client" dan DLL berada di "Framework 4".

Masalah yang saya hadapi adalah saya memiliki proyek yang tergantung pada proyek perpustakaan. Untuk membangun saya mengikuti langkah-langkah ini:

msbuild.exe myproject.vbproj /T:Rebuild
msbuild.exe myproject.vbproj /T:Package

Itu tentu saja berarti saya kehilangan file dll perpustakaan saya di bin dan yang paling penting dalam paket file zip. Saya menemukan ini bekerja dengan sempurna:

msbuild.exe myproject.vbproj /T:Rebuild;Package

Saya tidak tahu mengapa ini bekerja atau mengapa tidak di tempat pertama. Tetapi harapan itu membantu.

Saya hanya punya masalah yang sama persis dan ternyata disebabkan oleh kenyataan bahwa 2 proyek dalam solusi yang sama mereferensikan versi yang berbeda dari perpustakaan pihak ke-3.

Setelah saya koreksi semua referensi semuanya bekerja dengan sempurna.

Seperti yang dikatakan Alex Burtsev dalam komentar apa pun yang hanya digunakan dalam kamus sumber daya XAML, atau dalam kasus saya, apa pun yang hanya digunakan dalam XAML dan bukan dalam kode di belakang, tidak dianggap 'digunakan' oleh MSBuild.

Jadi hanya dengan membuat referensi tiruan ke kelas / komponen dalam perakitan dalam beberapa kode di belakang sudah cukup meyakinkan MSBuild bahwa perakitan itu sebenarnya sedang digunakan.

Mengubah kerangka kerja target dari .NET Framework 4 Profil Klien ke .NET Framework 4 memperbaiki masalah ini untuk saya.

Jadi dalam contoh Anda: atur kerangka target pada MyWebProject1 ke .NET Framework 4

Menggunakan skema deadlydog,

Y => X => A => B ,

masalah saya adalah ketika saya membangun Y, majelis (A dan B, semuanya 15) dari X tidak muncul di folder bin Y.

Saya mendapatkannya diselesaikan dengan menghapus referensi X dari Y, menyimpan, membangun, kemudian menambahkan kembali referensi X (referensi proyek), dan menyimpan, membangun, dan A dan B mulai muncul di folder bin Y.

Saya memiliki masalah yang sama dan dll adalah referensi yang dimuat secara dinamis. Untuk mengatasi masalah saya telah menambahkan "menggunakan" dengan namespace dll. Sekarang dll disalin dalam folder output.

Ini membutuhkan penambahan .targetsfile ke proyek Anda dan pengaturannya untuk dimasukkan dalam bagian termasuk proyek.

Lihat jawaban saya di sini untuk prosedurnya.

Majelis rujukan yang tidak digunakan selama pembangunan bukanlah praktik yang benar. Anda harus menambah file build Anda sehingga itu akan menyalin file tambahan. Baik dengan menggunakan acara pembuatan pos atau dengan memperbarui grup properti.

Beberapa contoh dapat ditemukan di pos lain

• MSBuild untuk menyalin file yang dihasilkan secara dinamis sebagai bagian dari ketergantungan proyek
• VS2010 Cara memasukkan file dalam proyek, untuk menyalinnya untuk membangun direktori keluaran secara otomatis selama membangun atau menerbitkan

Skenario lain di mana ini muncul adalah jika Anda menggunakan jenis proyek "Situs Web" yang lebih lama di Visual Studio. Untuk jenis proyek itu, tidak dapat referensi .dlls yang berada di luar struktur direktori itu sendiri (folder saat ini dan ke bawah). Jadi dalam jawaban di atas, katakanlah struktur direktori Anda terlihat seperti ini:

Di mana ProjectX dan ProjectY adalah direktori induk / anak, dan referensi ProjectX A.dll yang pada gilirannya merujuk B.dll, dan B.dll berada di luar struktur direktori, seperti dalam paket Nuget pada root (Paket), lalu A. dll akan dimasukkan, tetapi B.dll tidak akan.

Saya memiliki masalah yang sama hari ini, dan ini tentunya bukan jawaban untuk pertanyaan Anda. Tapi saya ingin memberi tahu semua orang, dan mungkin memberikan percikan wawasan.

Saya memiliki aplikasi ASP.NET. Proses membangun diatur untuk membersihkan dan kemudian membangun.

Saya memiliki dua skrip Jenkins CI . Satu untuk produksi dan satu untuk pementasan. Saya menyebarkan aplikasi saya ke panggung dan semuanya bekerja dengan baik. Digunakan untuk produksi dan tidak ada file DLL yang direferensikan. File DLL ini hanya di root proyek. Tidak dalam repositori NuGet. DLL diatur ke do not copy.

Script CI dan aplikasi itu sama antara dua penyebaran. Masih setelah bersih dan menggunakan di lingkungan pementasan, file DLL diganti di lokasi penggunaan aplikasi ASP.NET ( bin/). Ini tidak terjadi pada lingkungan produksi.

Ternyata di cabang pengujian saya telah menambahkan langkah ke proses membangun untuk menyalin file DLL ini ke bin direktori. Sekarang bagian yang butuh sedikit waktu untuk mencari tahu. Proses CI tidak membersihkan dirinya sendiri. DLL ditinggalkan di direktori kerja dan sedang tidak sengaja dikemas dengan file .zip ASP.NET. Cabang produksi tidak pernah memiliki file DLL disalin dengan cara yang sama dan tidak pernah secara tidak sengaja menyebarkan ini.

TLDR; Periksa dan pastikan Anda tahu apa yang dilakukan server build Anda.

Pastikan bahwa kedua proyek dalam versi .net yang sama juga memeriksa salinan properti lokal tetapi ini harus truesebagai default

Menggunakan Visual Studio 2015 menambahkan parameter tambahan

/ deployonbuild = false

ke baris perintah msbuild memperbaiki masalah.

Saya baru saja mengalami masalah yang sangat mirip. Saat kompilasi menggunakan Visual Studio 2010, file DLL dimasukkan dalam binfolder. Tetapi ketika mengkompilasi menggunakan MSBuild, file DLL pihak ketiga tidak disertakan.

Sangat membuat frustrasi. Cara saya menyelesaikannya adalah dengan memasukkan referensi NuGet ke paket di proyek web saya walaupun saya tidak menggunakannya langsung di sana.

Menyertakan semua file DLL yang dirujuk dari referensi proyek Anda di proyek Situs web tidak selalu merupakan ide yang baik, terutama ketika Anda menggunakan injeksi dependensi : proyek web Anda hanya ingin menambahkan referensi ke antarmuka file / proyek DLL, bukan DLL implementasi konkret mengajukan.

Karena jika Anda menambahkan referensi langsung ke file / proyek implementasi DLL, Anda tidak dapat mencegah pengembang Anda memanggil "baru" pada kelas konkret dari file / proyek implementasi DLL alih-alih melalui antarmuka. Anda juga telah menyatakan "hardcode" di situs web Anda untuk menggunakan implementasinya.