VS 2017에서 최소한의 종속성으로 .NET 표준 NuGet 패키지를 만드는 방법은 무엇입니까?

Question

Visual Studio 2017을 사용하여 .NET Standard 1.1을 지원하기 위해 현재 라이브러리 프로젝트를 마이그레이션 중입니다.

이 프로젝트를 .NET Framework 4.5 이상을 대상으로 할 수있는 단일 NuGet 패키지로 출시하고자합니다. .NET Core, UWP 등

그러나 .NET Framework 프로젝트에서 결과 패키지를 설치하려고하면 .NET 표준 (아래 참조)에 정의 된 모든 패키지가 들어있는 패키지 종속성의 거대한 목록이 생성됩니다.

이것들은 .NET Standard 1.1 사양의 일부로 정의 된 모든 어셈블리라는 것을 알고 있습니다. 그러나, 나의 특정 프로젝트는 실제로 그것들 중 아주 작은 부분 집합 만 필요로하며,이 의존성 목록은 프로젝트에 패키지를 설치하는 사람들에게 혼란을 줄 것입니다.

similar question에 대한 답변을 따르려고했는데 프로젝트에서 요구하는 정확한 종속성 만 참조하도록 프로젝트 사양을 변경하는 것이 좋습니다.

그러나 대답은 이전 project.json 형식의 컨텍스트에서였습니다. 이제는 VS 2017의 새로운 .csproj 형식으로 대체되었습니다. .NET Standard 1.1 메타 패키지에 대한 종속성을 제거하여 제거하려고 시도했습니다. <TargetFramework> 지시문을 사용했지만 빌드를 중단하고 필요한 종속성 만 추가하는 방법을 찾지 못했습니다.

플랫폼 호환성을 극대화하기 위해 .NET 표준으로 라이브러리를 이동하겠다는 약속은 대단히 매력적이지만 "클래식".NET Framework를 대상으로하는 프로젝트가 "오염 된"프로젝트를 찾지 못하도록 종속 구조를 구성하는 데 권장되는 방법은 무엇입니까? 이 모든 의존성?

Answer 1

<TargetFramework>에서 <TargetFrameworks>으로 변경하고 ;net45을 추가하십시오. 여전히 하나의 NuGet 패키지 출력을 얻지 만, 이제는 .NET 핵심 애플 리케이션 (이미 종속성을 가짐)을 대상으로 할 경우에만 추가 종속성을 끌어 당깁니다.

Answer 2

net45에 대한 패키지 참조를 보면로드 할 실제 DLL이 없다는 것을 알 수 있습니다. 패키지가 있으므로 DLL과 같은 BCL의 모든 부분을로드하는 coreclr과 같은 런타임을 가져올 수 있습니다. 그러나 net45에서, 당신은 실제로 그 패키지에 dll을 찾을 수 없습니다.

간단히 말해 .net 4.x에서 .net은 GAC를 사용하여 해당 어셈블리를로드합니다.

Answer 3

첫째,이 주로 디자인 타임 문제이며 그 결과 애플리케이션과 라이브러리의 이동성에 영향을주지 않습니다 point out 싶습니다 과거

을, 우리는 준 개발자는 NuGet 패키지에서 메타 패키지 (NETStandard.Library)를 참조하지 않고 대신 System.Runtime 및 System.Collections과 같은 개별 패키지를 참조 할 것을 권장합니다. 그 이유는 우리가 메타 패키지를 닷넷 플랫폼의 실제적인 기본 빌딩 블록 인 패키지 묶음의 약자로 생각했기 때문입니다. 가정은 다음과 같습니다. 우리는 이러한 원자 블록 중 일부만 지원하지만 다른 모든 .NET 블록은 지원하지 않는 다른 .NET 플랫폼을 만들게됩니다. 툴링이 대형 패키지 그래프를 다루는 방법에 대한 우려도있었습니다.

더 나아가, 우리는 이것을 간단합니다 :

1. .NET 표준 원자 빌딩 블록이다. 즉, 새로운 플랫폼은 .NET Standard를 부분 집합화할 수 없으므로 모든 플랫폼을 구현해야합니다.

2. .NET 표준을 포함하여 플랫폼을 설명하기 위해 패키지를 사용하지 않을 것입니다.

즉, 더 이상 .NET Standard 용 NuGet 패키지를 참조하지 않아도됩니다. lib 폴더와의 의존성을 나타 냈습니다. lib 폴더는 다른 모든 .NET 플랫폼, 특히 .NET Framework에서 어떻게 작동했는지 정확히 나타냅니다.

그러나 지금은 툴링이 여전히 NETStandard.Library으로 불타질 예정입니다. 그 중 하나에 해가되지 않습니다, 그것은 앞으로 중복 이동됩니다.

그러나이 결과가 거의 바람직하지 않다는 것을 충분히 인정합니다.

.NET 표준 1.x 및 packages.config을 사용하면 불행히도 사용자 지정 종속성 그룹을 사용하여 필기체 .nuspec을 생성 할 수 밖에 없습니다. 그러나 이것은 필요한 패키지가 무엇인지 이해해야하며 깨지기 쉬운 경향이 있습니다. 소비자가 <PackageReference>을 사용하면 직접적인 전이 참조를 분리하기 때문에 두통이 약간 적어 지므로 얼굴에 그다지 그다지 중요하지 않습니다.

.NET Standard 2.0에서는 문제가 완전히 사라집니다.