Nant에서 msbuild로 전환해야 합니까?

StackOverflow https://stackoverflow.com/questions/10634

문제

저는 현재 nant, ccnet(크루즈 컨트롤), svn, mbunit을 사용하고 있습니다.저는 msbuild를 사용하여 sln 빌드를 수행합니다. 쉘 아웃이 더 간단하기 때문입니다.

전체 빌드 스크립트를 MSBuild로 전환하면 어떤 장점이 있나요?테스트, 와트 스타일 테스트, xcopy 배포를 실행할 수 있어야 합니다.이게 더 쉽나요?

업데이트:Nant에서 msbuild로 전환하게 만드는 강력한 기능이 있습니까?

도움이 되었습니까?

해결책

저는 MSBuild를 좋아합니다.한 가지 이유는 .csproj 파일이 msbuild 파일이고 VS에서 빌드하는 것은 명령줄에서 빌드하는 것과 똑같기 때문입니다.또 다른 이유는 제가 사용해 온 CI 서버인 TeamCity의 좋은 지원입니다.MSBuild 사용을 시작하고 빌드 프로세스에서 더 많은 사용자 지정 작업을 수행하려는 경우 MSBuild 커뮤니티 작업.그들은 당신에게 멋진 추가 작업을 제공합니다.나는 몇 년 동안 NAnt를 사용하지 않았지만 후회하지 않았습니다.

또한 Ruben이 언급한 것처럼 SDC 작업 CodePlex의 작업.

더 많은 재미를 위해 CodePlex의 MSBuild 확장 팩, 여기에는 트위터 작업이 포함됩니다.

다른 팁

내 조언은 정반대입니다. 전염병처럼 MSBuild를 피하십시오.NANT는 자동 테스트를 수행하고, 여러 프로덕션 환경에 배포하고, 진입 환경을 위한 CruiseControl과 통합하고, 소스 제어와 통합하기 위해 빌드를 설정하는 것이 훨씬 쉽습니다.우리는 TFS/MSBuild(TFSDeployer, 사용자 정의 powershell 스크립트 등 사용)를 사용하여 NANT로 수행할 수 있었던 작업을 즉시 수행할 수 있도록 하는 데 많은 어려움을 겪었습니다.시간을 낭비하지 마십시오.

MSBuild를 사용하는 가장 강력한 이유(적어도 .NET 3.5 이상)는 빌드 엔진이 동시에 빌드될 수 있다는 것입니다.

이는 다중 코어/프로세서가 있는 경우 빌드 속도가 크게 향상됨을 의미합니다.

3.5 이전에는 MSBuild가 병렬 빌드를 수행하지 않았습니다.

나는 MSBuild와 Nant가 상당히 비슷하다고 생각합니다.이들 중 하나를 사용하는 경우, 귀하가 선택한 제품에 누락된 매력적인 기능이 없으면 일반적으로 이들 간에 전환하지 않을 것입니다.

저는 개인적으로 새 프로젝트에 MSBuild를 사용하지만 마일리지는 다를 수 있습니다.

도움이 되었기를 바랍니다!

편집하다: @ChanChan - @Jon은 Nant가 .NET 3.5 애플리케이션을 구축하지 않는다고 언급합니다.이는 변경하거나 적어도 병렬로 사용하는 이유가 될 수 있습니다.MSBuild 쪽으로 더 많이 이동하면서 두 기술 모두에서 다른 뛰어난 제품을 강조할 만큼 지식이 풍부한 사람은 아닐 것입니다.

편집하다: Nant는 이제 .NET 3.5 애플리케이션을 구축하는 것으로 보입니다.

NAnt는 더 오래 사용되었으며 훨씬 더 성숙한 제품이며 IMO 사용도 더 쉽습니다.활용할 수 있는 커뮤니티 노하우가 많이 있으며, 이는 크로스 플랫폼이기도 합니다. Mono는 물론 .NET 및 Silverlight에서도 실행할 수 있는 앱을 구축하는 데 관심이 있다면 말이죠.기본적으로 MSBuild가 수행하는 것보다 훨씬 더 많은 작업을 수행합니다.아, 그렇습니다. NAnt에서 MSBuild를 호출할 수 있습니다(NAntContrib에서 가능) :-)

