[.net] NAnt 또는 MSBuild 중 어느 것을 언제 선택해야합니까?

Program / 글쓴이

Stack Overflow에 다른 NAnt 및 MSBuild 관련 질문 이 있다는 것을 알고 있지만 둘 사이의 직접적인 비교를 찾을 수 없으므로 여기에 질문이 있습니다.

언제 MSBuild보다 NAnt를 선택해야합니까? 어느 쪽이 더 좋을까요? NAnt는 가정 / 오픈 소스 프로젝트와 MSBuild for work 프로젝트에 더 적합합니까? 둘 중 어느 것에 대한 경험이 있습니까?

답변

이번 주에도 비슷한 조사를 수행했습니다. 내가 결정할 수 있었던 것은 다음과 같습니다.

없음 :

  • 크로스 플랫폼 (Linux / Mono 지원). 예를 들어 웹 사이트를 여러 대상 (예 : Linux Apache 및 Windows IIS)에 설치하는 것이 편리 할 수 ​​있습니다.
  • Ant와 구문이 95 % 비슷 함 (현재 Ant 사용자 또는 Java 빌더가 쉽게 선택할 수 있음)
  • 빌드의 일부로 유닛 테스트를 실행하기 위해 NUnit과 통합하고 제품 문서화를 위해 NDoc과 통합합니다.

MSBuild :

  • .NET에 내장
  • Visual Studio와 통합
  • Visual Studio에서 MSBuild를 쉽게 시작할 수 있습니다. 더 깊이 들어가고 싶다면 파일을 직접 편집 할 수 있습니다.

주관적인 차이 : (YMMV)

  • NAnt 문서는 조금 더 간단합니다. 예를 들어, MSBuild 작업 참조 는 “Csc 작업-Csc 작업 및 해당 매개 변수를 설명합니다.”( “도움말”에 대한 감사?)와 NAnt 작업 참조 “csc-C # 프로그램 컴파일”을 나열합니다. 업데이트 : 내가 눈치 챘을 MSBuild를 문서 향상되었습니다 및 (아마도은 NAnt와 파에) 훨씬 낫다.
  • Visual Studio 내에서 직접 빌드 스크립트 소스 (*. * proj 파일)를 편집하는 방법을 알아내는 것은 쉽지 않습니다. NAnt에서는 Visual Studio에서 .build 스크립트를 XML 파일로 취급합니다.
  • 분명히 Visual Studio에서 웹 응용 프로그램 프로젝트는 기본적으로 *. * proj 파일을 얻지 못하므로 배포 스크립트를 만들기 위해 MSBuild를 실행하는 방법을 알아내는 데 큰 어려움이있었습니다.
  • NAnt는 Visual Studio에 기본 제공되지 않으므로 추가 기능을 사용하거나 “외부 도구”로 추가해야합니다. 이것은 약간의 고통입니다.
  • (편집 🙂 내 동료 중 한 명이 이것을 가져 왔습니다. 연속 통합을 위해 CruiseControl 을 사용하여 빌드 머신을 설정하려는 경우 CruiseControl은 즉시 NAnt와 통합됩니다. 업데이트 : CruiseControl에는 MSBuild 작업도 있습니다.
  • 주관적 차이에 대한 전체 및 최신 토론은 아래 의견을 참조하십시오.

답변

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를 사용하면 실제로 익숙해집니다.

  • Ant에 이미 익숙한 경우 NAnt를 사용하십시오. 학습 곡선은 매우 쉽습니다.
  • 두 도구 중 하나에 익숙하지 않은 경우 MSBuild는 이미 Visual Studio와 통합되어 있으며 추가 도구가 필요하지 않습니다.

또한 MSBuild는 모든 새로운 버전의 .NET 및 Visual Studio가 출시되는 즉시 작동하도록 보장 되지만 NAnt는 약간의 지연이있을 수 있습니다.

답변

NAnt 스크립트가 MSBuild를 호출 한다는 점에서 두 가지를 모두 사용합니다 . NAnt를 유지하는 나의 주된 이유는 고립 입니다. 이것이 왜 중요하다고 생각하는지 설명하겠습니다.

  1. 프로젝트에 의존성 추가. NAnt 빌드 파일은 Visual Studio에 익숙하지 않으므로 (제 경우에는 전문가라고 생각합니다) Visual Studio는 아무것도하지 않습니다. MSBuild 작업은 솔루션의 일부로 포함되므로 다른 MSBuild 작업을 참조 할 수 있습니다. MSBuild 커뮤니티 작업이 설치되지 않았기 때문에 빌드 할 수 없다는 것을 알기 위해 다른 사람으로부터 소스 코드를 받았습니다. 내가 특히 실망스럽게 생각하는 것은 Visual Studio가 빌드하지 않고 디버깅을 느슨하게하는 많은 오류를 발생시키지 않았다는 것입니다. 이것은 요청되는 빌드가 MSBuild 작업의 추가 사항없이 (예를 들어 디버그 빌드로) 진행될 수 있다는 사실에도 불구하고. 간단히 말해서 : 피할 수 있다면 프로젝트에 종속성을 추가하는 것을 좋아하지 않습니다 .

  2. 개발 팀을 던질 수있는 한 Visual Studio를 신뢰하지 않습니다. 이것은 HTML을 대량 학살 할 때 Visual Studio의 초기 시절로 이어집니다. 나는 여전히 예를 들어 디자이너를 사용하지 않습니다 (최근 회의에서 동료들도 같은 것을 발견했습니다). Visual Studio가 DLL 파일의 종속성과 버전 번호를 망칠 수 있음을 발견했습니다 (이를 복제 할 수는 없지만 프로젝트에서 일관되게 발생하여 많은 슬픔과 시간을 낭비했습니다). Visual Studio를 사용하여 디버그 모드로만 빌드하는 빌드 절차를 사용했습니다. 생산을 위해 NAnt를 사용하여 모든 것을 외부에서 제어 합니다. NAnt를 사용하여 빌드하면 Visual Studio가 더 이상 방해 할 수 없습니다.

추신 : 저는 웹 개발자이며 Windows Forms 개발을하지 않습니다.