NuGet을 사용합시다.

그동안 프로젝트 구성 시 사용하는 라이브러리  관리에 애를 먹으셨죠? NuGet 을 사용하시면, 허무할 정도로 쉽게 라이브러리 참조를 구성할 수 있습니다.

그동안 각 프로젝트마다 참조를 구성하기 위해, 또 Update 될 때마다 수동으로 Library를 복사하고, Runtime Assembly Binding 을 설정해줘야 하고…

가장 힘든 부분이지만 그 동안은 매뉴얼을 보고, 설정도 개인이 수행해야 했지만, NuGet을 사용하면, 자동으로 설정을 추가해주는 방식이라 초보자에게는 상당히 도움이 될 수 있습니다. (물론 양날의 칼이긴 합니다)

또 한가지 요즘에 ASP.NET UI 쪽 프로젝트를 다루는 데, 많은 javascript 를 사용해야 하더군요. 예전에는 그냥 복사해서 썼는데, JavaScript Framework으로 발전하여, 서로간의 version 매칭이 되어야 하고, 각기 다른 위치에 저장되어야 할 내용이 있기도 합니다. ( css, images 등 ) 

이런 JavaScript Framework 관련 추가는 NuGet을 이용하는 것이 훨씬 유리하겠지요?

다음으로 제가 담당하는  Solution 을 보시면 이해가 훨씬 빠를 것입니다.

NuGet은 솔루션 단위로 라이브러리를 관리합니다. 이에 한 솔루션에 많은 프로젝트가 있다면, 반복작업을 한번만 수행해도 되므로, 효율적인 측면에서는 상당히 유리하겠지요?

우선 VS.NET Tools -> Library Package Manager –> Manage NuGet Package for Solution 를 선택하여 아래와 같이 원하는 라이브러리를 설치합니다.

설치가 끝나면, 어떤 프로젝트에 실제로 참조를 설정할 것인지 선택하는 화면이 나옵니다. 보시다시피, 이 솔루션에는 85개 정도의 프로젝트가 있고, 특히 .NET 4.0 프로젝트와 Silverlight 4.0 프로젝트가 혼용되어 있습니다. 이렇게 혼용되어 있다 더라도, 설치할 Package 가 각 프로젝트의 환경을 지원한다면, 각자 알맞는 라이브러리 및 환경을 설정해 준다는 것입니다.

85개의 프로젝트를 한번에 구성한 것이 아니기에, 손으로 구성했지, 아마 한꺼번에 85개를 손으로 구성하라고 했다면 ~ 커헉…. 이 얼마나 판타스틱한 방식입니까?

더군다나 NuGet 공식 서버가 죽었을 경우를 대비해, Private NuGet Feed 를 구성할 수도 있고, 내부 Package를 내부 Feed에서만 제공할 수도 있습니다. ( 참고 : Hosting Your Own NuGet Feeds )

자신이 만든 라이브러리를 공식 NuGet Feeds 에 올려 배포할 수 도 있고, 회사 내부에서만 배포할 수 도 있으니, 실제 배포본 만드는 방법은 Using A GUI ( Package Explorer ) to build package 을 참고하시면 되겠습니다.

버전별 충동이라던가, Dependency라던가 하는 부분도 회사 중앙에서 관리가 가능하므로, 버전문제로 되네 안되네 하는 문제가 줄어들 것입니다.