부정적인 측면에서는 NAnt와 자매 프로젝트인 NAntContrib이 정체된 것으로 보이며 가장 최근 업데이트는 2007년 후반입니다.

제가 생각하는 MSBuild의 주요 장점은 .NET Framework와 함께 제공되므로 설치할 제품이 하나 적다는 것입니다.그리고 더 활발한 개발이 진행되고 있습니다(비록 이전 NAnt를 따라잡을 수는 있지만).

개인적으로 나는 그 구문을 익히기가 좀 더 어렵다고 생각하지만, ti에 계속 노출되면 일이 더 쉬워질 것이라고 확신합니다.

결론?기존 NAnt 스크립트로 작업하는 경우 계속 사용하세요. 번거롭게 이식할 가치가 없습니다.새 프로젝트를 시작하고 있고 모험심을 느끼고 있다면 MSBuild를 사용해 보세요.

또한 nant에서 msbuild로 전환했습니다.빌드가 매우 표준적이라면 설정하는 데 큰 문제가 없지만 특정 빌드 작업이 많으면 msbuild에 대한 사용자 지정 작업이 훨씬 적기 때문에 사용자 지정 ms 빌드 작업을 작성해야 합니다.

합리적인 빌드 결과를 표시하려면 사용자 정의 로거 등을 망쳐야 합니다.전체 팀 빌드는 Nant만큼 성숙하지 않습니다.

그러나 실제 이점은 TFS 소스 제어 및 보고 서비스와의 통합입니다.TFS를 소스 제어 시스템으로 사용하지 않는다면 그만한 가치가 없습니다.

  • (적어도) 아주 설득력 있는 이유가 있지 않는 한 전환하지 마세요.
  • NAnt는 오픈 소스이며 그렇지 않은 경우 빌드 시스템을 사용자 지정할 수 없지만 MSBuild는 그렇지 않습니다.
  • NAnt는 MSBuild를 쉽게 실행할 수 있지만 그 반대의 경우는 잘 모르겠습니다.
  • VS2005 이상을 사용하는 경우 MSBuild 스크립트가 이미 작성되어 있습니다(프로젝트 파일 ~이다 MSBuild 파일.)
  • NAnt를 사용하고 VS를 사용하여 프로젝트 파일, 설정 및 구성을 편집하는 경우 VS 프로젝트 파일에서 NAnt 파일을 업데이트하려면 변환기/동기화 도구를 작성해야 합니다.

@브래드 리치

저는 일반적으로 누락된 매력적인 기능이 없는 한 둘 사이를 전환하지 않을 것입니다.

msbuild를 사용하는 강력한 이유는 무엇입니까?단점이 있나요?

지금까지 나는 당신의 대답에서 "걱정하지 마세요"라는 꽤 좋은 대답을 얻었습니다.

기능이나 사용 편의성 측면에서 비교적 비슷하다고 생각합니다.C# 기반이기 때문에 msbuild가 nants보다 작업하기 더 쉽다는 것을 알았습니다. 하지만 이것이 전환해야 할 강력한 이유는 아닙니다.

Nant가 당신을 위해 정확히 무엇을 하지 않고 있습니까?아니면 혹시 놓칠 수 있는 멋진 기능이 있기를 바라시나요?:)

C#의 가장 좋은 점 중 하나는 .net 프레임워크가 있으면 msbuild를 실행하는 데 필요한 모든 것이 있다는 것입니다.대규모 팀/프로젝트에서 작업하고 인력/하드웨어 교체가 있을 때 이는 환상적입니다.

개인적으로 나는 둘 다보다 SCons를 선호합니다 :)

자동화된 빌드에 msbuild 대신 nAnt를 계속 사용하는 주된 이유는 빌드를 더욱 세밀하게 제어할 수 있기 때문입니다.csproj를 사용하는 msbuild에는 빌드 파일이 있으므로 해당 프로젝트의 모든 소스가 하나의 어셈블리로 컴파일됩니다.이로 인해 로직을 분리하는 대규모 프로젝트에 대한 내 솔루션에 많은 프로젝트가 있게 되었습니다.Nant를 사용하면 원하는 것을 하나의 프로젝트에서 여러 어셈블리로 컴파일할 수 있는 빌드를 배열할 수 있습니다.

