Derlemeyle ilgili komutlar için çözüm düzeyi --output seçeneği artık geçerli değil

  • Makale

7.0.200 SDK'sında, aşağıdaki komutlarla bir çözüm dosyası kullanılırken seçeneği artık kabul/--output-o etmemeye ilişkin bir değişiklik yapıldı:

  • build
  • clean
  • pack
  • publish
  • store
  • test
  • vstest

Bunun nedeni, seçeneği tarafından denetlenen özelliğin OutputPath semantiğinin --output/-o çözümler için iyi tanımlanmamış olmasıdır. Bu şekilde oluşturulan projelerin çıktıları, tutarsız olan ve kullanıcı tarafından bildirilen bir dizi soruna yol açan aynı dizine yerleştirilir.

Bu değişiklik, 7.0.201 SDK'sında uyarı önem düzeyine düşürüldü ve pack etkilenen komutlar listesinden kaldırıldı.

Sürüm kullanıma sunulmuştur

.NET 7.0.200 SDK'sı, yalnızca 7.0.201 SDK'sında uyarıya indirildi.

Önceki davranış

Daha önce, bir çözüm dosyası kullanırken belirttiyseniz --output/-o , tüm oluşturulan projelerin çıktısı belirtilen dizine tanımsız ve tutarsız bir sırada yerleştirilirdi.

Yeni davranış

Seçenek dotnet bir çözüm dosyasıyla kullanıldığında CLI hata --output/-o döndürür. 7.0.201 SDK'dan başlayarak, bunun yerine bir uyarı gönderilir ve uyarı veya hata oluşturulmaz.dotnet pack

Hataya neden olan değişikliğin türü

Bu hataya neden olan değişiklik, betikler ve sürekli tümleştirme işlem hatları oluşturmak için değişiklik yapılmasını gerektirebilir. Sonuç olarak hem ikili hem de kaynak uyumluluğunu etkiler.

Değişiklik nedeni

Seçeneği tarafından --output/-o denetlenen özelliğin OutputPath semantiği çözümler için iyi tanımlanmadığından bu değişiklik yapıldı. Bu şekilde oluşturulan projelerin çıktıları, tutarsız olan ve kullanıcı tarafından bildirilen bir dizi soruna yol açan aynı dizine yerleştirilir.

Seçeneğiyle --output bir çözüm oluşturulduğunda, OutputPath özelliği tüm projeler için aynı değere ayarlanır ve bu da tüm projelerin çıkışlarının aynı dizine yerleştirileceği anlamına gelir. Çözümdeki projelerin karmaşıklık düzeyine bağlı olarak farklı ve tutarsız sonuçlar ortaya çıkabilir. Şimdi farklı çözüm şekillerinin bazı örneklerine ve bunların paylaşılan OutputPathbir uygulamasından nasıl etkilendiğine göz atalım.

Tek proje, tek TargetFramework

Tek bir , hedefleyen tek bir proje içeren bir TargetFrameworknet7.0çözüm düşünün. Bu durumda, seçeneğin --output sağlanması proje dosyasındaki özelliğin ayarlanmasıyla OutputPath eşdeğerdir. Derleme sırasında (veya diğer komutlarda ancak şimdilik oluşturulacak tartışmanın kapsamına girelim), projenin tüm çıkışları belirtilen dizine yerleştirilir.

Tek proje, birden çok TargetFrameworks

Şimdi birden çok TargetFrameworksve net6.0net7.0içeren tek bir proje içeren bir çözüm düşünün. Çoklu hedefleme nedeniyle, proje her TargetFrameworkbiri için bir kez olmak üzere iki kez derlenir. Bu 'iç' derlemelerinin OutputPath her biri için , aynı değere ayarlanır ve böylece iç derlemelerin her biri için çıkışlar aynı dizine yerleştirilir. Bu, en son tamamlanan derlemenin diğer derlemenin çıktılarının üzerine yazılacağı ve MSBuild gibi paralel bir derleme sisteminde varsayılan olarak 'last' değerinin belirsiz olduğu anlamına gelir.

Kitaplık => Konsol => Test, tek TargetFramework

