Visual Studio Solution 파일 대신 MSBuild를 사용해야하는 이유는 무엇입니까?

지속적인 통합을 위해 TeamCity를 사용하고 있으며 솔루션 파일 (.sln)을 통해 릴리스를 구축하고 있습니다. 과거에는 다양한 시스템에서 Makefile을 사용했지만 msbuild는 없었습니다. 솔루션 파일 대신 msbuild를 직접 사용하는 방법에 대한 많은 게시물을 보았지만 왜 해야하는지 에 대한 명확한 대답을 보지 못했습니다 .

그렇다면 왜 솔루션 파일에서 MSBuild 'makefile'로 마이그레이션해야합니까? 우리는 #define (특징 빌드)마다 다른 몇 가지 릴리스가 있지만 대부분의 경우 모든 것이 작동합니다.

더 큰 관심사는 프로젝트 / 소스 코드를 추가 할 때 두 개의 시스템 을 유지해야한다는 것 입니다.

최신 정보:

사람들이 다음 세 가지 구성 요소의 수명주기 및 상호 작용에 대해 설명 할 수 있습니까?

1. Visual Studio .sln 파일
2. 많은 프로젝트 레벨 .csproj 파일 ( "서브"msbuild 스크립트를 이해함)
3. 사용자 지정 msbuild 스크립트

.sln 및 .csproj는 Visual Studio IDE GUI 내에서 평소와 같이 소비 / 유지 관리되는 반면 사용자 지정 msbuild 스크립트는 손으로 작성하며 일반적으로 기존의 개별 .csproj를 "있는 그대로"사용한다고 말하는 것이 안전합니까? 이것이 유지 보수에서 중복 / 중복을 줄이는 것을 볼 수있는 한 가지 방법입니다 ...

다른 사람들의 운영 경험에서 이것에 대해 약간의 감사를 표할 것입니다.

사실 MSBuild가 솔루션 파일을 실행할 때 솔루션 파일이 거의 마술처럼 MSBuild 파일이됩니다. 이는 Visual Studio에서 솔루션을 빌드 할 때 발생합니다. 또한 이러한 모든 프로젝트 파일은 Visual Studio에서 관리하는 msbuild 파일입니다. 실제로 프로젝트 파일은 솔루션에서 빌드하거나 사용자 지정 msbuild 스크립트에서 빌드하는 경우에 상관없이 대부분의 실제 작업을 처리합니다.

또한 TeamCity를 사용하여 응용 프로그램을 빌드 및 게시하고 일반적으로 대부분의 프로젝트에 대한 사용자 지정 msbuild 스크립트를 사용합니다. 솔루션 파일로는 쉽지 않은 이러한 스크립트의 역할은 배포 또는 배포를 위해 프로젝트를 패키징하는 것입니다. 일반적으로 이러한 스크립트는 웹 프로젝트를 특정 폴더에 빌드하거나 개발 구성과 달리 실행중인 구성을 복사하는 것과 같이 운영상의 일부 측면을 처리합니다. 무거운 리프팅은 프로젝트 파일 자체에서 처리되는 경향이 있습니다. 빌드 스크립트는 해당 파일을 참조하기 만합니다. 전반적으로 훌륭하게 작동하며 실제로 중복 코드는 아닙니다.

MSBuild를위한 메이크 입니다 의 .sln 파일 (또는 vcproj 파일).

일반적인 msbuild 명령 줄은 다음과 같습니다.

msbuild /p:Configuration=Release BigProject.sln

msbuild 사용의 핵심은 빌드 프로세스를 스크립트하고 자동화 할 수 있다는 것입니다. 당신이 알고 있는지 여부에 관계없이 TeamCity는 msbuild를 계속 사용하고 있습니다.

이 질문에 대한 답변을 드리겠습니다.

확실히 .SLN 파일을 '빌드 프로세스'로 사용할 수 있지만 파일 자체는 실제로 빌드 프로세스를 구성하지 않습니다. 솔루션 파일은 실제로 Visual Studio의 일부일 뿐이며 개발에 사용됩니다. 그러나 Visual Studio는 빌드 및 릴리스 프로세스의 일부일뿐입니다. 솔루션을 사용하여 빌드를 관리 할 수 ​​없으며 솔루션은 확장 가능한 빌드 상황을 제공하지 않습니다.

