다음을 통해 공유

NuGet 2.1 릴리스 정보

NuGet 2.0 릴리스 정보 | NuGet 2.2 릴리스 정보

NuGet 2.1은 2012년 10월 4일에 릴리스되었습니다.

계층적 Nuget.Config

NuGet 2.1을 사용하면 파일을 찾는 NuGet.Config 폴더 구조를 재귀적으로 탐색한 다음 찾은 모든 파일 집합에서 구성을 빌드하여 NuGet 설정을 보다 유연하게 제어할 수 있습니다. 예를 들어 팀에 다른 내부 종속성의 CI 빌드에 대한 내부 패키지 리포지토리가 있는 시나리오를 고려해 보세요. 개별 프로젝트의 폴더 구조는 다음과 같을 수 있습니다.

C:\
C:\myteam\
C:\myteam\solution1
C:\myteam\solution1\project1

또한 솔루션에 대해 패키지 복원을 사용하도록 설정하면 다음 폴더도 존재합니다.

C:\myteam\solution1\.nuget

팀의 내부 패키지 리포지토리를 컴퓨터의 모든 프로젝트에 사용할 수 있도록 하지는 않지만 팀에서 작업하는 모든 프로젝트에 대해 팀의 내부 패키지 리포지토리를 사용할 수 있도록 하기 위해 새 Nuget.Config 파일을 만들어 c:\myteam 폴더에 배치할 수 있습니다. 프로젝트당 패키지 폴더를 구체적으로 지정하는 방법은 없습니다.

<configuration>
    <packageSources>
    <add key="Official project team source" value="http://teamserver/api/v2/" />
    </packageSources>
    <disabledPackageSources />
    <activePackageSource>
    <add key="Official project team source" value="http://teamserver/api/v2/" />
    </activePackageSource>
</configuration>

이제 아래와 같이 c:\myteam 아래의 모든 폴더에서 'nuget.exe 원본' 명령을 실행하여 원본이 추가되었음을 확인할 수 있습니다.

상위 NuGet 구성의 패키지 소스

NuGet.Config 파일은 다음 순서로 검색됩니다.

  1. .nuget\Nuget.Config
  2. 프로젝트 폴더부터 루트까지 재귀 탐색
  3. 전역 Nuget.Config (%appdata%\NuGet\Nuget.Config)

구성은 역순으로 적용됩니다. 즉, 위의 순서에 따라 전역 Nuget.Config가 먼저 적용되며, 그 후 루트부터 프로젝트 폴더까지 발견된 Nuget.Config 파일이 순차적으로 적용됩니다 .nuget\Nuget.Config. 구성에서 항목 집합을 제거하기 위해 <clear/> 요소를 사용할 경우 특히 중요합니다.

'packages' 폴더 위치 지정

과거에 NuGet은 솔루션 루트 폴더 아래에 있는 알려진 '패키지' 폴더에서 솔루션의 패키지를 관리했습니다. NuGet 패키지가 설치된 다양한 솔루션이 있는 개발 팀의 경우 동일한 패키지가 파일 시스템의 여러 위치에 설치될 수 있습니다.

NuGet 2.1은 NuGet.Config 파일의 repositoryPath 요소를 통해 패키지 폴더의 위치를 보다 세밀하게 제어합니다. 계층적 Nuget.Config 지원의 이전 예제를 기반으로 C:\myteam\ 아래의 모든 프로젝트가 동일한 패키지 폴더를 공유한다고 가정합니다. 이 작업을 수행하려면 다음 항목을 에 추가하기만 하면 합니다 c:\myteam\Nuget.Config.

<configuration>
    <config>
    <add key="repositoryPath" value="C:\myteam\teampackages" />
    </config>
    ...
</configuration>

이 예제에서 공유 Nuget.Config 파일은 깊이에 관계없이 C:\myteam 아래에 만들어지는 모든 프로젝트에 대해 공유 패키지 폴더를 지정합니다. 솔루션 루트 아래에 기존 패키지 폴더가 있는 경우 NuGet에서 패키지를 새 위치에 배치하기 전에 삭제해야 합니다.