나는 이 경로를 좋아합니다. 왜냐하면 내 솔루션에 많은 프로젝트 파일이 필요하지 않기 때문입니다.레이어를 분할하는 폴더가 있는 하나의 프로젝트를 만든 다음 nant를 사용하여 각 레이어를 자체 어셈블리로 만들 수 있습니다.

그러나 WPF 애플리케이션 구축과 같은 일부 빌드 작업에는 nant와 msbuild를 함께 사용합니다.Nant 내에서 msbuild 대상을 사용하여 WPF 애플리케이션을 컴파일하는 것이 훨씬 쉽습니다.

이것을 끝내고 내 대답의 요점은 그것들을 나란히 사용하고 싶지만 이 구성에서 msbuild를 사용할 때 일반적으로 디렉터리에 파일을 복사하는 것과 같은 빌드 자동화 작업을 수행하지 않고 직접 컴파일하기 위한 것입니다. 예를 들어 도움말 문서를 참조하거나 단위 테스트를 실행합니다.

사실 저는 아직도 이 질문을 스스로 해결하려고 노력하고 있지만 여기에는 MSBuild에 대한 한 가지 큰 보너스가 있습니다.msbuild.exe를 직접 호출하여 로컬 연속 통합에 동일한 빌드 파일을 사용하는 동시에 동일한 빌드 파일과 VSTS의 서버 측 연속 통합을 사용할 수도 있습니다(속성/설정은 다를 가능성이 높지만).

즉.TeamCity의 MSBuild 스크립트 지원과 비교하여 VSTS 오직 MSBuild 스크립트를 지원합니다!나는 과거에 MSBuild에서 NAnt를 실행하여 이 문제를 해결했습니다.다른 사람들이 이 방법과 그 반대 방법을 권장하는 것을 본 적이 있지만 제겐 너무 엉성한 것 같아서 피할 수 있으면 하지 않으려고 노력합니다.따라서 "전체 Microsoft 스택"(VSTS 및 TFS)을 사용하는 경우 MSBuild 스크립트를 사용하는 것이 좋습니다.

낸트 기본적으로 더 많은 기능이 있지만 MSBuild 훨씬 더 나은 기본 구조(항목 메타데이터 암석)를 가지고 있어 재사용 가능한 MSBuild 스크립트를 훨씬 쉽게 작성할 수 있습니다.

MSBuild를 이해하는 데 시간이 좀 걸리지만 일단 이해하고 나면 매우 좋습니다.

학습 자료:

전환할 이유가 없습니다.MsBuild 자체는 사용 중인 프레임워크에 사용자를 고정시킵니다.NAnt를 사용하는 경우 이를 여러 프레임워크에서 사용할 수 있으며 msbuild로 쉘아웃하여 실제로 빌드 작업을 수행할 수 있습니다.

나는 이 점에서 NAnt의 팬입니다. 왜냐하면 NAnt가 프레임워크에서 여러분을 약간 분리시키기 때문입니다.

저는 자동화된 빌드에 규칙을 적용하는 프레임워크를 만들었고 이를 NAnt에 구축했습니다.UppercuT라고 하며 사용하기 매우 쉬운 Build Framework입니다.

(1) 솔루션 이름, (2) 소스 제어 경로, (3) 대부분의 프로젝트에 대한 회사 이름만큼 쉽게 자동 빌드됩니다!

http://code.google.com/p/uppercut/

여기에 좋은 설명이 있습니다: 어퍼컷

MSBuild가 Visual Studio와 통합되면 프로그래머가 빌드 시스템을 사용하는 데 따른 마찰이 줄어듭니다.주로 "솔루션 빌드"만 하면 모든 것이 작동하는 반면, 사용자 지정 빌드 단계 및 기타 기능을 사용하거나 더 나쁘게는 개발자가 일종의 외부 스크립트를 실행하여 빌드하도록 강요하는 것과 비교됩니다.

