패키지가 수행하는 작업이나 패키지에 포함된 코드에 관계없이 CLI 도구 nuget.exe 중 하나를 사용하거나 dotnet.exe해당 기능을 다른 개발자와 공유하고 사용할 수 있는 구성 요소로 패키지합니다. NuGet CLI 도구를 설치하려면 NuGet 클라이언트 도구 설치를 참조하세요. Visual Studio에는 CLI 도구가 자동으로 포함되지 않습니다.
SDK 스타일이 아닌 프로젝트(일반적으로 .NET Framework 프로젝트)의 경우 이 문서에 설명된 단계에 따라 패키지를 만듭니다. Visual Studio 및
nuget.exeCLI를 사용하는 단계별 지침은 .NET Framework 패키지 만들기 및 게시를 참조하세요.SDK 스타일 형식을 사용하는 .NET Core 및 .NET Standard 프로젝트 및 기타 SDK 스타일 프로젝트의 경우 dotnet CLI를 사용하여 NuGet 패키지 만들기를 참조하세요.
packages.config로 마이그레이션된 프로젝트의 경우 msbuild -t:pack을 사용합니다.
기술적으로 NuGet 패키지는 확장명이 변경되고 콘텐츠가 특정 규칙과 .nupkg 일치하는 ZIP 파일일 뿐입니다. 이 항목에서는 이러한 규칙을 충족하는 패키지를 만드는 자세한 프로세스에 대해 설명합니다.
패키징은 패키지로 배달하려는 컴파일된 코드(어셈블리), 기호 및/또는 기타 파일로 시작합니다( 개요 및 워크플로 참조). 이 프로세스는 패키지에 포함될 파일을 컴파일하거나 생성하는 것과는 독립적으로 진행됩니다. 그러나 프로젝트 파일의 정보를 활용하여 컴파일된 어셈블리와 패키지를 동기화 상태로 유지할 수 있습니다.
중요합니다
이 항목은 SDK 스타일이 아닌 프로젝트에 적용되며, 일반적으로 Visual Studio 2017 이상 버전과 NuGet 4.0 이상을 사용하는 .NET Core 및 .NET Standard 프로젝트 이외의 프로젝트에 적용됩니다.
어셈블리를 패키지화할지 결정하기
대부분의 범용 패키지에는 다른 개발자가 자신의 프로젝트에서 사용할 수 있는 하나 이상의 어셈블리가 포함되어 있습니다.
일반적으로 각 어셈블리가 독립적으로 유용하다면 NuGet 패키지당 하나의 어셈블리를 사용하는 것이 가장 좋습니다. 예를 들어,
Utilities.dll가Parser.dll에 의존하고,Parser.dll가 자체적으로 유용하면, 각각의 요소에 대해 하나의 패키지를 만드십시오. 이렇게 하면 개발자가Parser.dll를Utilities.dll에서 독립적으로 사용할 수 있습니다.라이브러리가 독립적으로 유용하지 않은 여러 어셈블리로 구성된 경우 라이브러리를 하나의 패키지로 결합하는 것이 좋습니다. 이전 예제를 사용할 때,
Parser.dll가Utilities.dll에 의해 독점적으로 사용되는 코드를 포함하고 있다면,Parser.dll를 같은 패키지에 두어도 괜찮습니다.마찬가지로,
Utilities.dll가Utilities.resources.dll에 의존하고 있으며, 후자는 단독으로는 유용하지 않을 경우 두 항목을 동일한 패키지에 넣습니다.
리소스는 실제로 특별한 경우입니다. 패키지가 프로젝트에 설치되면 NuGet은 지역화된 위성 어셈블리로 간주되므로 명명 된 참조를 .resources.dll 패키지의 DLL에 어셈블리 참조를 자동으로 추가합니다(지역화된 패키지 만들기 참조). 이러한 이유로 필수 패키지 코드가 포함된 파일에는 .resources.dll를 사용하지 마세요.
라이브러리에 COM interop 어셈블리가 포함된 경우 COM interop 어셈블리를 사용하여 패키지 만들기의 추가 지침을 따릅니다.
.nuspec 파일의 역할 및 구조
패키지하려는 파일을 알고 나면 다음 단계는 XML 파일에서 패키지 매니페스트를 .nuspec 만드는 것입니다.
매니페스트:
- 패키지의 내용을 설명하고 패키지에 포함됩니다.
- 패키지 만들기를 모두 실행하고 프로젝트에 패키지를 설치하는 방법에 대해 NuGet에 지시합니다. 예를 들어 매니페스트는 주 패키지가 설치될 때 NuGet에서 해당 종속성을 설치할 수 있도록 다른 패키지 종속성을 식별합니다.
- 아래에 설명된 대로 필수 속성과 선택적 속성을 모두 포함합니다. 여기에 언급되지 않은 다른 속성을 포함하여 정확한 세부 정보는 .nuspec 참조를 참조하세요.
필수 속성:
- 패키지를 호스트하는 갤러리에서 고유해야 하는 패키지 식별자입니다.
- -Suffix가 시험판 버전을 식별하는 Major.Minor.Patch[-Suffix] 형식의 특정 버전 번호
- 호스트에 표시되는 패키지 제목(예: nuget.org)
- 작성자 및 소유자 정보입니다.
- 패키지에 대한 긴 설명입니다.
일반적인 선택적 속성:
- 출시 정보
- 저작권 정보
- Visual Studio의 패키지 관리자 UI에 대한 간단한 설명
- 로캘 ID
- 프로젝트 URL
- 식 또는 파일로 라이선스 사용(
licenseUrl사용되지 않음, 대신 nuspec 메타데이터 요소 사용license) - 아이콘 파일(
iconUrl은 사용 중단되었습니다. 대신 nuspec 메타데이터 요소를 사용하세요.) - 종속성 및 참조 목록
- 갤러리 검색을 지원하는 태그
다음은 속성을 설명하는 주석이 포함된 일반적인(가상) .nuspec 파일입니다.
<?xml version="1.0"?>
<package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
<metadata>
<!-- Identifier that must be unique within the hosting gallery -->
<id>Contoso.Utility.UsefulStuff</id>
<!-- Package version number that is used when resolving dependencies -->
<version>1.8.3</version>
<!-- Authors contain text that appears directly on the gallery -->
<authors>Dejana Tesic, Rajeev Dey</authors>
<!--
Owners are typically nuget.org identities that allow gallery
users to easily find other packages by the same owners.
-->
<owners>dejanatc, rjdey</owners>
<!-- Project URL provides a link for the gallery -->
<projectUrl>http://github.com/contoso/UsefulStuff</projectUrl>
<!-- License information is displayed on the gallery -->
<license type="expression">Apache-2.0</license>
<!-- Icon is used in Visual Studio's package manager UI -->
<icon>icon.png</icon>
<!--
If true, this value prompts the user to accept the license when
installing the package.
-->
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<!-- Any details about this particular release -->
<releaseNotes>Bug fixes and performance improvements</releaseNotes>
<!--
The description can be used in package manager UI. Note that the
nuget.org gallery uses information you add in the portal.
-->
<description>Core utility functions for web applications</description>
<!-- Copyright information -->
<copyright>Copyright ©2016 Contoso Corporation</copyright>
<!-- Tags appear in the gallery and can be used for tag searches -->
<tags>web utility http json url parsing</tags>
<!-- Dependencies are automatically installed when the package is installed -->
<dependencies>
<dependency id="Newtonsoft.Json" version="9.0" />
</dependencies>
</metadata>
<!-- A readme.txt to display when the package is installed -->
<files>
<file src="readme.txt" target="" />
<file src="icon.png" target="" />
</files>
</package>
종속성 선언 및 버전 번호 지정에 대한 자세한 내용은 packages.config 및 패키지 버전 관리를 참조하세요.
include 및 exclude 속성을 dependency 요소에 사용하여 패키지에서 직접 종속 항목의 자산을 표시할 수도 있습니다.
.nuspec 참조 - 종속성을 참조하세요.
매니페스트는 해당 매니페스트에서 만든 패키지에 포함되어 있으므로 기존 패키지를 검사하여 몇 가지 추가 예제를 찾을 수 있습니다. 좋은 소스는 컴퓨터의 global-packages 폴더이며, 그 위치는 다음 명령으로 반환됩니다.
nuget locals -list global-packages
package\version 폴더로 들어가서, .nupkg 파일을 .zip 파일로 복사하십시오. 그런 다음 그 .zip 파일을 열고 내부의 .nuspec를 검사하십시오.
비고
Visual Studio 프로젝트에서 만들 .nuspec 때 매니페스트에는 패키지가 빌드될 때 프로젝트의 정보로 대체되는 토큰이 포함됩니다.
Visual Studio 프로젝트에서 .nuspec 만들기를 참조하세요.
.nuspec 파일 만들기
전체 매니페스트 만들기는 일반적으로 다음 방법 중 하나를 통해 생성된 기본 .nuspec 파일로 시작됩니다.
그런 다음 최종 패키지에서 원하는 정확한 콘텐츠를 설명할 수 있도록 파일을 직접 편집합니다.
중요합니다
생성된 파일에는 .nuspec 명령을 사용하여 패키지를 nuget pack 만들기 전에 수정해야 하는 자리 표시자가 포함되어 있습니다.
.nuspec에 자리 표시자가 포함된 경우 해당 명령이 실패합니다.
관례 기반 작업 디렉터리에서
NuGet 패키지는 .nupkg 확장자를 가진 ZIP 파일일 뿐이므로, 로컬 파일 시스템에서 원하는 폴더 구조를 만든 다음, 해당 구조에서 직접 .nuspec 파일을 만드는 것이 가장 쉬운 경우가 많습니다. 그런 다음 이 nuget pack 명령은 해당 폴더 구조의 모든 파일을 자동으로 추가합니다(.로 시작하는 폴더는 제외하므로, 동일한 구조에서 프라이빗 파일을 유지할 수 있습니다).
이 방법의 장점은 매니페스트에서 패키지에 포함할 파일을 지정할 필요가 없다는 것입니다(이 항목의 뒷부분에서 설명). 빌드 프로세스에서 패키지에 들어가는 정확한 폴더 구조를 생성하도록 할 수 있으며, 그렇지 않으면 프로젝트의 일부가 아닐 수도 있는 다른 파일을 쉽게 포함할 수 있습니다.
- 대상 프로젝트에 삽입해야 하는 콘텐츠 및 소스 코드입니다.
- PowerShell 스크립트
- 프로젝트의 기존 구성 및 소스 코드 파일로 변환합니다.
폴더 규칙은 다음과 같습니다.
| 폴더 | Description | 패키지 설치 시 작업 |
|---|---|---|
| (root) | readme.txt 위치 | Visual Studio는 패키지가 설치될 때 패키지 루트에 readme.txt 파일을 표시합니다. |
| lib/{tfm} | 지정된 TFM(.dll대상 프레임워크 모니커)에 대한 어셈블리(.xml), 설명서(.pdb) 및 기호() 파일 |
어셈블리는 컴파일 및 런타임에 대한 참조로 추가됩니다. .xml 프로젝트 .pdb 폴더에 복사됩니다. 프레임워크 대상별 하위 폴더를 만들기 위한 여러 대상 프레임워크 지원을 참조하세요. |
| ref/{tfm} | 지정된 TFM(.dll대상 프레임워크 모니커)에 대한 어셈블리(.pdb) 및 기호() 파일 |
어셈블리는 컴파일 시간에 대한 참조로만 추가됩니다. 따라서 프로젝트 bin 폴더에 아무것도 복사되지 않습니다. |
| runtimes | 아키텍처별 어셈블리(.dll), 기호(.pdb) 및 네이티브 리소스(.pri) 파일 |
어셈블리는 런타임에 대한 참조로만 추가됩니다. 다른 파일은 프로젝트 폴더에 복사됩니다. 해당 컴파일 시간 어셈블리를 제공하려면 항상 해당(TFM) AnyCPU 특정 어셈블리가 폴더 아래에 /ref/{tfm} 있어야 합니다.
여러 대상 프레임워크 지원을 참조하세요. |
| 내용 | 임의 파일 | 콘텐츠는 프로젝트 루트에 복사됩니다. 콘텐츠 폴더를 궁극적으로 패키지를 사용하는 대상 애플리케이션의 루트로 간주합니다. 패키지가 애플리케이션의 /images 폴더에 이미지를 추가하도록 하려면 패키지의 콘텐츠/이미지 폴더에 배치합니다. |
| build |
(3.x+) MSBuild .targets 및 .props 파일 |
프로젝트에 자동으로 삽입됩니다. |
| 멀티 타겟팅 빌드 |
(4.0 이상) 프레임워크 간 대상 지정을 위한 MSBuild .targets 및 .props 파일 |
프로젝트에 자동으로 삽입됩니다. |
| buildTransitive |
(5.0 이상) 모든 소비 프로젝트로 전이적으로 흐르는 MSBuild .targets 및 .props 파일
기능 페이지를 참조하세요. |
프로젝트에 자동으로 삽입됩니다. |
| 도구들 | 패키지 관리자 콘솔에서 액세스할 수 있는 Powershell 스크립트 및 프로그램 | 폴더는 tools 패키지 관리자 콘솔의 PATH 환경 변수에만 추가됩니다(특히 프로젝트를 빌드할 때 MSBuild에 대해 설정된 대로 추가PATH). |
폴더 구조에는 여러 대상 프레임워크에 대한 어셈블리 수가 포함될 수 있으므로 여러 프레임워크를 지원하는 패키지를 만들 때 이 메서드가 필요합니다.
원하는 폴더 구조를 완료했으면, 해당 폴더에서 다음 명령을 실행하여 .nuspec 파일을 만드십시오.
nuget spec
다시 말하지만, 생성된 .nuspec 파일에는 폴더 구조의 파일에 대한 명시적 참조가 없습니다. NuGet은 패키지를 만들 때 모든 파일을 자동으로 포함합니다. 그러나 매니페스트의 다른 부분에서 자리 표시자 값을 편집해야 합니다.
어셈블리 DLL에서
어셈블리에서 패키지를 만드는 간단한 경우 다음 명령을 사용하여 어셈블리의 메타데이터에서 파일을 생성 .nuspec 할 수 있습니다.
nuget spec <assembly-name>.dll
이 양식을 사용하면 매니페스트의 몇 자리 표시자가 어셈블리의 특정 값으로 바뀝니다. 예를 들어 <id> 속성은 어셈블리 이름으로 설정되고 <version> 어셈블리 버전으로 설정됩니다. 그러나 매니페스트의 다른 속성에는 어셈블리에 일치하는 값이 없으므로 자리 표시자가 계속 포함됩니다.
Visual Studio 프로젝트에서
.nuspec 파일 또는 .csproj 파일에서 .vbproj를 만드는 것은 해당 프로젝트에 설치된 다른 패키지가 종속성으로 자동으로 참조되기 때문에 편리합니다. 프로젝트 파일과 동일한 폴더에서 다음 명령을 사용하기만 하면 합니다.
# Use in a folder containing a project file <project-name>.csproj or <project-name>.vbproj
nuget spec
결과 <project-name>.nuspec 파일에는 패키징 시 이미 설치된 다른 패키지에 대한 참조를 포함하여 프로젝트의 값으로 대체되는 토큰 이 포함되어 있습니다.
.nuspec에 포함할 패키지 종속성이 있는 경우 nuget pack를 대신 사용하고, 생성된 .nupkg 파일 내에서 .nuspec 파일을 가져오세요. 예를 들어 다음 명령을 사용합니다.
# Use in a folder containing a project file <project-name>.csproj or <project-name>.vbproj
nuget pack myproject.csproj
토큰은 프로젝트 속성의 양쪽에 있는 기호로 구분 $ 됩니다. 예를 들어 <id> 이러한 방식으로 생성된 매니페스트의 값은 일반적으로 다음과 같이 표시됩니다.
<id>$id$</id>
이 토큰은 압축 시 프로젝트 파일의 값으로 AssemblyName 대체됩니다. 토큰에 대한 프로젝트 값 .nuspec 의 정확한 매핑은 대체 토큰 참조를 참조하세요.
토큰은 프로젝트를 업데이트할 때 버전 번호 .nuspec 와 같은 중요한 값을 업데이트할 필요가 없습니다. 원하는 경우 항상 토큰을 리터럴 값으로 바꿀 수 있습니다.
나중에 .nupkg 파일을 생성하기 위해 Nuget 팩 실행 에서 설명한 대로 Visual Studio 프로젝트에서 작업할 때 사용할 수 있는 몇 가지 추가 패키징 옵션이 있습니다.
솔루션 수준 패키지
NuGet 2.x만 해당합니다. NuGet 3.0 이상에서는 사용할 수 없습니다.
NuGet 2.x는 패키지 관리자 콘솔에 대한 도구 또는 추가 명령(폴더의 내용)을 설치하지만 솔루션의 프로젝트에 참조, 콘텐츠 또는 빌드 사용자 지정을 추가하지 않는 솔루션 수준 패키지의 tools 개념을 지원했습니다. 이러한 패키지에는 직접 lib또는 contentbuild 폴더에 파일이 없으며 해당 종속성 중 어느 것도 해당 libcontent폴더 또는 build 폴더에 파일이 없습니다.
NuGet은 프로젝트의 packages.config 파일이 아니라 .nuget 폴더의 packages.config 파일에서 설치된 솔루션 수준 패키지를 추적합니다.
기본값이 있는 새 파일
다음 명령은 자리 표시자를 사용하여 기본 매니페스트를 만들어 적절한 파일 구조로 시작할 수 있도록 합니다.
nuget spec [<package-name>]
패키지 이름을< 생략>하면 결과 파일은 .입니다Package.nuspec. 같은 Contoso.Utility.UsefulStuff 이름을 제공하는 경우 파일은 Contoso.Utility.UsefulStuff.nuspec입니다.
결과 .nuspec에는 projectUrl와 같은 값에 대한 자리 표시자가 포함됩니다. 파일을 사용하여 최종 .nupkg 파일을 만들기 전에 파일을 편집해야 합니다.
고유한 패키지 식별자 선택 및 버전 번호 설정
패키지 식별자(<id> 요소)와 버전 번호(<version> 요소)는 패키지에 포함된 정확한 코드를 고유하게 식별하기 때문에 매니페스트에서 가장 중요한 두 가지 값입니다.
패키지 식별자에 대한 모범 사례:
-
고유성: 식별자는 nuget.org 또는 패키지를 호스트하는 모든 갤러리에서 고유해야 합니다. 식별자를 결정하기 전에 해당 갤러리를 검색하여 이름이 이미 사용 중인지 확인합니다. 충돌을 방지하기 위해 회사 이름을 식별자의 첫 번째 부분(예:
Contoso..)으로 사용하는 것이 좋습니다. -
네임스페이스 같은 이름: 하이픈 대신 점 표기법을 사용하여 .NET의 네임스페이스와 유사한 패턴을 따릅니다. 예를 들어
Contoso.Utility.UsefulStuff을 사용하고Contoso-Utility-UsefulStuff또는Contoso_Utility_UsefulStuff를 사용하지 마십시오. 또한 소비자는 패키지 식별자가 코드에 사용된 네임스페이스와 일치하는 경우에도 유용합니다. -
샘플 패키지: 다른 패키지를 사용하는 방법을 보여 주는 샘플 코드 패키지를 생성할 때,
.Sample를 식별자에 접미사로 추가합니다, 예시로는Contoso.Utility.UsefulStuff.Sample가 있습니다. (샘플 패키지는 물론 다른 패키지에 종속됩니다.) 샘플 패키지를 만들 때 앞에서 설명한 규칙 기반 작업 디렉터리 메서드를 사용합니다. 폴더content에서\Samples\Contoso.Utility.UsefulStuff.Sample와 같이\Samples\<identifier>라는 이름의 폴더에 샘플 코드를 정렬합니다.
패키지 버전에 대한 모범 사례:
- 일반적으로 라이브러리와 일치하도록 패키지 버전을 설정하지만 반드시 필요한 것은 아닙니다. 이는 패키지를 패키지할 어셈블리 결정의 앞부분에서 설명한 대로 패키지를 단일 어셈블리로 제한하는 경우 간단한 문제입니다. 전반적으로 NuGet 자체는 어셈블리 버전이 아닌 종속성을 확인할 때 패키지 버전을 처리합니다.
- 비표준 버전 체계를 사용하는 경우 패키지 버전 관리에서 설명한 대로 NuGet 버전 관리 규칙을 고려해야 합니다.
다음 일련의 간단한 블로그 게시물은 버전 관리도 이해하는 데 유용합니다.
추가 정보 및 기타 파일 추가
패키지에 포함시킬 파일을 직접 지정하려면, <files> 노드를 <metadata> 태그 뒤에 오는 .nuspec 파일에서 사용하십시오.
<?xml version="1.0"?>
<package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
<metadata>
<!-- ... -->
</metadata>
<files>
<!-- Add a readme -->
<file src="readme.txt" target="" />
<!-- Add files from an arbitrary folder that's not necessarily in the project -->
<file src="..\..\SomeRoot\**\*.*" target="" />
</files>
</package>
팁 (조언)
규칙 기반 작업 디렉터리 접근 방식을 사용할 때, readme.txt를 패키지 루트에 배치하고 다른 콘텐츠는 content 폴더에 배치할 수 있습니다. 매니페스트에는 <file> 요소가 필요하지 않습니다.
패키지 루트에 이름이 지정된 readme.txt 파일을 포함하면 Visual Studio는 패키지를 직접 설치한 직후 해당 파일의 내용을 일반 텍스트로 표시합니다. (종속성으로 설치된 패키지에 대해서는 추가 정보 파일이 표시되지 않습니다.) 예를 들어 HtmlAgilityPack 패키지에 대한 추가 정보가 표시되는 방법은 다음과 같습니다.
비고
빈 <files> 노드를 .nuspec 파일에 포함하는 경우 NuGet은 lib 폴더에 있는 것만 패키지에 포함하며, 다른 콘텐츠는 포함하지 않습니다.
패키지에 MSBuild 소품 및 대상 포함
경우에 따라 빌드 중에 사용자 지정 도구 또는 프로세스를 실행하는 등 패키지를 사용하는 프로젝트에 사용자 지정 빌드 대상 또는 속성을 추가할 수 있습니다. NuGet 패키지에서 MSBuild 소품 및 대상에 대해 자세히 알아볼 수 있습니다.
프로젝트의 빌드 폴더 내에서 만들 <package_id>.targets 거나 <package_id>.props (예: Contoso.Utility.UsefulStuff.targets)
그런 다음 .nuspec 파일에서 <files> 노드에 이 파일들을 참조해야 합니다.
<?xml version="1.0"?>
<package >
<metadata minClientVersion="2.5">
<!-- ... -->
</metadata>
<files>
<!-- Include everything in \build -->
<file src="build\**" target="build" />
<!-- Other files -->
<!-- ... -->
</files>
</package>
패키지가 프로젝트에 추가되면 NuGet은 이러한 소품과 대상을 자동으로 포함합니다.
nuget pack을 실행하여 .nupkg 파일 생성
어셈블리 또는 규칙 기반 작업 디렉터리를 사용할 때, 파일로 nuget pack를 실행하고, <project-name>를 특정 파일 이름으로 대체하여 패키지를 생성합니다.
nuget pack <project-name>.nuspec
Visual Studio 프로젝트를 사용하는 경우 프로젝트 파일과 함께 nuget pack을 실행합니다. 이는 프로젝트 파일을 자동으로 로드하고 프로젝트 파일 내의 .nuspec 모든 토큰을 프로젝트 파일의 값을 사용하여 바꿉니다.
nuget pack <project-name>.csproj
비고
프로젝트가 토큰 값의 원본이므로 토큰을 교체하려면 프로젝트 파일을 직접 사용해야 합니다. 파일과 함께 .nuspec 사용하는 경우 nuget pack 토큰 교체가 발생하지 않습니다.
모든 경우에 nuget pack는 점으로 시작하는 폴더(예: .git 또는 .hg)를 제외합니다.
NuGet은 매니페스트의 .nuspec 자리 표시자 값을 변경하지 않는 것과 같이 수정이 필요한 파일에 오류가 있는지를 나타냅니다.
성공하면 nuget pack.nupkg에 설명된 대로 적합한 갤러리에 게시할 수 있는 파일이 있습니다.
팁 (조언)
패키지를 만든 후 검사하는 유용한 방법은 패키지 탐색기 도구에서 여는 것입니다. 이렇게 하면 패키지 내용 및 해당 매니페스트의 그래픽 보기가 제공됩니다. 결과 .nupkg 파일의 이름을 파일로 .zip 바꾸고 해당 내용을 직접 탐색할 수도 있습니다.
추가 옵션
다양한 명령줄 스위치를 nuget pack 사용하여 파일을 제외하고, 매니페스트의 버전 번호를 재정의하고, 출력 폴더를 변경할 수 있습니다. 전체 목록은 pack 명령 참조를 참조하세요.
다음 옵션은 Visual Studio 프로젝트에 공통적인 몇 가지 옵션입니다.
참조된 프로젝트: 프로젝트에서 다른 프로젝트를 참조하는 경우 다음 옵션을 사용하여
-IncludeReferencedProjects참조된 프로젝트를 패키지의 일부로 추가하거나 종속성으로 추가할 수 있습니다.nuget pack MyProject.csproj -IncludeReferencedProjects이 포함 프로세스는 재귀적이므로 참조 프로젝트 B 및 C와 해당 프로젝트가 D, E 및 F를 참조하는 경우
MyProject.csprojB, C, D, E 및 F의 파일이 패키지에 포함됩니다.참조된 프로젝트에 자체 파일이 포함된
.nuspec경우 NuGet은 참조된 프로젝트를 종속성으로 추가합니다. 해당 프로젝트를 별도로 패키지하고 게시해야 합니다.빌드 구성: 기본적으로 NuGet은 프로젝트 파일의 기본 빌드 구성 집합(일반적으로 디버그)을 사용합니다. 릴리스와 같은 다른 빌드 구성의 파일을 압축하려면 구성과
-properties함께 이 옵션을 사용합니다.nuget pack MyProject.csproj -properties Configuration=Release기호: 소비자가 디버거에서 패키지 코드를 단계별로 실행할 수 있는 기호를 포함하려면 다음
-Symbols옵션을 사용합니다.nuget pack MyProject.csproj -symbols
패키지 설치 테스트
패키지를 게시하기 전에 일반적으로 프로젝트에 패키지를 설치하는 프로세스를 테스트하려고 합니다. 테스트를 통해 반드시 파일이 모두 프로젝트의 올바른 위치에 있게 됩니다.
일반 패키지 설치 단계를 사용하여 Visual Studio 또는 명령줄에서 수동으로 설치를 테스트할 수 있습니다.
자동화된 테스트의 경우 기본 프로세스는 다음과 같습니다.
-
.nupkg파일을 로컬 폴더에 복사합니다. - 패키지 원본에 폴더를
추가하려면 명령을 사용하십시오 (nuget 원본 참조 ). 지정된 컴퓨터에서 이 로컬 원본을 한 번만 설정하면 됩니다. -
nuget sources에 지정된 원본 이름과 일치하도록<name>을 사용하여 해당 원본에서 패키지를 설치합니다nuget install <packageID> -source <name>. 원본을 지정하면 해당 원본에서만 패키지가 설치됩니다. - 파일 시스템을 검사하여 파일이 올바르게 설치되어 있는지 확인합니다.
다음 단계
파일인 패키지를 만든 후에는 .nupkg 패키지 게시에 설명된 대로 선택한 갤러리에 게시할 수 있습니다.
다음 항목에 설명된 대로 패키지의 기능을 확장하거나 다른 시나리오를 지원할 수도 있습니다.
마지막으로 다음과 같은 추가 패키지 유형에 주의해야 합니다.