.NET에서 Maven이 필요하지 않은 이유는 무엇입니까?

.NET에서 Maven이 필요하지 않은 이유는 무엇입니까?

---

.NET 세계에서는 Maven과 같은 도구가 실제로 필요하지 않다는 인상을 받았습니다.

Byldan 과 NMaven 이 있다는 것을 알고 있지만 (아직 살아 있습니까?) 아직이를 사용하는 실제 프로젝트를 보지 못했습니다.

또한 내가 작업 한 대부분의 .NET 프로젝트에서 Maven과 같은 도구가 필요하지 않았습니다. Maven maven이 해결하는 문제 (자동 종속성 해결, 규칙 기반 빌드 구조 ...)는 .NET에서 그다지 중요하지 않은 것 같습니다.

내 인식이 정확합니까?

왜 그렇습니까?

사람들은 .NET에서 실제로 무엇을 사용하고 있습니까? 자동 종속성 해결이 전혀 없습니까?

자체 빌드 도구를 작성하고 있습니까?

.NET 프로젝트를 관리하기 위해 Maven 자체를 사용하는 사람이 있습니까? 이것이 좋은 선택입니까?

당신의 경험은 무엇입니까?

---

아티팩트 종속성 해결을 위해 Nuget 이 이제 선호되는 대안 이라고 말하고 싶습니다 . 빌드 시간 해결을 지원하고 촉진합니다. 즉, 바이너리 종속성 아티팩트를 vcs에 체크인 할 필요가 없습니다. 이 기사를 참조하십시오 .

Nuget 버전 2.7부터는 옵션 중 하나 인 Nuget restore 명령을 사용하여 빌드 시간 확인이 훨씬 더 잘 지원됩니다.

업데이트 : 이제 대체 Nuget 호환 패키지 관리자를 사용할 수 있습니다. Paket 은 동일한 솔루션에서 일시적인 종속성을 처리하고 프로젝트 간의 종속성을 조화시키는 데 바닐라 누겟 클라이언트보다 낫습니다. 도구도 꽤 성숙해 보입니다 (VS 통합 및 CI 용 명령 줄 도구)

---

Maven은 거대한 자바 오픈 소스 인프라 의 핵심 부분 인 Apache 프로젝트에 의해 추진되고 있습니다. Maven의 광범위한 채택은 이것과 관련이 있어야하며 현재의 성숙도 (품질) 수준도 매우 좋습니다.

나는 .NET 오픈 소스 세계에 그러한 개념을 밀어 붙이는 큰 오픈 소스 행위자가 없다고 생각합니다. 어떻게 든 .NET은 항상 이러한 것들을 위해 레드몬드를 기다리는 것처럼 보입니다.

---

질문이 오래되었지만 여기에 내 생각이 있습니다. Maven은 단순한 빌드 도구가 아니며 저장소 관리, 프로젝트 관리, 종속성 관리, 빌드 관리 등과 같은 것보다 훨씬 많은 일을합니다.

하지만 제 생각에 가장 큰 매력은 의존성 관리입니다. JAR 지옥은 처음부터 Java Land에서 큰 문제이며 이에 대처하려면 도구가 필요합니다. .Net 세계에서는 그런 문제가 없습니다 (실제로 .Net 초기에는 DLL 지옥이 주요 매력으로 광고 되었음). 그래서 대부분의 사람들은 MSBuild에 대해 괜찮습니다. 나중에 많은 타사 라이브러리의 가용성으로 인해 관리 문제가 발생했습니다. 이 문제를 해결하기 위해 이제 Nuget이 있습니다.

간단히 말해서 MsBuild + Nuget은 대부분의 프로젝트에서 .Net 세계에서 충분히 훌륭하며 Maven은 그들에게 과잉입니다.

---

나는 여기에 대한 많은 답변에 동의합니다. .NET에는 많은 수의 독립 IDE가 없었으며 Visual Studio를 사용하여 코드를 작성하고 종속성을 관리했습니다. VS의 솔루션은 MSBuild에 충분하므로 빌드 서버에서 사용합니다.

반면에 Java는 많은 IDE를 발전 시켰고 Java는 IDE 외부에서 프로젝트를 관리하는 경로를 따라갔습니다. 개발자가 자신이 선택한 IDE를 사용할 수 있도록합니다. 저는 최근에 C #에서 Java 로의 크로스 트레이닝을 시작했으며 maven 빌드 개념이 상당히 이질적이라고 말할 수 있습니다.하지만 잠시 후 저는 그것을 좋아하고 더 중요한 것은 repo 개념이 나에게 제공하는 것을 봅니다.

이제 VS 관리 종속성에서 프로젝트 참조 또는 DLL에 대한 참조를 추가해야합니다. 이 DLL 참조 추가는 결함이 있습니다. 버전 변경을 관리하는 방법, 외부 및 내부 소스를 형성하는 타사 dll은 물론 프로젝트 참조가 아닌 자체 팀에서 포함하려는 dll을 어떻게 구성합니까? 일반적으로 파일 기반 디렉토리 구조를 기반으로 많은 해결 방법을 수행했지만 버전이 변경 될 때 우아하거나 훌륭하지는 않습니다. 또한 디렉토리를 구성하는 방법에 대한 고려 사항이되기 때문에 분기를 어렵게 만듭니다.

이제 Java 및 공용 mavan repos로 작업했습니다. 나는 Python으로 작업하고 pip install을 효과적으로 공용 저장소에서 다시 가져 왔습니다. 마지막으로 VS 2015로 C #에서 몇 가지 작업을 다시 수행했으며 Nuget과의 통합이 정확히 누락되었습니다.