Şimdi kitaplık projesi, kitaplık projesine başvuran bir konsol projesi ve konsol projesine başvuran bir test projesi içeren bir çözüm düşünün. Bu projelerin tümü tek TargetFrameworkbir hedefle, net7.0. Bu durumda, önce kitaplık projesi, ardından konsol projesi derlenir. Test projesi en son oluşturulacak ve konsol projesine başvuracaktır. Oluşturulan her proje için, her derlemenin çıkışları tarafından OutputPathbelirtilen dizine kopyalanır ve böylece son dizin üç projenin de varlıklarını içerir. Bu, test için çalışır, ancak yayımlama için test varlıklarının üretime gönderilmesine neden olabilir.

Kitaplık => Konsol => Test, birden çok TargetFrameworks

Şimdi aynı proje zincirini alın ve derlemeye ek olarak bu projelere net7.0 bir net6.0TargetFramework derleme ekleyin. Tek projeli, çok hedefli derlemeyle aynı sorun oluşur- TFM'ye özgü varlıkların belirtilen dizine tutarsız bir şekilde kopyalanması.

Birden çok uygulama

Şimdiye kadar doğrusal bağımlılık grafiğine sahip senaryolara bakıyorduk ancak birçok çözüm birden çok ilgili uygulama içerebilir. Bu, aynı çıkış klasörüne aynı anda birden çok uygulama derlenebileceği anlamına gelir. Uygulamalar aynı ada sahip bir bağımlılık dosyası içerirse, birden çok proje aynı anda çıkış yolunda bu dosyaya yazmaya çalıştığında derleme zaman zaman başarısız olabilir.

Birden çok uygulama bir dosyanın farklı sürümlerine bağımlıysa, derleme başarılı olsa bile, dosyanın çıkış yoluna kopyalanan sürümü belirleyici olmayabilir. Projeler bir NuGet paketinin farklı sürümlerine bağımlı olduğunda (büyük olasılıkla geçişli olarak) bu durum oluşabilir. Tek bir projede NuGet, bağımlılıklarının (NuGet paketleri ve/veya proje başvuruları aracılığıyla geçişli bağımlılıklar dahil) aynı sürümde birleştirilmesine yardımcı olur. Birleştirme tek bir proje ve bağımlı projeleri bağlamında yapıldığından, iki ayrı üst düzey proje oluşturulduğunda paketin farklı sürümlerini çözümlemenin mümkün olduğu anlamına gelir. Daha yüksek sürüme bağlı olan proje en son bağımlılığı kopyalarsa, genellikle uygulamalar başarıyla çalıştırılır. Ancak, en son alt sürüm kopyalanırsa, daha yüksek sürüme karşı derlenen uygulama çalışma zamanında derlemeyi yükleyemeyecektir. Kopyalanan sürüm belirleyici olmadığından, bu durum sorunu tanılamanın çok zor olduğu düzensiz, güvenilir olmayan derlemelere yol açabilir.

Diğer örnekler

Bu temel hatanın pratikte nasıl ortaya koyuluyor hakkında daha fazla örnek için dotnet/sdk#15607 konusuna bakın.

Genel öneri, daha önce gerçekleştirdiğiniz eylemi seçenek olmadan/--output-o gerçekleştirmek ve ardından komut tamamlandıktan sonra çıkışı istenen konuma taşımaktır. Eylemi belirli bir projede gerçekleştirmek ve daha iyi tanımlanmış semantiklere sahip olduğu için bu seçeneği uygulamaya --output/-o devam etmek de mümkündür.

Mevcut davranışı tam olarak korumak istiyorsanız, bir MSBuild özelliğini istenen dizine ayarlamak için bayrağını kullanabilirsiniz --property . Kullanılacak özellik şu komuta göre değişir:

Command Özellik Örnek
build OutputPath dotnet build --property:OutputPath=DESIRED_PATH
clean OutputPath dotnet clean --property:OutputPath=DESIRED_PATH
pack PackageOutputPath dotnet pack --property:PackageOutputPath=DESIRED_PATH
publish PublishDir dotnet publish --property:PublishDir=DESIRED_PATH
store OutputPath dotnet store --property:OutputPath=DESIRED_PATH
test TestResultsDirectory dotnet test --property:OutputPath=DESIRED_PATH

NOT En iyi sonuçlar için DESIRED_PATH mutlak bir yol olmalıdır. Göreli yollar, beklemediğiniz yollarla 'sabitlenir' (yani mutlak hale getirilir) ve tüm komutlarla aynı şekilde çalışmayabilir.