이제는 더 간단하기 때문에 NAnt보다 MSBuild를 선호하는 경향이 있습니다.물론, NAnt는 훨씬 더 많은 기능을 갖고 있고, 더 강력하지만, 금방 감당할 수 없게 될 수 있습니다.귀하와 귀하의 빌드 엔지니어가 NAnt 스크립트를 단순하게 유지하는 원칙을 갖고 있다면 모든 것이 좋습니다.그러나 나는 너무 많은 NAnt 기반 시스템이 더 이상 그것이 무엇을 하는지 아무도 이해하지 못하는 지점까지 가고, 좋은 printf와 동등한 작업을 수행하는 것 외에는 디버깅할 수 있는 실제 방법이 없는 지점까지 가는 것을 보았습니다.if/else 문이나 for 루프를 사용하기 시작하는 순간, IMHO 냄새가 나기 시작합니다.

반면에 MSBuild는 메타데이터를 기반으로 하는 견고한 기반과 덜 장황한 구문을 갖추고 있습니다.단순성(또는 기능 부족...)보는 방법에 따라) XML 마크업으로 논리를 작성하는 대신 새 작업을 통해 .NET 코드로 논리를 작성해야 합니다.이는 재사용성을 장려하고 무엇보다도 실제 디버거에서 빌드 시스템을 실제로 디버깅할 수 있게 해줍니다.

MSBuild의 유일한 문제는 자주 발생하지 않는 버그(특히 첫 번째 버전에서) 또는 모호한(문서화되었지만) 동작입니다.그리고 그것이 정말로 당신을 괴롭히는 종류의 일이라면 Microsoft에 묶여 있다는 것입니다.

NANT에서 MSBuild로 전환했습니다.프로젝트는 .Net 4.0에서 실행 중입니다.

Nant에서의 나의 경험은 좋았습니다.프로젝트가 일종의 사망했습니다.그리고 .Net 4.0이 출시되면서 빌드 프로세스를 재평가할 때가 되었습니다.

Nant가 마지막으로 릴리스된 이후 MSBuild가 계속해서 발전해 왔습니다.이 시점에서는 MSBuild가 최선의 방법입니다.사용하기 쉽고 확장 기능도 많습니다.나는 하루 반 만에 Nant 스크립트를 다시 작성했습니다.MSBuild 스크립트는 Nant 스크립트 크기의 1/3입니다.

Nant 스크립트 작업의 대부분은 다양한 환경을 설정하는 것이었습니다.MsBuild/.Net 4.0에는 내장되어 있습니다.

MSBuild를 사용합니다 나란히 Nant, Nant의 현재 버전은 아직 .NET 3.5 애플리케이션을 컴파일할 수 없기 때문입니다(.NET 2.0이 처음 출시되었을 때도 마찬가지였습니다).

msbuild를 사용하는 유일한 이유는 크루즈 컨트롤과 같은 자동화된 빌드 서버를 사용하려는 경우입니다.전환하지 않을 경우에는 그대로 두겠습니다.

나는 Nant를 사용하고 그것을 좋아합니다.나는 MSBuild를 사용했지만 다음과 같은 이유로 그것을 싫어했습니다.

  1. Microsoft는 자신의 작업에 너무 본질적인 자체 빌드 절차를 따르도록 강요하므로 적어도 작동할 수 없었습니다(NET1.1을 컴파일해야 했기 때문에 Nant와 MSbuild를 혼합해야 했습니다).자신만의 MSBuild 파일을 만들 수 있다는 것을 알고 있지만 이해하고 유지 관리하는 것이 복잡하다고 생각했습니다.

  2. 파일 작업을 수행하는 ItemType은 따라가기가 너무 어렵습니다.Nant가 똑같은 작업을 훨씬 더 쉽고 직접적으로 수행하도록 할 수 있습니다(ItemType 목록을 만든 다음 파일 작업에 전달해야 했습니다).

  3. MsBuild에서는 자신만의 작업 dll을 만들어야 합니다. Nant에서는 이를 수행하거나 스크립트 내에 C# 코드를 포함할 수 있으므로 전체 프로젝트를 훨씬 쉽게 진행하고 빌드할 수 있습니다.

  4. Nant는 Net1.1에서 작동하지만 MsBuild는 작동하지 않습니다.

  5. nant를 설치하려면 압축을 풀고 자체 저장소 내에서 찾아서 실행할 수도 있습니다.MsBuild를 설치하는 것은 Visual Studio 등의 많은 요소에 의존하기 때문에 훨씬 어렵습니다.(어쩌면 내가 틀렸을지도 모르지만 그것은 진실인 것 같습니다).

뭐 이건 내 의견인데...

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top