Çözümde proje bağımlılıkları kullanılıyorsa MSBuild referansları (DLL dosyaları) kopyalamaz

Visual Studio çözümümde dört proje var (.NET 3.5'i hedefleyen herkes) - sorunum için sadece bu ikisi önemlidir:

1. MyBaseProject <- bu sınıf kütüphanesi üçüncü taraf DLL dosyasına başvuruyor (elmah.dll)
2. MyWebProject1 <- bu web uygulaması projesi MyBaseProject için bir referans var

Ben elmah.dll başvuru eklendi MyBaseProject tıklayarak Görsel stüdyoda 2008'de "başvuru ekleyin ..." → "Gözat" sekmesi → "elmah.dll" seçerek.

Elmah Referansının Özellikleri aşağıdaki gibidir:

• Takma adlar - global
• Yerel kopyala - doğru
• Kültür -
• Açıklama - ASP.NET için Hata Günlüğü Modülleri ve İşleyicileri (ELMAH)
• Dosya Türü - Montaj
• Yol - D: \ webs \ otherfolder \ _myPath \ __ tools \ elmah \ Elmah.dll
• Çözüldü - Doğru
• Çalışma zamanı sürümü - v2.0.50727
• Belirtilen sürüm - yanlış
• Kesin Ad - yanlış
• Sürüm - 1.0.11211.0

In MyWebProject1 I tarafından Proje MyBaseProject başvurusunu ekledi: "MyBaseProject" seçerek → "Projeler" sekmesi → "referansı ... Ekle". Bu başvurunun özellikleri, aşağıdaki üyeler dışında aynıdır:

• Açıklama -
• Yol - D: \ webs \ CMS \ MyBaseProject \ bin \ Debug \ MyBaseProject.dll
• Sürüm - 1.0.0.0

Visual Studio'da yapıyı çalıştırırsam elmah.dll dosyası MyBaseProject.dll ile birlikte MyWebProject1'in bin dizinine kopyalanır !

Ancak , çözüm için MSBuild'i temizleyip çalıştırırsam (D: \ webs \ CMS> C: \ WINDOWS \ Microsoft.NET \ Framework \ v3.5 \ MSBuild.exe / t: ReBuild / p: Configuration = MyProject.sln hatalarını ayıkla ) elmah.dll MyWebProject1 bin dizininde eksik - her ne kadar yapının kendisi hiçbir uyarı veya hata içermiyor!

Zaten MyBaseProject .csproj "true" ( "Visual Studio'da " kopya yerel " için bir takma ad olmalıdır) değeri ile özel öğe içerdiğinden emin oldum :

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

(Özel etiket varsayılan olarak .csproj'un xml dosyasında görünmüyordu, ancak Visual Studio "yerel kopyala" doğru dedi. "Yerel kopyala" yı yanlış - kaydedilmiş - olarak değiştirdim ve tekrar doğru değerine ayarladım - kaydet!)

MSBuild ile ilgili sorun nedir? (Elmah.dll) referansının MyWebProject1'in bin kutusuna kopyalanmasını nasıl sağlayabilirim?

Her projenin postbuild komutuna bir postbuild kopya eylemi eklemek istemiyorum! (MyBaseProject'e bağlı birçok projem olacağını hayal edin!)

Visual Studio ve MsBuild arasında oluştururken neden farklı olduğundan emin değilim, ama burada MsBuild ve Visual Studio'da bu sorunla karşılaştığımda bulduğum şey.

açıklama

Örnek bir senaryo için, proje X, montaj A ve montaj B'ye sahip olduğumuzu varsayalım. Montaj A, montaj B'ye başvurur, bu nedenle proje X, hem A hem de B'ye bir referans içerir. Ayrıca, proje X, montaj A'ya (örn. bir_işlev ()). Şimdi, X projesine referansta bulunan yeni bir Y projesi oluşturursunuz.

Böylece bağımlılık zinciri şöyle görünür: Y => X => A => B

Visual Studio / MSBuild akıllı olmaya çalışır ve yalnızca X projesinin gerektirdiğini algıladığı Y projesine referanslar getirir; Y projesinde referans kirliliğini önlemek için bunu yapar. Sorun, X projesi aslında B derlemesini açıkça kullanan herhangi bir kod içermediğinden (örn. B.SomeFunction ()), VS / MSBuild B'nin gerekli olduğunu algılamaz. ve böylece Y projesinin bin dizinine kopyalamaz; yalnızca X ve A montajlarını kopyalar.

Çözüm

Bu sorunu çözmek için iki seçeneğiniz vardır, her ikisi de B derlemesinin Y projesinin bin dizinine kopyalanmasına neden olur:

1. Y projesinde B montajına bir referans ekleyin.
2. X projesinde B derlemesini kullanan bir dosyaya sahte kod ekleyin.

Şahsen ben birkaç nedenden dolayı 2. seçeneği tercih ediyorum.

1. Gelecekte X projesine başvuran başka bir proje eklerseniz, B montajına da bir referans eklemeyi hatırlamanız gerekmeyecektir (1. seçenekle yapmanız gerektiği gibi).
2. Sahte kodun neden orada olması gerektiğini ve onu kaldırmamak gerektiğini söyleyen açık yorumlarınız olabilir. Birisi kodu yanlışlıkla silerse (örneğin, kullanılmayan kodu arayan bir refactor aracıyla), kodun gerekli olduğunu ve geri yükleyebildiğini kaynak kontrolünden kolayca görebilirsiniz. 1. seçeneği kullanırsanız ve biri kullanılmayan referansları temizlemek için bir yeniden düzenleme aracı kullanırsa, yorumunuz yoktur; bir başvurunun .csproj dosyasından kaldırıldığını göreceksiniz.

İşte bu durumla karşılaştığımda tipik olarak eklediğim "kukla kod" örneğidir.

    // 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);
    }

Sadece bununla başa çıkıyorum. Referansınızın özelliklerine gidin ve bunu yapın:

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

ve bu kadar.

Visual Studio 2010 başlangıçta şunu eklemez: <private>True</private> referans etiketine ve "yerel kopyala" seçeneğini yanlış olarak ayarlamak etiketin oluşturulmasına neden olur. Daha sonra buna göre doğru ve yanlış olarak ayarlanır.

Derleme doğrudan kodda kullanmıyorsanız, yardımcı olmaya çalışırken Visual Studio kullanılmadığını algılar ve çıktıya dahil etmez. Visual Studio ve MSBuild arasında neden farklı davranışlar gördüğünüzden emin değilim. Her ikisi için derleme çıktısını diyagnostik olarak ayarlamayı deneyebilir ve sonuçları karşılaştırarak nerede ayrıldığını görebilirsiniz.

Elmah.dll referansınıza gelince, doğrudan kodda başvurmuyorsanız, projenize bir öğe olarak ekleyebilir ve Eylem Oluşturma Contentve Çıktı Dizine Kopyala olarak ayarlayabilirsiniz Always.

Şuna baksana:

Bu MSBuild forum iş parçacığını başlattım

Geçici çözümümü / geçici çözümü burada bulacaksınız!

(MyBaseProject, elmah.dll dosyasının MyWebProject1'in kutusuna kopyalanması için elmah.dll dosyasından bazı sınıflara (her ne olursa olsun) başvuran bazı kodlara ihtiyaç duyar!)

Ben de aynı problemi yaşadım.

Projenizin çerçeve sürümünün başvurduğunuz dll'nin çerçeve sürümüyle aynı olup olmadığını kontrol edin.

Benim durumumda, istemcim "Framework 4 Client" kullanılarak derlendi ve DLL "Framework 4" idi.

Karşılaştığım sorun kütüphane projesine bağlı bir projem olmasıydı. Oluşturmak için şu adımları izliyordum:

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

Tabii ki ben bin ve en önemlisi paket zip dosyasında benim kütüphanenin dll dosyaları eksik demekti. Bunun mükemmel çalıştığını gördüm:

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

Neden bu işe ya da neden işe yaramadığına dair hiçbir fikrim yok. Ama umarım bu yardımcı olur.

Aynı problemi yaşadım ve aynı çözümdeki 2 projenin 3. taraf kütüphanesinin farklı bir versiyonuna atıfta bulunmasından kaynaklandı.

Tüm referansları düzelttikten sonra her şey mükemmel çalıştı.

Alex Burtsev'in bir yorumda bahsettiği gibi, sadece bir XAML kaynak sözlüğünde kullanılan herhangi bir şey veya benim durumumda, yalnızca XAML'de kullanılan ve arkasında kod olmayan herhangi bir şey, MSBuild tarafından 'kullanımda' olarak kabul edilmez.

Bu nedenle, sadece bir kodda derlemede bir sınıf / bileşene kukla bir başvuru yapmak MSBuild'i derlemenin gerçekten kullanımda olduğuna ikna etmek için yeterliydi.

Hedef çerçevesini değiştirme .NET Framework 4 İstemci Profili için .NET Framework 4 benim için bu sorunu düzeltildi.

Örneğinizde: MyWebProject1'deki hedef çerçeveyi .NET Framework 4 olarak ayarlayın

Deadlydog'un şemasını kullanarak,

Y => X => A => B ,

benim sorunum Y'yi inşa ettiğimde, X'in derlemeleri (A ve B, hepsi 15) Y'nin bin klasöründe görünmüyordu.

Ben referans X'i Y'den kaldırarak, kaydettikten, derledikten sonra X referansını (bir proje referansı) yeniden ekleyerek çözdüm ve kaydet, inşa et ve A ve B Y'nin bin klasöründe görünmeye başladı.

Aynı sorunu vardı ve dll dinamik olarak yüklenen bir referans oldu. Sorunu çözmek için dll ad alanı ile bir "kullanma" ekledim. Şimdi dll çıktı klasörüne kopyalanır.

Bunun için bir .targets için projenize dosya dosyayı projenin içerilenler bölümünde içerecek şekilde ayarlamanız gerekir.

Prosedür için cevabımı buraya bakın .

Derleme sırasında kullanılmayan referans düzenekleri doğru uygulama değildir. Ek dosyanızı kopyalaması için derleme dosyanızı artırmalısınız. Bir post-build olayı kullanarak veya özellik grubunu güncelleyerek.

Bazı örnekler diğer yazılarda bulunabilir

• MSBuild, proje bağımlılığının bir parçası olarak dinamik olarak oluşturulan dosyaları kopyalamak için
• VS2010 Oluşturma veya yayınlama sırasında çıktı dizinini otomatik olarak oluşturmak için dosyaları projeye dahil etme

Bunun ortaya çıktığı başka bir senaryo, Visual Studio'da eski "Web Sitesi" proje türünü kullanıyorsanız. Bu proje türü için, kendi dizin yapısının (geçerli klasör ve aşağı) dışındaki .dll'lere başvuruda bulunamaz. Yukarıdaki yanıtta, dizin yapınızın şöyle göründüğünü varsayalım:

ProjectX ve ProjectY, üst / alt dizinler olduğunda ve ProjectX, A.dll'yi başvuruda bulunan A.dll'ye başvurur ve bu da B.dll ve B.dll'yi kök (Nugets) üzerindeki bir Nuget paketinde olduğu gibi dizin yapısının dışındadır. dll dahil edilecek, ancak B.dll olmayacak.

Bugün benzer bir sorunum vardı ve bu kesinlikle sorunuzun cevabı değil. Ama herkesi bilgilendirmek ve muhtemelen bir içgörü sağlamak istiyorum.

Bir ASP.NET uygulamam var. Derleme işlemi, temizlemeye ve sonra derlemeye ayarlanır.

İki Jenkins CI senaryom var. Biri üretim, diğeri sahneleme için. Başvurumu sahnelemeye yerleştirdim ve her şey yolunda gitti. Üretime dağıtıldı ve başvurulan bir DLL dosyası eksikti. Bu DLL dosyası sadece projenin kökündeydi. Hiçbir NuGet deposunda değil. DLL olarak ayarlandı do not copy.

CI betiği ve uygulama iki dağıtım arasında aynıydı. Yine de temizleme ve hazırlama ortamına konuşlandırıldıktan sonra DLL dosyası ASP.NET uygulamasının dağıtım konumunda değiştirildi (bin/ ) . Üretim ortamı için durum böyle değildi.

Bir test dalında bindizine bu DLL dosyasını kopyalamak için inşa sürecine bir adım ekledi ortaya çıkıyor . Şimdi anlaması biraz zaman alan kısım. CI süreci kendini temizlemiyordu. DLL çalışma dizininde bırakıldı ve yanlışlıkla ASP.NET .zip dosyasıyla paketleniyordu. Üretim dalı hiçbir zaman DLL dosyası aynı şekilde kopyalanmadı ve bunu yanlışlıkla dağıtmadı.

TLDR; Yapı sunucunuzun ne yaptığını kontrol edin ve emin olun.

Her iki projenin de aynı .net sürümünde olduğundan emin olun, ayrıca yerel kopyalamayı da kontrol edin, ancak bu truevarsayılan olarak olmalıdır

Ek parametre ekleyerek Visual Studio 2015 kullanma

/ Deployonbuild = yanlış

msbuild komut satırına sorun giderildi.

Çok benzer bir sorunla karşılaştım. Visual Studio 2010 kullanarak derlerken, DLL dosyasıbin klasöre . Ancak, MSBuild kullanarak derlerken üçüncü taraf DLL dosyası dahil edilmedi.

Çok sinir bozucu. Çözdüğüm yol, doğrudan orada kullanmama rağmen NuGet referansını web projeme dahil etmekti .

Başvurulan tüm DLL dosyalarını Web Sitesi projesine proje referanslarınızdan dahil etmek, özellikle bağımlılık enjeksiyonunu kullanırken her zaman iyi bir fikir değildir. : web projeniz herhangi bir somut uygulama DLL'si değil, arayüz DLL dosyasına / projesine bir referans eklemek istiyor dosya.

Bir uygulama DLL dosyasına / projesine doğrudan bir başvuru eklerseniz, geliştiricinizin arabirim yerine uygulama DLL dosyasının / projesinin somut sınıflarında "yeni" çağrılmasını engelleyemezsiniz. Uygulamayı kullanmak için web sitenizde bir "sabit kod" da belirtmişsinizdir.