이식 가능한 라이브러리 지원

이식 가능한 라이브러리 는 .NET 4에서 처음 도입된 기능으로, the.NET Framework 버전에서 Windows Phone, 심지어 Xbox 360까지 다양한 Microsoft 플랫폼에서 수정 없이 작동할 수 있는 어셈블리를 빌드할 수 있습니다(하지만 현재 NuGet은 Xbox 이식 가능한 라이브러리 대상을 지원하지 않음). 이제 NuGet 2.1은 프레임워크 버전 및 프로필에 대한 패키지 규칙을 확장하여 복합 프레임워크 및 프로필 대상 lib 폴더가 있는 패키지를 만들 수 있도록 하여 이식 가능한 라이브러리를 지원합니다.

예를 들어 다음과 같은 이식 가능한 클래스 라이브러리의 사용 가능한 대상 플랫폼을 고려해 보세요.

이식 가능한 라이브러리 만들기 대화 상자

라이브러리가 빌드되고 명령 nuget.exe pack MyPortableProject.csproj 이 실행되면 생성된 NuGet 패키지의 내용을 검사하여 새 이식 가능한 라이브러리 패키지 폴더 구조를 확인할 수 있습니다.

이식 가능한 라이브러리 패키지 레이아웃

여기서 볼 수 있듯이 이식 가능한 라이브러리 폴더 이름 규칙은 프레임워크 식별자가 기존 프레임워크 이름 및 버전 규칙을 따르는 'portable-{framework 1}+{framework n}' 패턴을 따릅니다. 이름 및 버전 규칙에 대한 한 가지 예외는 Windows Phone에 사용되는 프레임워크 식별자에서 찾을 수 있습니다. 이 모니커는 프레임워크 이름 'wp'(wp7, wp71 또는 wp8)를 사용해야 합니다. 예를 들어 'silverlight-wp7'을 사용하면 오류가 발생합니다.

이 폴더 구조에서 만든 패키지를 설치할 때 NuGet은 이제 폴더 이름에 지정된 대로 해당 프레임워크 및 프로필 규칙을 여러 대상에 적용할 수 있습니다. NuGet의 일치 규칙 뒤에는 "보다 구체적인" 대상이 "덜 구체적인" 대상보다 우선한다는 원칙이 있습니다. 즉, 특정 플랫폼을 대상으로 하는 모니커가 프로젝트와 호환되는 경우 항상 이식 가능한 모니커보다 선호됩니다. 또한 여러 이식 가능한 대상이 프로젝트와 호환되는 경우 NuGet은 지원되는 플랫폼 집합이 패키지를 참조하는 프로젝트에 "가장 가까운" 대상을 선호합니다.

Windows 8 및 Windows Phone 8 프로젝트 대상 지정

NuGet 2.1은 이식 가능한 라이브러리 프로젝트 대상 지정에 대한 지원을 추가하는 것 외에도 Windows 8 스토어 및 Windows Phone 8 프로젝트 모두에 대한 새로운 프레임워크 모니커뿐만 아니라 이후 버전의 각 플랫폼에서 더 쉽게 관리할 수 있는 Windows 스토어 및 Windows Phone 프로젝트에 대한 몇 가지 새로운 일반 모니커를 제공합니다.

Windows 8 스토어 애플리케이션의 경우 식별자는 다음과 같습니다.

NuGet 2.0 이하 NuGet 2.1
winRT45, . NETCore45 Windows, Windows8, win, win8

Windows Phone 프로젝트의 경우 식별자는 다음과 같습니다.
휴대폰 OS NuGet 2.0 이하 NuGet 2.1
Windows Phone 7 silverlight3-wp wp (윈도우 폰), wp7 (윈도우 폰 7), WindowsPhone (윈도우 폰), WindowsPhone7 (윈도우 폰 7)
Windows Phone 7.5(망고) silverlight4-wp71 wp71, WindowsPhone71
Windows Phone 8 (지원되지 않음) wp8, WindowsPhone8