빌드 프로세스를 설정하는 목적은 안정적인 빌드를 만드는 것입니다. 즉, 빌드 프로세스는 매우 안정적이므로 빌드 구성에 관계없이 예측 가능한 빌드 출력을 얻을 수 있습니다. 매번, 모든 기계. 예측 가능하고 신뢰할 수있는 빌드의 결과로 테스트, 배포 및 릴리스 프로세스를 고도로 자동화하여 인적 오류의 위험을 더욱 줄일 수 있습니다.

빌드 프로세스를 설정하려면 투자가 필요하지만 경우에 따라 투자가 필요합니다. msbuild 프로세스를 선호하는 몇 가지 요소는 다음과 같습니다.

• 제품에 동일한 팀 프로젝트에서 작업하는 여러 팀 (기능 간 또는 기타)이 있습니다.
• 조직에 팀 프로젝트가 하나만 있습니다 (전통적인 상점의 99 %, 개발자가 200 명 이상인 상점도 해당)
• 20 개 이상의 프로젝트를 빌드해야하며, 그 중 일부는 다른 프로젝트에 종속되어 있으며 다른 팀에서 유지 관리합니다.
• 이 제품에는 여러 .NET 기술 (C #, C ++, VB, F #, ASP.NET 등) 또는 비 .NET 기술 (Grunt, node, npm, Java 등)이 통합되어 있습니다.
• 귀하의 제품은 헤비급 종속성이 있거나 헤비급 플랫폼 위에 구축되었습니다. 예를 들어 SharePoint

마지막 요점을 확장하는 예를 들어 보겠습니다. 현재 회사에서 SharePoint 개발을하고 있습니다. SharePoint 개발은 최소한 SharePoint 프로젝트에서 빌드를 수행하기 위해 SharePoint Foundation을 설치해야합니다. 경량 빌드 서버와 관련하여 말하자면, 빌드 서버에 SharePoint가 설치되어 있어야한다는 것은 비현실적입니다. SharePoint는 요구 사항이 높은 짐승 일뿐만 아니라 빌드에 심각한 성능 영향을 미치며 빌드는 가능한 한 빠르고 간결해야합니다. MSBuild를 활용하면 빌드 서버에서이 설치 요구 사항을 제거 할 수 있습니다. 실제로 빌드 서버에는 .NET 프레임 워크 (MSBuild에 필요) 및 노드 이외의 설치 요구 사항이 없습니다.

참고로, Sayed Ibrahim Hashimi ( http://www.amazon.com/Inside-Microsoft-Build-Engine-Foundation/dp/0735645248/ref=sr_1_fkmr0_1?ie=UTF8&qid=1412014650&sr= 8-1-fkmr0 & 키워드 = msbuild + reliable + build

이것은 내가 몇 달 전에 나 자신에게 물었던 질문이다! 우리는 모든 것을 멋지게 설정했습니다.

• 리포지토리의 루트에 멋지게 솔루션 파일
• 다음과 같이 Teamcity에서 구성된 단계를 빌드하십시오.
  • NuGet 패키지 복원
  • 솔루션 구축
  • 단위 테스트 실행
  • 설정 통합 테스트 환경
  • 통합 테스트 실행
  • 통합 테스트 환경 해체
  • 배포 패키지 만들기
  • 마이그레이션 스크립트 작성

그리고 재현성에 관해서는 이것이 낮은 점수를 받았다는 것이 명백해졌습니다. TeamCity를 빌드 스크립트로 지정하면 자체 개발 시스템에서 유사한 결과를 안정적으로 재현하기가 어려워집니다.

빌드 스크립트가 있으면 빌드 스크립트는 수행해야 할 모든 것을 알고 있으며 모든 변수가 제자리에 있습니다. CI 서버를 빌드 스크립트로 사용하고 복잡한 테스트가 실패하거나 배포 패키지를 수동으로 빌드해야하는 등의 문제가 발생할 경우 (예제에 따라) 빌드의 모든 단계를 수동으로 구성해야합니다.

그래서, 짧은에 , 왜 (MS) 빌드 스크립트? 빌드와 관련하여 더 많은 요구 사항이 생길 수 있습니다. 아마도 몇 가지 테스트를 실행하고 그로부터 일부 아티팩트를 생성하고 싶을 것입니다. 배포를 원할 것입니다. 그리고 빌드 서버 든 머신이든 관계없이 원하는 모든 것을 실행할 수 있어야하는 경우 어느 곳에서나 빌드 스크립트로 끝날 수 없습니다.