우리는 많은 프로젝트와 그 프로젝트간에 다소 복잡한 의존성 그래프가있는 솔루션을 가지고 있습니다. 이제 각 프로젝트는 자체의 너겟 패키지가되어야하며, 너겟 패키지의 종속성 그래프는 프로젝트의 내용을 반영해야합니다.하나의 솔루션으로 서로 의존하는 nuget 패키지를 선언하십시오.
나는이 두 가지 질문 : 동일한 솔루션 내의 모든 프로젝트를 유지하면서
우리의 프로젝트에 상황은 동일하며 우리는 다음과 같은 접근 방식을했다 :
이첫 번째 단계는 패키지를 정의하는 nuspec 파일을 만드는 것입니다. 모든 논문 파일을 솔루션의 루트 디렉토리에있는 ".nuspec"폴더에 저장했습니다. nuspec 파일은 ".nuspec"이라는 솔루션 폴더의 솔루션에도 추가됩니다.
솔루션 자체에는 버전 정보뿐만 아니라 저작권 정보가 포함 된 전역 AssemblyInfo 파일이 있습니다. 간단히 말해서 우리 프로젝트간에 공통적 인 모든 정보입니다. 각 프로젝트에는 각 프로젝트에 대한 정보를 추가하는 고유 한 어셈블리 정보가 있습니다.
nuspec 파일에 버전이 없습니다. 대신 우리가이 자리 표시 자 $(version)를 사용
<?xml version="1.0" encoding="utf-16"?>
<package xmlns="http://schemas.microsoft.com/packaging/2011/08/nuspec.xsd">
<metadata>
<id>MyCompany.MyProduct.Server.DataAccess</id>
<version>$(Version)</version>
<authors>MyCompany</authors>
<projectUrl>http://example.com/myProduct.html</projectUrl>
<iconUrl>http://example.com/myProduct.icon.png</iconUrl>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<description>Some description goes here.</description>
<summary>The summary goes here</summary>
<copyright>Copyright © MyCompany 2015</copyright>
<language>en-US</language>
<dependencies>
<dependency id="MyCompany.MyProduct.Common" version="$(Version)" />
<dependency id="MyCompany.MyProduct.Server" version="$(Version)" />
</dependencies>
</metadata>
<files>
<file src="path\to\MyCompany.MyProduct.Server.DataAccess.dll" target="lib\net45\MyCompany.MyProduct.Server.DataAccess.dll" />
</files>
</package>
(. 물론 의존성 종속성 자체가있을 수 있습니다 서버 구성 요소는 예를 들어, 로깅 구성 요소를 참조 할 수 있습니다.)
처음에 우리는 콘솔 응용 프로그램을 만들어 전역 AssemblyInfo 파일에서 솔루션 버전을 읽고이를 패키지를 작성하고 공개하기 전에 모든 nuspec 파일로 구문 분석하십시오.
콘솔 응용 프로그램은 정상적으로 작동했지만 지속적인 통합을 사용하는 TFS 환경에서 유지 관리하는 것은 약간 지루했습니다. 그래서 우리는이 작업을 수행하는 커스텀 TFS 빌드 템플릿을 정의했습니다.우리 프로젝트의 모든 너겟 패키지를 만들려면 지금해야 할 일은 TFS 빌드를 트리거하는 것입니다.
이 접근 방식은 모든 패키지가 동일한 버전을 가지므로 함께 잘 작동한다는 이점이 있습니다. 이 방법은 모든 패키지가 동일한 버전을 가지며 독립적으로 릴리스 될 수 없다는 단점이 있습니다.
우리는 심하게 통합 된 구성 요소의 대기업을 만들 수 없기 때문에이 방법을 선택했습니다. 우리 프로젝트는 모두 아주 비슷한 작은 LOB 응용 프로그램을 개발하는 데 사용되는 작은 프레임 워크를 제공합니다. 우리가 다양한 패키지 세트로 프레임 워크를 제공한다는 사실 때문에 개발자는 실제로 필요한 패키지를 선택한 다음 해당 패키지 만 설치할 수 있습니다. 개발자가 누락 된 기능을 나중에 추가하기로 결정한 경우에는 이미 설치된 것과 동일한 버전의 관련 패키지를 설치하기 만하면됩니다. 따라서 호환성에 대해 걱정할 필요가 없습니다.
예, "아마도"이 작업을 수행 할 수 있습니다. 나는 아마 그것을 시도하지 않았기 때문에 나는 말할 것이다. 그러나 나는 이것과 비슷한 것으로 접근 할 것이다 :당신의 참조를 정의하는 수동 nuspec으로 작동 할 것이다. 정말 멋진 생각을하고 싶다면 프로젝트 빌드 후 Roslyn 코드를 작성하여 프로젝트 종속성을 구문 분석하고 Nuget 종속성 트리를 빌드하십시오. 즉, do not do은 그다지 간단한 해결책이 아니므로 거의 수동으로 쉽게 부서지기 쉽습니다.
궁극적으로 해결책을 깨고 Nuget 패키지 당 솔루션을 만들고 Nuget을 사용하여 종속성을 끌어내는 것이 좋습니다. 빌드/CI 서버가 있다고 가정하면 이는 매우 사소한 일입니다. 자신 만의 Nuget repo를 실행하고 구축 된 빌드 아티팩트를 게시하면 종속 프로젝트가 반드시 빌드 한 최신 패키지를 가져옵니다. 매번 빌드 프로세스가 Nuget을 새로 고치고 표준 빌드 nuget spec 명령을 빌드 후 단계로 사용할 수 있습니다. 좋은 보너스로, 코드를 작업하는 모든 사람들이 변경 작업을 수행 할 때 종속성을 통해 실제로 생각하게 만듭니다.
위대한 답변, 감사합니다. 우리는 여러분이 묘사 한 것과 같은 상황을 가지고 있습니다 만, 지금까지는 모든 lib를 포함하는 하나의 커다란 패키지 만 만들었습니다. 이제 우리는 필요하지 않은 다른 모든 크래프트/웹 파일 등을 끌어 들이지 않고도 서로 다른 비트를 독립적으로 참조 할 수 있어야합니다. 이것은 지난 단락에서 묘사 한 것과 정확히 같습니다. 완벽한 감사입니다. – xan
'''$ (Version) '이 유효한 버전 문자열이 아닙니다 .''' 당신은 이것을 어디에서 정의합니까? – Wilbert
@Wilbert 제 대답을 자세히 읽으십시오. 처음에는 작은 콘솔 응용 프로그램을 사용하여 $ (Version) 자리 표시자를 대체했습니다. 요즘 우리는이 목표를 달성하기 위해 TFS 빌드를 사용합니다. – Spontifixus