답변:
이번 주에도 비슷한 조사를 수행했습니다. 내가 결정할 수 있었던 것은 다음과 같습니다.
없음 :
MSBuild :
주관적인 차이 : (YMMV)
Windows 플랫폼에서 MSBuild의 주요 장점 중 하나는 .NET 자체의 일부로 제공된다는 것입니다. 즉, Windows Update가 최신 인 모든 Windows 컴퓨터에는 MSBuild를 사용할 수 있습니다. 여기에 C # 컴파일러도 .NET 자체의 일부이며 깨끗한 시스템에서 프로젝트를 빌드 할 수있는 플랫폼이 있습니다. Visual Studio behemoth를 설치할 필요가 없습니다. 반면 NAnt는 빌드를 트리거하기 전에 명시 적으로 설치해야합니다.
기록을 위해 과거에 사소한 빌드에서 NMake, Make, Ant, Rake, NAnt 및 MSBuild를 순서대로 사용했습니다. 내가 가장 좋아하는 것은 MSBuild입니다. "Visual Studio에서 사용하는 것이기 때문에 선호하지 않습니다." IMHO, 그것은 매우 평가되지 않은 빌드 도구입니다.
NAnt와 MSBuild를 절차 적 프로그래밍과 기능적 프로그래밍의 차이점과 비교합니다. NAnt는 매우 간단하고 쉽게 볼 수 있습니다. 반면에 MSBuild는 좀 더 많은 생각이 필요합니다. 학습 곡선이 더 가파 릅니다. 그러나 일단 "얻으면"놀라운 일을 할 수 있습니다.
따라서 기능적 또는 논리적 스타일 프로그래밍을 선호하는 경우 MSBuild를 살펴 보는 것이 좋습니다. 유형 결과를보기 전에 약간의 시간과 노력을 투자하려는 경우 (물론, 결국 투자가 수익을 거두고 있다고 생각합니다. 더 강력한 일을 더 효율적으로 할 수 있습니다).
개인적으로, 나는 같은 프로젝트에 둘 다 사용합니다.
MSBuild는 Visual Studio 솔루션 및 프로젝트 구축에 탁월합니다. 그것이 바로 그 목적입니다.
NAnt은 더 쉽게 손으로 편집 할 수 있습니다. 특히 Ant를 이미 알고 있다면 더욱 그렇습니다. NAnt는 NAntContrib로 MSBuild를 매우 쉽게 호출 할 수 있습니다. 따라서 빌드 된 파일 복사, 정리 등의 작업을 수행하는 NAnt 스크립트를 직접 작성하고 MSBuild를 호출하여 실제 "C # 소스 코드를 어셈블리로 변환"부분을 수행합니다.
그 예를 원하면 내 프로토콜 버퍼 빌드 파일을보십시오 . (나는 그것이 멋진 NAnt 스크립트라고 주장하지는 않지만 일을한다.)
NAnt 는 기본적으로 더 많은 기능을 제공하지만 MSBuild 는 훨씬 더 나은 기본 구조 (항목 메타 데이터 락)를 사용하여 재사용 가능한 MSBuild 스크립트를 훨씬 쉽게 작성할 수 있습니다.
MSBuild는 이해하는 데 시간이 걸리지 만 일단 그렇게하면 매우 좋습니다.
학습 자료 :
KISS = MSBuild 사용
상자에서 합리적인 작업을 수행 할 무언가가있을 때 왜 믹스에 다른 것을 추가해야합니까? MSBuild가 도착하자 NAnt는 사망했습니다. 그리고 Mono 는 MSBuild 구현 ( xbuild )을 갖습니다 .
DRY = MSBuild를 사용하십시오.
빌드 시스템에서 무엇을 원하십니까? 두 가지 구성을 유지 관리하는 대신 IDE에서 사용하는 빌드 시스템을 원합니다 .
개인적으로 NAnt에 대한 실제 주장을 듣고 싶습니다. 왜냐하면 실제로 물을 보유하고있는 것을 생각할 수 없기 때문입니다.
여러 포스터에서 언급 한 한 가지 사실은 .csproj (또는 .vbproj 등) 파일을 직접 편집해야한다는 것입니다.
MSBuild를 사용하면 .user 파일을 사용하여 이러한. * proj 파일을 사용자 지정할 수 있습니다. 나는라는 이름의 프로젝트가있는 경우 MyCreativelyNamedProject.csproj을 그것의 내부의 MSBuild 작업을 사용자 정의 할, 나는라는 이름의 파일을 생성 할 수 있습니다 MyCreativelyNamedProject.csproj.user을 하고 사용 CustomBeforeMicrosoftCommonTargets 및 CustomAfterMicrosoftCommonTargets을 해당 파일을 사용자 정의 할 수 있습니다.
또한 NAnt 및 MSBuild는 모두 사용자 지정 MSBuild 작업 및 NantContrib 확장을 통해 심장의 내용에 맞게 사용자 지정할 수 있습니다.
따라서 NAnt 또는 MSBuild를 사용하면 실제로 익숙해집니다.
또한 MSBuild는 모든 새로운 버전의 .NET 및 Visual Studio가 출시되는 즉시 작동하도록 보장 되지만 NAnt는 약간의 지연이있을 수 있습니다.
NAnt 스크립트가 MSBuild를 호출 한다는 점에서 두 가지를 모두 사용합니다 . NAnt를 유지하는 나의 주된 이유는 고립 입니다. 이것이 왜 중요하다고 생각하는지 설명하겠습니다.
프로젝트에 의존성 추가. NAnt 빌드 파일은 Visual Studio에 익숙하지 않으므로 (제 경우에는 전문가라고 생각합니다) Visual Studio는 아무것도하지 않습니다. MSBuild 작업은 솔루션의 일부로 포함되므로 다른 MSBuild 작업을 참조 할 수 있습니다. MSBuild 커뮤니티 작업이 설치되지 않았기 때문에 빌드 할 수 없다는 것을 알기 위해 다른 사람으로부터 소스 코드를 받았습니다. 내가 특히 실망스럽게 생각하는 것은 Visual Studio가 빌드하지 않고 디버깅을 느슨하게하는 많은 오류를 발생시키지 않았다는 것입니다. 이것은 요청되는 빌드가 MSBuild 작업의 추가 사항없이 (예를 들어 디버그 빌드로) 진행될 수 있다는 사실에도 불구하고. 간단히 말해서 : 피할 수 있다면 프로젝트에 종속성을 추가하는 것을 좋아하지 않습니다 .
개발 팀을 던질 수있는 한 Visual Studio를 신뢰하지 않습니다. 이것은 HTML을 대량 학살 할 때 Visual Studio의 초기 시절로 이어집니다. 나는 여전히 예를 들어 디자이너를 사용하지 않습니다 (최근 회의에서 동료들도 같은 것을 발견했습니다). Visual Studio가 DLL 파일의 종속성과 버전 번호를 망칠 수 있음을 발견했습니다 (이를 복제 할 수는 없지만 프로젝트에서 일관되게 발생하여 많은 슬픔과 시간을 낭비했습니다). Visual Studio를 사용하여 디버그 모드로만 빌드하는 빌드 절차를 사용했습니다. 생산을 위해 NAnt를 사용하여 모든 것을 외부에서 제어 합니다. NAnt를 사용하여 빌드하면 Visual Studio가 더 이상 방해 할 수 없습니다.
추신 : 저는 웹 개발자이며 Windows Forms 개발을하지 않습니다.
MsBuild에 익숙하지는 않지만 양쪽의 주요 차이점 중 일부를 추가로 보완 할 수 있다는 인상을 받았습니다.
최근에 Nant에 Silverlight 프로젝트를 구축해야했습니다. 방금 MsBuild 로이 작업을 수행하면 인생이 더 쉬울 것이라는 것을 알았습니다 .Nant 스크립트 내에서 MsBuild 작업을 호출하여 두 가지를 혼합하고 일치시키는 것이 너무 평범하지 않다고 생각했습니다.
그 외에도 개인 취향의 문제가 될 것이라고 생각합니다. 분명히 Visual Studio 내에서 MsBuild의 기능 중 일부 / 대부분을 관리 할 수 있습니다. Nant는 스크립트를 직접 작성하는 것을 선호하는 경우 더 유연하고 더 적합 해 보입니다. Java 세계에서 온 사람이라면 집에있을 것입니다.
나는 둘 다 사용했다. 빌드 시스템을 재 설계 할 때 까다로운 문제가 발생했습니다. 즉, 우리 모두가 VS를 사용하여 프로젝트 파일, 설정 및 구성을 업데이트했기 때문에 .vcproj (및 제품군)를 제거 할 수 없었습니다. 따라서 중복 및 오류가 발생하기 쉬운 프로세스가 없으면 빌드 시스템을 새로운 파일 세트에 기반을 둘 수 없었습니다.
이런 이유로 나는 VS의 'proj'파일을 유지하고 MSBuild를 사용하기로 결정했습니다 (MSBuild 파일은 적어도 VS2005 및 VS2008은 MSBuild 프로젝트 파일을 사용합니다). 그 밖의 모든 것 (맞춤 구성, 단위 테스트, 포장, 문서 준비 ...)에 NAnt를 사용했습니다.
지속적인 통합을 위해 CruiseControl을 사용했습니다. 그래서 우리는 MSBuild를 사용하는 NAnt 작업을 트리거하는 CC 스크립트를 가지고있었습니다.
마지막 참고 사항 : MSBuild는 설치 프로젝트를 지원하지 않습니다! 따라서 DevEnv.com을 호출하거나 Visual Studio를 직접 사용하는 데 어려움이 있습니다. 이것이 내가 한 일이지만 개발자가 일반적으로 빌드 할 필요가 없으므로 빌드 할 때 수동으로 선택할 수 있기 때문에 모든 솔루션 구성에서 기본적으로 설치 프로젝트를 비활성화했습니다.
VS 솔루션을 빌드 할 수있는 능력 때문에 최근 NAnt에서 MSBuild로 전환했습니다. 그래도 여전히 NAnt를 사용합니다.
NAntContrib와 같은 MSBuild 커뮤니티 작업 을 확인할 수도 있습니다 .
NAnt에 사용할 수있는 설명서 및 자습서를 통해 NAnt를 사용하여 빌드 스크립트 학습을보다 쉽게 시작할 수 있습니다. NAnt가 중단되고 빌드 스크립트를 만들면 해당 지식을 MSBuild로 변환하기 시작했습니다 (NAnt에서 X를 수행했습니다. MSBuild에서 X를 어떻게 수행합니까?). Microsoft의 문서는 일반적으로 유용하기 전에 상당히 높은 수준의 지식을 가정합니다.
NAnt에서 MSBuild로 전환하는 이유는 MSBuild가 최신 버전이기 때문입니다. 불행히도 NAnt의 마지막 릴리스는 2007 년 12 월 8 일 이었지만 MSBuild 4.0 (.NET 4.0)은 그리 멀지 않았습니다. NAnt 프로젝트가 종료 된 것 같습니다.
MSBuild를 사용하여 빌드 스크립트 작성을 배우기 시작한 누군가를위한 좋은 문서를 찾으면 NAnt를 건너 뛰고 MSBuild로 바로 이동하십시오. NAnt가 새로운 릴리스를 내 놓으면 NAnt를 고수하는 것을 고려할 것이지만 지금은 뒤쳐져 있습니다.
YDeliver 마노로는 PSake 위에 구축 빌드 프레임 워크입니다. 이 라이브러리에는 다양한 라이브러리 기능, 워크 플로우 정의 기능이 있으며이를 통해 6 개 이상의 엔터프라이즈 프로젝트를 프로덕션에 제공했습니다.
TeamCity , CruiseControl 또는 PowerShell 을 실행할 수있는 모든 것과 함께 사용하십시오 .
우리는 FlubuCore를 사용합니다. C # 코드를 사용하여 프로젝트를 빌드하고 배포 스크립트를 실행하기위한 오픈 소스 C # 라이브러리입니다.
flubu가 사용되는 간단한 예 :
protected override void ConfigureTargets(ITaskContext session)
{
var compile = session.CreateTarget("compile")
.SetDescription("Compiles the solution.")
.AddTask(x => x.CompileSolutionTask())
.DependsOn("generate.commonassinfo");
}flubu에 대한 자세한 정보와 시작 방법은 여기에서 확인할 수 있습니다. choice-for-build-tool-msbuild-nant 또는 something