이제 기업 환경에서 공용 리포지토리에 항상 직접 액세스 할 수있는 것은 아니므로 기업 리포지토리가 필요합니다. 다시 한 번 비 Microsoft 에코 시스템이 이에 앞서 있습니다.

기본적으로 Java를 요약하면 IDE 프로젝트 유지 관리가 사용되지 않은 오픈 소스 환경에서 발전한 반면 .NET은 프로젝트를 관리하는 Visual Studio에서 발전했으며 이러한 다른 경로는 나중에 Visual Studio에서 repo가 ​​제공된다는 것을 의미합니다.

마지막으로 이것이 저의 관찰입니다. Java 커뮤니티는 Java 기본 라이브러리가 제공하는 것이 적기 때문에 다른 사람들의 프레임 워크를 더 많이 사용하는 경향이 있습니다. .NET 사람들은 자신의 코드를 훨씬 더 많이 작성합니다. 자바 커뮤니티는 패턴과 관행의 생태계가 더 큰 반면 .NET은 다시 자체 코드를 작성하거나 Microsoft를 기다렸습니다. 이것은 변화하고 있지만 repos에 대한 요구 사항에서 .NET이 Java 뒤에있는 이유를 다시 보여줍니다.

---

성숙한 실제 대안이 없기 때문에 우리는 NAnt를 사용하고 있습니다. 동시에 여러 프로젝트에서 작업하면서 여러 버전의 라이브러리를 사용하고이를 처리하는 방법을 연구했습니다. Maven 제안은 정말 유망하지만 .NET 플랫폼에서 유용 할만큼 성숙하지는 않습니다.

대부분의 .NET 프로젝트는 디렉터리 구조, 종속성 등을 자동으로 제안 / 강제하는 Visual Studio를 사용하기 때문에 필요성이 덜 명확하다고 생각합니다. IDE에 따라 이러한 종류의 규칙에 따라 개발 팀의 유연성이 제한되고 특정 솔루션 및 공급 업체에 구속되기 때문에 이는 잘못된 '솔루션'입니다. 이것은 Java 세계에서는 분명히 해당되지 않으므로 Maven과 같은 도구가 분명하게 필요합니다.

---

XML 기반 빌드 도구가 마음에 들지 않습니다.

우리는 .net 제품을 만들기 위해 루비 레이크를 적용했습니다. Albacore 는 .net 프로젝트를 빌드하기위한 정말 멋진 레이크 작업 모음입니다.

Rake를 사용하면 복잡한 빌드 스크립트도 매우 쉽게 만들 수 있으며 수많은 꺾쇠 괄호 대신 코드를 처리하게됩니다.

---

나는 이것이 오래된 게시물이라는 것을 알고 있지만 그것을 만났을 때 다른 훌륭한 대안을 공유하고 싶었습니다.

Build Automation with PowerShell and Psake  

많은 사람들이 Psake (sockey로 발음)를 이용하지 않고 있습니다. 정말 멋진 점은 msbuild를 사용하고 있다는 것입니다.

이것은 maven 질문에 대한 대답은 아니지만 (maven은 지루한 장황한 ANT 스크립트를 기반으로 한 Java 빌드의 필요성에서 나왔습니다).

대부분의 사람들은 Jenkins, Hudson, Cruise Control, TeamCity, TFS와 같은 CI (지속적 통합)를 사용하지 않으며 powershell도 사용하지 않습니다.

msbuild를 활용하는이 PSake for Powershell은 작업 중심의 작업을 매우 체계적으로 구성합니다. 다음은 링크 예입니다. http://www.shilony.net/2013/06/15/build-automation-with-powershell-and-psake/

---

우리는 UppercuT를 사용합니다. UppercuT는 NAnt를 사용하여 빌드하며 빌드 프레임 워크를 사용하기 매우 쉽습니다.

(1) 솔루션 이름, (2) 소스 제어 경로, (3) 대부분의 프로젝트에 대한 회사 이름만큼 쉬운 자동화 된 빌드!

https://github.com/chucknorris/uppercut/

여기에 몇 가지 좋은 설명이 있습니다 : UppercuT

추가 정보

---

UppercuT는 기존의 자동화 된 빌드입니다. 즉, 구성 파일을 설정하면 많은 기능을 무료로 사용할 수 있습니다. 아마도 가장 강력한 기능은 한 곳에서 환경 설정을 지정하고 소스를 빌드 할 때 문서를 포함하여 모든 곳에 적용 할 수있는 기능입니다.

Documentation available: https://github.com/chucknorris/uppercut/wiki

Features :

• Simple setup
• Simple upgrades
• Custom extension points (pre, post, and replace) for each step of the build process http://uppercut.pbworks.com/CustomizeUsingExtensionPoints
• Has documentation for integration w/Team City, CruiseControl.NET, and Jenkins (formerly Hudson) https://github.com/chucknorris/uppercut/tree/master/docs
• Works on Linux w/Mono
• Versioning DLLs based on build number and source control revisions (SVN, TFS, Git, HG)
• Compile activities - F5 or Ctrl + Shift + B
• Strong naming made as easy as true/false
• Code Testing and Analysis
  • Testing
    • NUnit
    • MbUnit v2
    • Gallio
    • xUnit
  • NCover
  • NDepend
  • Nitriq
  • Mono Migration Analyzer
• Obfuscation
• ILMerge
• Environment Templating and Building (ConfigBuilder, DocBuilder, SQLBuilder, DeploymentBuilder) https://github.com/chucknorris/uppercut/blob/master/docs/ConfigBuilder.doc?raw=true
• Packaging output to prepare for deployment
• Zips up output

참고URL : https://stackoverflow.com/questions/729545/why-is-there-no-need-for-maven-in-net