위의 모든 변경 내용에서 이전 프레임워크 이름은 NuGet 2.1에서 계속 완전히 지원됩니다. 앞으로 새 이름은 해당 플랫폼의 향후 버전에서 더 안정적으로 사용되므로 사용해야 합니다. 그러나 새 이름은 2.1 이전 버전의 NuGet에서 지원되지 않으므로 전환 시기를 적절하게 계획합니다.

패키지 관리자 대화 상자에서 향상된 검색

지난 몇 번의 반복을 통해 NuGet 갤러리에 변경 내용이 도입되어 패키지 검색의 속도와 관련성이 크게 향상되었습니다. 그러나 이러한 개선 사항은 nuget.org 웹 사이트로 제한되었습니다. NuGet 2.1을 사용하면 NuGet 패키지 관리자 대화 상자를 통해 향상된 검색 환경을 사용할 수 있습니다. 예를 들어 Windows Azure 캐싱 미리 보기 패키지를 찾고 싶다고 상상해 보세요. 이 패키지에 대한 적절한 검색 쿼리는 "Azure Cache"일 수 있습니다. 이전 버전의 패키지 관리자 대화 상자에서 원하는 패키지는 결과의 첫 번째 페이지에도 나열되지 않았습니다. 그러나 NuGet 2.1에서는 이제 원하는 패키지가 검색 결과의 맨 위에 표시됩니다.

패키지 관리자 대화 상자 검색

강제 패키지 업데이트

NuGet 2.1 이전에는 버전 번호가 높지 않은 경우 NuGet에서 패키지 업데이트를 건너뜁니다. 이렇게 하면 특정 시나리오에 대한 마찰이 발생했으며, 특히 빌드 또는 CI 시나리오에서 팀이 각 빌드에서 패키지 버전 번호를 증가시키지 않으려는 경우가 있습니다. 원하는 동작은 관계없이 강제로 업데이트하는 것이었습니다. NuGet 2.1은 '다시 설치' 플래그를 사용하여 이 문제를 해결합니다. 예를 들어 이전 버전의 NuGet은 최신 패키지 버전이 없는 패키지를 업데이트하려고 할 때 다음과 같이 발생합니다.

PM> Update-Package Moq
No updates available for 'Moq' in project 'MySolution.MyConsole'.

다시 설치 플래그를 사용하면 최신 버전이 있는지 여부에 관계없이 패키지가 업데이트됩니다.

PM> Update-Package Moq -Reinstall
Successfully removed 'Moq 4.0.10827' from MySolution.MyConsole.
Successfully uninstalled 'Moq 4.0.10827'.
Successfully installed 'Moq 4.0.10827'.
Successfully added 'Moq 4.0.10827' to MySolution.MyConsole.

다시 설치 플래그가 도움이 되는 또 다른 시나리오는 프레임워크를 다시 대상으로 지정하는 것입니다. 프로젝트의 대상 프레임워크(예: .NET 4에서 .NET 4.5로)를 변경하는 경우 Update-Package -Reinstall 프로젝트에 설치된 모든 NuGet 패키지에 대해 올바른 어셈블리에 대한 참조를 업데이트할 수 있습니다.

Visual Studio 내에서 패키지 원본 편집

이전 버전의 NuGet에서는 Visual Studio 옵션 대화 상자 내에서 패키지 원본을 업데이트하려면 패키지 원본을 삭제하고 다시 추가해야 했습니다. NuGet 2.1은 구성 사용자 인터페이스의 첫 번째 클래스 함수로 업데이트를 지원하여 이 워크플로를 개선합니다.

패키지 관리자 구성 대화 상자

버그 수정

NuGet 2.1에는 많은 버그 수정이 포함되어 있습니다. NuGet 2.0에서 수정된 작업 항목의 전체 목록은 다음을 [NuGet Issue Tracker for this release](http://nuget.codeplex.com/workitem/list/advanced?keyword=&status=Fixed&type=All&priority=All&release=NuGet%202.1&assignedTo=All&component=All&sortField=LastUpdatedDate&sortDirection=Descending&page=0)참조하세요.

  • Last updated on