允許訪問間接依賴關係類型的.NET Core 1.1

我創建了一個新的.NET Core 1.1解決方案，並注意到一個奇怪的行爲：如果我在解決方案中創建多個項目並鏈接引用它們，我可以自由訪問類型位於依賴關係的依賴關係，任何級別下。允許訪問間接依賴關係類型的.NET Core 1.1

這是一個例子：

我們有一個沙盒液，巴茲類庫項目，一個酒吧類庫項目引用巴茲和富控制檯應用程序項目引用酒吧。

從美孚項目我能夠訪問和使用BazThing，在巴茲項目定義的類型，即使富不會對巴茲參考。

這適用的NuGet包過：如果我通過的NuGet添加實體框架巴茲我能夠在美孚項目使用的DbContext類型。

當項目用於實現層分離時，這是一個巨大的問題。現在

開發者被允許訪問和使用的依存關係或旁路層偏析的實施細節，既「惡意」和錯誤（在上述提到的例子中，智能感知將愉快地建議使用BazThings鍵入BA時沒有任何警告）。

這是事情從現在開始如何工作，還是我們錯過了什麼？

是否有可能以某種方式防止/抑制此行爲？

我在哪裏可以找到有關此行爲的文檔？

來源

2017-04-20 Albireo

這是新的VS 2017中的一項新功能 – VMAtm

[.Net Core 1.1中的傳遞引用]的可能重複（http://stackoverflow.com/a/42431299/213550） – VMAtm

重複的http：// stackoverflow。com/questions/37963523/showing-classes-from-indirect-referenced-packages-in-net-core/38038192＃38038192 – Thomas

這是現代NuGet/msbuild的預期行爲。它被稱爲meta-packages/transitive dependencies，並用於例如NETStandard.Library包，以包含基類庫的所有庫。我不認爲有隱藏他們的方式。預計將在VS的下一個版本中將此功能添加到完整的.NET Framework項目中。

除了你的問題，我個人的觀點是隱藏在參考樹背後的文物可能一見鍾情，但不會帶來任何建築效益。加載的程序集可以被調用。一種方式或其他。分層，分層架構和遵守架構只能被教導/學習/審查/記錄。教導開發者，但不要在他們周圍建造牆壁。紀律不應該由工件強制執行，而應由開發人員自己執行。

來源

2017-04-23 06:32:11 Thomas

重新_「隱藏在參考樹背後的工件可能一見鍾情，但不會帶來任何架構好處」_：問題是這也影響到NuGet包：如果NuGet包_Foo_在我們的項目中使用，並且_Foo_內部使用NuGet包_Bar_，在我們的項目_Bar_中突然可用;如果_Bar_被錯誤使用或無意中使用，並且_Foo_的更新丟失_Bar_我們的項目突然爆炸，因爲我們依賴_Foo_的實現細節。封裝不再是編程的核心概念嗎？ – Albireo

Re _「建築的分層，層層架構和堅持只能被教導/學習/評論/記錄，教導開發者，但不要在他們周圍建立圍牆，學科不應該由工件強制實施，而應由開發者自己實施。 - 確實如此，但是這個新功能使得製作錯誤變得更容易;由各種自動完成功能（IntelliSense，Resharper等）主動提出的「私有」類型，開發人員必須密切監視（自動）包含的每個名稱空間，甚至無法知道他使用了他不應該擁有的類型。 – Albireo

我同意意外使用，但發生率應該非常低。過去我很擔心這樣的事情，而且過度設計了很多東西。我認爲時間投入在代碼審查和信任上會更好。依賴樹問題與傳統的NuGet一起可能已經有了，它們只是被添加到頂層。 – Thomas

允許訪問間接依賴關係類型的.NET Core 1.1

回答

相關問題