스탠드업에서 Damian은 Nuget 관련 항목이 현재 packages.config를 대체할 항목으로 이동할 것이라고 언급했습니다. 분명히 이러한 결정은 공정한 길을 가고 있으며 이 시점에서 구체적인 답변을 얻을 수 있을지는 의문입니다.

그리고 저는 "JSON이 이러한 종속성을 표현하는 것이 더 간단하다"는 데 동의하지 않습니다. 장단점이 있습니다. https://gist.github.com/darrelmiller/07fed784d2c20de9f5d3719977167181을 참조

_if_가 nuget.json으로 이동하는 변경 사항에 동의합니다. 어쨌든 dev 편집이 가능해야한다고 생각한 project.Json의 유일한 부분입니다.

@darrelmiller Yaml은 아마도 장황한 측면에서 더 나은 대안일 것입니다. 그리고 배열 대신 쉼표로 구분된 문자열로 속임수 ;).

@sandorfr 입니다. 그러나 XML 기반 프로젝트 시스템으로 다시 이동하는 이유 중 하나는 .net 생태계의 XML 기반 프로젝트 시스템에 대한 기존의 중요한 도구 때문이라고 생각합니다. 내 의견은 XML이 본질적으로 나쁘지 않다는 점을 지적하기 위해 최상의 형식을 식별하려고 시도하고 식별하려는 것이 아닙니다.

네, 이번 주 최악의 소식입니다. 시간을 되돌리는 것과 같습니다... :(실제로 Xml은 나쁘지 않지만 msbuild는... 그리고 msbuild xml 기본 프로젝트는 귀하가 설명한 것처럼 매끄럽지 않을 것입니다.

그러나 XML 기반 프로젝트 시스템으로 다시 이동하는 이유 중 하나는 .net 생태계의 XML 기반 프로젝트 시스템에 대한 기존의 중요한 도구 때문이라고 생각합니다.

나는 의도가 msbuild와 같이 수하물을 앞으로 운반하려는 의도라면 그것이 완전히 새로운 것임을 나타내기 위해 모든 것에 " core " 접미사를 붙인 이유를 이해할 수 없습니다.

그 과정이 2년 넘게 너무 고통스러웠지만 새로운 추가와 개선이 모두 생태계를 다른 생태계와 일치시키고 모두 정당한 이유가 있는 변화였기 때문에 많은 사람들이 괜찮았습니다. 그러나 갑자기 암흑 물질 기업 개발자들이 비공개로 피드백을 제공하기 시작했고 우리는 이월해야 할 많은 짐을 보고 있습니다.

XML 기반 구성이 있는 생태계는 많지 않습니다. 실제로 새로 설계된 모든 생태계는 다른 형식(YAML, JSON 등)을 수용하고 있습니다. 소셜 미디어에 있는 모든 사람들의 반응을 보세요. 이 변화를 좋아하는 사람은 많지 않습니다. 그러나 개인적으로 제공된 피드백이 팀에 더 중요해 보입니다. 그것은 나쁜 것이 아닙니다. 이유를 이해하지만 이 생태계에서 결정이 처리되는 방식을 보여주는 것일 뿐입니다.

이번주 최악의 뉴스에 +1. 이에 대한 논의는 어디에서 이루어졌습니까? 나는 아무 것도 찾을 수 없으며 일방적 인 결정입니다.

나는 이 결정에 대한 커뮤니티 지원을 보지 못했고 반대도 많이 했습니다(마지막 계산에서 85%에서 15%). 어떤 정보를 바탕으로 누가 결정을 내렸는지 토론은 어떻게 진행됐나요?

이것이 .NET Core에서 작업을 수행하는 방식입니까? 비공개 레거시 기술 목록을 지원하기 위해 비공개로 품질을 저하시키십니까?

부디 예전 기술을 사용하는 사람들이 사용할 수 있는 project.json에서 .csproj를 만드는 VS 확장을 만들어 봅시다.

그러나 XML 기반 프로젝트 파일의 악몽으로 우리를 되돌려 보내지 마십시오. 그것들은 도입되었을 때 나쁜 생각이었고 우리는 10년 넘게 나쁜 병합과 어려운 가독성에 대한 세금을 내고 있습니다. 충분 해.

나는 당신이 너무 비관적이라고 생각합니다. 그리고 그것은 주로 우리 모두가 이것에 놀랐기 때문인 것 같습니다. 그들이 그들의 계획에 대해 더 많은 정보를 공유하게 하고 우리는 보게 될 것입니다. @DamianEdwards 는 project.json 모델의 좋은 부분을 유지하고 싶다고 분명히 말했습니다.

제 생각에는 다음과 같습니다.

• 각 cs 파일을 지정할 필요가 없습니다.
• 프로젝트를 언로드하지 않고도 파일을 수정할 수 있음
• 파일에서 직접 너겟 종속성을 수정할 수 있음(IntelliSense 사용)
• global.json을 통해 nuget 패키지를 로컬 소스로 교체할 수 있음

컴파일 면에서는 Visual Studio를 설치하지 않고도 컴파일이 가능해야 한다고 생각합니다. 나에게 실제 명령이 "dotnet build"인지 "msbuild"인지는 중요하지 않습니다. 중요한 것은 전체 솔루션을 컴파일하는 방법이 있어야 한다는 것입니다. 그건 그렇고 - 아직 "dotnet cli"에 존재하지 않습니다(적어도 내가 아는 한).

이것이 달성될 수 있다면, 나는 그들이 사용하는 구문이 무엇이든 괜찮습니다. XML은 훌륭하지 않지만 JSON에는 분명히 단점도 있습니다.

편집 : 이것이 .NET Core 등의 기본 (그리고 훌륭한) 아이디어를 변경하지 않는다고 생각합니다.

IMHO, 주요 문제는 RTM 직전의 이러한 유형의 급격한 변화가 좋지 않다는 것입니다. 베타 시간에 이런 일이 발생하면 개발자/팀이 그다지 놀라지 않을 것입니다. 사람들이 지난 2년 동안 하고 있는 project.json 시스템 에 따라 현재 제품/라이브러리/프레임워크에 대해 생각해 보세요. Asp.Net은 미리 보기/알파/베타가 아닌 RC에 있습니다. 이러한 유형의 변경은 개발자/팀의 신뢰를 깨뜨립니다.

IMHO, 주요 문제는 RTM 직전의 이러한 유형의 급격한 변화가 좋지 않다는 것입니다.

나도 처음에는 그렇게 생각했지만 내가 이해하는 한 애플리케이션 코드가 변경되지는 않을 것입니다. 이는 project.json/xproj/csproj 파일에만 영향을 미치며 변경이 자동일 수 있다고 말했습니다. 따라서 이는 Visual Studio를 업그레이드할 때 이미 여러 번 발생한 이전 프로젝트 마이그레이션 단계와 유사합니다.

BTW 저는 항상 project.json 및 xproj 파일(Visual Studio 템플릿의 기본 네임스페이스와 일부 출력 경로가 포함되어 있으므로 때때로 편집해야 함)이 이상하다고 생각했습니다.

BTW 저는 항상 project.json 및 xproj 파일(Visual Studio 템플릿의 기본 네임스페이스와 일부 출력 경로가 포함되어 있으므로 때때로 편집해야 함)이 이상하다고 생각했습니다.

어쩌면 이상할 수도 있지만 그들은 다른 것들에 대해 대답합니다. project.json은 .net 핵심 프로젝트를 빌드하는 데 필요한 유일한 파일이고 xproj는 Visual Studio라는 독점 도구와 관련이 있습니다. webstorm을 사용하여 노드 프로젝트에서 작업하는 경우 package.json 및 .idea와 매우 유사합니다. 관심사의 분리일 뿐입니다. Visual Studio는 원하는 경우 속성 아래에서 project.json을 숨길 수 있고 모든 것을 함께 혼합하지 않고 원하는 경우 병합된 큐레이트 GUI 경험을 제공할 수 있습니다.

나는 xproj에 대한 모든 것을 잊어 버린 너무 오랫동안 VS Code의 Mac에서이 물건을 사용해 왔습니다. OTOH, Visual Studio에서 디버깅과 훨씬 더 많은 것을 놓쳤습니다!

나는 당신이 너무 비관적이라고 생각합니다. 그리고 그것은 주로 우리 모두가 이것에 놀랐기 때문인 것 같습니다

아니요, 죄송합니다. 제가 너무 비관적이라고 생각하지 않습니다. XML은 코드 병합을 수행할 모든 상황, 즉 모든 소프트웨어 프로젝트에 적합하지 않은 형식입니다. XML은 구성 파일 및 프로젝트 파일과 같은 것을 위해 설계되지 않았으며 절대 사용되어서는 안 됩니다. .NET은 모든 사람들이 XML이 모든 것을 해결할 수 있다고 생각했을 때 다시 빌드되는 불운을 겪었습니다.

http://c2.com/cgi/wiki?XmlSucks
http://www.ibm.com/developerworks/xml/library/x-sbxml/index.html
http://nothing-more.blogspot.co.za/2004/10/where-xml-goes-astray.html

이제 모든 사람들이 JSON이 모든 것을 해결할 것이라고 생각할 때 .NET Core가 구축되고 있습니다. 나는 JSON이 XML보다 더 장기적인 솔루션이라고 생각하지 않지만, XML 충돌보다 JSON 충돌을 병합하는 것이 더 쉽다는 것을 알고 있습니다.

프로젝트 파일에 대한 XML 쓰레기를 처리하지 않는 신선한 공기를 찾았고 JSON 파일을 읽는 것이 더 쉽다는 것을 알게 되었고 JSON 파일을 Visual Studio 외부에서 작업하는 것이 더 쉽다는 것을 알게 되었습니다. XML/MSBuild로 돌아가고 싶지 않습니다.

네, 이것들은 제 개인적인 느낌이고 네 주관적입니다. 하지만 트위터와 다른 곳의 댓글에 따르면 저는 그것들이 고립되어 있다고 생각하지 않습니다. 솔직히 말해서, 이 결정은 .NET Core의 전체 방향, 특히 이와 같은 중요한 결정이 내려지는 방식을 완전히 의심하게 만듭니다.

@DamianEdwards 는 project.json 모델의 좋은 부분을 유지하고 싶다고 분명히 말했습니다.

내 관점에서 볼 때 project.json 모델의 가장 좋은 부분은 csproj도, MSBuild도, XML도 아니라는 점입니다. 그 "좋은" 부품이 유지됩니까? 분명히 아닙니다. 우리가 그들이 마침내 잔디를 깎고 있다고 믿게 된 후, 그것은 모두 잘못된 방향이었다는 것이 밝혀졌습니다. 새로운 빌드 시스템, Gulp 및 project.json 및 상황이 어떻게 달라지는지에 대해 들었고, 그 다음에는 모두 가짜였으며 다시 구식 MSBuild인 것으로 나타났습니다.

JSON 및 XML 형식은 병합 측면에서 거의 동일하다고 생각합니다. 둘 다 닫는 태그가 있습니다(JSON에서는 중괄호일 뿐임). 이는 빈/하나/다 시나리오에 문제가 있음을 의미합니다. 빈 JSON 배열을 항목이 있는 배열로 변경하기만 하면 됩니다. JSON은 목록에 항목을 추가하면 두 줄을 변경하는 끝 쉼표의 추가 단점이 있다고 주장합니다.

그것을 피하려면 YAML 등으로 이동해야합니다.

csproj의 IMO 문제는 XML이 아니라 Visual Studio가 이를 처리하는 방식과 모든 cs 파일이 포함되어 있다는 것입니다. 이 문제가 해결되고 도구가 파일의 항목을 임의로 변경하지 않으면 병합이 더 이상 문제가 되지 않습니다.

그러나 가독성 측면에서도 JSON을 선호합니다. 처음부터 project.json을 작성할 수 있었습니다. 더 이상 csproj로 그렇게 할 수 없을 것 같습니다(csproj에는 임의의 ProjectGuid 등이 필요함). 따라서 이를 위한 도구/명령줄 지원이 확실히 필요합니다.

내가 많이 듣지 못한 이 모든 것에 대한 나의 주요 관심사는 .csproj 프로젝트 파일보다 참조에 관해서 project.json 가 훨씬 더 선언적이라는 것입니다. project.json 파일에 있는 종속성의 장점과 내가 우리 코드베이스를 이 파일로 마이그레이션하기를 고대했던 이유는 "이 종속성이 필요합니다"라고 말하면 로컬 프로젝트든 NuGet 패키지. 우리의 경우 이것은 우리에게 많은 유연성과 멋진 새로운 옵션을 제공할 것입니다. 대조적으로, 현재 .csproj 파일의 참조는 디스크의 .dll 파일에 대한 하드 상대 경로입니다. 지금은 기존 프로젝트의 packages.config에 항목을 추가해도 아무 것도 하지 않습니다. 해당 패키지의 특정 .dll 에 대한 참조도 .csproj 파일에 추가해야 합니다. . 이는 Visual Studio 내의 NuGet 도구를 통해 수행되지만 project.json 파일에 한 줄의 텍스트를 추가하는 것이 훨씬 간단할 때 이러한 도구를 사용하고 싶지 않습니다.

나는 팀이 project.json 파일에서 제공하는 모든 기능을 유지하고 .csproj 형식의 기능을 확장하기를 원하지만 project.json 를 파일로 유지하는 것에 대해서도 이야기한다는 것을 알고 있습니다. 당신의 NuGet 패키지를 지정할 수 있습니다. 나는 그와 함께 현재의 상황과 비교하여 추가 할 수 무엇을 볼 수 없습니다 packages.config 당신은 여전히에 대한 참조를 추가해야하기 때문에 어디에 단지에 항목을 추가하는 것만으로는 충분하지 않습니다 .dll .csproj 에도 .csproj 파일이 미래가 된다면 Core 팀이 끝까지 가서 project.json 또는 nuget.json을 삭제하거나 _완전히_ 호출되는 것을 보고 싶습니다. .csproj 형식에 대한 참조를 추가하는 보다 선언적인 방법입니다. JSON 파일 대신 XML 파일을 편집해야 잘 살 수 있지만(저는 확실히 JSON을 선호하지만) project.json 의 선언적 특성을 잃는 것은 정말 부끄러운

https://www.surveymonkey.com/r/H6Q88PP 에서 피드백을 주세요.

분명히 하기 위해 Standup 노트를 읽을 때 한 가지 옵션은 nuget install --save 일종의 옵션을 갖는 것입니다(https://blogs.msdn.microsoft.com/webdev/2016/05/11/ 참조). Notes-from-the-asp-net-community-standup-may-10-2016/). 나는 그것이 좋은 생각이라고 생각하지만 'intellisense로 .json 파일 편집'을 대체하는 것은 나쁜 생각이라고 생각합니다. 모든 작업을 셸로 전환하고 싶지 않은 우리 중 일부에게는 편집기에 머무르는 것이 좋습니다. 제 취향은 개인적으로 두 가지 경험을 모두 갖는 것입니다. 종속성을 추가하기 위한 명령줄 + UI로는 충분하지 않습니다.

저는 코더입니다. 에디터를 떠나고 싶지 않습니다.

나는 이것이 끔찍한 결정이라고 생각한다. 여러분은 .NET Core를 진정으로 단순하게 만들고 싶다고 말했지만 이 변경을 수행했습니다. 나는 당신이 MSBuild에 얼마나 많은 립스틱을 바르든 상관하지 않습니다. 그것은 여전히 ​​MSBuild가 될 것이고 외부인은 그것을 보고 즉시 꺼버릴 것입니다. 손으로 쉽게 편집할 수 있는 형식은 절대 아닙니다. 어려운 기술적인 문제가 있었을 수도 있겠지만, 프로젝트 시스템을 단순한 프로젝트 시스템 이상으로 만들려는 것과 관련이 있는 것 같습니다. 사람들이 빌드에서 더 복잡한 작업을 수행하려는 경우 스크립트를 작성하거나 msbuild를 사용하여 이를 수행할 수 있습니다. project.json은 매우 간단하며 지금은 정말 부끄럽습니다.

MSBUILD 파일에서 내가 가장 좋아하는 인용문은 무엇입니까?

나는 최근에 csproj 파일로 많은 시간을 보내야 했습니다. 그들은 Ant/Maven과 상당히 비슷하게 보이고 행동합니다. 이것은 그들에게 유리한 점이 아닙니다.
Ant/Maven은 많은 사랑을 받았고 이후 많은 Java 개발자들에게 미움을 받았습니다. XML은 처리해야 할 매우 장황한 구문입니다.
하지만 진짜 살인자는 락인(lockin)이다. 예, msbuild를 사용하여 작업을 수행할 수 있지만 구문은 실제로 개발자가 읽기/편집하는 것이 아니라 IDE에서 상태를 직렬화하도록 설계되었습니다. 명령줄 실행기가 있다고 해서 형식이 개발자에게 친숙하다는 의미는 아닙니다. VS에 머무르는 한 실제로 눈치 채지 못할 것입니다. 떠나 자마자 더 이상 편안하지 않습니다. csproj 파일은 .Net이 Java에서 다른 경로를 사용했으면 하는 한 가지입니다.

원천

MSBuild와 Visual Studio가 현재 MSBuild를 사용하는 방식을 구분하는 것이 중요하다고 생각합니다. 저는 수년간 MSBuild 파일을 직접 편집해 왔으며 모든 프로젝트에 사용하고 있습니다. 예: https://github.com/tavis-software/Tavis.home/blob/master/build/Build.proj

Visual Studio가 생성하는 csproj 파일은 꽤 불쾌하지만 MSBuild에서 이를 비난하는 것은 코드 생성기가 그것으로 못생긴 코드를 한 번 생성하는 것을 보았기 때문에 C#이 쓰레기라고 말하는 것과 같습니다.

@darrelmiller 동의합니다.

시간을 6개월 앞으로 이동하여 "그렇게 말한" 순간인지 또는 "총알을 피한" 순간인지 봅시다.

그의 블로그에서 @shawnwildermuth 호출에 따라 나는 내 자신의 2센트를 던질 것입니다:

이게 왜 그렇게 큰일인지 모르겠네요. 다음과 같은 이유로 XML 기반 csproj로 다시 이동하게 되어 기쁩니다.

• JSON을 수동으로 편집하는 것은 XML보다 더 자연스럽거나 쉽지 않습니다. 실제로는 반대 IMHO입니다. 모든 어리석은 편집기는 XML 태그 완성 기능을 제공하므로 수동으로 형식 오류를 찾아내는 것이 더 쉽습니다. JSON은 수동으로 작성해야 하는 경우 쉽지 않습니다. 그렇게 말하면 2번 항목으로 갑니다...
• 처음부터 편집기로 프로젝트 파일을 편집하는 것이 왜 그렇게 소란스럽습니까? 프로젝트 파일 편집은 개발자로서 시간을 보내고 싶은 곳이 아닙니다. 이것은 새 프로젝트를 시작할 때 일회성이어야 하지만 그 이후에는 IMHO에서 자주 발생해서는 안 됩니다. JSON, XML, YAML, TOML 또는 그 당시 누군가가 상상하는 모든 것으로 편집해야 하는 경우 나와는 전혀 관련이 없습니다.
• 내가 피하고 싶은 한 가지는 NuGet을 ASP.NET과 긴밀하게 연결하는 것 입니다. NuGet은 훌륭하고 마음에 들고 내 ASP.NET이 잘 작동하기를 원하지만 ASP.NET을 실행하는 데 필수는 아닙니다. 예, MVC 등의 기능을 얻으려면 NuGet 피드에서 바이너리를 가져와야 할 수도 있지만 공식 NuGet 피드를 통해 이 작업을 수행하든 소스를 가져오는 경우 로컬로 컴파일하고 복사하여 폴더는 계속 사용할 수 있는 유연성이 있어야 합니다. 나는 ASP.NET, csproj 또는 기타 "지원" 타사 시스템에 밀접하게 결합되는 것을 원하지 않습니다. 나는 그들이 훌륭한 통합을 허용하기를 원하지만 사용자 정의를 위해 문을 열어 두십시오 ! 따라서 NuGet 패키지가 .csproj 파일에서 선언되지 않고 nuget.json이 MSBuild에 긴밀하게 통합되지 않기를 바랍니다.
  잘 정의된 인터페이스 뒤에 긴밀한 통합 == GREAT.
  이것이 모든 사람의 표준이라고 가정하는 긴밀한 결합 == BAD.
• 마지막으로 project.json은 .NET Core 및 ASP.NET Core와 거의 관련이 없다고 말하고 싶습니다. Core는 project.json 파일보다 훨씬 더 많은 것을 제공합니다. Project.json은 새로운 기능이 아니라 이미 다른 형식으로 존재하던 것을 다시 디자인하려는 시도였습니다. 저는 개발자로서 클라우드에서 훌륭한 애플리케이션을 개발하기 위해 가끔 수행해야 하는 지루한 구성 대신 .NET Core가 제공하는 새로운 기능과 가능성에 집중하기 때문에 그다지 신경 쓰지 않습니다.

저는 개발자로서 호환성에 더 관심이 있고 이것이 핵심이라고 생각하기 때문에 MSBuild로 돌아가는 것은 훌륭한 조치라고 생각합니다. MSBuild는 작동하며 대부분의 경우 매우 잘 작동하며 새로운 문제를 가져오고 호환성 문제를 일으키는 새로운 것으로 교체하는 대신 누군가가 이미 작동하는 것을 개선하고 시간이 지남에 따라 개선하도록 합니다. 모든 사람들은 자신이 무언가를 다시 작성하고 더 좋게 만들 수 있다고 생각하지만, 그 당시에 중요했던 작은 문제 공간만 해결했다는 것을 깨닫고 나중에 확장하고 싶을 때 똑같은 오래된 것을 다시 짓고 있는 자신을 발견하게 됩니다. 당신은 처음에 교체를 시도했습니다. 이미 작동하는 것을 개선하는 것이 좋습니다.

이것이 내가 새로운 크로스 플랫폼 런타임을 구현하는 대신 Mono를 더 좋게 만들고 격차를 줄이는 것을 선호하는 이유이기도 하지만 그건 다른 논의입니다.

최종 설문 조사 결과: 95% 신뢰도에서 ±10%인 9백만 .NET 개발자 인구에 대해 100개의 응답.

project.json으로의 이동이 마음에 드셨나요?
네, 가장 기대했던 기능 중 하나였습니다. 19.19%
예 39.39%
아니오 13.13%
아니, 16.16%를 가져가는 것은 끔찍한 방향이었다.

MSBuild로 다시 이동하는 것에 대해 만족하십니까?
예, 이제 채택에 대해 생각할 수 있습니다. 9.09%
예 16.16%
아니오 30.30%
아니요, 이것은 .NET Core가 29.29%를 차지하는 방향에 대해 의문을 갖게 합니다.
상관없어 15.15%

MSBuild가 개선될 것이라고 믿습니까?
향상? 이미 완벽합니다. 1.01%
예 63.64%
아니오 12.12%
근본적으로 망가졌는데 어떻게 개선할 수 있습니까? 20.20%
상관없어 3.03%

이번 결정이 옳았다고 생각하십니까?
예, 팀에서 피드백을 받아 20.41%로 해야 할 때 방향을 변경했습니다.
예 6.12%
아니오 24.49%
아니요, 팀은 커뮤니티에 참여하지 않고 책임감 없는 비공개 결정을 내렸습니다. 39.80%
상관없어 9.18%

이 결정은 .NET Core에 대한 인식에 어떤 영향을 줍니까?
개선, 마침내 정신력 13.00%에 가까워지고 있습니다.
11.00% 향상
42.00% 악화
그것을 악화시키고, 모든 것을 의심하게 만듭니다. 18.00%
신경쓰지마 16%

100명이 설문조사를 했습니다. 나는 지금까지 그것에 대해 알지 못했습니다. 대표번호가 있을 때 다시 한 번 봅시다. 기껏해야 100명이라는 말이 우스꽝스럽기 때문입니다.

실제로 표시된 대로 100명이 95% 신뢰로 ±10%의 오차 범위를 제공합니다. 진정한 반영을 보려면 어느 정도의 자신감이 필요합니까? 900만 개발자 모두를 조사해야 하나요?

Project.json을 VS의 나머지 부분으로 확장하기 위해 UserVoice에 대한 800표도 추세를 보여주지 않습니까?

그리고 우리가 진정으로 대표적인 샘플을 만들려면 Microsoft가 해야 할 것입니다. 그들은 이 결정에 대해 한 번도 의견을 구하지 한 후에도 마찬가지입니다.

그들은 개인 설문 조사를 하는 나보다 훨씬 더 나은 도달 범위를 가질 것입니다. 100개 이상의 결과에 액세스하려면 내 SurveyMonkey 계획을 업그레이드해야 합니다. 그러면 Microsoft 가 자체적으로 수행

의미 있는 숫자를 원한다면 900만 개발자를 공정하게 대표하는 것을 목표로 삼고 싶을 것입니다. 같은 관심사를 공유하고 모든 사람에게 설문조사에 참여하도록 요청하기 때문에 나를 팔로우하는 100명의 Twitter 팔로어가 있는 경우 특정 개발자 그룹을 대표하는 매우 일방적인 관점을 가진 100명의 사람들이 있습니다.

MSBUILD 부활에 대한 입장에서 제시한 정당성은 기존 도구 간의 통합을 가능하게 하고 기존 프로젝트에서 .NET Core를 보다 쉽게 ​​사용할 수 있도록 하는 것이었습니다. 그러나 다소 큰 프로젝트를 .NET Core로 마이그레이션한 후 솔직히 말해서 프로젝트 시스템이 가장 어려웠습니다. 그래서 그것을 유일한 정당화로 사용하는 것은 나에게 큰 이유처럼 보이지 않습니다. 나는 또한 수동으로 파일 편집을 포함하여 csproj 시스템으로 수년 동안 일했습니다. 그것은 항상 고통스러웠습니다. project.json 기반 시스템은 훨씬 더 간단하고 모든 사람(초보자 포함)이 훨씬 더 쉽게 접근할 수 있습니다. 이것이 목표라고 생각합니다. 그러나 지금 우리는 MSBUILD를 부활시켜 한 발짝 뒤로 물러서고 있습니다. 내 개인적인 생각은 이것이 큰 실수라는 것입니다. project.json을 유지하기 위해 투표했습니다.

사실 저는 Twitter 팔로어가 거의 없습니다. 이들은 대부분 제가 Twitter 스트림을 게시한 .NET Core 개발자의 팔로어입니다.

그리고 다시 말하지만, 그러한 설문 조사를 수행하는 올바른 사람은 확실히 Microsoft입니까? 사람들에게 실제로 원하는 것이 무엇인지 묻는 일이 왜 나에게만 남아 있습니까?

왜 MS는 사람들의 생각을 무시하지 않습니까?

TBH 30분 전까지 설문조사가 있는 줄도 모르고 설문조사를 비공개로 하고 계신 줄도 몰랐습니다. 동의합니다... Microsoft가 이 변경 사항에 대한 개발자 반응에 관심이 있다면 그러한 설문 조사를 실행해야 합니다. 그러나 아마도 그들은 이미 숙제를 했고 이것이 그들이 이 변경을 하는 이유입니다. 잘 모르겠지만 항상 그렇게 부정적으로 보지는 않을 것입니다. 왜냐하면 이 모든 사람들이 우리를 위해 이 물건을 만들고 있기 때문입니다. 그래서 그들이 우리에게 가장 큰 관심을 갖고 있다고 확신합니다.

그들이 숙제를 했다면 개발자의 60%가 이 움직임에 반대한다는 것을 알았을 것이고 그에 따라 의사 소통하고 참여했을 것입니다. 그들은 반응에 대해 전혀 알지 못했다는 것을 의미합니다. 즉, 참여하지 않았음을 의미합니다.

저는 VS용 엔터프라이즈 라이선스에 대한 유료 고객입니다. 나는 아무것도 보지 못했다. 저는 4개의 우량 핀 서비스 회사에서 일하며 기업 고객에게도 비용을 지불합니다. 그들은 아무것도 보지 못했습니다. 그렇다면 그들은 정확히 누구와 교제 했 습니까? 어젯밤부터 그 질문을 하고 있는데 답변을 받지 못했습니다.

이것은 .NET Core 이야기의 근본적인 부분에 대한 대규모의 늦은 주요 변경이기 때문에 부정적인 것으로 보고 있습니다. 이 부분은 미래의 핵심으로 우리에게 전달되었으며 우리는 (아마도 어리석게도) 이를 이 기술을 기반으로 CD/CI 파이프라인을 구축했으며 이제는 완전히 가치가 없습니다. 나는 또한 그것을 부정적으로 보고 있습니다. 하루 종일 의사 결정에 대한 세부 사항을 요구하는 동안 완전한 라디오 침묵이 있었기 때문입니다.

내가 들은 바에 따르면 도구 제작자를 돕기 위해 사용자를 버스 아래로 몰아넣었다고 합니다. 그렇다면 그들이 내가 아닌 도구 제조업체로부터 VS 라이센스 비용을 징수할 수 있습니까?

@shederman 귀하의 설문 조사 결과에 동의하지만, 질문은 분명히 w/ json 형식을 유지하는 선호하는 방향으로 기울어져 있으며 실제로 좋은 설문조사가 되지는 않습니다. 나는 그것을 재미로 받아들였으며 그 결과를 심각하게 받아들이지 않을 것입니다(죄송합니다). 나는 왜 우리가 둘 다 가질 수 없는지 궁금합니다. 저는 msbuild나 그 밖의 것들을 좋아하지 않기 때문에 선택 사항으로 만드십시오. 저는 json을 사랑합니다. 제 친구입니다.

이상적인 설문조사가 아니라는 데 동의합니다. 5분 만에 만들었습니다. 요점 은: 내가 왜 그것을 만드는가?

Microsoft가 사람들의 생각을 알아내는 데 관심이 없는 이유는 무엇입니까?

나는 30개 정도의 응답만을 예상했는데, 그들이 의견을 억지 부리기보다 토론을 재개하고, 그들의 생각을 공개적으로 공유하고, 우리와 적절하게 참여하도록 설득하기에 충분하기를 바랐습니다.

현재 138개의 응답이 있지만 Microsoft의 결정이 잘못된 결정이었을 수도 있음을 고려하더라도 여전히 Microsoft의 징후는 없습니다. 사실에 근거하지 않은 설명을 흔드는 아주 모호한 손.

내가 원하는 것은 이 결정에 대한 적절한 참여입니다. 비밀 정보와 피드백을 바탕으로 비공개로 결정된 주요 결정이 아닙니다. 이 과정에서 유일하게 누락된 단어인 투명하고 공개적으로 이루어져야 합니다.

오, 얘들아. Microsoft는 프레임워크를 소유하고 그가 원하는 것을 하도록 허용합니다. 그러나 잠시 생각해보세요. 사람들은 2014년 3월-4월부터 이 작업을 하고 있으며 출시 1개월 전에 이러한 유형의 극적인 변화를 만드는 것은 우스꽝스러운 일입니다. 개발자의 신뢰를 무너뜨립니다. 그것은 사람들의 시간을 낭비합니다. 커뮤니티를 신뢰할 수 없다면 오픈 소스 프레임워크를 만들 필요가 없습니다. 어두운 방에서 이러한 유형의 변경을 수행할 때 아무도 방해하지 않도록 즉시 소스를 닫으십시오.

이 시간에 Microsoft의 변명을 요청하고 공감하는(MVP 또는 커뮤니티 회원) 현실적입니다.

@shederman

그들이 숙제를 했다면 개발자의 60%가 이 움직임에 반대한다는 것을 알았을 것입니다.

.net 생태계의 개발자 중 20% 이상이 project.json의 존재를 알고 있다는 사실이 저를 놀라게 할 것입니다. 우리는 때때로 우리가 새로운 기술 개발의 최전선에 서서 약간의 개발자 거품 속에 살고 있다는 사실을 잊습니다.

저는 project.json의 매력 중 많은 부분이 단순성이라고 생각합니다. 그러나 3년 전 ASP Net Insiders의 날에 처음 소개된 이후로 개발을 따라왔다면 더 많은 사용 사례를 지원하려고 할수록 더 복잡해지기 시작했습니다. 전체 .net 생태계를 지원하기 위해 사랑받는 단순함의 많은 부분이 손실될까 두렵습니다.

이것은 project.json이 몇 가지 멋진 새 기능을 가져오지 않는다는 것을 말하는 것이 아니며, 프로젝트 형식을 사람이 더 쉽게 접근할 수 있도록 하는 것이 좋은 것이라고 생각합니다. 그러나 그 장점을 MSBuild에 가져오는 것이 더 달성 가능하고 project.json을 모든 곳에서 가져오려고 하는 것보다 훨씬 더 빨리 더 많은 사람들에게 혜택을 줄 것이라고 생각합니다.

.net 생태계의 개발자 중 20% 이상이 project.json의 존재를 알고 있다는 사실이 저를 놀라게 할 것입니다.

.net eco의 20% 미만 개발자가 MVC 및 Web Api에 대해 알고 있습니다. 70명 이상의 사람들이 WebForms, WCF, WebService를 사용하고 있습니다. 다시 한 번 Microsoft의 변명을 요청합니다. 현실적일 수 있도록 동정해 주십시오.

@shederman 설문 조사 결과에 대한 귀하의 보고서는 .NET 개발자 집단에 대해 정확하지 않을 수 있으며 ... "그들은 .NET Core 개발자의 대부분을 추종하는 좋은 대표 샘플이 아닐 수도 있습니다. 내가 올린 트위터 스트림." 표본은 모집단 전체에 대해 암시하는 것과 같은 신뢰 구간을 명시하는 데 절대적으로 필요한 무작위 표본이

전체 인구에 대한 설문 조사를 기반으로 유용한 통계적 결론을 도출할 수 없습니다. 그래도 설문조사를 해주셔서 기쁩니다. 당신은 많은 우수한 포인트를 제시합니다. 결과는 많은 사람들이 변화에 대해 화를 내거나 우려하고 있음을 나타냅니다. 그러나 잘못된 통계적 결론을 게시하지 마십시오. 사실상 무의미한 수치를 퍼뜨리고 "개발자의 60%가 이 움직임에 반대한다는 것을 알았을 것입니다."와 같은 터무니없는 발언을 합니다.

그렇다면 시장 기반의 70% 이상을 귀찮게 하려면 무엇이든 변경해야 하는 요점이 무엇입니까? 우리가 있는 곳에 그대로 머물면서 점진적인 진화를 계속합시다. 고장나지 않았다면 고치지 마세요, 그렇죠?

나는 project.json이 복잡성을 축적했다는 것을 알고 있습니다. 나는 그 점에 100% 동의합니다. csproj에 다시 병합하는 솔루션이었나? 나는 사람들에게 서두르지 않고 일을 바로잡는 데 대해 완전히 Microsoft 뒤에 있다고 말했습니다. csproj로의 이동이 급해 보입니다.

RC2 이후에 이것을 하는 이유는 무엇입니까? 이것은 어디에서 왔습니까? Xamarin 인수가 이와 관련이 있습니까? dotnet-cli 통합이었나? 빅 클라이언트였나? 누가 알아...

나는 대중에게 RC1 -> RC2가 최선이라고 설명할 수 있었다. dotnet cli와 통합되었습니다. 하지만 project.json 변경? 나는 그것을 설명하기 위해 할 말이 없다. 다만 내가 모른다. 사람들은 혼란스러워하고 나는 그들에 대한 설득력 있는 논거가 없습니다.

RC2 이후에 이것을 하는 이유는 무엇입니까? 이것은 어디에서 왔습니까? Xamarin 인수가 이와 관련이 있습니까? dotnet-cli 통합이었나? 빅 클라이언트였나? 누가 알아...

이것이 포인트 생각입니다. 우리는 csproj로의 이전에 대한 전체 이야기를 모릅니다. 이제 뒤로 기대고 휴식을 취하고 왜 이런 일이 일어나는지 지켜보고 이해하는 대신 모두가 Microsoft를 저주하고 최악의 상황을 가정하고 있습니다. 이것은 의미가 없습니다. 이 사람들은 우리와 우리만을 위해 이 물건을 만들고 있습니다. 그들은 한 명의 큰 고객 때문에 그런 변경을 하지 않습니다. 왜냐하면 한 명의 큰 고객은 전체 커뮤니티를 잃을 위험이 있는 경우 가치가 없기 때문입니다. Microsoft .NET 에코 시스템은 HUUUUUUGE이며 .NET Core를 이 시스템에 잘 맞추는 것은 분명히 복잡한 작업이므로 모두가 조금 진정하고 이 사람들 뒤에 현명한 사람들이 있다고 가정하고 올바른 결정을 내리도록 제안합니다. 장기적으로 가장 큰 이점을 얻을 수 있습니다. 이 모든 부정적인 성급한 추측이 나를 지루

@darrelmiller 죄송합니다. 60%라고 하면 설문조사에 응답한 사람들의 60%를 의미합니다.

@GuardRex 당신이 절대적으로 옳습니다. 우리에게 적절한 결과를 줄 수 있는 유일한 조직은 MS이고 그들은 신경 쓰지 않는 것 같습니다.

내 설문조사는 단순히 통계적으로 유의미한 샘플을 제공하기 위한 것이 아니라 막연한 지원 수준을 측정하기 위한 것이었습니다. 나는 이 결정을 공개하기에 충분한 불행이 있음을 보여주었다고 생각하지만, 마이크로소프트는 그들의 무선 침묵이 어떤 징후라도 잘 동의하지 않는 것으로 보입니다.

여기 질문이 있습니다. MS가 실수를 저질렀다는 것을 인정하려면 정확히 무엇이 필요할까요? 그들이 토론을 재개하려면 무엇이 필요할까요? 현 시점에서 답은 "우리는 당신의 관점에 신경 쓰지 않고, 우리의 결정이 유효하며, 그 이유를 공유하지 않을 것입니다"인 것 같기 때문입니다.

나는 모두가 조금 진정하고 이 사람들 뒤에 현명한 사람들이 있다고 가정하고 올바른 결정을 내려 장기적으로 최대의 이익을 얻을 수 있다고 가정할 것을 제안합니다.

내가 말한 것은 그 뒤에 있는 영리한 사람들과 그들이 항상 옳고 오픈 소스 커뮤니티가 바보이기 때문에 그것을 클로즈 소스로 만드는 것입니다.

@shederman "통계적으로 유의미한 샘플을 제공하지 않는 것" ... 괜찮습니다. 하지만 설문조사가 그 자체로 장점이 되도록 하고 이 줄을 제거해 주셨으면 합니다...

최종 설문 조사 결과: 95% 신뢰도에서 ±10%인 9백만 .NET 개발자 인구에 대해 100개의 응답.

정말 골치아픈 부분입니다. .NET 개발자의 60%가 이 변경 사항을 싫어하거나 싫어한다는 것이 정확할 수 있습니다. 그러나 해당 샘플에서는 표시할 수 없습니다. 예, 많은 개발자가 변경 사항과 처리 방식에 대해 크게 우려하고 있다고 가정해 보겠습니다

@abcplex : 오픈소스라고 해서 16명이 GitHub에서 이슈를 열고 스크림 점프할 때마다 점프해야 하는 것은 아닙니다.

@MaximRuiller Standup Notes 는 변경 동기를 잘 설명하고 있습니다. 그리고 내가 읽었을 때 현실은 xproj가 csproj로 대체되고 있고 project.json이 nuget.json으로 이름이 바뀌고 _some_ 항목이 project.json에서 옮겨질 것이라는 것입니다.

그리고 스탠드업에서 나온 코멘트에서 이것은 꽤 최근의 결정이었습니다. 커뮤니티는 거의 즉시 RTM 이후까지 project.json이 아무 데도 가지 않을 것이므로 변경이 다시 발생할 수 있다고 들었습니다.

나에게 이것은 일어날 수 있는 가장 포괄적이고 투명한 과정처럼 보인다.

@darrelmiller 그건, 당신에게 동의해야 할 것입니다. 꽤 투명합니다.

그들이 피드백을 원했다면, 나는 그들이 그것을 얻었다고 생각합니다. 어쨌든 싸울 일은 없습니다. 사람들이 말했습니다. 마이크로소프트는 귀를 기울였다. 그들이 할 수 있는 일인지, 아니면 손이 묶여 있는지 봅시다.

이제 시간만이 우리에게 말해줄 것입니다.

투명성에 문제가 있다고 생각하지 않습니다. 그들은 투명한 일을 훌륭하게 해냈습니다. 문제는 커뮤니티가 이에 대해 어떻게 생각하는지 모른 채 중대한 결정을 내리고 있다는 것입니다. 위원회에서 디자인하는 것이 불가능하다는 것을 알고 있지만, 아마도 그들이 검토한 장단점 목록을 문서화하고 이 변경과 같은 근본적인 것에 대해 커뮤니티에 제출했어야 했을 것입니다. 바라건대 그들은 그러한 유형의 정보를 곧 게시할 것이지만, 그럼에도 불구하고 이미 결정이 내려진 것처럼 들립니다.

이것은 다른 누구보다 얼리 어답터에게 더 큰 영향을 미칩니다.

JSON은 읽기가 좋지만 단순할 때만 가능합니다. </system> 가 ]} 보다 이해하기 쉽습니다.

여기에서 가장 합리적인 의견은 XML 고유의 장황함을 필요로 하지 않는 프로젝트 및 종속성 관리의 언로드/로드에 대한 제 생각을 반영합니다.

JSON 대 XML에 대한 논의가 정말 있어야 합니까? IMHO는 정말 중요하지 않습니다.
(물론, 저는 개인적으로 XML보다 JSON을 더 좋아하지만 이것은 중요하지 않습니다)

내가 ASP.NET Core에 대해 정말 좋아하는 것은 Visual Studio 및 기타 IDE에서 매우 개방적이고 독립적이라는 것입니다. 이것이 여전히 주어진다면 나는 이 결정에 문제가 없습니다.

이 문제에 대해 상당히 많은 유독한 토론이 진행되고 있으며, 이로 인해 많은 사람들이 시력을 잃는다고 생각합니다. 일반적인 주장은 "MSBuild가 잘못되었습니다!"인 것 같습니다. 그러나 두 접근 방식 모두에 대해 무엇이 좋고 나쁨에 대한 충분한 이해가 이루어지지 않고 있습니다.

이것이 "뒤로가는 단계"라고 말하는 모든 사람은 "csproj"로 돌아가지만 몇 년 동안 사용했던 csproj 파일과 _동일하지_ 않을 것임을 유의하십시오. 하나는 "새" csproj 형식 의 파일 목록이 표시되지 않을 것이라고 분명히 밝혔습니다. 대부분의 사람들이 project.json 형식을 좋아하는 주된 이점이자 주된 이유는 이 파일 목록이 없기 때문입니다.

바로 즉각적인 차이입니다. 오늘 xproj를 살펴보면 "새로운" csproj에서 무엇을 기대할 수 있는지 대략 알 수 있을 것입니다. 조금 더 커질 수 있지만 project.json에서 가져온 몇 가지 추가 속성이 있기 때문입니다. 실제 토론은 "MSBuild가 얼마나 나쁜지"가 아니라 새 csproj에서 보고 싶은 것과 .json 파일에 남기고 싶은 것이 아닙니다.

@dustinmoris 당신은 불공평합니다. 커뮤니티는 대부분의 변화를 환영했지만 이번만은 환영한다고 생각합니다. 이것은 우리를 과거로 데려가고 있으며, 그들은 이미 이유에 대한 통찰력 없이 어떻게 할 것인지에 대해 이야기하고 있습니다. 그들은 결정이 최종적인 것처럼 들리므로 커뮤니티가 더 나은 제안을 할 수 있는 곳이 없습니다.

그리고 예, 우리는 프로젝트 파일을 직접 편집하고 project.json 전에 고통스럽게 작업했습니다. Msbuild는 부족 지식에 관한 것이며 그것을 마스터하기가 조금 어렵습니다.

그리고 ".net 4.5에서 .net 코어로의 마이그레이션을 용이하게 할 것"이라는 말은 다소 정직하지 못한 것 같습니다. 이것은 확실히 골칫거리가 아닙니다...

그것은 우리가 수년간 가지고 있던 csproj 파일과 같지 않을 것입니다.

XML이 될까요? 네, 그렇게 생각했습니다.

대부분의 사람들이 project.json 형식을 좋아하는 주된 이점이자 주된 이유는 이 파일 목록이 없기 때문입니다.

어떤 정보에 근거하여 이것을 말하는가? 내 말은, 파일 목록이 없다는 것이 큰 장점이지만 결코 저에게만 유일한 것은 아닙니다.

오늘 xproj를 살펴보면 "새로운" csproj에서 무엇을 기대할 수 있는지 대략 알 수 있을 것입니다.

오늘은 xproj가 없습니다. 왜 그런 것이 필요할까요?

실제 토론은 "MSBuild가 얼마나 나쁜지"에 관한 것이 아니며 해서는 안 됩니다.

토론이 _해서는 안 되는_ 이유는 무엇입니까? 터핑 MSBuild는 .NET Core 채택의 주요 장점이었습니다. 내 (분명히) 비과학적, 반향실, 편향된 설문조사에 대한 응답자의 20%는 이것이 근본적으로 잘못되었다는 데 동의합니다.

@shederman 귀하의 응답은 제가 언급하는 것과 정확히 같은 종류의 유독한 토론입니다. "MSBuild가 나쁘다!"와 같은 일반적인 주장을 하고 있지만 건설적인 토론을 통해 이를 뒷받침하고 있지는 않습니다.

XML이 될까요? 네, 그렇게 생각했습니다.

예. 그리고? 문제가 _XML_이 마음에 들지 않는다는 것이라면 충분합니다. JSON이 XML보다 우수하다고 생각한다면 그 이유를 설명하고 _project 구조_와 구문과 관련된 모든 것과 관련이 없습니다. 불행히도 XML과 JSON은 모두 세계에서 각자의 위치를 ​​차지하고 있으며 둘 다에 뚜렷한 장단점이 있으며 어느 것이 더 나은지에 대한 결정적인 "정답"은 없을 것입니다. 다시 말하지만, 내가 당신이라면 _프로젝트 구조_의 차이점이 이동에 따라 어떻게 달라지는지에 집중할 것입니다.

어떤 정보에 근거하여 이것을 말하는가? 내 말은, 파일 목록이 없다는 것이 큰 장점이지만 결코 저에게만 유일한 것은 아닙니다.

나는 그것이 유일한 이점이라고 주장한 적이 없으며 단순히 그것이 _main_ 이점이라고 말했습니다. 몇 개월 전 project.json 형식에 대한 토론을 살펴보고 사람들이 가장 먼저 이야기하는 것은 그것이 얼마나 작고 간단하다는 것입니다. JSON이 구문적으로 더 깔끔해서가 아니라 프로젝트 파일 목록을 제거하는 것입니다. 사람들이 언급하는 가장 큰 장점은 병합이 잘되고 파일 참조가 많이 나열되지 않기 때문에 잘 병합된다는 것입니다.

오늘은 xproj가 없습니다. 왜 그런 것이 필요할까요?

이 전체 토론은 최신 프로젝트 파일 형식에 관한 것입니다. 현재 환경을 비교하지 않으려는 경우 정보가 없는 의견이 될 것입니다.

왜 그것이 토론이 되어서는 안 되는가? 터핑 MSBuild는 .NET Core 채택의 주요 장점이었습니다. 내 (분명히) 비과학적, 반향실, 편향된 설문조사에 대한 응답자의 20%는 이것이 근본적으로 잘못되었다는 데 동의합니다.

실제로 _MSBuild_에 대해 논의하는 것이 아니기 때문에 Visual Studio가 역사적으로 MSBuild 프로젝트를 처리한 방식에 대해 논의하고 있는 것입니다. MSBuild는 실제로 프로젝트의 모든 단일 파일을 나열할 필요가 없는 것을 포함하여 이미 필요한 거의 모든 것을 지원합니다.

더 중요한 것은, 지금까지 이 토론에서 당신이 한 일은 XML이 마음에 들지 않는다고 소리치고 외치는 것뿐입니다. 글쎄", 지금은 여러 번 언급했듯이 일반적으로 "이전" csproj에 나열된 파일 수로 줄어듭니다. xproj 형식을 살펴보는 것이 귀찮다면 매우 작은 것을 알 수 있을 것이며 Daniel은 스탠드업 동안 "새로운" csproj 형식이 현재 project.json 파일과 크기가 거의 같을 것이라고 말했습니다. 문제? 당신은 대담한 주장을 펼치지만 전혀 뒷받침하지 않습니다.

@neoKushan 정당한 이유 없이 Microsoft를 방어함으로써 곧 Microsoft로부터 일종의 상을 받게 될 것입니다. 이것이 백도어에서 내리는 최악의 결정이라는 사실을 깨닫습니다. asp net을 다시 소스를 닫고 Microsoft와 같은 지지자가 오픈 소스 커뮤니티 구성원에게 묻지 않고 원하는 것을 결정할 수 있도록 하는 것이 좋습니다.

@abcplex 욕하고 손가락질 하는 것 외에는 대화에 기여할

지금까지 당신은 당신의 실제 문제가 무엇인지 단 한 가지 이유도 나열하지 않고 변경 사항에 대해 불평만 하고 있습니다.

@neoKushan 가장 큰 포인트는 RTM으로 한 달 전에 이러한 유형의 변화를 위한 시기가 아니라는 것입니다. 이 시간에 변경하는 것은 의미가 없습니다.

@abcplex RTM에서는 변경 사항이 발생하지 않습니다. RTM 이후에 점진적으로

JSON 대 XML(Standup Blog Post에서 일부 사람들이 요청하는 것처럼 XAML과 비교)은 이전 도구와 모든 종류의 하위 호환성을 갖는 장점에서 주의를 산만하게 한다는 데 동의합니다.

그리고 나는 이것이 매우 잘못된 사고방식이라고 주장하고 싶습니다. 좋든 싫든 csproj와 MSBuild는 도구 체인에 프로젝트를 정의하는 대신 프로젝트를 빌드하는 방법을 지시하는 ant의 전통을 따릅니다. 이것들은 매우 다르지만 이 유산은 프로젝트에 "정의" 권한을 부여하는 것 같습니다. 이제 우리는 여기에 논리를 적용할 수 있기 때문입니다. 그것이 하는 일은 일을 엄청나게 복잡하게 만드는 것입니다.

예전 세계에서는 "맨 아래에 있어야 함"이 위로 이동했거나 누군가 환경 변수를 엉망으로 만들어 갑자기 잘못된 .targets 파일을 가져왔기 때문에 프로젝트 파일이 깨진 것을 여러 번 보았습니다. 선언적 구문에서 First-Level 요소(root-of-root)가 순서 종속적이라는 바로 그 개념은 완전히 깨졌습니다. 그것이 MSBuild와 csproj의 땅입니다. 이것이 우리가 여기에서 다시 가져오는 유산입니다. 이제 csproj를 이해하려면 "실행"하고 MSBuild와 똑같이 실행해야 합니다. 예, MSBuild는 오픈 소스이지만 실제로는 아무 것도 수정하지 않습니다. 여전히 단일 강제 종속성을 도입합니다. 여전히 어딘가에 있는 매직 타겟 파일에 의존합니다.

프로젝트 파일에는 특정 상점에서 사용하기로 결정한 도구 체인의 모양에 영향을 받지 않는 몇 가지 특성이 있어야 합니다.

• 사람이 편집/읽을 수 있어야 합니다.
• 댓글을 허용해야 합니다.
• 선언적이어야 한다
• 자급자족해야 한다
• 병합 충돌을 줄이고 가능하면 병합을 단순화하도록 설계해야 합니다.
• 완전히 문서화할 수 있어야 합니다(문서에 자체 포함 원칙이 적용됨).
• 도구에 독립적이어야 합니다.

그리고 ".net 4.5에서 .net 코어로의 마이그레이션을 용이하게 할 것"이라는 말은 다소 정직하지 못한 것 같습니다. 이것은 확실히 골칫거리가 아닙니다...

100% 동의합니다. 우리가 당면한 과제가 무엇인지 분명히 말씀드리겠습니다. 지금까지 코드베이스를 마이그레이션하는 데 있어 유일한 어려움은 특정 .NET 클래스 라이브러리의 손실(System.Drawing 참조), .NET 코어 지원에 대한 Microsoft 팀의 과묵함이었습니다. (DocumentDB를 보고 있음) 및 주요 버전 간에 예상할 수 있는 표준 주요 변경 사항.

어느 시점에서도 project.json 문제가 없었습니다. 사실 그게 장점이었다. Ctrl+Shift+B를 할 때 마술처럼 발생하는 보이지 않는 세부 사항에 MSBuild를 덤프할 수 있는 것과 마찬가지입니다.

@neoKushan

1. 나는 XML을 좋아하지 않는다. 프로젝트 및 구성 파일에 대해 잘못된 형식입니다. "모든 것을 위한 XML" 단계에서 도입되었을 때 그것은 나쁜 생각이었고 지금은 나쁜 생각입니다.
2. JSON 파일이 XML 파일보다 훨씬 더 잘 병합된다는 것을 알았습니다. 제 의견임을 인정하지만 제 경험에 근거한 것입니다.
3. xproj 파일이 필요하지 않고 사용하지 않는 vscode를 사용하고 있습니다. _그_는 나의 현재 풍경이고 나에게 아무 의미가 없는 xproj 파일을 원하지 않거나 필요로 하지 않습니다.
4. 아니요, 저는 MSBuild에 대해 논의하고 있습니다. MSBuild 및 Team Build로 많은 작업을 수행했습니다. 그들은 결코 재미 없었고 결코 쉽지
5. MSBuild는 간단한 작업도 어렵게 만듭니다. 대안을 살펴보고 MSBuild에 의해 깜박이지 않는 것이 좋습니다. 특히 gulp와 sbt가 작동하는 방식을 보십시오.

@shederman

나는 XML을 좋아하지 않는다. 프로젝트 및 구성 파일에 대해 잘못된 형식입니다. "모든 것을 위한 XML" 단계에서 도입되었을 때 그것은 나쁜 생각이었고 지금은 나쁜 생각입니다.

이것 중 어느 것도 그것이 나쁜 생각인 _이유_를 설명하지 못합니다.

JSON 파일이 XML 파일보다 훨씬 더 잘 병합된다는 것을 알았습니다. 제 의견임을 인정하지만 제 경험에 근거한 것입니다.

나는 악몽 .json 병합과 악몽 .xml 병합을 겪었습니다. 병합에 관해서는 특별히 마음에 들지 않습니다. 내 경험에 따르면 형식에 관계없이 파일의 _size_에 문제가 있는 병합 가능성이 높아집니다.

xproj 파일이 필요하지 않고 사용하지 않는 vscode를 사용하고 있습니다. 그것이 나의 현재 풍경이고 나에게 아무 의미가 없는 xproj 파일을 원하지 않거나 필요로 하지 않습니다.

그렇다고해서 현재 xproj 파일 을보고 그것이 무엇인지 알 수 없다는 의미는 아닙니다. 그렇게 하지 않으면 손가락을 귀에 대고 눈을 감고 "라라라"라고 말하는 것과 같은 행위를 하는 것입니다.
다시 말해, 변화가 일어나고 있다는 사실에 화를 내고 그것에 대해 신음하며 아무 것도 성취하지 못하거나 실제 대화에 참여하여 이것의 결과를 지시하는 데 도움을 줄 수 있습니다.

예를 들어, 아직 결정되지 않은 한 가지는 nuget 종속성이 csproj의 일부가 될 것인지 또는 nuget.json이 될 것인지입니다. 바로 거기에 기본 설정이 있습니다. .json 파일에 종속성 목록이 있으면 csproj에 무엇이 남습니까? 얼마나 자주 변경됩니까? _그것은_ 병합하는 것이 얼마나 어려울까요?

나는 개인적으로 그것이 하나의 프로젝트 파일에 모두 포함되어 있기를 원하지만 프로젝트 자체에서 너겟을 분리하는 것의 매력과 이점을 볼 수 있습니다. 둘 다 장단점이 있으며 아마도 가장 좋은 솔루션은 둘 다 허용하고 종속성 목록이 있는 csproj를 사용하되 대신 종속성이 있는 .json 파일을 가리킬 수 있도록 하는 것입니다. MSbuild 자체에 약간의 복잡성이 추가되는 대신 두 세계와 모두의 최고가 승리합니다.

아니요, 저는 MSBuild에 대해 논의하고 있습니다. MSBuild 및 Team Build로 많은 작업을 수행했습니다. 그들은 결코 재미 없었고 결코 쉽지 않았으며 항상 진흙탕에서 돼지와 씨름을 했습니다. 저는 MSBuild를 싫어하며 혼자가 아닙니다.

TFS의 XAML 기반 빌드 정의를 처리해야 했기 때문에 적어도 이 항목(일부)에 대해서는 동의할 수 있습니다.

MSBuild는 간단한 작업도 어렵게 만듭니다. 대안을 살펴보고 MSBuild에 의해 깜박이지 않는 것이 좋습니다. 특히 gulp와 sbt가 작동하는 방식을 보십시오.

그런 다음 유모차에서 장난감을 던지지 말고 "새로운" 프로젝트 구조가 _실제로_ 어떤 모습이어야 하는지에 대한 토론에 적극적으로 참여하는 것이 좋습니다. XML 기반 프로젝트 파일을 처리해야 하는 미래를 상상해 보십시오. 그 프로젝트 파일이 실제로 어떻게 생겼으면 합니까?

XML 기반 프로젝트 파일을 처리해야 하는 미래를 상상해 보십시오.

음. 좋아, 그럼 내가 원하지 않는 미래를 상상하고 그것이 어떻게 작동하는지 설명해야 합니까? 음, 그렇게 생각하지 않습니다. 좀 더 현대적이고 혁신적인 빌드 시스템을 살펴보는 것은 어떻습니까? 아주 먼 과거에 XML을 남긴 것들입니다.

어때요:

var gulp = require('gulp')
, minifyCss = require("gulp-minify-css");

gulp.task('minify-css', function () {
    gulp.src('./Css/one.css') // path to your file
    .pipe(minifyCss())
    .pipe(gulp.dest('path/to/destination'));
});

아니면 어쩌면

organization := "com.devdaily"

name := "ScalatraTest1"

version := "0.1.0-SNAPSHOT"

scalaVersion := "2.9.1"

seq(webSettings :_*)

libraryDependencies ++= Seq(
  "org.scalatra" %% "scalatra" % "2.0.4",
  "org.scalatra" %% "scalatra-scalate" % "2.0.4",
  "org.scalatra" %% "scalatra-specs2" % "2.0.4" % "test",
  "ch.qos.logback" % "logback-classic" % "1.0.0" % "runtime",
  "org.eclipse.jetty" % "jetty-webapp" % "7.6.0.v20120127" % "container",
  "javax.servlet" % "servlet-api" % "2.5" % "provided",
  "com.mongodb.casbah" %% "casbah" % "2.1.5-1"
)

resolvers += "Sonatype OSS Snapshots" at "http://oss.sonatype.org/content/repositories/snapshots/"

오, 그래, 당신이에 연결하는 xproj 훨씬 더 그렇다. 멋지고 명확하고 간결합니다. 그리고 표현력, 표현력을 잊지 마세요. 그 ProjectGuid는 무엇을 위한 것입니까? 그리고 나는 도구 버전을 설정하는 90자를 좋아합니다. 그리고 DnxInvisibleContent? 내 빌드 시스템이 알면 유용한가요? 내가 실행하지 않는 IDE에 어떤 파일이 표시되지 않습니까?

유모차에서 장난감을 던지지 않는 것이 좋습니다.

원하지 않습니다 :-)

아니, 끝났어. Immo와 긴 대화를 나눴고 이 전투를 끝냈습니다. 모든 사람은 부분적인 견해를 가지고 있으며 자신의 방식이 모든 사람에게 완벽하지 않을 수 있다는 터무니없는 개념을 듣고 싶어하는 사람은 없습니다.

[욕설을 제거하도록 수정됨]

@shederman : 여기에 빌드 정의 파일이 표시됩니다. 프로젝트 정의로 빌드 정의에서 벗어나고 싶습니다. 생성 방법에 대한 지침과 별도로 생성할 프로젝트/아티팩트에 대한 정적 세부 정보를 정의할 공간이 있습니다. 이 둘을 병합한다는 것은 MSBuild 파일을 프로젝트 파일로 사용할 때의 주요 문제 중 하나입니다.

생성할 아티팩트, 사용할 종속성 및 도구 체인, 디스크에서 프로젝트를 구성하는 다양한 요소의 레이아웃을 설명하는 데 필요한 정보만 지정할 수 있기를 원합니다. 다른 모든 것은 분리되어야 합니다. 내부적으로 MSBuild를 사용하려면 바로 진행하십시오. 꿀꺽꿀꺽, babel 또는 what-have-you를 선호하는 경우에도 마찬가지입니다. 나에게 그것은 project.json이 수행하도록 설정된 것입니다. (나는 거기에서 명령을 정의하는 기능의 팬이 아니었지만)

네, 이해가 됩니다. 그것이 내가 project.json에 대해 좋아했던 것 중 하나였습니다. 그것은 "어떻게"가 아니라 "무엇"을 정의했습니다. 하나의 파일에 너무 많은 것을 넣으면 파일이 너무 복잡해집니다. 특히 IDE가 어리석은 경우에는 더욱 그렇습니다. 그리고 그 내용은 편집자와 간단한 IDE에 필요하지 않습니다.

VS Code와 같은 낮은 행사 UI에서는 프로젝트 시스템이 별로 필요하지 않습니다. 모두 빌드입니다. 빌드해야 할 내용과 메타데이터를 말하는 선언적인 부분이 많습니다. 어떤 단계를 수행해야 하는지 말하면서 일부는 필수적일 수 있습니다.

예, MSBuilds의 가장 큰 문제는 하나의 시스템에서 모든 작업을 수행하려고 한다는 것입니다.

내가 이해하지 못하는 것은 다음과 같습니다. project.json을 작동시키는 것과는 반대로 MSBuild를 프로젝트 시스템으로 사용하여 개선된 몇 가지 사용 사례를 보여주세요. 나는 그것을 보지 않는다. 내 사용 사례가 너무 단순할 수 있으므로 몇 가지를 보여주세요.

@shederman 스탠드업 노트에는 프로젝트 간에 소스 파일을 공유할 수 있어야 한다고 언급되어 있습니다.

그래서 ... 이것은 오픈 소스 프로젝트이고 Microsoft가 "존재하는 힘"이라는 것을 알고 있지만 이것이 사람들에게 그렇게 중요하다면 - 그리고 나는 여기서 무지한 질문을하고 있다는 것을 알게되었습니다 - 얼마나 많은 시간 .NET Core가 MSBuild의 대안으로 project.json을 계속 사용할 수 있도록 /effort/energy를 사용해야 합니까? 충분한 사람들이 기여하고 코드가 충분하다면 MS가 이 프로젝트에서 이를 수락하지 않는 이유는 무엇입니까? 오픈 소스의 아름다움(그리고 몰락)의 일부는 기본 유지 관리자가 다른 사람이 제공하는 것을 너무 많이 거부하는 경우 코드를 분기할 위험이 있다는 것입니다. 오픈 소스인 코드의 요점 중 일부는 단순히 보는 것이 아니라 수정하고 개선하는 것입니다.

변경 사항에 대한 개인적인 견해는 향후 계획에 관한 것이라는 점에서 Xamarin과 관련이 있다는 것입니다. 또한 최근의 스탠드업에서 콘솔 앱을 빌드하는 것이 일류 시민이 되기를 원한다고 말하는 것을 들은 것 같습니다. 원래 새로운 .NET(ASP.NET 5 + DNX)은 웹 앱 구축에 중점을 두었지만 이제는 그 이상입니다. 이 모든 것이 비교적 최근에 발생했으며 .NET 및 ASP.NET 팀이 병합되었으며 Xamarin도 구매했습니다. 그들은 이러한 여러 시나리오(및 여기에서 추측하지 않을 새로운 미래 시나리오)를 지원하기 위해 더 나은 프로젝트 시스템이 필요하고 .NET Core도 곧 제공하기를 원한다는 결론에 도달했습니다. 무엇을 할까요? 필요한 것을 이미 처리하고 처음부터 시작할 수 있는 기존 MSBuild를 완전히 무시하시겠습니까? 미안하지만, 나는 내가 선택할 길을 알고 있다.

문제의 좋은 비트는 병합과 관련된 것 같습니다. 그러나 프로젝트 파일에 프로젝트의 파일 이름이 포함되어 있지 않고 종속성이 별도의 구성 파일로 푸시되는 경우 프로젝트 파일이 변경되어야 병합 문제가 사라져야 합니다. 비교적 드물게.

그냥 내 의견

병합 문제는 단 하나의 문제입니다. MSBuild에서 벗어나는 것은 또 다른 문제입니다. 이 시나리오의 미친 결과 중 하나는 이제 MSBuild를 Linux 및 OSX로 이식하는 데 시간과 노력을 들일 것이라는 것입니다! 상상 해봐.

나는 그들의 이유를 알지만 그들의 이유는 나에게 전혀 효과가 없으며 많은 사람들에게 효과가 없습니다. 우리는 그들이 가고 있는 방향에 대한 확고한 확신을 바탕으로 투자를 했고, 그들은 아무런 책임 없이 다시 투자에 착수했으며, 아마도 그들이 더 나은 결정을 _커뮤니케이션_했어야 한다는 표시에 불과했습니다. 그들은 MSBuild가 지원하는 엣지 케이스와 이러한 엣지 케이스를 지원하는 것이 얼마나 어려운지를 기반으로 project.json에 대한 결정을 내리고 있습니다. 글쎄, 그것은 올바른 생각으로 아무도 그 모든 극단적 인 경우를 지원하지 않을 것이기 때문에 사용을 _절대_ 중단하지 않을 것임을 의미합니다. 확실히 ASP.NET 프로젝트를 수행하는 사람은 이러한 엣지 케이스가 필요하지 않습니다.

포크가 가능하지만 모든 것이 얼마나 크고 통합되어 있는지를 고려할 때 관련 코드를 배우는 것조차 고려하는 것은 벅찬 전망입니다. 현실은 이것이 진정한 오픈 소스 프로젝트가 아니라 Microsoft 프로젝트이며 그들은 우리의 의견 없이 회사 결정을 내렸고 우리는 그것을 빨아들이고 받아들여야 한다는 것입니다. 어떤 반대가 있더라도 기본적으로 그들이 _절대_ 재고할 가능성이 없다는 것이 나에게 분명해졌습니다.

그래서, 우리가 노력을 기울이고 project.json 빌드 시스템을 분기하거나, 다른 빌드 시스템(FAKE?)으로 전환하거나, 당신이 그것을 빨아 먹거나, 다른 플랫폼을 사용합니다. 나는 거기에서 모든 선택을 열거했다고 믿습니다.

@shederman MSBuild는 2015년 초부터 오픈 소스였으며 빌드는 OSX/Ubuntu에서 전달되므로 이식할 생각만큼 많은 작업이 필요하지 않습니다(https://github.com/Microsoft/msbuild). , 예를 들어 OSX가 3월에 OK를 구축하고 있었던 것처럼 리포지토리를 탐색합니다.

이런. 나는 우리가 이것을 _해야_ 하는지에 대해 걱정하고 있습니다. 그리고 그들은 떠나서 그것을 했습니다...

마치 프랑켄슈타인 괴물이 멀리서 돌진하는 것을 보는 사람처럼 느껴집니다. 흥미롭고, 흥미롭고, 걱정되고, 조금 더 혐오스럽습니다 :-)

@darrelmiller 스탠드업 노트는 프로젝트 간에 소스 파일을 공유할 수 있어야 한다고 언급합니다.

진짜? 사람들이 아직도 그렇게 해요? 내 말은 AssemblyInfo.cs에 대해 수행했고 암흑 시대로 돌아가서 강력한 이름 키를 공유 소스 파일에 넣었습니다.

좋아, 그 사용 사례이지만, 지금은 정말로 사용 사례에 대한 사용 사례를 듣고 싶습니다. 궁금하다.

@shederman

음. 좋아, 그럼 내가 원하지 않는 미래를 상상하고 그것이 어떻게 작동하는지 설명해야 합니까? 음, 난 그렇게 생각하지 않아

당신이 해야 할 일은 JSON 대신 XML을 받아들이는 것뿐입니다. 이점이 무엇인지 보기 위해 그 게임을 하고 싶지 않습니다. 왜냐하면 당신이 하고 싶은 일은 실제로 이유를 언급하지 않고 XML이 얼마나 나쁜지에 대해 이야기하는 것뿐이기 때문입니다.

이런. 나는 우리가 이것을해야하는지 걱정하고 그들은 가서 그것을했습니다 ...

그들은 지금 문자 그대로 _년_ 동안 "일을 하고 있습니다." 그들은 몇 년 전에 오픈 소싱 .net에 대해 이야기했으며 로드맵을 제시했으며 궁극적으로 모든 사용 사례에 대해 모든 플랫폼에서 실행되는 것임을 분명히 했습니다.

당신은 이 변화에 상당히 화가 났고, 나는 그 변화에 화가 난 대다수의 사람들이 모두 웹 개발자라고 생각합니다. 그러나 그것은 .net 생태계의 작은 부분일 뿐입니다. 거대한 서비스 생태계, 모바일 및 클라우드 개발자가 있습니다. .net 코어로 이식할 수 있기를 원하는 코드 라이브러리. 좋든 싫든 project.json은 현재 모든 모델에서 작동하지 않습니다. "작동시키십시오"라고 말하지만 명확하고 명확하게 정의된 구조가 없고 더 나쁜 것은 주석이 없는 파일을 제외하고는 또 다른 지저분한 프로젝트 파일로 끝날 것입니다. 마지막 요점은 project.json을 재고하기에 충분한 이유입니다.

오 예, 연결한 xproj가 훨씬 좋습니다. 멋지고 명확하고 간결합니다. 그리고 표현력, 표현력을 잊지 마세요.

적어도 당신은 마침내 그것을 보았습니다. 당신이 귀찮게하기 전에이 문제에 72 개의 댓글이 필요했습니다. 계속 말하지만 이해가 되지 않습니다. MSBuild가 얼마나 끔찍한지에 대해 불평하는 대신, 왜 끔찍한지에 대해 이야기

병합 문제는 단 하나의 문제입니다. MSBuild에서 벗어나는 것은 또 다른 문제입니다.

이것이 왜 문제일까요? 당신은 MSBuild를 싫어합니다. 우리는 이해합니다. 하지만 XML을 _감히 사용한다는 사실을 제외하고 MSBuild에 대해 당신이 싫어하는 것은 무엇입니까?

이 시나리오의 미친 결과 중 하나는 이제 MSBuild를 Linux 및 OSX로 이식하는 데 시간과 노력을 들일 것이라는 것입니다! 상상 해봐.

네가 옳아! 원하는 IDE를 사용하여 원하는 플랫폼에서 모든 종류의 .net 앱을 개발할 수 있다는 것은 끔찍할 것입니다. 아이들을 생각하십시오!
Microsoft가 자신의 폐쇄 소스 기술에 투자하는 대신 작업을 오픈 소싱하고 도구를 다른 플랫폼에 이식하는 데 어떻게 시간을 할애합니까?

나는 그들의 이유를 알지만 그들의 이유는 나에게 전혀 효과가 없으며 많은 사람들에게 효과가 없습니다.

그러나 그들은 당신보다 훨씬 더 많은 사람들을 위해 일하고 있습니까?

우리는 그들이 가고 있는 방향에 대한 확고한 확신을 바탕으로 투자를 했으며, 그들은 아무런 책임 없이 다시 투자에 착수했으며, 아마도 그들이 결정을 더 잘 전달했어야 한다는 표시에 불과했습니다.

어떤 _방향_을 말씀하시는 건가요? 목표는 항상 모든 곳에서 .net이었으며 "모든 개발자, 모든 앱, 모든 플랫폼"이 오늘의 만트라이며 이 변경 사항에 영향을 미치는 것은 전혀 없습니다. 그들은 프로젝트 파일을 작고 단순하며 사람이 읽을 수 있고 IDE 없이 편집할 수 있도록 유지하는 것이 목표라고 분명히 밝혔습니다. 당신에게서 빼앗긴 것은 아무것도 없습니다. .net이 모바일, 클라우드 및 웹을 위한 일류 경험이라는 것을 의미한다면 약간의 XML을 처리해야 할 수도 있습니다. 그렇다면 그만한 가치가 있습니다.

그들은 MSBuild가 지원하는 엣지 케이스를 기반으로 project.json에 대한 결정을 내리고 있습니다.

이것은 _edge_ 경우를 훨씬 능가합니다. project.json이 거의 완벽하다고 제안하는 것조차 우스꽝스럽습니다.

확실히 ASP.NET 프로젝트를 수행하는 사람은 이러한 엣지 케이스가 필요하지 않습니다.

이것이 문제의 핵심이라고 생각합니다. asp.net 개발자인 자신 외에 다른 사람은 신경 쓰지 않습니다. 충분히 공평하지만 다시 한 번 말씀드리고 싶습니다. 다른 개발자가 중요하다는 사실을 받아들이고 그저 무기를 들고 있는 대신 최고의 시스템을 만들기 위해 노력하십시오. 즉,이 그림이 당신과 다른 사람들과 작업이 모두가 큰 있도록하는 것보다 더 큰 것을 받아들이는 의미는 완전히 다른 마크 업에 대한 임의의 구문까지하지 평균
내가 계속 말하듯이, nuget.json이 모든 종속성을 나열한다면 무엇이 남아 있습니까? XML의 명명된 요소에서 일부 상당히 정적인 필드를 정의하는 데 어떤 문제가 있습니까?

현실은 이것이 진정한 오픈 소스 프로젝트가 아니라는 것입니다.

다른 사람들이 말했듯이 오픈 소스가 된다는 것은 소수의 불만을 제기하는 사람들에게 뒤로 구부리는 것을 의미하지 않습니다. 그들은 pull 요청을 수락하고 더 나은 것을 작성합니다.

모든 것이 얼마나 크고 통합되어 있는지 고려할 때 관련 코드를 배우는 것조차 고려하는 것은 벅찬 일입니다.

좋아, 그래서 나는 기본적으로 이것을 "나는 더 큰 그림을 이해하지 못하고 더 큰 그림을 이해하고 싶지 않지만, 그것이 의미를 완전히 무시하고 내 작은 거품에 영향을 미치기 때문에 여전히 불평할 것입니다. 내 거품은 다른 사람에게 있습니다."

그래서, 우리가 노력을 기울이고 project.json 빌드 시스템을 분기하거나, 다른 빌드 시스템(FAKE?)으로 전환하거나, 당신이 그것을 빨아 먹거나, 다른 플랫폼을 사용합니다. 나는 거기에서 모든 선택을 열거했다고 믿습니다.

또는 ... 그리고 이것은 단지 말도 안 되는 생각이지만 실제로 대화에 건설적인 것을 기여해 볼 수 있습니다.

본론으로 돌아가....

더 많은 생각을 했고 이제 project.json이 nuget.json이 되도록 하여 종속성 관리를 지금과 같은 방식으로 유지하는 방향으로 기울고 있습니다. 이제 잘 작동하고 Intellisense가 이미 거기에 있으며 gulp 및 npm과 일치합니다.

csproj가 단순히 정적 부분을 정의하도록 하십시오.

그러나 내가 볼 수있는이 접근 방식의 단점은 여러 프레임 워크를 대상으로 할 때 이것이 얼마나 잘 작동하는지 확실하지 않다는 것입니다. nuget.json에 넣는 것이 합리적이지 않다고 생각하지만 nuget.json은 여전히 그것에 대해 알아야 할 것입니다.

project.json은 단순한 json 파일이 아닙니다.
csproj는 단순한 XML 파일이 아닙니다.

IMHO 저와 같은 많은 사람들이 Microsoft, 더 정확하게는 Asp.Net 팀,
아주 오래된 레거시 코드/개념/시스템/도구/외관/...

이것은 우리에게 '희망'을 주었습니다!

나는 최초의 미리보기 비트 이후로 Asp.Net을 개발합니다. 나는 주로 그것으로 일하는 것을 좋아합니다. 그러나 15년 후,
XML과 같은 '오래된' 것은 정말 무겁고 구식으로 느껴집니다. 인식이 중요합니다.

XML이 없고 최소한 JSON을 대신 사용하면 내 '개발자 행복'이 훨씬 더 큽니다.
나는 일을 할 수 있고 나머지 세계는 사용하기로 결정했습니다. 내 IDE는 레거시 형식보다 이러한 것들을 선호합니다.
더 이상 '앵글 브라켓 세금'을 내지 않아도 됩니다.

project.json을 제거하는 것은 큰 문제가 아니지만 거의 마지막 순간에 닫힌 문 뒤에서 수행하는 것은 그 '희망'을 즉시 죽입니다.

갑자기 이것은 더 이상 오픈 소스 프로젝트처럼 느껴지지 않습니다.

fyi: "Asp.Net Core"에는 환상적인 기능이 많이 있습니다. 나는 대부분 그것을 좋아한다.
Asp.Net 팀은 훌륭하며 Asp.Net 개발자가 된 것이 자랑스럽습니다.

하지만 나는 다쳤다. 어쩌면 나만 그런 것이 아닐 수도 있습니다.

그냥 내 2 센트.

msbuild(특히 VS가 사용하는 방법)가 완벽하지 않다는 데 우리 모두 동의할 수 있다고 생각합니다. 저는 project.json에 대해 흥분했지만 MS가 많은 문제를 해결하고 정직한 한 나는 그들이 그것을 어떻게했는지에 대해 그다지 신경 쓰지 않을 것입니다.

• csproj 병합이 잘 작동하지 않습니다. 격주로 깨진 병합을 수동으로 수정해야 합니다. csproj에서 파일 목록을 제거하면 여기에서 많은 도움이 될 것입니다.
• NuGet 참조 및 프로젝트 참조가 항상 정렬되지는 않으며, 병합이 끊어졌을 수도 있습니다. 어느 쪽이든 진단하고 수정하는 것은 성가신 일입니다.
• 때때로 빌드 프로세스에 연결해야 하지만(project.json에서 작동하는 방식이 확실하지 않음) 전체를 언로드/로드해야 하기 때문에 빌드 스크립트의 디버깅이 고통스러운 프로세스입니다.

그들이 그 3가지 항목을 고칠 방법을 찾는다면 아마 csproj 파일에 대해 그다지 불평하지 않을 것입니다.

@neoKushan

당신이 하고 싶은 일은 실제로 그 이유를 밝히지 않고 XML이 얼마나 나쁜지에 대해 이야기하는 것뿐입니다.

완전히 공정하지는 않지만 MSBuild가 어떻게 나쁜지에 대해서도 이야기하고 싶습니다 :-)

나는 내가 빌드 파일을 위한 XML을 좋아하지 않는 이유를 실제로 _have_ 말했을 것이라고 확신하지만, 다시 한 번 찔러보겠습니다. XML은 장황하고 보기 흉하고 손으로 편집하는 것보다 도구를 사용하는 것이 더 좋으며 XML을 병합하는 경험이 즐겁지 않습니다. 당시 업계에서는 XML이 모든 것에 사용될 수 있다고 생각했기 때문에 MSBuild에 사용되었습니다. 그 이후로 계속 진행했습니다. 글쎄, 일부 장소에서.

더 나쁜 여전히 - 코멘트 없음

나는 여러 사람들이 여기에서 대안을 제시했다고 생각합니다. HJson은 하나의 옵션일 뿐입니다. 야! 우리는 결국 그것을 다시 생각할 필요가 없습니다 ;-)

당신은 이 변화에 꽤 화가 났어요

공정하게 말하자면, 나는 이전에 project.json에 대한 매우 확고한 지원을 액면 그대로 받아들였던 커뮤니티를 고려하거나 참여하지 않고 폐쇄된 공간에서 이 변경이 어떻게 이루어졌는지에 대해 대부분 화가 났습니다. 소년, 다시는 그 실수를 하지 않을 것입니다!

오해하지 마십시오. XML이 마음에 들지 않거나 MSBuild가 마음에 들지 않습니다. 하지만 내가 정말 좋아하는 것을 입양하라는 말을 듣고 마지막 순간에 그것을 빼앗긴다는 말을 듣는 것을 싫어 합니다. 내 치즈를 움직이지 마!

나는 변화에 화난 사람들의 대다수가 모두 웹 개발자라고 생각합니다.

음, 예, 그들이 project.json을 제공한 유일한 개발자이기 때문일 것입니다. 다른 소식으로, Swift 개발자들도 이 결정에 대해 화를 내지 않습니다. 내 말은 당신이 여기에서 말하는 것을 생각하십시오:

1. 웹 개발자만 이 새로운 기능을 사용할 수 있습니다.
2. 그들 중 많은 사람들이 우리가 그것을 가져갔을 때 정말로 화를 냈습니다.
3. 다른 사람이 사용하지 않아도
4. 사용하지 않은 사람들은 그것을 빼앗긴 것에 대해 화를 내지 않습니다.
   그래서 다른 모든 개발자는 그것을 원하지 않을 것입니다.

나는 당신이 당신의 생각의 질을 살펴볼 필요가 있다고 생각합니다. 그리고 그것이 내가 꽤 오랫동안 심문하려고 시도한 것이고 아무데도 없었습니다. 생각에 대한 정보가 부족하고 관련 당사자가 뭉쳤다는 사실은 나에게 그 생각이 의심되었을 수 있음을 나타냅니다.

그리고 "웹 개발자"는 무엇을 의미합니까? 작은 회사를 위한 작은 웹사이트를 생각하고 계십니까? 수백억 달러의 자산 관리 비즈니스를 지원하는 마이크로서비스 스택은 어떻습니까? 물론 거기에도 웹 사이트가 있습니다. 그러나 그것은 시스템의 약 10%입니다. 아, 예, 실제로 클라우드도 대상으로 하므로 실제로 "클라우드 개발자"를 말하는 것일 수 있습니다.

성급한 결정을 내리는 기술이 어떻게, 누구에 의해 사용되고 있는지조차 이해하지 못하는 것 같습니다.

감히 XML을 사용한다는 사실 외에 MSBuild에 대해 싫어하는 것은 무엇입니까?

너무 복잡해
이는 임피던스 불일치로, 사람들이 주로 명령형 또는 선언적 논리를 다루는 상황에 추론 기반 논리를 밀어넣습니다.
맙소사, 실제로 MSBuild 파일을 _보셨나요_? 네, 죄송합니다. XML을 사용하는 것 외에는 말씀하셨습니다 ;-)
속성과 항목이 선언되는 방식은 정기적으로 사용하지 않는 사람에게는 직관적이지 않습니다.
스크립트에서 수행해야 하는 작업을 수행하려고 하는 모든 도구에 맞는 크기로 사용됩니다. 망치, 못.
많은 경우 큰 파일에서 수행하는 모든 작업은 최대 3줄의 스크립트로 표현할 수 있습니다.
쏟아지는 VS 쓰레기. 해결될 것이라고 들었습니다. 그것도 잘려나갔나 보려고 약간의 떨림으로 기다립니다. 위에서 언급했듯이, 나는 지금 약속에 대해 약간 총성이 있습니다.

당신이 그렇게 사랑하는 것은 무엇입니까? 그리고 가장 중요한 것은, 다른 사람들이 당신의 견해를 공유하지 않을 수도 있다는 사실을 기꺼이 받아들일 의향이 있습니까? 그렇다면 "모든 사람에게 적합한" 접근 방식이 올바르지 않을 수 있음을 인정할 수 있습니까?

어떤 방향을 말하는거야

project.json은 우리의 새로운 프로젝트 접근 방식의 기초입니다. 우리는 그 약속을 바탕으로 실제 돈과 시간과 고통을 투자했습니다.

그러나 그들은 당신보다 훨씬 더 많은 사람들을 위해 일하고 있습니까?

어쩌면 그들은 정말로 할 것입니다. 그러나 그렇다면 그 증거는 어디에 있습니까? 나는 이것에 사용된 생각과 의사 결정과 증거를 조사하려고 노력했지만 나는 누구에게서도 아무것도 얻지 못했습니다. 제공된 모든 증거에 대해 우리가 알고 있는 모든 것에 대해 Magic 8-ball을 흔들 수 있었습니다.

얼마나 많은 사람들이 이런 식으로 생각하는지 아무도 모릅니다. 실제로 알아 내려고 노력한 사람은 제가 아는 유일한 사람입니다.

asp.net 개발자인 자신 외에는 아무도 신경 쓰지 않습니다.

별로 좋지 않다. 내가 실제로 말하는 것은 새로운 방향이 모든 사용 사례에 적용된다는 주장이며, 나는 손을 들어 그것이 나에게 효과가 없다고 말하고 있습니다. 당신은 모든 반대에 거친 신발을 탄 사람입니다. 나는 사람들에게 어떻게 생각하는지 묻는 사람입니다. MS는 그렇지 않습니다.

나는 "MSBuild를 완전히 제거하고 다른 모든 개발자에게 내 빌드 프로세스를 적용하십시오"라고 말한 적이 없습니다. 당신은 "project.json을 완전히 제거하고 모든 개발자에게 MSBuild를 시행하십시오"라고 말하는 사람입니다. 모든 미리 보기에 두 가지 빌드 시스템이 있었고 만족했습니다. 웹 개발자는 행복했고 웹이 아닌 개발자는 행복했습니다.

우리는 그것이 얼마나 가능한지 논의할 수 있고 어쩌면 그렇지 않을 수도 있습니다. 그러나 우리는 의논하거나 약혼한 적이 없기 때문에 모릅니다 .

당신은 제외된 중간에 대한 당신의 주장을 정말 좋아합니다.

그들은 풀 리퀘스트를 받아들입니다

진짜? 기본 도구 기능에 비 MSBuild 기반 빌드 도구를 남겨두고 project.json만 읽는 풀 요청을 발행했다면 프레임워크에 포함하시겠습니까? 진짜?

좋아, 그래서 나는 기본적으로 이것을 다음과 같이 읽고 있다...

와우, 당신은 그것에 대해 많이 읽었습니다. 맙소사, 내가 당신처럼 읽었다면 나는 결코 책을 끝내지 못했을 것입니다. 그리고 그것은 작가가 쓴 것과 상당히 다를 것입니다.

차라리 "나는 더 큰 그림을 완전히 이해하지 못하고 이것을 하는 데 관련된 노력과 시간을 고려하고 있습니다. 우리가 상당한 부분을 제공하는 데 기존 개발자의 도움이 있다면 훨씬 더 좋을 것입니다. 의 커뮤니티가 원하지만 사용자가 원하는 것을 신경 쓰지 않는다면 우리는 그 길을 가야 할 수도 있습니다."

젠장! 나는 당신처럼 읽습니다! 당신의 다소 히스테리적인 해석보다 실제로 원본 텍스트에 조금 더 잘 맞는다는 점을 제외하고는.

실제로 대화에 건설적인 것을 기여해 볼 수 있습니다.

글쎄, 나는 사실 내가 건설적이라고 생각했다. 나는 처음의 충격을 극복한 후 이 결정의 근거가 무엇인지 알아내려고 노력했습니다. 나는 의사결정 과정이 어떤 것인지 알아보려고 노력했다. 나는 그 이면에 있는 생각의 질을 묻고자 노력했다. 대다수의 개발자가 이것을 원한다는 말을 들었을 때 이 주장을 뒷받침할 증거가 제공되지 않았기 때문에 저는 실제로 그들 에게 물었 습니다. 팀의 _아무도_ BTW를 수행한 사람은 없었습니다.

내가 무엇을 얻었습니까? 방해, 모욕 및 회피. 수백만 명에게 영향을 미치는 중대한 결정을 내리는 사람이 숙제를 했는지 묻는 것이 왜 건설적이지 않다고 생각합니까? 그리고 사람들이 숙제 책을 보여주기를 거부할 때 건설적이거나 의심스럽다고 생각합니까?

현실적으로 가능한 시나리오는 다음과 같습니다.
1) 귀하는 완전한 피드백과 정보를 기반으로 결정을 내렸고, 그 결정은 진정으로 앞으로 나아갈 수 있는 최선의 선택입니다. 그렇다면 닥치고 약속할게. 나는 당신이 받은 반대의 수준과 당신이 증거와 결정을 숨기고 있다는 사실 때문에 이 상황이 상당히 가능성이 낮다고 생각합니다.
2) 당신은 부분적인 견해에 근거하여 결정을 내렸지만 당시 당신이 가진 최선의 것입니다. 나는 결정을 다시 내리고 당신이 빠진 견해를 간청하는 것이 올바른 응답이라고 말하고 싶습니다. 저는 이것이 가장 가능성이 높은 상황이라고 생각합니다.
3) 잘못된 결정을 내리거나 잘못된 정보를 기반으로 결정했습니다. 이 경우 다시 결정을 재개하고 커뮤니티에 요청해야 합니다. 여러분이 저를 믿지 못하시겠지만 저는 DotNetCore 개발자를 대단히 존경하기 때문에 이것이 상황이라고 생각하지 않습니다. 그들 모두.

그리고 결정을 다시 시작하고 의견을 구하고 결정이 이전과 같은 방식으로 내려오면 손해가 무엇인지 압니다. 그리고 의견을 구한 후 의사 결정의 일부에 결함이 있음을 깨닫고 수정하면 실제로 더 좋지 않습니까?

와, 진지하게. 이걸 끝낼 수 있을까요?

간단한 질문: 반대 의견을 수용하고 새로운 정보에 기반한 결정을 다시 검토하시겠습니까?

아니면 당신과 동의하지 않는 사람들이 미쳤고, 어리석고, 미숙하거나, _정보가 없는_이거나, 아니면 정보에 입각한 유효한 의견을 유지할 능력이 없다는 것을 계속 암시하시겠습니까?

제안: msbuild csproj 레거시 고객을 지원하기 위한 Microsoft 포크. #carryOnAsNormal

나는 또한 오랜 기간 .Net 개발자이며 마케팅에서 .Net 이름을 발명하기도 전에 1.0의 미리보기로 작업했습니다. 잡초에 너무 헤매지 않고 여기 내 2 센트가 있습니다.

다른 xml 구성 파일을 보지 않고 평생을 보낼 수 있고 완벽하게 행복할 수 있습니다.

xml 구성을 원하지 않습니다. 어딘가에. 항상.

나는 팀이 csproj의 모든 단일 문제를 수정하더라도 상관하지 않습니다. 완료했을 때 여전히 xml 구성 파일이면 관심이 없습니다. .net 4.5 프로젝트 시스템을 그대로 유지해도 됩니다.

MSBuild의 경우... MSBuild는 화재로 죽을 수 있습니다.

강력하고 주변에 많은 도구가 존재하지만 MS 외부에서는 MSBuild에 대한 깊이 있는 전문가만이 실제로 무엇을 하는지 또는 어떻게 작동하는지 알고 있습니다. 모든 사용자 정의를 빌드 프로세스에 연결해야 할 때마다 결국 3~5일의 직업 생활을 잃게 됩니다. 나는 출력에 빈 폴더를 포함하는 것과 같은 사소한 것조차도 VS, VS 게시 및 내 CI 서버에서 동시에 올바르게 작동하는 것을 거의 얻을 수 없습니다.

알겠습니다... asp.net core 1.0 기간 동안 MSBuild를 대체할 좋은 제품을 만들 시간이 없다면 확실히... asp.net core 2.0이 될 때까지 MSBuild를 계속 활용할 수 있는 방법을 강구하십시오. 주기; 그러나 적어도 그 똥을 다른 사람들이 작업할 수 있는 것으로 대체하는 방향으로 계속 작업하십시오.

그 동안 가능한 한 많은 구성을 json에 유지하십시오. 나는 그것이 project.json인지, 아니면 새롭고 더 나은 것인지 특별히 신경 쓰지 않습니다. 필요한 경우 도구가 필요할 때 레거시 MSBuild 파일을 즉석에서 생성하도록 하십시오. 하위 폴더 어딘가에 저장하십시오.

내가 원하지 않는 것은 다음과 같은 파일 시스템입니다.

• bower.json
• 패키지.json
• nuget.json
• 모든 것-else.json
• microsoft-old-ass.xml.csproj

또한 260자 경로 길이 제한을 수정해 주실 수 있나요... 제발... 예, Windows와 관련이 많은 것으로 알고 있지만 심각하게는... 2016년입니다. .

추신. 당신이 반대를 무시하고 계속하기 위하여려고하는 경우에 다음을 제공하십시오 수 있습니다 :

• 빌드 도구 개발자 여유 채널에 액세스하는 방법
• 현재 아키텍처와 코드, 그리고 MSBuild/xproj로 이동할 변경 사항에 대한 상위 수준 보기를 통해 원하는 비트를 유지하고 잘 통합하기 위한 접근 방식을 계획할 수 있습니다.
• 품질 기준을 충족하는 경우 project.json 기반 도구에서 pull 요청 베이킹이 허용된다는 보장
• 품질 기준이 충족되면 전체 project.json에 대한 "dotnet 빌드" 지원과 ASP.NET Simple 템플릿을 포함할 수 있으며 잠재적으로 더 표준적인 프로젝트 유형에 대한 일부 템플릿도 포함할 수 있습니다.

"건설적이 되십시오", "기여하지 마십시오. 목소리를 내지 마십시오." 글쎄, 당신은 당신이 요구하는 것을 얻습니다 ...

@Mike-EEE, SimpleUseCaseBuild에 대한 Xaml 직렬화를 원하십니까?

이 모든 것을 읽은 후 나는 다음과 같은 결론에 도달했습니다.

• project.json은 많은 개선을 가져왔습니다. .net 및 asp.net 코어가 레거시 코드 및 도구에 연결되어 있었다면 이 중 어느 것도 불가능했을 것입니다.
• project.json(및 json)이 완벽하지 않습니다.
• xml 대 json 대 anyserializationlanguage는 무균입니다. .net 핵심 과제에 답하기 위해 이를 활용하는 방법에 대한 논의가 더 흥미로울 것입니다.
• msbuild로 돌아가는 것은 레거시를 다시 가져오고 아마도 .net 팀이 자유를 잃을 가능성이 있기 때문에 프로젝트 시스템에서 더 이상 개선 사항을 볼 수 없다는 것을 의미합니다.

저는 .net 팀이 심호흡을 하고, 이것을 잠시 멈추고, 피드백을 수집하고(그리고 이 새로운 스택의 채택과 인식을 고려하고) msbuild 접근 방식(우리 중 일부가 생각하는 것만큼 나쁘지 않을 수 있음)에 도전하기를 바랍니다. 몇 가지 대안. 서두를 필요가 있다고 생각합니다.

LOL @shederman 지금 나를 끌어

xml 대 json 대 anyserializationlanguage는 무균입니다. .net 핵심 과제에 답하기 위해 이를 활용하는 방법에 대한 논의가 더 흥미로울 것입니다.

예, 나에게 중요한 것은 프로젝트 및/또는 프로젝트가 하는 일을 설명하는 데 사용되는 지원 모델이며, 이 대화 중 일부에서 이에 대해 언급했습니다. 설명하고 작업하기가 더 쉬운 개선된 프로젝트 모델/api를 보고 싶습니다(설명된 형식에 관계없이 -- 그래도 그렇습니다 :heart: my Xaml!). 여기에 MSBuild의 리포지토리(https://github.com/Microsoft/msbuild/issues/613)와 Roslyn의 프로젝트 시스템(https://github.com/dotnet/roslyn-project)에 대한 공개 토론이 있습니다. -system/issues/37) 또한 관심이 있는 경우.

여기에 정말 훌륭한 포인트가 많이 있으며, 저는 개인적으로 "비건설적"이든 아니든 에너지를 파헤치고 있습니다. 여기 있는 모든 사람들이 MSFT를 개선하고 생산되는 것을 최대한 활용하는 데 마음을 가지고 있다고 생각합니다. :+1:

내 2센트:

저는 이 변화에 대해 두 부류의 사람들이 논의하고 있다고 믿습니다.

• _다양한_ 종류의 프로젝트를 빌드하기 위해 VS & .NET을 사용해 왔으며 해당 프로젝트를 오랫동안 지원해야 하는 개발자
• 그런 부담이 없고 새롭고 깨끗하고 멋진 크로스 플랫폼 ASP.NET Core 프레임워크를 원하는 개발자

개인적으로 저는 첫 번째 범주에 속하므로 새로운 ASP.NET Core가 가능한 다른 VS 프로젝트 유형과 호환되기를 원하며 "이전" csproj/msbuild 솔루션으로 이동하는 것이 저에게 유리합니다(+my 팀 및 아마도 많은 다른 개발자). 이렇게 하면 전환이 훨씬 부드럽고 명확해집니다. 아마도 두 번째 범주의 사람들은 나와 동의하지 않을 것입니다(또는 그냥 상관하지 않습니다).

지금 내가 볼 수 있는 유일한 주요 문제는 NuGet 패키지가 정의되고 참조되는 방식입니다. packages.config 및 csproj 파일을 모두 유지해야 하는 것은 고통 스러운 일입니다 ( @cwe1ss 처럼 수행해야 합니다. 이 주제 BTW에서 가장 건설적인 의견 중 하나였습니다...

XML/JSON의 성스러운 전쟁에 관해서는... IMHO, XML은 JSON보다 손 편집에 더 좋습니다. XML은 주석을 지원하며 볼 때 더 많은 컨텍스트 정보를 가지고 있습니다. JSON은 구성 파일이 아닌 데이터에 더 좋습니다. 병합은 두 형식 모두에 똑같이 좋고 나쁨이 있으며 전적으로 내용에 따라 다릅니다. 프로젝트 참조가 현재 csproj 파일과 분리된다면 병합도 훨씬 쉬워질 것입니다...

@Funbit가 사람들을 분류하려고 해도 도움이 되지 않습니다. 그리고 나는 어떤 범주에도 속하지 않습니다. 저는 v1 베타 이후로 asp.net 개발자입니다. 나는 2년 전에 거의 하나가 되지 않을 뻔했지만 .net 코어가 깨끗한 슬레이트와 .net 및 노드 세계의 최고였기 때문에 다시 돌아왔습니다.

저는 .net core가 채택도 없고 커뮤니티도 없는 오래된 기업 테크노가 아니라 성공하기를 바랍니다.

내 입장에서는 이 결정에 대해 별로 신경 쓰지 않고 XML에 대해서도 별로 신경 쓰지 않고 인용문을 훔쳐보기 위해 "중괄호가 꺾쇠 괄호보다 낫습니다." csproj/msbuild - 나는 유연해서 대처할 수 있습니다.

그래도 @shederman 의견 중 일부를 반영하고 싶습니다.

현실은 이것이 진정한 오픈 소스 프로젝트가 아니라 Microsoft 프로젝트이며 그들은 우리의 의견 없이 회사 결정을 내렸고 우리는 그것을 빨아들이고 받아들여야 한다는 것입니다. 어떤 반대가 있더라도 기본적으로 그들이 재고할 가능성이 없다는 것이 분명해졌습니다.

그리고

공정하게 말하자면, 나는 이전에 project.json에 대한 매우 확고한 지원을 액면 그대로 받아들였던 커뮤니티를 고려하거나 참여하지 않고 폐쇄된 공간에서 이 변경이 어떻게 이루어졌는지에 대해 대부분 화가 났습니다. 소년, 다시는 그 실수를 하지 않을 것입니다!

이것은 저를 괴롭히는 _does_입니다. Microsoft는 .NET을 오픈 소싱하고 커뮤니티에 실제로 참여하고 협력하고 피드백을 받고 커뮤니티의 좋은 '구성원'(파트너?)이 되기를 원합니다. 그러나 이런 종류의 일은 실제로 그 모든 노력을 후퇴시키고 .NET 생태계에 전체 "보그"가 /. 커뮤니티는 몇 년 동안 레이블을 붙였습니다.

마이크로소프트에게 공정하게 말하자면, 기업 후원 프로젝트에서 이런 종류의 일을 하는 것은 그들만이 아닙니다. (io.js 포크를 일으킨) nodejs 커뮤니티의 분할을 기억하십니까? 하지만 마이크로소프트라면 훨씬 더 나쁘다고 생각합니다.

그것은 처음에 의도했던 것보다 균형을 벗어났습니다.

처음에 의도한 것보다 비율이 많이 떨어졌습니다.

@MaximRouiller 당신은 심지어 개발자입니까, 형??? :웃다:

@Mike-EEE 그렇습니다. 나는 열띤 논쟁을 예상했지만 너무 많은 인신 공격을 보았습니다. :실망한:

프로젝트 간에 소스 파일을 공유할 수 있어야 함

@darrelmiller 이것은 .csproj의 목록 파일이 다시 돌아오고 있음을 암시하는 것처럼 보이기 때문에 무섭게 들립니다.

@lokitoth 링크된 파일이 와일드카드 globs를 사용할 수 없는 이유는 아마 없을 것입니다.

@MaximRuiller 저 역시 너무 @shederman 은 던지는 법을 알고 있습니다! ㅋ. 덧붙여서, 나는 @shederman이 내 내면의 코딩 동물을

나는 우리가 하는 일이 정말 힘든 일이라는 것을 스스로에게 상기시켜야 한다고 생각합니다. 그럴 때입니다! 거기에 도착하는 것은 훨씬 더 어렵습니다. Silverlight에 대한 내 경험에서(예, 그것으로 인해 화상을 입었습니다. 그래서 @shederman 이 어디에서

어쨌든 지금은 "웹" 진영과 "네이티브" 진영으로 나뉜 팀이더라도 심호흡을 하고 겸손한 마음을 갖고 우리가 같은 팀임을 스스로에게 상기시키는 것이 항상 최선입니다. 잠시 동안은 형편없을 수 있지만 여기서 우리가 이야기하는 것은 10년 이상, 심지어는 오랫동안 우리에게 도움이 될 것입니다. 다른 사람들과 그들이 어디에서 왔는지 공감하면서 장기적인 접근 방식에 집중합시다.

좋아... 충분한 설교와 하루를 위한 rah-rah. :stuck_out_tongue: 정기적으로 예정된 슬러그페스트로 돌아갑니다!

이것은 .csproj의 목록 파일이 다시 돌아오고 있음을 암시하는 것 같아서 무섭게 들립니다.

또한, 제쳐두고 이 기능을 높이 평가하는 사람은 지구상에서 나뿐입니까? :stuck_out_tongue:

이것은 .csproj의 목록 파일이 다시 돌아오고 있음을 암시하는 것 같아서 무섭게 들립니다.

또한, 제 생각에는 이 기능을 높이 평가하는 사람이 지구상에서 유일한 사람이라고 생각합니까? :stuck_out_tongue:

@Mike-EEE 네, 그런 것 같아요. :눈짓:

연결된 파일의 주요 사용 사례는 여러 플랫폼을 대상으로 하는 것입니다. 그것이 내가 정말 유지하고 싶은 project.json의 기능 중 하나입니다. 이 기능에 대한 구체적인 설명을 본 적이 없다고 생각합니다. 하지만 팀이 msbuild에서 이를 다시 생성하려는 의도를 확인할 수 있다면 좋을 것입니다.

@shederman 은 던지는 방법을 알고 있습니다!
😆

나는 노력한다. 그래도 누군가를 모욕하지는 않았으면 좋겠습니다. 나는 논쟁만 쫓기 위해 열심히 노력했다.

나는 특히 비열한 인신공격에 화를 내기 때문에 누가 나에 대해 논쟁을 벌인다고 해서 입을 다물게 해서는 안 된다. 😉 그리고 꽤 많았습니다.

csproj 파일 편집에 대한 사용 사례가 궁금합니다. 내 경험에 따르면 nuget이 엉망이거나 힌트 경로가 손상되었을 때 csproj 파일만 편집해야 했습니다. 빌드 프로세스에 새 단계를 추가하기 위해 저는 항상 CI 시스템에서 실행되는 더 높은 수준의 build.proj 파일을 사용했습니다. 저는 CI 설정에서 .sln 파일을 사용하지 않습니다.

사람들이 Visual Studio에서 디버그할 때 실행하려는 BeforeBuild 및 AfterBuild 단계를 추가하기 위해 csproj 파일을 편집하려는 주요 목적입니까?

@Mike-EEE 어쩌면; 나는 대부분 매우 많은 수의 파일(예: Expression Blend, Visual Studio XAML Designer 등)이 있는 프로젝트를 처리할 때 와일드카드 선택을 위해 교체한 시점까지 매우 고통스러웠던 것으로 기억합니다. VS가 수행하는 제대로 작업하는 방법을 모릅니다. 즉, 파일을 추가할 때마다 프로젝트를 다시 로드해야 합니다(또는 빌드 시 "이 파일이 이미 추가되었습니다" 오류가 발생함).

이 "기능"에 대해 실제로 무엇을 좋아합니까(프로젝트 간에 파일을 공유하지 않고 분명히 유용하지만 모든 파일이 개별적으로 나열될 때만 VS가 제대로 작동함)?

이 "기능"에 대해 실제로 무엇을 좋아합니까(프로젝트 간에 파일을 공유하지 않고 분명히 유용하지만 모든 파일이 개별적으로 나열될 때만 VS가 제대로 작동함)?

분명히 이것은 나쁜 습관이지만 리팩토링을 수행할 때 프로젝트에서 파일을 제거할 수 있는 것이 좋습니다. 또는 역사적 관점에서도. 나중에 원할 수도 있는 작업을 하고 있다는 것을 알고 있으면 디스크에 보관하지만 프로젝트에서는 제거합니다. 물론 이것은 repo/source control을 더럽히지만(나쁜 습관 참조), 저는 그런 종류의 제어를 즐깁니다. 이제 내가 그 파일을 원할 때 repo의 히스토리(이 삭제된 파일의 히스토리를 찾는 방법??? 너무 많은 작업이 필요합니다!)를 가지고 여기저기 다닐 필요가 없기 때문에 단순히 "모든 파일을 표시"합니다. 내 솔루션에 다시 추가하십시오. 인스턴트 히스토리. :웃다:

csproj 파일 편집 사용 사례가 궁금합니다.

.csproj의 경우(이 중 하나는 내가 수행했으며 대다수는 여러 번 수행했습니다)

• 데스크톱 애플리케이션에서 UWP 유형을 참조해야 하는 경우
• NuGet으로 VS 문제를 수정해야 하는 경우(특히 a.targets 파일 및 .proj/.props 포함 추가 관련)
• 생성된 출력의 레이아웃을 변경해야 하는 경우
• 프로젝트를 리팩토링하고 어셈블리 이름을 바꾸는 경우
• 많은 파일에 영향을 미치는 대규모 리팩토링을 수행하는 경우
• 여러 사람이 동일한 프로젝트에서 작업 중이고 와일드카드를 사용하지 않아 병합 충돌이 발생한 경우
• 빌드가 갑자기 작동하지 않는 이유를 이해해야 하는 경우(편집: 지정했어야 함 - 이것은 "읽을 수 있고 '자체 포함'이 필요한 이유"에 가깝습니다.)
• 성가신 종속성으로 인해 어셈블리 버전 충돌을 디버그해야 하는 경우
• "링크된"(공유) 파일을 추가하려는 경우

project.json의 경우

• 손으로 처음부터 파일 만들기(매우 중요)
• NuGet 패키지 추가/제거
• 대상 프레임워크 변경
• 출력 패키지 버전 변경

@shederman 나는 당신이 좌절한다는 것을 알고 있지만 당신이 다음과 같이 응답할 때

진짜? 사람들이 아직도 그렇게 해요? 나는 AssemblyInfo.cs를 위해 그것을 했었다는 것을 의미합니다. 그리고 암흑 시대로 돌아갑니다.

톤을 설정하고 있습니다. 대면 대화를 하는 것은 괜찮지만 이런 환경에서는 대화를 양극화하고 중요한 요점에 집중하기 어렵게 만드는 모든 감정 기반 논평의 문을 여는 경향이 있습니다. 나는 이러한 토론에서 감정을 억제하는 것이 어렵다는 것을 알고 있습니다(내 혀는 물린 자국으로 가득 차 있습니다 ;-)). 그러나 우리는 토론을 유용하게 유지하기 위해 정말로 노력해야 합니다.

@Mike-EEE Exclude 속성/패턴을 사용하여 (모든 단일 파일을 나열하지 않고) 동일한 작업을 수행할 수 없습니까? 기록을 위해 나는 종종 같은 일을 합니다. 커밋/롤백 주기를 수행할 필요 없이 무언가를 빠르게 제거하고 싶을 때 매우 편리합니다.

기록을 위해, 나는 실제로 Roslyn을 사용하고 프로젝트 파일이 직렬화된 AST가 되도록 하는 @Mike-EEE의 제안을 좋아합니다. 그러나 메모장만 사용하여 똑같이 쉽게 작업할 수 있는 경우에만 가능합니다. (예, 메모장을 의미합니다. notepad++ 또는 더 발전된 것이 아닙니다. 사람이 편집할 수 있는 파일 형식의 유용성에 대한 "연기 테스트"입니다.)

@CodingGorilla 나는 그것에 열려 있습니다. 나는 도구가 이것을 도와주는 것을 보고 싶다(어떻게 하는지 알아내기보다 나를 위해 패턴을 정의하라 -- 내가 DOS로 다시 작업하는 것처럼 느껴진다면, 모두가 진다!!). 지금과 똑같은 경험을 할 수 있어야 합니다.

따라서 기본적으로 "옵트인"이 아닌 "옵트아웃" 모델을 살펴봅니다.

언로드하지 않고 프로젝트 파일을 편집하고 싶은 분들을 위해.... https://twitter.com/migueldeicaza/status/730978470734401536

언로드하지 않고 프로젝트 파일을 편집하고 싶은 분들을 위해....

@darrelmiller 내가 여기서 무엇을보고 있습니까 ... 대신 Xamarin Studio를 사용하도록 제안합니까? 예, 비즈니스/워크플로/경험을 언로딩/로딩하는 것은 최악입니다! 2003년부터 있었던 일이죠.

나는 최종 파일이 형식이 무엇이든 표준 텍스트 편집기(예: 메모장)로 쉽게 편집하고 읽을 수 있어야 한다는 개념을 두 번째로 생각합니다.

또한 더 나은 도구가 현재 csproj 뒤에 있는 많은 문제점을 제거할 것이라고 생각합니다. VS는 최고의 예가 아니며 VS가 제공하는 경험은 많은 사람들이 MSBuild 프로젝트 시스템에 대해 실제로 싫어하는 것이라고 생각합니다.

@Mike-EEE Miguel의 의견에 대한 답변은 새 프로젝트 시스템에서 일하는 David Kean의 답변이었습니다. 팀은 VS도 이 작업을 수행할 수 있어야 한다는 것을 알고 있습니다.

@Mike-EEE 제 생각에는 그들이 무엇을 생각해내든 처리할 수 있다는 것입니다. 은 MSBuild 프로젝트 시스템 (@shederman 말한대로하지 않으면, 그냥 XML 될 _can't_) 아무것도 단지 할 수있는 강력한 충분하다. 어떤 사람들은 "내 방식이 아니면 실패야"라고 말하고 다른 사람이 말했듯이(죄송합니다. 이 스레드는 YUUUUUUGE입니다!) "나는 열린 마음을 유지하려고 노력합니다..." 그리고 그냥 적응.

게다가, 당신은 새로운 것을 배울 수 있고, 그것은 항상 좋은 일입니다. :웃음이 넘치는:

@neoKushan 저는 msbuild 스크립트를 처음부터 작성

@CodingGorilla 사실 제 주력은 MSBuild입니다. XML이 문제이지만 MSBuild만큼 나쁘지는 않습니다.

xproj와 나란히 project.json 지원을 계속 실행하기 위해 직접 작업을 제안했습니다. 가장 신경쓰는 사람이 일을 하는 것 맞죠?

그리고 이것이 사실 핵심입니다. 팀에서 내가 이 기여를 할 수 있도록 허용합니까? 그렇지 않다면 왜 안됩니까? 그것은 결국 OSS, 그렇지 않습니까?

그런 다음 MSBuild가 마음에 들고 강력한 성능을 원한다면 xproj를 사용합니다.

그리고 ASP.NET Core용으로 구축된 도구가 마음에 들면 계속 사용하십시오.

그들은 동일한 기본 컴파일러를 사용합니다.

그리고 어떤 경우에도 그렇게 많은 작업을 해서는 안 됩니다. 내가 해야 할 일은 더 이상 사용되지 않는 코드를 다른 명령으로 리팩터링하는 것입니다.

이상적으로는 "dotnet build"를 사용하고 디렉토리를 보고 어떤 파일이 있는지에 따라 사용할 디렉토리를 결정할 수 있기를 바랍니다. 그러나 빌드 또는 새 명령의 옵션 플래그는 괜찮을 것입니다.

@sandorfr _ 전체_ 빌드 프로세스를 정의하는 본격적인 MSBuild 파일을 작성하는 데 동의합니다. 구조.

다시 말해서 MSBuild는 거대하고 강력한 시스템이며 많은 복잡성을 수반하지만 사용하는 경우에만 가능합니다. VS는 기본적으로 필요하지 않은 많은 쓰레기를 던졌고 xproj를 보면 MSBuild에도 실제로 필요하지 않은 것이 분명합니다. dot 팀이 csproj에 필요한 것을 최소화하는 데 초점을 맞추면 대부분의 사람들에게 상대적으로 최소화되고 깨끗해야 합니다. "병합 지옥"을 겪어야 하는 유일한 사람들은 그 추가 기능을 원하는 사람들이 될 것입니다(이 변경을 주도하는 사람들은 머리로 생각합니다).

CAKE나 TFS Team Services 등 원하는 빌드 시스템을 사용하는 데 방해가 되는 것은 없습니다.

다시 말하지만, 이것은 팀이 "올바른" 일을 하도록 규정하고 있습니다.

VS는 최고의 예가 아니며 VS가 제공하는 경험은 많은 사람들이 MSBuild 프로젝트 시스템에 대해 실제로 싫어하는 것이라고 생각합니다.

@neoKushan TFS Build와 Xaml에 대해 이렇게 생각합니다. Xaml은 엄청나게 훌륭하지만(그리고 여전히 MSBuild "스크립트"의 가능한 형식으로 사용되는 것을 보고 싶습니다), TFS Build에서 Xaml을 사용하면 이름이 잘못되었습니다.

이 github 문제를 채팅 창으로 사용하는 것이 생산적이지 않다고 생각합니다. MS의 누군가가 답장을 보낼 경우를 대비하여 이 스레드에 대한 이메일 알림을 유지하고 싶었지만 메일 양이 너무 많아졌습니다.

MSBuild 프로젝트 시스템은 거의 모든 작업을 수행할 수 있을 만큼 강력합니다.

그것은 문제의 일부이며 csproj 파일을 읽을 때 무슨 일이 일어나고 있는지 이해하기 어렵게 만드는 것은 프로젝트 파일 형식에 적합하지 않은 선택이 됩니다(빌드 정의 파일 형식과 혼동하지 마십시오).

(편집: 추가됨)

CAKE나 TFS Team Services 등 원하는 빌드 시스템을 사용하는 데 방해가 되는 것은 없습니다.

불행히도 VS가 통신할 수 있기를 원하는 경우(그리고 관리 코드와 네이티브 코드가 모두 있고 디버그하려는 경우 제대로 작동하기를 원하는 경우) 빌드 시스템을 MSBuild에 집어넣으려는 시도가 막혔습니다. 그렇기 때문에 실제로 빌드 파일에서 프로젝트 파일을 분리하는 것이 _기능_이라고 생각합니다.

ㅎㅎ 예 드리면 요!) 대화 중에 문제가

수요일에 있을 다음 커뮤니티 스탠드업에 뛰어들 것을 제안해도 될까요? 나는 그것이 대부분 하루나 이틀 전에 RC2의 출시에 대해 이야기할 것이라고 생각하지만(하나는 희망할 수 있습니다!) 우리 모두에게 필요한 질문을 핑하고 라이브 청중과 솔직한 토론을 할 수 있는 기회를 줄 것입니다. 그것은 실제로 답을 줄 수 있습니다.

수요일에 있을 다음 커뮤니티 스탠드업에 뛰어들 것을 제안해도 될까요?

@shederman이 나타내는 경우에만. 나는 그가 실시간으로 개발자와 그들의 아이디어를 부수는 것을 보고 싶습니다. WWE PPV 이벤트처럼!

[projectName].csproj에 비해 project.json의 장점은 형식에 관한 것이 아니라고 생각합니다. 그것은 모든 오래된 것들과 역호환될 필요가 없다는 것입니다. 아주 간단하게 할 수 있었습니다. Damian Edward와 팀이 지정된 모든 목표를 달성할 수 있다고 가정하면 XML 대 JSON 대 YML 대... 나에게 중요한 것은 단순하고 Linux에서 Windows용 항목을 볼 필요가 없다는 것입니다. .

@glennsills MSBuild 프로젝트 파일에는 _windows_에만 해당하는 내용이 별로 없다고 생각합니다. MS Build 자체 또는 신경 쓰지 않는 다른 프로젝트 유형에만 해당된다는 점입니다. MSBuild를 만족스럽게 유지하기 위해 많은 빈 요소가 필요하지 않습니다. 나는 팀이 가능한 한 많은 것을 줄일 계획을 하고 있기를 바라고 있지만 우리는 보게 될 것입니다.

@Mike-EEE @shederman이 나타내는 경우에만. 나는 그가 실시간으로 개발자와 그들의 아이디어를 부수는 것을 보고 싶습니다. WWE PPV 이벤트처럼!

나는 그것을 만들기 위해 노력할 것입니다. 나는 내가 입력하는 것보다 느리게 말하는 것을 경고합니다. 그러니 너무 기대하지 마세요 😄

따라서 https://github.com/dotnet/roslyn-project-system/issues/40 을 감안할 때 웜 캔을 열 위험이 있는 경우(기본적으로 ) 프로젝트에 필요한 기본적인 사항은 무엇입니까?

(이걸 "나는 XML이 싫어!" 조롱으로 바꾸지 마세요.)

"나는 MSBuild tirade가 싫어"는 어떻습니까?

@shederman

MSBuild가 JSON 파일을 허용하도록 하면 어떻게 될까요? :웃음: (거절할 수 없었다)

@shederman 어떤 종류의 농담도 진지하게 받아들이기는 어려우며 Microsoft가 이 _토론_을 진지하게 받아들이는 것이 훨씬 낫습니다.

이것이 5년 안에 진행되는 방식으로 당신은 Swift, Java(!!), Node.JS 또는 Elixir를 프로그래밍하게 될 것입니다. ;)

요즘 .NET 프로젝트/솔루션/무엇이든 간에 두 가지 엉터리 기술이 있습니다. Nuget 및 .csproj 파일. Git(예: GitFlow)을 사용하여 5개 이상의 팀에서 작업하는 경우 완전히 악몽입니다. ".csproj에 파일을 포함하는 것을 잊었다면 이런 쓰레기"는 점점 귀찮아지고 있습니다. 도구는 이 문제를 해결해야 하며 도구는 충돌하는 DLL 버전이 있다는 경고도 표시해야 하며 도구는 병합에 도움이 될 것입니다.

똥을 잘라. Project.json은 처음에는 멋져 보였는데 나중에 정치와 감정이 생겼습니다.

MS 팀은 RC가 아니라 베타라고 불러야 합니다.
MS 팀이 모든 것을 다시 망가뜨린 RTM2를 출하하기로 결정했다면 RTM이 언제 출시될지조차 믿을 수 없을 것 같습니다.
저는 비관론자가 아니지만 .NET Core를 둘러싼 이러한 움직임은 매우 이상합니다.

@neoKushan 조롱 하지 않고

나는 토론에 참여하기 위해 내가 맡은 직위를 포기해야 하는 토론 조건에 동의하지 않습니다. 나는 project.json을 지지하는 사람들이 기본적으로 MS가 결정한 것을 약간의 수정 또는 두 가지를 포함하여 정확히 받아들여야 한다는 말을 계속 듣고 있습니다.

나는 그것이 어떻게 이어지는지 모르겠다. 나는 단순히 약속되고 약속된 빌드 시스템을 원합니다. MS가 그것을 유지하고 계속할 의향이 없다면 나는 제안했습니다.

문제가 어디에 있습니까? 나는 MS에 그들의 계획을 철회하라고 요구하는 것이 아니라 작업을 추가하도록 요구하는 것이 아니다. 나는 그들이 일방적으로 어긴 약속을 내가 이행할 수 있도록 해달라고 요청할 뿐입니다.

거의 혁명적인 요청이 아닙니다.

내 2센트:

저는 이 변화에 대해 두 부류의 사람들이 논의하고 있다고 믿습니다.

VS & .NET을 사용하여 다양한 종류의 프로젝트를 빌드하고 오랫동안 해당 프로젝트를 지원해야 하는 개발자
그런 부담이 없고 새롭고 깨끗하고 멋진 크로스 플랫폼 ASP.NET Core 프레임워크를 원하는 개발자
개인적으로 저는 첫 번째 범주에 속하므로 새로운 ASP.NET Core가 가능한 다른 VS 프로젝트 유형과 호환되기를 원하며 "이전" csproj/msbuild 솔루션으로 이동하는 것이 저에게 유리합니다(+my 팀 및 아마도 많은 다른 개발자). 이렇게 하면 전환이 훨씬 부드럽고 명확해집니다. 아마도 두 번째 범주의 사람들은 나와 동의하지 않을 것입니다(또는 그냥 상관하지 않습니다).

지금 내가 볼 수 있는 유일한 주요 문제는 NuGet 패키지가 정의되고 참조되는 방식입니다. packages.config 및 csproj 파일을 모두 유지해야 하는 것은 고통 스러운 일입니다 ( @cwe1ss 와 같이 수행되어야 합니다. 이 주제 BTW에서 가장 건설적인 의견 중 하나였습니다...

XML/JSON의 성스러운 전쟁에 관해서는... IMHO, XML은 JSON보다 손 편집에 더 좋습니다. XML은 주석을 지원하며 볼 때 더 많은 컨텍스트 정보를 가지고 있습니다. JSON은 구성 파일이 아닌 데이터에 더 좋습니다. 병합은 두 형식 모두에 똑같이 좋고 나쁨이 있으며 전적으로 내용에 따라 다릅니다. 프로젝트 참조가 현재 csproj 파일과 분리된다면 병합도 훨씬 쉬워질 것입니다...

나는 또한 카테고리 1에 해당합니다(여러 프로젝트/유형을 개발했으며 오랫동안 지원해야 하는 개발자). 제 고용주는 csproj 형식으로 수백만 줄의 코드 가치가 있는 프로젝트를 보유하고 있으며 ASP.NET RC1 및 RC2 개발 분기에서 실행되는 최신 제품도 있습니다. 공정한 경고, 우리는 또한 사용자 지정 MSBuild 작업 어셈블리 등과 함께 MSBuild를 고급 사용합니다.

둘 사이의 실제 통합은 여러 가지 이유로 엉망이 되었습니다. 특히 랩 생성, 래핑된 종속성이 변경될 때 랩 재생성, 소스 제어에서 이것이 어떻게 보이는지(우리는 내부적으로 Git와 TFVC를 모두 지원하고 사용합니다. ), VS의 디자인 타임에 프로젝트가 솔루션에서 서로를 참조하는 방법과 빌드/배포 시 가져오는 방법. 시스템이 _맞는_ 느낌을 받은 적이 없습니다. 각각 .cs 파일만 있는 두 개의 개별 프로젝트를 가질 수 있다는 것이 이해가 되지 않았지만 이 두 가지 프로젝트 유형은 잘 섞일 수 없었습니다.

그런 의미에서 지금까지 작성된 애플리케이션과 코드를 지원하는 것이 왜 중요한지 충분히 이해하고 있습니다. 다른 모든 변경 사항이 진행 중인 상태에서 이러한 유형의 변경 사항을 도입할 적절한 시기가 아니라고 생각합니다. 한 번에 너무 많은 일이 일어나고 있는 것 같습니다.

아마도 미래의 가능한 해결책은 우리가 다른 사람들에게서 힌트를 얻어 LTS 릴리스 또는 이와 유사한 것에 대해 생각하는 것입니까? 이것은 훨씬 더 큰 대화이지만 프로젝트 시스템 교체와 같은 일부 기능이 도입되어 사람들이 이를 흡수할 시간을 줄 수 있습니다.

또 다른 가능한 솔루션은 더 플러그인 가능한 빌드 시스템이지만 이것은 장기적인 솔루션이며 현재 대화에 도움이 되지 않습니다. 기본적으로/또는/3rd 파티를 허용합니다.

프로젝트 종속성에 관해서는 이미 수많은 packages.config 파일이 떠돌아다니고 있으므로 packages.json/nuget.json으로 포팅하는 것은 큰 문제가 아닙니다. 종속성을 위한 저장소 형식보다 일관성 없는 어셈블리 바인딩 리디렉션에 더 많은 문제가 있습니다.

@shederman 귀하는 MSBuild에 대한 귀하의 의견을 매우 잘 알려 주셨지만 명확히 하지 않은 것은 MSBuild의 실제 _문제_입니다. 이것이 제가 매우 실망스럽게 생각하는 것입니다. 저는 진정으로 해결할 수 있다고 느끼기 때문에 MSBuild에서 발생한 실제 문제를 알고 싶습니다.

자, 당신은 XML을 좋아하지 않습니다. 알겠습니다. JSON과 XML 간의 논쟁은 새로운 것이 아니며 우리는 여기서 절대 해결하지 않을 것입니다. 그러나 그것이 MSBuild를 그토록 싫어하는 _유일한_ 이유가 될 수 없습니다. 실제로 겪은 문제는 무엇입니까?

제가 질문하는 이유와 계속해서 질문하는 이유는 이것이 바로 Microsoft가 해결하고자 하는 정확한 문제이고 문제가 무엇인지 명확히 하지 않으면 해결되지 않기 때문입니다. 우리가 MSBuild에 대해 싫어했던 많은 부분이 이미 수정되고 있음을 알고 있습니다.

1. 프로젝트의 모든 파일 목록 - 제거/수정 중(실제로는 VS 문제)
2. 지옥 병합 - 대부분의 경우 1로 고정
3. 불필요한 복잡성/상세함 - https://github.com/dotnet/roslyn-project-system/issues/40 에서 해결되기를
4. 쉽게 손으로 편집할 수 없음 - 다시 1.과 3으로 수정되었습니다.

뭐가 남았어? 실제로 MSBuild의 문제에 대해 논의하고 모든 것을 분기하거나 수만 개의 복잡하고 비즈니스 크리티컬한 프로젝트를 포기하지 않는 솔루션이 있는지 알아보겠습니다. 그것이 내가 _ 원하는_ 토론입니다.

이것에 대한 내 2 센트 :
도대체 왜 이런 변화가 지금 일어나고 있는 것일까요? 로드맵에 따르면 최종 릴리스까지 1개월 밖에 남지 않았습니다.
처음에 이거보고 농담인줄 알았습니다. 그러나 슬프게도 그렇지 않습니다.
이것은 커뮤니티의 얼굴에 큰 타격입니다. 그러한 결정은 채택되기 전에 긴 대화 스레드가 있어야 합니다.

@laskoviymishka (및 기타 몇 가지)는 @neoKushan이 여기에서 언급했습니다. 이 변경은 현재 발생하지

@laskoviymishka RTM 이전 에는 변경 사항

RTM은 오늘날 사용되는 것처럼 여전히 project.json을 사용합니다(RC2에 대한 스키마가 변경되고 있다고 생각하지만 관계없이 발생했습니다). "새로운" csproj로의 이동은 RTM 이후에 이루어질 예정이며 점진적으로 이루어질 것입니다. RTM에서 아무 것도 변경되지 않습니다(xproj의 이름이 변경되는 것을 제외하고).

@CodingGorilla RC2로 한달만에 1.0버전으로 옮겨갑니다. 현실 세계에서 이것은 모든 개발을 중단하고 안정화에 집중한다는 것을 의미합니다. 이 변경은 실제로 아무것도 안정화되지 않습니다.

@neoKushan RTM 이후에 발생한다면 왜 asc 커뮤니티가 그것에 대해 이야기하지 않습니까? github에서 토론 스레드를 시작하세요. 논쟁 등을 지적하기 시작합니다. 왜 개발자와 대화하지 않고 강제해야합니까?

IMHO project.json 에서 project.csproj 로의 이 이동은 채택되기 전에 논의되어야 합니다. 지금 당장은 좋은 결정이 아닙니다. 적어도 저에게는요.

@laskoviymishka 커뮤니티 스탠드업 노트 : (강조 추가)

RC2/Preview 1에서는 변경 사항이 없습니다 . RTM/미리 보기 2에서 _ 유일한 변경 사항은 xproj 파일의 이름이 Visual Studio에서 csproj_로 변경되는지 확인할 수 있습니다. 그 시점부터 project.json은 csproj 옆에 있을 것입니다. 그런 다음 팀은 project.json에서 csproj 파일로 기능 마이그레이션을 시작합니다. project.json 파일이 남아 있고 NuGet에 대한 모든 패키지 참조가 포함되어 있고 이름이 nuget.json으로 변경될 수 있습니다. 팀은 project.json 모델의 주요 이점 중 하나인 프로젝트 파일의 모든 파일을 나열할 필요가 없음을 보여주는 몇 가지 작업을 이미 테스트했습니다.

따라서 이것은 대부분 도구 변경이며 매우 단기적으로(즉, RTM+) project.json 파일이 여전히 존재하고 지금과 동일하게 작동합니다. 이것에 대한 좋은 소식은 우리가 상황을 정중하고 건설적으로 유지할 수만 있다면 커뮤니티가 이것에 영향을 미칠 시간이 아직 있다는 것입니다.

@laskoviymishka 글쎄요, 저는 Microsoft를 대변하고 싶지 않습니다. 그들의 궁극적인 계획이 무엇인지는 모르지만 그들도 정말 알고 있다고 생각하지 않습니다. 많은 사람들이 깔개가 아래에서 뽑혔고 Microsoft가 이것을 결정하기 전에 우리와 상의했어야 한다고 말하지만 실제로는 아직 아무 것도 바뀌지 않았으며 몇 달 동안 아무 것도 바뀌지 않을 것입니다. 점진적인 변화와 툴링이 어느 정도 도움이 되기를 바랍니다.

Microsoft 또는 적어도 asp.net 팀은 이에 대한 피드백을 요청했으며 의심할 여지 없이 이 스레드를 읽고 있지만 아마도 우리가 누락된 것은 "토론을 하고 싶다면, _여기_". 그러나 나는 전환이 사람들이 생각하는 것보다 훨씬 더 일찍이라고 생각합니다. 지금까지 그들이 확실히 알고 있는 것은 xproj의 이름을 csproj로 바꾸는 것뿐입니다.

나는 개인적으로 그것이 약간의 엉터리 변화라고 생각하지만, 나는 그들이 그것을 하는 이유를 이해합니다. 더 나은 답변이 없으므로 제 생각은 csproj 스타일 프로젝트를 처리해야 하는 경우 이 기간을 활용하여 우리가 할 수 있는 최고의 _종류_의 csproj를 제시할 수 있다는 것입니다. project.json은 아니지만 두 세계의 장점을 모두 얻을 수 있다면 장기적으로 우리 모두가 더 나아질 것입니다. 모두가 동의하는 것은 아니며 괜찮습니다.

@neoKushan 이것은 좋은 지적입니다. MS가 그것을 보았으면 합니다. 핵심 팀의 피드백을 보면 정말 좋을 것입니다.

@CodingGorilla 글쎄요 최종 버전에는 여전히 변경 사항이 있습니다. 이러한 변화의 주요 문제는 핵심 팀이 쓸데없이 많은 시간을 보내야 한다는 것입니다. 이것은 아마도 관리자 문제일 것입니다. 하나의 작동하는 것을 아마도 작동하는 다른 것으로 변경하기 위해 많은 개발 시간을 보내도록 합시다. 진짜 좋은 이유 없이.

@neoKushan

실제로 MSBuild의 문제에 대해 논의해 보겠습니다.

나는 의견을 형성하기에 충분한 정보를 찾는 데 어려움을 겪고 있습니다. project.json 및 .csproj 파일 삭제로 인해 활성화되는 _seem_ 많은 변경 사항이 있었습니다. 이러한 개선 사항이 사라지기를 원하지 않지만 "새롭고 개선된" msbuild로 이동하면 내 워크플로가 어떻게 바뀔지 모르겠습니다.

• 현재 우리는 모든 빌드 작업에 꿀꺽 꿀꺽 꿀꺽 꿀꺽 마시고 있습니다. 그게 바뀌나요? 내 gulpfile은 dnu 또는 dotnet-cli로 실행하여 실제로 .cs 파일 모음을 어셈블리로 전환합니다. 나는 그것을 지킬 수 있다, 그렇지?
• VS는 계속해서 작업 탐색기를 지원하고 내 꿀꺽 꿀꺽 꿀꺽 꿀꺽 꿀꺽 마시는 작업에 대한 afterbuild/prebuild/etc 트리거를 지원하므로 VS 사용자가 F5를 실행할 수 있습니까? 아니면 모든 꿀꺽 꿀꺽 꿀꺽 마시기 작업에 래퍼 msbuild 작업이 정의되어 있어야 함을 의미하는 msbuild 킥오프 gulp가 있어야 합니까? (아야)
• msbuild는 별도 설치인가요? dotnet cli 또는 런타임과 별도로 버전이 관리되나요? 이것은 내 CI 빌드 서버에서 사용 가능한 최소값을 어떻게 변경합니까? 개발 환경에 최소 설치해야 하나요?
• 텍스트 편집기를 사용하여 nuget 종속성 또는 .cs 파일을 추가하는 경우 이제 추가해야 하는 추가 단계(있는 경우)는 무엇입니까?
• VS 사용자가 nuget 종속성과 .cs 파일을 추가한 변경 집합을 검토할 때 csproj 변경 사항이 간단하고 사람이 읽을 수 있습니까? (비교를 위해 .net 4.6 및 VS2015에서 csproj에 대한 변경 사항은 사람이 쉽게 읽을 수 _없습니다_)

이 변경을 수행하는 사람들이 고려해야 할 시나리오(나처럼!)에 도달하고 이에 대한 논의가 이루어지기를 바랍니다. "아무리 논의도 없이 치즈를 옮기고 있다"는 말이 .net core의 SOP가 되지 않기를 바랍니다.

그 도구는 당신을 위해 어느 정도 할 것입니다

그리고 그것이 주요 요점입니다. 필요한 도구는 적을수록 좋습니다. 나는 현재 상류에서 수영하고 있다는 느낌 없이 텍스트 편집기와 명령줄을 사용할 수 있습니다. 나는 그것이 변하지 않기를 바랍니다. .net46에서 VS를 사용하지 않으려면 거대하고 장황한 xml 파일을 편집해야 하며 동일한 프로젝트에서 VS 사용자와 비 VS 사용자를 혼합하는 것은 악몽입니다.

"RTM에 오신 것을 환영합니다. 이것은 귀하의 프로젝트 파일이 가까운 미래에 변경될 것임을 상기시켜줍니다. 우리는 이미 이것을 결정했습니다. 이유, 그러나 대부분 우리가 곱슬곱슬한 것보다 각도를 더 좋아하기 때문입니다. 오, 빌드 도구, 예, 빌드 우리는 최종 스키마를 결정하지 않았지만(하지만 이것은 xml 기반일 것입니다, 위 참조), 파일 이름은 확실히 .csproj로 끝나서 레거시 도구에 최대한의 혼란을 줄 것입니다. Agile.(ps 당신이 도구 벤더라면::o)"

@Oceanswave 소프트웨어 개발을 관리 하지 말아야 하는 방법의 아름다운 예

@neoKushan

하지만 명확하지 않은 것은 MSBuild의 실제 문제입니다.

이 똑같은 질문에 대한 이전 답변을 읽어야 할까요? https://github.com/aspnet/Home/issues/1433#issuecomment -218993559

나는 MSBuild 파일을 수정, 개발 및 디버깅하는 데 수백 시간을 낭비했습니다. 저는 Team Builds를 수행했고 거대한 빌드 및 배포 파이프라인을 수행했습니다. 나는 도대체 왜 이상한 상황이 발생하는지 알아내려고 장황한 로그를 조사하는 데 몇 시간을 보냈습니다. 나는 이 기술에 대해 수년 동안 회비를 지불했으며 개인적으로 이 기술과 관련이 없기를 바랍니다. project.json은 신선한 공기의 숨결이었습니다. MSBuild로 수년간 고생한 끝에 마침내 MS가 변경 사항이 필요하고 적용되고 있다는 인상을 받았습니다.

그리고 영광이었습니다. 간단한 빌드, 간단한 편집, 빠르고 이해하기 쉬운 출력. MSBuild 스크립트에 욕설을 퍼붓던 그 시간의 기억을 씻어냈습니다. 우리가 마침내 과거의 시체에서 분리되는 것처럼 느껴졌습니다. 그러나 아니요, 이제 우리는 그런 일이 일어나지 않을 것이라는 약속에도 불구하고 우리가 그토록 증오하는 시체에 다시 족쇄를 채웠습니다.

토론 없이, 검토 없이, 어떤 종류의 참여도 없이.

일부 분기에서 MSBuild가 얼마나 미움을 받는지조차 알지 못한다 는 것을 증명 합니다.

MSBuild에 빌드 시스템으로서 중요한 기능적 제한이 있다고 생각하지 않습니다. 그것은 엄청나게 강력하고 어떤 의미에서 그것이 주요 약점입니다. 너무 많은 시나리오를 처리해야 하기 때문에 복잡합니다. 단순한 "복원, 빌드, 테스트, 포장" 시나리오의 경우 이는 정말 엄청난 일입니다.

우리 팀에서는 C# 개발자를 상대하고 있습니다. 그들은 압박감, 촉박한 마감일, 높은 스트레스를 받고 있습니다. 그들은 방해가 되거나 지연되는 것을 원하지 않습니다.

MSBuild는 다른 사고 방식, 즉 명령형 코딩과의 주요 컨텍스트 전환입니다. 개발자는 단순히 그것을 싫어합니다. 그들은 그것이 둔하고 직관적이지 않다고 생각합니다. 그들은 그것을 피합니다. 요즘 내가 감독하는 모든 팀에서 생성되는 유일한 MSBuild는 도구 생성입니다.

저는 지난 5년 동안 MSBuild에 열광하거나 MSBuild 작업을 즐기는 C# 개발자를 한 명도 만나지 못했습니다. Github에서 지난 며칠간 댓글을 살펴보세요. MSBuild가 싫은 것은 결코 혼자가 아닙니다. MSBuild는 10년 동안 .NET 개발자의 목을 조르는 맷돌로 인식되어 왔습니다. 그러한 인식의 대부분은 불공정합니까? 네, 아마도.

하지만 어쩌죠? 소프트웨어 엔지니어링 책임자인 제 관점에서는 원하는 결과를 생성하는 도구가 필요합니다. MSBuild에서는 이러한 결과를 얻지 못합니다. 나는 project.json + gulp.js + powershell에서 그 결과를 얻습니다.

_Can_ MSBuild가 이러한 결과를 얻을 수 있습니까? 물론 가능하지만 개발자가 이러한 결과를 얻기 위해 MSBuild에서 작업을 수행하는 경우에만 가능합니다. 그리고 그들은 단지하지 않습니다. 우리가 그들에게 강요 하면 그들은 그것을 하고 나서 그것을 유지하지 않습니다.

개발자가 싫어하는 도구에 의존할 수 없습니다. 그것이 단순한 현실입니다. 그리고 내가 스스로 그것을 사용하지 않는 것을 얼마나 좋아했는지 생각하면 나는 실제로 그들을 비난 할 수 없습니다.

실제로 MSBuild의 문제에 대해 논의하고 모든 것을 분기하거나 수만 개의 복잡하고 비즈니스 크리티컬한 프로젝트를 포기하지 않는 솔루션이 있는지 알아보겠습니다.

자, 무엇을 할 수 있습니까?

약 5년 전, 지금 논의되고 있는 변화 중 일부가 도입되었다면 인식이 더 좋았을 것이라고 생각합니다. 그러나 그들은 그렇지 않았고 지금은 수많은 개발자들 사이에서 부정적인 사고방식을 갖고 있습니다. 내가 기억하기로는 이러한 동일한 문제 중 일부가 당시 MSBuild에서 제기되었지만 거부되었습니다. 현재 문제가 제기되고 거부되는 것처럼.

어떻게 복구할 수 있는지 모르겠습니다. 실제로는 그렇지 않습니다. 나는 몇 가지 주요 깨끗한 휴식이 있어야한다고 생각합니다. 거기에 있는 것을 부수지 않고 어떻게 만드나요? 너무 적습니다. 너무 늦었습니다. 따라서 MSBuild가 앞으로 나아갈 길은 저를 위한 것이 아니라 저를 위해 일하는 개발자, 제 파트너 또는 _그들_을 위해 일하는 팀이 아닌, 우리가 컨설팅하는 클라이언트가 아닙니다. 이러한 청중 중 누구도 MSBuild를 사용하고 싶어하지 않으며, 필요하기 때문에 도구에서 사용하며 반복적으로 맹세합니다. 분명히 일반적으로 병합 시간 주변에 있습니다.

그래서 _지금_ 더 나은 병합을 원하십니까? 10년. 도구 후 많은 부분에서 욕입니까?

기본적으로 2010년 이후 개발자들이 실제로 사용하고 있는 90년대 후반 Build Masters용으로 설계된 도구를 사용하고 있습니다. 논리에 대한 추론을 사용하는 도구는 개발자가 명령형 작업 및 명령형 도구에 사용하는 데 사용합니다. 속성 집합이 단순한 할당 연산자라고 생각하고 왜 PropertyGroup 하고 싶어하는지 이해하지 못하는 개발자가 사용하는 속성을 설정하는 매우 유연하지만 명확하지 않은 방법을 사용하는 도구입니다. 신경쓰지 마세요.

그것이 제가 하고 싶은 토론입니다.

알겠습니다. 알겠습니다. 내가 하고 싶은 토론은 다르지만, "당신이 우리에게 약속한 것을 우리에게 주거나, 아니면 우리가 당신의 오래된 새로운 아이디어를 좋아하지 않기 때문에 우리가 약속한 대로 하기 때문에"입니다.

슬픈 것을 공유 할 수 있습니까? 나와 비슷한 경험을 가진 비즈니스 파트너(사실상) 중에서 저는 당시에 MSBuild에 가장 찬성했습니다. 실제로 _사용_했습니다. 나는 그것을 배웠다. 큰 파이프라인을 구축했습니다. 그러나 그것은 5년 전의 일이며 그 이후로 많은 물이 다리 아래로 흘러갔습니다.

Man 나는 @shederman 의 코멘트와 역사가 나와 매우 유사하기 때문에 읽으

생각해 보세요: Visual Studio 확장(.vsix). 아무도 그것들을 만지고 싶어하지 않습니다. 왜냐하면 그것들이 오늘날 거기에 있는 다른 모든 것들과 얼마나 레거시/오래됨/다르게 비교되어 있기 때문입니다. 글쎄, 당신은 그것을 원하는 일부 개발자가 있습니다. 왜냐하면 그들은 MSBuild와 마찬가지로 신비한 시스템을 배우는 데 비용을 지불했기 때문입니다.

저도 MSBuild를 다뤄본 경험이 있는 전문가 중 가장 경험이 풍부한 사람일 것입니다. 대부분의 개발자는 그것을 배우는 데 많은 시간을 들이고 싶어하지 않습니다(당신이 가장 확실히 하기 때문입니다). 마치 자신의 언어인 것 같습니다.

"더 .NET과 유사하고"(VS와 더 나은 통합이 있었다면) 작업하기에 더 나은 제품이고 고려해야 할 매력적인 제안이 될 것이라는 데 우리 모두 동의할 것이라고 생각합니다.

@Mike-EEE & @shederman Mike의 요점에 따르면, 오래되고 구식이며 "다른 (.NET) 개발자가 작업해야 하는 것과는 달리..."입니다. 그러나 수리가 불가능합니까? 그들은 수정하고 싶은 문제가 있음을 인정했습니다. 따라서 질문은 다음과 같습니다. 수정할 수 있습니까? 나는 @shederman의 응답을 알고 있다고 생각하고 그의 추론에 대부분 동의합니다(빌드 및 프로젝트 시스템이 우려의 이상한 혼합이라는 주제에 동의합니다).

다시 말하지만, 나는 이 경주에 말이 없으며 그들이 어떤 길을 선택하든 상관하지 않습니다. 나는 그저 엄지손가락을 치켜드는 반응을 얻고 내 자신이 말하는 것을 듣는 것을 좋아합니다.

나는 그저 엄지손가락을 치켜드는 반응을 얻고 내 자신이 말하는 것을 듣는 것을 좋아합니다.

도와 줄 수있어서 기뻐! :웃다:

그러나 수리가 불가능합니까? 고칠 수 있습니까?

당신이 묻는 사람에 따라 다릅니다. @shederman이 제안한 대로 이었습니다 (예, 거기에서 내 말을 검열했습니다 :stuck_out_tongue: ). 그들의 방식대로 설정되어 있는 것 같습니다. 하지만 소프트웨어의 특성상 시간과 노력만 있다면 무엇이든 가능합니다. :눈짓:

@PhilipRieck 정말 멋진 질문을 하고 있습니다! 불행히도 나는 그들 모두에 대한 확실한 답을 가지고 있지는 않지만 다음을 봅시다.

현재 우리는 모든 빌드 작업에 꿀꺽 꿀꺽 꿀꺽 꿀꺽 마시고 있습니다. 그게 바뀌나요? 내 gulpfile은 dnu 또는 dotnet-cli로 실행하여 실제로 .cs 파일 모음을 어셈블리로 전환합니다. 나는 그것을 지킬 수 있다, 그렇지?

나는 이것이 바뀔 것이라고 _생각__하지 않습니다. 여기서 우리가 이야기하는 것은 프로젝트가 실제로 어떻게 빌드되는지가 아니라 프로젝트 _definition_에만 영향을 미친다고 95% 확신합니다(적어도 dotnet build를 호출하는 것 이상). dotnet CLI는 어느 시점에서 MSbuild를 호출할 수 있지만 그 시점까지는 일종의 내부 작업입니다.

msbuild는 별도 설치인가요? dotnet cli 또는 런타임과 별도로 버전이 관리되나요? 이것은 내 CI 빌드 서버에서 사용 가능한 최소값을 어떻게 변경합니까? 개발 환경에 최소 설치해야 하나요?

이에 대한 명확한 답은 없지만 MSBuild가 이미 설치되어 있는 경우에도(예: VS로) MSBuild가 완전히 별도의 설치로 dotnet CLI의 일부로 제공된다고 _상상_합니다. 순전히 제 추측입니다. 나는 이 전체 ".net 도처에" 프로젝트의 큰 목표가 사람들이 개발할 수 있도록 최소한의 소란을 피우는 것이라는 것을 알고 있습니다. 말 그대로 apt-get dotnet-cli(또는 무엇이든), dotnet new, dotnet build여야 합니다. 프로젝트를 빌드하기 위해 MSBuild를 호출할 필요가 없습니다. 이것이 dotnet-cli의 작업입니다.

텍스트 편집기를 사용하여 nuget 종속성 또는 .cs 파일을 추가하는 경우 이제 추가해야 하는 추가 단계(있는 경우)는 무엇입니까?

.cs 파일의 경우 오늘날과 마찬가지로 확실히 다른 것은 없습니다. 그들이 매우 명확하게 밝힌 한 가지는 프로젝트의 모든 .cs 파일을 지정하는 시대가 지났다는 것입니다(원하는 경우 여전히 그렇게 할 수 있지만 , @Mike-EEE를 보고 있습니다). 종속성에 관해서는 확실히 단기적으로(단기적으로는 몇 개월), 그들은 project.json에 머물고 이전과 똑같이 작동할 것입니다. project.json이 nuget.json이 될 가능성이 있으므로 이름 변경을 제외하고 다른 것은 변경되지 않지만 이에 대한 다른 가능성이 있으며 이것은 Microsoft가 매우 확신하지 못하는 주요 사항 중 하나인 것 같습니다. 이에 대한 선호도를 들을 수 있습니다.
(내 개인적인 취향은 다음과 같은 것을 할 수 있다는 것입니다..nuget.json 그러나 그것은 단지 나에게 침을 뱉는 것입니다).

VS 사용자가 nuget 종속성과 .cs 파일을 추가한 변경 집합을 검토할 때 csproj 변경 사항이 간단하고 사람이 읽을 수 있습니까? (비교를 위해 .net 4.6 및 VS2015에서는 csproj에 대한 변경 사항을 사람이 쉽게 읽을 수 없다고 생각합니다.)

.cs 파일의 경우 csproj가 전혀 변경되지 않아야 합니다. 너겟 종속성의 경우 - 좋은 질문입니다. 다시 말하지만 이것은 다소 공중에 떠 있습니다. 실제로 csproj가 변경되지 않아야 하지만 현재 가장 큰 결정자는 nuget이 nuget.json에 있어야 하는지 또는 csproj에 해당 항목이 있어야 하는지 여부입니다. 둘?

그리고 그것이 주요 요점입니다. 필요한 도구는 적을수록 좋습니다. 나는 현재 상류에서 수영하고 있다는 느낌 없이 텍스트 편집기와 명령줄을 사용할 수 있습니다. 나는 그것이 변하지 않기를 바랍니다. .net46에서 VS를 사용하지 않으려면 거대하고 장황한 xml 파일을 편집해야 하며 동일한 프로젝트에서 VS 사용자와 비 VS 사용자를 혼합하는 것은 악몽입니다.

나는 이것에 전적으로 동의하지만 Microsoft는 갑자기 그것을 악몽으로 만들기 위해 크로스 플랫폼 노력에 너무 많은 투자를 했습니다. "도구"를 사용하면 VS 또는 이와 유사한 것이 아니라 .net CLI에 영향을 미칠 것이라고 생각합니다. .net 코어의 궁극적인 "최종 게임"은 매우 민첩하고 빠르게 움직이는 플랫폼이지만 몇 주마다 업그레이드하는 데 시간을 소비하지 않아도 되는 플랫폼이라는 사실을 잊지 마십시오. 6월에 dotnet 1.0 응용 프로그램을 작성하면 지금부터 몇 년 후에도 여전히 빌드 및 실행될 것이지만, 최신 버전은 준비가 되었을 때 "dotnet upgrade" 또는 그 라인을 따라 실행하는 경우가 될 것이라고 확신합니다. . RTM이 히트하더라도 RC2 프로젝트는 실제로 들어가서 대상을 RTM으로 변경할 때까지 여전히 RC2 비트를 빌드하고 실행합니다(global.json이나 어딘가에서?).

:웃음: 이런 글을 읽을 때면 마이크로소프트가 후회하는 순간이 있을까 하는 생각이 듭니다. 저는 개발자를 위한 투명하고 오픈 소스이며 커뮤니티 지향적인 안식처를 만드는 것을 목표로 Microsoft를 완전히 뒤집기 위해 최선을 다하고 노력하고 있는 사람들을 진심으로 존경하고 느낍니다. 이 변환 뒤에 있는 사람들은 관심을 갖고 있습니다. 그들은 좋은 사람들입니다. 그들은 지금 바위와 단단한 곳 사이에 있어야 합니다. (나를 즐겁게 하면서도) 떠도는 덜 건설적인 커뮤니티 감정은 그들의 경우에 도움이 되지 않습니다.

현재 IDE에 있는 많은 매직 프로젝트 생성 기능을 많은 매직 csproj 조작을 수행하는 명령줄 앱으로 교체하는 것은 나쁜 생각이라는 점을 지적하고 싶습니다. 프로젝트 정의 파일을 가능한 한 간단하게 만드는 것은 필수입니다. project.json의 가장 좋은 부분은 내가 읽고 이해할 수 있다는 것입니다.

@shederman MSBuild의 문제는 크고 복잡한 시스템에서 크고 복잡하다는 것입니다....

또한 구축 팀과 함께 일을했고 나는 또한 절대적으로 싫어했습니다 (핑 (Ping) 우리는 모두이 경험이 얼마나 끔찍한 이야기 한 becuse 마이크-EEE @), 나는 그것을 얻을 수 있지만, 당신이 설명하는 것은 완전히 다른 않습니다 대본. MSbuild는 크고 복잡할 수 있으며 기본적으로 VS를 크고 복잡하게 만들 수 있습니다. 하지만 그것이 바로 변화하는 것 입니다.

최신 csproj 파일은 훨씬 작아야 합니다. 즉, "디버깅"이 크게 단순화되어야 합니다. 크러스트가 없거나 거의 없습니다. 여전히 원하는 _build 시스템_을 사용할 수 있습니다. 지옥에서 *.csproj에서 "dotnet build"를 호출하는 .bat 파일을 호출하면 오늘처럼 원하는 출력을 얻을 수 있습니다. dotnet cli가 MSbuild를 처리하도록 하면 건드릴 필요조차 없습니다.

@neoKushan 감사합니다.

나는 우리가 멀어진다는 말을 들은 립스틱이 아니라 약속된 것을 원합니다.

그리고 약속된 것을 우리에게 주기를 원하지 않는다면, 우리가 우리 자신에게 주도록 하십시오. 이미 다 있습니다. 리팩토링을 유지하는 경우일 뿐입니다. 내가 전에 말했듯이, 나는 일을 할 것이다.

남겨두고 싶은 마음이 없는 첫 번째 이유는 이것이 MSBuild 프로젝트에서 대규모 마이그레이션의 시작이 될 것이라는 인식 때문인 것 같습니다. 죄송합니다. 생명 유지에 구식 기술을 유지하는 것은 .NET Core의 설계 목표 중 하나가 아닙니다 . 그렇습니까?

ms 빌드의 가장 큰 문제는 누가 수정하고 시간이 얼마나 걸리는가입니다. 현재 전체 ASPnet 프로젝트에는 1000개 이상의 미해결 문제가 있으며 그 중 일부는 매우 중요합니다. SignalR을 보십시오.
릴리스까지 한 달이 남았고 이 버그는 최종 상태에 거의 가깝습니다.

그리고 이제 그들은 ms build가 개선될 수 있다고 말합니다. MS에 이 모든 레거시를 관리할 수 있는 충분한 리소스가 있습니까? 커뮤니티에서 처리할 수 있습니까? 나는 그것을 정말로 믿지 않는다.

@shederman

그리고 약속된 것을 우리에게 주기를 원하지 않는다면, 우리가 우리 자신에게 주도록 하십시오.

그들은 당신이 아무것도 하는 것을 막지 않습니다. 계속해서 포크하십시오. 아무것도 당신을 막을 수

이미 다 있습니다. 리팩토링을 유지하는 경우일 뿐입니다. 내가 전에 말했듯이, 나는 일을 할 것이다.

그럼 해? 다시 말하지만, 아무것도 당신을 막을 수 없습니다.

남겨두고 싶은 마음이 없는 첫 번째 이유는 이것이 MSBuild 프로젝트에서 대규모 마이그레이션의 시작이 될 것이라는 인식 때문인 것 같습니다.

그들이 왜 신경을 쓰겠습니까? MSbuild 또는 다른 것을 사용하면 Microsoft에 어떤 차이가 있습니까?

가장 큰 이유는 ASP.net 코어의 프로젝트 구조가 asp.net 코어에만 적합하기 때문입니다. project.json에 적합하지 않은 수백 가지의 다른 프로젝트 유형이 있습니다. project.json에 자체 문제가 있다는 사실을 신경쓰지 마십시오. 우리는 분명히 잊어버렸습니다. 주석이 부족하여 내 애완 동물이 짜증납니다(아니요. XML은 도움이 되지 않습니다).

죄송합니다. 생명 유지에 구식 기술을 유지하는 것은 .NET Core의 설계 목표 중 하나가 아닙니다. 그렇습니까?

아니요, 하지만 사람들이 기존 프로젝트를 .net 코어로 이식하도록 돕는 것이 목표입니다. 게다가, 우리는 완전한 데스크톱 버전이 아닌 .net 코어 버전의 MSBuild에 대해 이야기 하고 있습니다 .

당신의 유일한 문제는 그들이 감히 그것을 MSBuild라고 부르는 것입니다. 그들이 XML이 되었지만 "CoreBuild"라고 불리는 새로운 프로젝트 스타일을 생각해냈다면, 당신은 더 현명하지 못했을 것이고 계속 진행해야 하는 것은 "나는 XML을 싫어합니다!"뿐입니다.

당신은 마이크로소프트의 허가를 기다리고 있고, 당신은 이미 그것을 얻었습니다.

사실이 아닙니다. 나는 그것을 포크 하고 싶지 않고 메인 리포지토리에 유지하고 싶습니다. 차이가 있습니다. 따라서 아무도 완전히 새로운 .NET SDK를 다운로드할 필요가 없습니다. 나는 도구에 그것을 원하고, 예, 나는 그들의 묵인이 필요합니다.

당신의 유일한 문제는 그들이 감히 그것을 MSBuild라고 부르는 것입니다.

아니요, 그들은 MSBuild를 _사용_하기를 원합니다. 사소하지만 중요한 차이. 새 project.json 빌드 시스템의 이름을 바꾸고 MSBuild라고 하면 행복하게 사용하겠습니다.

당신은 더 현명하지 않을 것이고 당신은 "나는 XML을 싫어합니다!"라고만 하면 됩니다.

아마도 😄

어쨌든 원을 그리며 돌고 있습니다.

취침.

스탠드업에 맡기라고 합니다. 아무도 설득하지 않습니다. 나는 친 MSBuild 측을 이해한다고 확신하지만 그것에 동의하지 않습니다. 그리고 친 MSBuild 측이 비 MSBuild 측을 이해한다고 확신하지만 동의하지는 않습니다.

내 말은 우리가 둘 다 가질 수 있다는 것뿐입니다. MS 팀의 추가 노력이 전혀(또는 거의) 없습니다. 그런 다음 실제 프로덕션 사용의 눈부심 속에서 옵션이 가라앉거나 헤엄치도록 하십시오.

@neoKushan 의 질문에 따라:

뭐가 남았어?

나는 실제로 내가 생각하기에 훌륭하고 사용 가능한 프로젝트 파일을 만든다고 생각하는 위에서 설명한 "신조"를 중심으로 내 응답을 구성하고 싶습니다.

• 사람이 편집/읽을 수 있어야 합니다.

위의 @neoKushan 의 진술을 해결될 것임을 의미하는 것으로 간주합니다. MSFT의 누군가가 이것을 말

Guid ProjectType을 제거하는 것이 해결해야 할 주요 항목 중 하나라고 가정합니다.

그러나 나는 위의 부록을 지지합니다. 간단한 프로젝트(예: Angular의 ASP.Net Hello World)의 경우 메모장에서 전체를 손으로 만들 수 있다는 것은 어려운(협상 불가능한) 요구 사항입니다. Yeoman/VS/similar를 사용해야 하는 경우 사람이 편집할 수 있는 프로젝트 파일을 제안하는 데 실패했습니다.

• 댓글을 허용해야 합니다.

이미 작동 중, MSBuild에서

• 선언적이어야 한다

First-Level의 순서 변경(직계 자식)는 종종 디버그하기 어려운 방식으로 프로젝트의 전체 의미를 변경할 수 있습니다. 실수로 .targets 가져오기를 맨 위로 가져오는 경우보다 더 주목할만한 곳은 없습니다.

• 자급자족해야 한다

이것은 MSBuild의 가장 큰 문제입니다. 파일을 정적으로 읽는 것은 실제로 무슨 일이 일어나고 있는지 알기에 충분한 정보를 제공하지 않습니다. _environment variable_ 지정 경로에서 오는 .targets 파일과 환경 변수가 이벤트 지원된다는 사실부터 조건부 및 가져오기에 이르기까지 매우 높은 수준의 복잡성을 희생하면서 효과적으로 Turing Complete 환경을 얻을 수 있습니다. , 그리고 가난한 도구 능력. 나는 VS의 MSBuild의 열악한 통합이 그러한 주변에 도구를 구축하는 어려움의 결과라고 가정합니다.

이것은 인간의 가독성/편집 가능성 문제와 유사합니다.

• 병합 충돌을 줄이고 가능하면 병합을 단순화하도록 설계해야 합니다.

MSBuild는 기술적으로 와일드카드 형식으로 이를 지원합니다. 와일드 카드에 대한 VS 지원은 심연보다 나쁩니다. 그것은 적극적으로 일하기 어렵게 만듭니다. 위의 내용에 따르면 이 문제가 해결될 것이라는 점을 기꺼이 받아들입니다. 하지만 _migrate_에 대한 _제안_의 항목이어야 합니다. 기반 프로젝트 파일.

• 완전히 문서화할 수 있어야 합니다(문서에 자체 포함 원칙이 적용됨).

MSBuild에 문서가 있다고 생각합니다. 그 문서, 특히 MSBuild의 VS _flavor_에 대한 문서는 상당히 필요합니다. 나는 종종 왜 다른 것들이 그들이 속한 그룹에 있는지 어리둥절하고 VS "도움"이 도움이되지 않습니다.

완벽한 예는 Bond NuGet 패키지입니다. 디스크에 BondInclude 폴더가 없는 경우(csproj에서 참조하는 경우) 빌드가 결과 어셈블리에 Bond 유형을 실제로 생성하지 못할 것이라는 사실을 얼마나 많은 사람들이 알고 있습니까? (오류도 발생하지 않음). 그런 다음 해당 이름으로 빈 폴더를 만들고 프로젝트를 다시 로드하면 문제가 해결됩니다.

(예, 알고 있습니다. 버그를 신고할 예정입니다.)

• 도구에 독립적이어야 합니다.

MSBuild와 아무 관련이 없다고 가정해 보겠습니다. 내 프로젝트를 정의하고 너겟을 통해 패키지를 가져오고 싶습니다. 이 특정 빌드 시스템을 강제로 사용해야 하는 이유는 무엇입니까? 특히 내가 원하는 것이 프로젝트를 정의하는 것뿐이라면?

빌드 정의 파일은 프로젝트 파일 형식이 아닙니다. VS가 작동하도록 관리했다는 것은 (다소) 계속 사용하기에 좋은 이유가 아닙니다. 나는 단지 프로젝트 자체를 나타내는 실제 파일과 그것이 생성하는 아티팩트에 대한 정보를 원합니다(이를 빌드하는 방법에 대한 지침이 아님). 여기에서는 "명령"을 정의할 수 있기 때문에 project.json도 실패합니다. 그것들이 존재하는 이유는 무엇입니까? 출력 유형과 찾을 수 있는 위치를 정의하기만 하면 됩니다.

이 전체 스레드를 읽었고 project.json 대 project.csproj 대한 토론에서 저에게 눈에 띄는 한 가지는 해당 파일 이름 중 하나만 전체 프로그래밍 언어가 구워졌다는 것입니다. F#에서 ASP.NET 개발을 선호합니다. ASP.NET Core에서도 가능합니까? 이 시점에서 나는 가장 희미한 생각이 없지만 그렇지 않다는 느낌을 받습니다. 사람들이 csproj 를 csproj, fsproj, vbproj 의 약어로 사용하는지 아니면 실제로 csproj 만을 의미하는지 잘 모르겠습니다.

업데이트: F# 사람들이 CoreCLR 지원을 위해 노력하고 있지만 실제 ETA는 아직 없습니다. 제 요점은 지금 결정된 프로젝트 시스템이 무엇이든 지금 당장은 사람들의 관심을 끌지 못하는 프로그래밍 언어에 영향을 미칠 것이라는 것입니다. 내가 XML보다 JSON을 선호하는 만큼 project.json이 나를 C#에 고정시키려는 경우(그리고 컴파일의 파일 순서가 F#에서 결정적으로 중요함) 나는 그것에 동의하지 않습니다.

지금은 FAKE와 Paket으로 돌아온 것 같습니다.

저는 처음부터 .NET으로 작업하고 있으며 MSBuild에서 주목할만한 문제가 발생한 적이 없습니다. 그 주된 이유는 바로 사용 가능한 솔루션 컴파일 이외의 다른 용도로 사용한 적이 없기 때문입니다.

그리고 그것이 내가 MSBuild에 대해 싫어하는 것에 대해 이해하지 못하는 것입니다. 누구도 솔루션 컴파일 이외의 용도로 MSBuild를 사용하도록 강요하지 않습니다. 그리고 솔루션을 컴파일할 수 있다는 것은 꽤 유용한 기능이라고 생각합니다. BTW는 "dotnet cli"에도 아직 존재하지 않습니다(지금 바로 프로젝트를 수동으로 반복해야 합니다. 내가 틀렸다면 수정해 주세요).

실제 빌드 시스템은 변경할 필요가 없습니다. Nant를 사용하고 있다면 Nant를 계속 사용하십시오. psake를 사용하는 경우 psake를 계속 사용하십시오. powershell 스크립트를 사용하는 경우 계속 사용하십시오. 등! 아마도 "dotnet build" 부분만 MSBuild에 대한 호출로 대체해야 합니다. (dotnet build가 MSBuild를 호출하는 경우에는 필요하지 않을 수도 있음)

이것이 MSBuild가 구현 세부 사항을 상당히 중요하지 않게 만든다고 저는 주장하고 싶습니다. 지난 10년 동안 그렇게 보아왔고 앞으로도 그렇게 볼 것입니다.

하지만 물론 이 스레드의 시작 부분에서 이미 말했듯이 우리에게 확실히 필요한 것은 csproj를 더 잘 처리하기 위해 project.json 및 Visual Studio의 _기능_ 중 일부입니다. 그것을 전달할 수 있습니다.

@jtmueller F#(또는 그렇게 하고 싶은 경우 VB.net)을 사용할 수 없어야 하는 _기술적_ 이유는 없습니다. MSBuild 프로젝트 파일로의 전환이 이를 용이하게 하는 데 도움이 된다면 놀라지 않을 것입니다. DNX는 결코 만족하지 않았지만 CoreCLR은 확실히 F#을 지원합니다. F# come RTM을 사용할 수 있을지 모르겠지만 확실히 파이프라인에 있습니다.

@jtmueller project.json은 종속성 매니페스트와 사용자 지정 명령이 포함된 거의 프로젝트 정의입니다. 특정 언어와 관련된 것은 전혀 없습니다.

내 꿈의 빌드 시스템(MSBuild를 완전히 대체하기 위해)은 Roslyn을 사용하여 작업과 대상을 파악하므로 F#을 사용하여 빌드 프로세스(또는 C# 또는 VB.NET, Roslyn이 지원하는 모든 것)를 정의할 수 있습니다.

물론 아직 아무도 제안하지 않습니다. 그러나 우리를 MSBuild에 다시 가두는 것은 매우 오랫동안 그 문을 닫을 것이 거의 확실합니다.

휴식을 취했고 MSBuild를 "저장"하기 위해 수행해야 하는 작업에 대한 도전에 대해 조금 이야기했습니다. 나는 우리가 MSBuild를 상당히 다른 빌드 시스템으로 바꿀 수 있거나 바꿔야 한다고 생각하지 않습니다. 이는 추론 기반의 XML 정의 빌드 시스템이며, 이는 매우 많은 사람들의 시나리오, 특히 일부 더 복잡한 시나리오에 적합합니다.

그러나 우리 모두에게 MSBuild와 씨름할 수 있는 전담 빌드 마스터가 있는 것은 아닙니다. 우리 모두에게 MSBuild의 복잡성이 가져다주는 힘이 필요한 것은 아닙니다. 그 복잡성 이 필요한 사람들 중 일부는 MSBuild를 사용하고 싶어하지 않습니다. 예를 들어 내 팀 중 하나에서 모든 사용자 정의 빌드 논리는 빌드 전 및 후 단계에서 수행되며 Exec은 기본적으로 Powershell에 포격됩니다. MSBuild에서 수행할 수 없기 때문이 아니라 할 수 있으며 이 경우에는 아마도 _해야 합니다_. 그러나 그들은 MSBuild에서 그것을 하고 싶지 않기 때문입니다.

1단계 는 확실히 빌드 시스템에서 프로젝트 정의를 분리해야 한다는 것입니다. 나에게 그것은 엄청난 의미가 있습니다. 우리는 프로젝트 정의에서 종속성을 분리하는 것에 대해 논의할 수 있지만 그것이 필수라고 생각하지 않습니다.

2단계 는 빌드 시스템이 필요하다는 것입니다. 매우 간단한 사용 사례와 매우 복잡한 사용 사례를 처리해야 합니다. 그러나 하나의 빌드 시스템이 _둘 다_를 처리해야 한다는 규칙은 없습니다. 내 생각에 가장 의미 있는 것은 기본적으로 프로젝트 정의를 빌드하는 간단하고 가벼운 빌드 시스템을 갖는 것입니다. restore , build , test 및 pack 합니다.

나는 정의로 디렉토리 구조를 사용하여, 전혀 프로젝트 정의를 _without_ 일할 수있을 때까지 우리는 또한 수있는 방법을 찾아야한다 생각합니다. 분명히 그러한 상황은 기본 프레임워크와 기본 종속성을 사용한다는 것을 의미합니다. 가능할 수도 있고 아닐 수도 있습니다. 그러나 정의의 각 요소를 보고 "이에 대해 지능적인 기본값을 추론할 수 있습니까?"라고 물을 수 있습니다.

그러나 사용 사례의 80%에는 충분하지만 다른 20%에는 충분하지 않습니다. 그들은 더 많은 것이 필요합니다. (주의: 사용 사례 비율에 대한 의견은 다를 수 있습니다).

세 번째 단계 는 해당 빌드 시스템에 매우 간단한 형태의 확장성을 허용하는 것입니다. 그러나 우리는 매우 간단하게 이야기하고 있습니다. 기본적으로 기본 빌드를 실행하거나 외부 빌드 시스템을 실행할 수 있습니다. 외부 빌드 시스템은 MSBuild, 스크립트 또는 기타 빌드 시스템일 수 있습니다.

새 빌드 프로세스가 MSBuild에 적용할 수 있게 되어 기쁩니다. 하지만 (IMO) MSBuild와 같이 낡고 부자연스럽고 부풀려진 것이 향후 모든 빌드의 기초가 되어야 한다고는 생각하지 않습니다.

웹 프레임워크와 같은 것들을 사용하여 우리는 MS 팀이 미친 듯이 반복하는 것을 봅니다. 왜냐하면 그들에게는 경쟁이 있기 때문입니다. 예를 들어 낸시가 목을 졸라 숨을 쉬는 것을 걱정해야 합니다. 다른 것으로 전환하는 것은 _쉽습니다_. 그리고 MVC/WebAPI를 더 좋게 만듭니다.

전체 .NET 도구에 포함된 MSBuild를 사용하면 다른 도구를 사용하기가 어렵습니다. 경쟁은 어디에 있습니까? 그리고 MSBuild Github 보드에서 그 효과를 볼 수 있습니다. 모든 닫힌 제안을 검토하기만 하면 됩니다. 지금 이러한 "슬리밍" 변경에 대해 이야기하는 유일한 이유는 사람들이 project.json에서 MSBuild로 이동하기를 원하기 때문입니다.

MSBuild가 처음부터 .NET Core에 구워졌다면 지금 MSBuild 팀에서 보고 있는 움직임 중 _아무도_ 볼 수 있을 것입니다. 하지만 우리가 다시 갇히면 어떻게 될까요? 일단 경쟁은 기본적으로 배제? 무슨 일이 일어날까요? 경쟁이 없는 시나리오에서 항상 일어나는 일과 지금까지 몇 년 동안 일어난 일: 대규모 탈북을 막을 수 있을 만큼만 개선되었지만 특별히 흥미로운 것은 없습니다.

사람들은 어떻게 MSBuild를 "저장"할 수 있다고 생각하는지 물었습니다. 나는 그것을 실제 경쟁과 선택에 개방하는 것이 유일한 방법이라고 믿습니다. 거의 강력한 것이 필요하지 않은 개발자(예, 강력하다고 생각합니다)를 포함한 모든 개발자에게 이를 법정화폐로 강제하면 이에 대한 분노가 더욱 커질 것입니다.

그것은 어떤 프레임워크의 성공을 위한 비법도 아닙니다.

우리 모두 는 .NET이 성공하기를 바랍니다. 저는 .NET을 _사랑_합니다. 저는 C#이 현존하는 최고의 프로그래밍 언어 중 하나이며 Scala - The Good Parts™로의 느린 전환을 즐겼습니다.
나는 우리가 .NET Core로 새롭게 시작하고 구식 .NET의 최악의 부분 중 하나(IMO)에 속박함으로써 그것을 한다고 생각하지 않습니다. 예, MSBuild, 하지만 아니오, 그것에 속박되어 있지 않습니다.

꼭 지키되, 시스템의 핵심에 내장된 전면과 중앙은 아닙니다.

내 꿈의 빌드 시스템(MSBuild를 완전히 대체하기 위해)은 Roslyn을 사용하여 작업과 대상을 파악하므로 F#을 사용하여 빌드 프로세스(또는 C# 또는 VB.NET, Roslyn이 지원하는 모든 것)를 정의할 수 있습니다.

야아아아아아아!!! 그러고 보니... 여기가 이런 대화를 나누기에 적합한 장소입니까? 우리는 Roslyn과 MSBuild 저장소도 가지고 있으며 그들도 참여해야 할 것 같습니다. MSBuild 리포지토리에서 시도하고 있는 것 같지만 (말씀하신 대로) 매우 엄격하고 유연하지 않습니다. 이 스레드가 생성한 관심을 좋아하는 사람이 더 많아지면 개혁에 큰 도움이 될 것입니다.

세 번째 단계는 해당 빌드 시스템에 매우 간단한 형태의 확장성을 허용하는 것입니다.

공급자 기반 빌드 시스템/모델?! 천재! 이 메시지를 승인합니다.

Btw, 원하는 것을 얻고 자신의 빌드 시스템에 액세스할 수 있다면 그것을... BERSERKER BUILD라고 부르기를 제안합니다! "Berzerker @shederman"의 이름을 따서 명명되었습니다... 당신을 위한 새로운 별명입니다. :웃다:

@Mike-EEE 너무 흥분하지 마세요. 나는 _아직_ 그 모든 것만큼 과감한 것을 결코 제안하지 않습니다.

지금은 3단계에 대한 MSBuild 지원과 함께 1단계와 2단계여야 한다고 생각합니다.

그러나 이러한 종류의 가능성은 우리가 project.json을 얻었을 때 진행하고 있었지만 빌드 공급자를 더 쉽게 교체할 수 있도록 프로젝트를 빌드에서 분리했습니다. 내 생각에 MSBuild를 루트로 다시 가져오면 이러한 가능성이 닫힙니다. 또는 최소한 견인력을 얻을 가능성이 훨씬 적습니다.

현재 사용자 정의 빌드는 루트 시스템이 _is_ 강력하기 때문에 채택되지 않습니다. MS 빌드 시스템이 실제로 필요한 모든 작업을 수행할 수 있을 때(고통을 무시하고) 비 MS 빌드 시스템을 사용하고 싶다고 사람들을 설득하는 것은 어려운 대화입니다.

이 대화를 나누기에 적합한 장소입니까?

나는 그렇게 생각하지 않습니다. 또한, 아직 때가 되었다고 생각하지 마십시오. 어떤 방향이 가능한지 보기 전에 이 문제를 종료해야 합니다.

버서커 빌드! "Berzerker @shederman"의 이름을 따서 명명되었습니다... 당신을 위한 새로운 별명입니다. :웃다:

어떤 느낌인지 잘 모르겠습니다 😉

버서커가 되려고 하지 않습니다. 저는 우리가 앞으로 _하고 있었을 때_ 뒤로 움직이고 싶지 않을 뿐입니다.

여러분, 아마도 바퀴를 재발명하는 대신( nuget.json 또는 무엇이라고 부르든 간에) 대부분의 종속성 관리 문제를 해결하는 기존의 커뮤니티 중심 솔루션인 Paket 을 사용합시다.

1. 전이적 종속성의 개념이 있습니다.
2. MsBuild와 잘 통합됩니다.
3. 종속성을 정의하기 위해 사람이 읽을 수 있는 파일 형식이 있습니다.
4. packages.config 에서 마이그레이션 경로가 매우 좋습니다.
5. 그리고 다른 많은 기능(그러나 분명히 이 4가지가 모든 사람에게 가장 중요한 것이므로 Git 종속성 또는 더 나은 패키지 해결 전략과 같은 사항은 언급하지 않겠습니다)

@Krzysztof-Cieslak은 Microsoft가 MSbuild 프로젝트 정의를 추진하는 가장 큰 이유는 MSBuild에 많은 투자를 한 사람들의 마이그레이션을 용이하게 하기 위함임을 기억합니다. 그런 점에서 Paket은 project.json(또는 project.yaml 또는 project.cs 등)보다 낫지 않습니다.

그럼에도 불구하고 원하는 빌드 시스템을 사용할 수 없는 이유는 아직 찾지 못했습니다. 궁극적으로 "dotnet build"는 프로젝트 정의의 최종 형식에 관계없이 변경되지 않으며 dotnet build는 여전히 출력을 생성합니다.

@neoKushan 예, 하지만 MSBuild를 사용하지 않더라도 "

@shederman 의심할 여지 없이 "

내가 말했듯이, 단지 한 내가 일을 할 수있어 나는 행복 해요, 전혀 MSBuild를 필요로하지 않는 장소에 경량 빌드를 유지한다. 여러분은 원하는 막다른 골목에 자체 참조 "MSBuild every" 파이프라인을 구축할 수 있습니다.

그러나 그것이 작동한다면 csproj는 RichiCoder 제안 과 같은 project.json을 포함해야 합니다.

그렇게 하면 "코어 빌드"와 "MSBuild"가 나란히 작동하거나 MSBuild 없이 코어 빌드가 작동할 수 있습니다. 그리고 분명히 project.json을 가져오지 않으면 csproj에서도 프로젝트 속성을 정의할 수 있습니다.

사실 아주 쉬운 변경. 내 머리 꼭대기에서 우리는 다음이 필요합니다.

• 기존 dotnet-build 코드를 유지하고 특정(미정) 상황에서 실행합니다.
• 다른 곳에서는 DotNet 핵심 팀 계획에 따라 MSBuild를 실행합니다.
• VS가 프로젝트 속성에 대해 project.json 또는 MSBuild를 읽을 수 있도록 합니다.
• MSBuild에 project.json 가져오기 기능 추가

꽤 적은 양의 작업으로 Microsoft는 "영원한 MSBuild" 경로를 계속할 수 있으며 .NET Core 커뮤니티에 대한 약속을 지키며 MSBuild에서 옵트아웃하려는 사람들이 그렇게 할 수 있습니다.

asp.net 회원 중 누구도 여기에서 아무 말도 하지 않았습니다.

한편, 나는 ASP.NET Community Standup – 2016년 5월 10일 의

@rhires 내가 이해한

나는 당신의 project.json 아이디어를 좋아합니다. 방금 RC2 변경을 겪고 "테스트 러너"를 넣었으므로 수행하지 못할 이유가 없습니다. _BUT_, 그들의 마음은 완전히 project.json을 제거하고 MSBuild-first 세계로 돌아가는 데 완전히 설정되어 있는 것 같습니다.

MS가 도구를 통해 json 파일의 주석을 "단순히" 허용할 수 없는 이유(유명한 마지막 단어)

그들이 할 수 없었던 이유는 없습니다. 그들이 사용하는 라이브러리인 JSON.Net은 주석을 지원합니다.

실제로 project.json은 해당 경로로 이동해야 하는 경우 { "BuildSystem" : "MSBuild" } 항목을 포함해야 합니다.

내 프로젝트가 자체 빌드 시스템을 지시하기를 원하는 이유는 무엇입니까? 확실히 빌드 시스템이 프로젝트를 빌드하고 그 반대가 아닌 프로젝트를 빌드합니까?

@neoKushan :

Microsoft가 MSbuild 프로젝트 정의를 추진하는 가장 큰 이유는 MSBuild에 많은 투자를 한 사람들의 마이그레이션을 용이하게 하기 위함입니다. 그런 점에서 Paket은 project.json(또는 project.yaml 또는 project.cs 등)보다 낫지 않습니다.

Paket은 새로운 빌드 시스템이 아니라 MsBuild와 100% 호환되는 종속성 관리자입니다. packages.config 문제를 해결합니다.

@Krzysztof-Cieslak 나는 그것이 빌드 시스템이라고 주장한 적이 없으며 종속성 관리가 실제로 .net 코어의 주요 문제는 아닙니다(최소한 내가 아는 한). .net 코어는 packages.config 를 사용하지 않고 project.json 합니다.

.Net Core가 여전히 project.json 를 사용하도록 계획되어 있었다면 이 100개 게시물 토론을 하지 않았을 것입니다. ;) 내가 말하는 것은 종속성을 처리하기 위해 "nuget.json"을 사용하는 솔루션이 완전히 동일한 제품을 가지고 있기 때문에 바퀴를 재발명하는 것입니다.

@shederman

"최종 설문 조사 결과: 95% 신뢰도에서 ±10%인 9백만 .NET 개발자 모집단에 대해 100개의 응답이 있습니다."

예, 컨퍼런스에서 개나 고양이가 선호하는 애완 동물인 고양이 장난감에 대해 물어보면 비슷한 결과를 얻을 수 있습니다.

@darrelmiller

"MSBuild와 Visual Studio가 현재 MSBuild를 사용하는 방식을 구별하는 것이 중요하다고 생각합니다. 저는 수년간 MSBuild 파일을 직접 편집해 왔으며 이를 모든 프로젝트에 사용하고 있습니다. 예: https://github.com/tavis- 소프트웨어/Tavis.home/blob/master/build/Build.proj "

명령줄에서 msbuild가 작동하지 않는 프로젝트 파일 위에 VS 특정 빌드 파일에 대해 논의해 볼까요?

@gregoryyoung 그래야 합니다. 이전에 devenv에 의존하는 빌드 파일을 수행했지만 명령줄에서 실행되지 않는 파일은 보지 못했습니다. 어떤 예?

@gregoryyoung

예, 컨퍼런스에서 개나 고양이가 선호하는 애완 동물인 고양이 장난감에 대해 물어보면 비슷한 결과를 얻을 수 있습니다.

흥미로운 비유입니다. 제외하고...

MSBuild로의 이전을 _지원한_ 사람들의 Twitter 피드에 링크를 게시했습니다. 따라서 실제로는 귀하의 비유와 전혀 같지 않습니다.

그리고 설문조사가 잘못된 포럼에서, 또는 비과학적으로 편향되어 있다는 계속되는 비방이 마음에 듭니다. 그러나 질문은 주도적이지 않았고 답변은 광범위한 응답을 했으며 설문조사는 스스로 선택한 청중이었지만 적어도 이론상으로는 내 관점에서 _멀리_ 편향되어야 하는 광범위한 청중이었습니다.

나는 또한 이러한 비난을 하는 사람들이 설문조사에 대해 약간의 구글링을 했다는 인상을 받았고 어떤 경우에는 확인을 받았습니다. 저는 개인적으로 건강 연구를 위한 석사 수준의 연구 프로토콜을 설계했으며 설문 조사가 완벽하다고 주장하지는 않지만 확실히 Microsoft 직원이 만드는 것만큼 결함이 있는 것은 아닙니다.

통계적으로 가장 확실하게 _is_ 하며, 의견이 어디에 있는지에 대한 좋은 지표를 제공합니다. GitHub, gitter, Twitter, 블로그는 모두 이를 어느 정도 뒷받침하고 있습니다.

같은 말을 하는 여러 증거 출처. 중요한 사용자의 의견을 무시하고 싶다면 그렇게 말하십시오. "잘못된" 의견을 주장하면 자신의 의견을 말할 권리를 상실하는 것처럼 반대를 물리치려는 시도를 중단하십시오.

또는 내가 여러 번 말했듯이 내 설문조사에서 잘못되었다고 생각하는 부분을 개선하는 설문조사를 만드는 것이 좋습니다.

내가 설문 조사를 한 이유는 Microsoft가 사람들이 무슨 생각을 하는지 전혀 모른다는 것이 완전히 명백했기 때문입니다. 이제 완전히 명백해지고 있는 것은 그들이 사람들이 생각하는 것에 _관심_이 없다는 것입니다.

자신과 지역 사회에 부정직하지 말고 반대를 흔들지 말고 참여하십시오.

사실을 바꾸려는 시도를 멈추고 사실에 근거하여 마음을 바꾸십시오.

@shederman Microsoft 팀이 이 스레드(귀하의 설문 조사 포함)에 실제로 답변했다는 인상을 받지 못했습니다. 예, 팀의 한 사람이 당신만큼 신뢰할 수 있다고 생각하지 않는다고 말했지만 그게 전부입니다. 나는 그들이 현재 그들이 가고 있는 길에 대한 엄청난 반대에 대해 이야기하고 있고 그들이 취해야 할 올바른 길에 대해 논의하고 있으며 그들이 더 많이 알게 되면 우리에게 응답할 것이라는 희망이 여전히 있다고 생각합니다.

나는 우리가 이 팀에 약간의 신용을 줄 수 있다고 생각합니다 ;).

@gregoryyoung 죄송합니다. 말씀하신 유추로 맴돌고 있기 때문입니다.

@sandorfr

나는 우리가 이 팀에 약간의 신용을 줄 수 있다고 생각한다

나는 우리가 할 수 있다고 생각했지만 지난 며칠 동안의 경험은 그 희망을 강화하지 못했습니다.

'팀' 탓이 아니라, 조직의 상위 누군가가 이런 결정을 하고 내려놓은 건데… 그런 다음 '팀'이 그걸 빨아들이고 예쁘게 만들어야 한다고 생각해야 한다. BTDT. 재미 없어.

project.json이 비 ASP.NET Core 애플리케이션과 좀 더 호환되도록 최근 에 이미

거기에서 "고전적인" csproj 파일로 이동하는 것은 실제로 나에게 그렇게 멀리 확장되지 않는 것 같습니다. 그리고 csproj 자체가 project.json에서 배운 더 유연한 방향으로 조금 발전한다면 실제로 "새롭고 개선된" csproj가 정말 잘 작동하는 것을 볼 수 있습니다. 또한 project.json에 대한 최근 변경 사항이 _모든_ 종류의 .NET 프로젝트에 사용할 수 있도록 하는 과정의 마지막 변경 사항이 아니었을 것이라고 안전하게 가정할 수 있습니다. ASP.NET(Core) 이외의 다른 많은 대상입니다.

그리고 실제로 파일 형식이 JSON, XML 또는 무엇이든 간에 그다지 중요하지 않아야 합니다. 예, 여러 가지 타당한 이유로 하나가 다른 것보다 유리할 수 있지만 결국 에는 프로젝트 파일 내에서 실제로 얼마나 많은 시간을 보내고 싶은지 생각해야

사람들이 project.json을 생각할 때 대부분 구성보다 관례가 많은 초기 단계 를 생각하는 것 같습니다. 예, 그것은 매우 훌륭했지만 ASP.NET Core에만 국한되어 매우 제한적이었습니다. 다른 대상에서는 제대로 작동하지 않으므로 수년 동안 잘 작동하는 것을 사용하고 확장하고 호환성을 유지하면서 가능한 모든 면에서 개선하는 것이 합리적입니다.

그래서, tl;dr: 예, 저는 project.json을 정말 좋아하고 그것을 ASP.NET Core용으로 유지할 수 있는 방법이 있었으면 합니다(예: 특별한 MSBuild 작업 사용). 하지만 동시에 왜 지금 이런 일이 일어나고 있는지 완전히 이해하고 있으며 실제로 그들이 하는 행동이 나쁜 것은 아니라고 생각합니다. 물론 타이밍이 조금 이상하긴 하지만 ASP.NET Core 및 .NET Core 릴리스와 병행하여 변경이 발생하지 않는다는 점을 감안할 때 타이밍이 실제 문제라고 생각하지 않습니다(나중에 전환이 원활할 것이라고 가정하면 ).

프로젝트 간에 소스 파일을 공유할 수 있어야 함

@darrelmiller 이것은 .csproj의 목록 파일이 다시 돌아오고 있음을 암시하는 것처럼 보이기 때문에 무섭게 들립니다.

@lokitoth csproj가 파일 참조에 대해 새로운 project.json과 유사하게 작동한다고 가정하면 일반적으로 glob을 사용하고 개별 파일 참조를 함께 사용하는 것을 방해하는 것은 없습니다.

@shederman 저는 MS 직원이 아니라 합리적인 사람입니다. 저를 구글링하시면 제가 이 플랫폼에 장기적으로 관심을 가지고 있다는 것을 알게 되실 거라 확신합니다.

변경과 관련된 많은 찬반 양론이 있지만 귀하가 제공한 내용은 정상적인 토론에 유용하지 않습니다.

듣기만 해도 실망스러운 변화였습니다. project.json, 자동 파일 포함/글로빙 및 전이적 복원은 ASP.NET Core에 대한 첫 번째 요소로 저를 "오, 멋지다!"하게 만들었습니다. 처음에.

나는 그 모든 것이 사라지지 않을 것이라는 것을 알고 있습니다(희망?). 그러나 XML 프로젝트 파일로 돌아가는 것은 기분이 좋지 않습니다. 역사적으로 이것은 인간에게 골칫거리였습니다. 나는 csproj 파일이 구문 분석하기 어려운 텍스트의 벽이기 때문에 문제를 해결하기 위해 여는 것을 싫어합니다.

그냥 내 2 센트.

@poke 게시물의 변경 사항을 보면 기본적으로 csproj를 json으로 변환한 것처럼 보입니다.

Compile, Embed, CopyToOutput, Exclude, Shared Files 등의 옵션을 지원하기를 원한다는 사실을 기반으로 하면 실제로 json 형식은 어쨌든 XML보다 더 잘 작동하지 않을 것입니다. 나는 또한 json이 무거운 빌드 스크립트 사용자 정의에 대해 잘 작동하지 않았을 것이라고 생각합니다.

나는 이것이 그들이 그것을 잘 할 수 있는 방법을 알아낼 시간을 가질 수 있을 때까지 프로덕션에 아직 반쯤 구운 솔루션을 추가하지 않으려고 노력하는 팀이 되기를 바랄 뿐입니다.

@gregoryyoung 당신이 제공한 것은 정상적인 토론에 유용하지 않습니다.

엄청난. 좋아, 내가 무엇을 제공했는지 보자.

• 나는 다른 많은 사람들과 마찬가지로 XML로의 이동에 대해 불평했습니다.
• 나는 MSBuild로의 이동에 대해 불평했습니다.
• 나는 결정의 배후에 있는 이유와 증거를 이해하려고 노력했습니다.
• 나는 _또한_ 실제로 제공되지 않은 결정 뒤에 숨겨진 _생각_에 접근하려고 노력했습니다.
• 커뮤니티에 의견을 요청했지만 MS는 전혀 신경 쓰지 않았습니다.
• 나는 이유를 제시하는 사람들이 말한 결과를 허용하면서도 커뮤니티가 즐기는 간단한 빌드 프로세스를 유지하도록 허용하는 대안을 생각해내려고 노력했습니다.
• 나는 상기 대안을 지원하기 위해 필요한 작업을 수행하겠다고 제안했습니다.

무슨 미친 부분이 궁금해서 여쭤봐도 될까요? 요즘 누군가의 생각을 묻는 것은 합리적이지 않습니까? 아니면 내가 거기에 뭔가를 남겨 놓았습니까?

내 말은, 내가 화가 났어요, 오해하지 마세요. 나는 성급하고 제대로 생각하지 못한 움직임으로 보이는 마지막 순간에 빼앗긴 프레임워크의 핵심 약속을 중심으로 많은 작업, 시간 및 돈을 낭비했습니다. 나는 화를 낼 _권리_가 없는가?

추신. 아, 당신이 바로 그렉 영입니다. 존경. 당신의 일을 사랑합니다. 정말이야.

@bzbetty 전적으로 동의합니다. 마지막으로 보고 싶은 것은 MSBuild를 project.json으로 재구성하는 것입니다. 현재 형태의 MSBuild의 가장 큰 문제 중 하나는 _프로젝트 정의_를 _빌드 프로세스_와 결합한다는 것입니다.

따라서 빌드 프로세스를 project.json에 추가하는 것은 MSBuild/VS가 저지른 것과 똑같은 실수를 하게 됩니다.

프로젝트 정의는 빌드 프로세스와 별도로 있어야 하며 빌드 프로세스에 제공되어야 합니다.

그런 다음 질문해야 합니다. 프로젝트가 단순하고 프로젝트 정의를 직접 빌드해야 하는 경우 간단한 빌드를 수행하기 위해 강력하고 확장 가능하고 사용자 정의 가능하고 유연하고 직관적이지 않은 빌드 시스템이 정말로 필요합니까?

다른 방법으로 넣어. 그런 간단한 프로젝트 정의와 프로젝트 정의를 빌드하는 것 외에는 아무 것도 할 수 없는 매우 간단한 빌드 도구를 _가지고 있는_ 경우 MSBuild 또는 NAnt 등을 설치하고 사용하기로 선택하시겠습니까?

아니, 아마 아닐거야, 그렇지? 복잡성에 불필요하게 추가하는 이유를 의미합니다. 효과적인 소프트웨어 엔지니어링 실습의 핵심 부분은 일을 단순하게 유지하는 것입니다.

그러나 간단한 "정의 작성" 도구가 처리할 수 없는 시나리오에 도달했다면? 물론 _그렇다면_ 그럴 겁니다.

두 도구를 나란히 설치하면 필요에 가장 적합한 도구를 선택할 수 있습니다. MS는 다음과 같이 말합니다. 아니요. 복잡하고 직관적이지 않은 도구만 있으면 됩니다. 하지만 가장 심하게 나쁜 기능은 제거하겠습니다.

비누 상자

제가 하고 있는 약간의 연구를 공유하고 싶습니다. 저는 Twitter, Slack, Github, Gitter, Jabbr을 보고 있습니다.

핵심 팀 외부로의 이동에 대한 지원은 거의 없었습니다. 내 말은, 약간은 있었지만 많지는 않았습니다. 대부분의 사람들은 그 움직임에 대해 상당히 화를 내고 있습니다.

나는 또한 친 MSBuild 진영의 많은 사람들이 상대방이 잘못된 정보를 얻거나 더 일반적으로 자격이 없다고 추론하는 경향에 상당히 실망했습니다. 이것은 pro-project.json 진영에서 좋지 않은 동기를 추론하는 경향과 일치했습니다(저를 포함하여, mea culpa).

다음과 같이 묻고 싶습니다.

• 사람들은 자신의 의견과 다른 의견을 가진 사람들이 정당한 이유가 있다고 생각합니다. 그들은 속이거나, 무능하거나, 공모하거나, 미쳤지 않습니다.
• 사람이 아니라 주장 과 증거 를 공격하는 사람
• 제공된 증거는 확고한 이유 없이 즉시 기각되어서는 안 됩니다.

에 대한 인수
MSBuild로의 이동에 대해 고급화된 주요 이유는 다음과 같습니다.

• 도구 지원 - 서로 다른 도구(예: VS, VSCode, Xamarin 등) 간의 왕복을 허용합니다.
• 기존 투자 - 대규모 고객은 폐기할 여유가 없는 기존 빌드를 보유하고 있습니다.
• "근육 기억" - 사람들은 MSBuild에 익숙합니다.

반대 주장

• 기존 투자 - .NET Core 도구에 대한 투자: RC 이후. RC _should_는 주요 변경 사항이 없음을 의미합니다.
• CSProj/MSBuild 불쾌한 - csproj 및 MSBuild를 다룰 때의 과거 부정적인 경험
• 뒤로 단계 - project.json으로 이동은 부분적으로 새로운 세대의 개발자를 끌어들이기 위한 새로운 작업 방식으로 이동했습니다. 취소 중입니다

의견
전체 SurveyMonkey 구독료를 지불하여 전체 결과 집합에 액세스할 수 있습니다(100개 100개가 아닌). 321개의 응답으로, 일반적으로 9백만 인구에 대해 ±5.5% 오차 한계, 95% 신뢰로 해석됩니다.

이 설문조사에 대해 제가 들은 일반적인 주장은 다음과 같습니다.

• 질문/답변은 편향되어 있습니다. 나는 그것을 믿지 않으며, 그렇다고 해도 그다지 많지 않습니다. 광범위한 답변이 존재합니다.
• 설문조사는 편향된 청중에게 게시되었습니다. Twitter? 다양한 팀원 타임라인의 추종자에게. 그것이 어떻게 편향된 청중인지 확실하지 않습니다.
• 과학적으로 관련이 없음: 알겠습니다. 나는 완전한 연구 프로토콜을 수행하지 않았으므로 피어 리뷰를 통과하지 못했습니다. 그것이 제안에 대한 지지를 측정하는 데 필요한 확실성 수준입니까?

여기 있습니다:

.NET 프레임워크를 사랑하는 사람에게 호소하는 바는 이러한 변경 사항에 대한 우려의 수준을 과소평가하지 말고, 문제가 유효하고 정보에 입각한 경험에서 비롯된 것이라는 점을 기반으로 커뮤니티에 피드백을 제공하고 이에 대해 커뮤니티에 참여하는 것입니다. .

그리고 결정이 계속 진행된다면 지금까지보다 더 나은 추론과 증거가 제공되어야 합니다.

Man @shederman 은 Silverlight가 그것을 먹었을 때 저와 다른 많은 사람들을 생각나게 경우 는 예외입니다. 내가 그를 지지하는 이유일 것이다 :100:%! ㅋ.

현재 형태의 MSBuild의 가장 큰 문제 중 하나는 프로젝트 정의를 빌드 프로세스와 결합한다는 것입니다.

따라서 빌드 프로세스를 project.json에 추가하는 것은 MSBuild/VS가 저지른 것과 똑같은 실수를 하게 됩니다.

프로젝트 정의는 빌드 프로세스와 별도로 있어야 하며 빌드 프로세스에 제공되어야 합니다.

:+1: :+1: :+1: ... 문제를 구성하는 탁월한 방법!!! 알다시피, 나는 이것에 너무 오랫동안 코를 가두어 왔고 이것은 나에게 실제로 일어난 적이 없습니다. 그러나 당신은 (다시) 100% 요점에 있습니다.

나는 csproj 파일이 구문 분석하기 어려운 텍스트의 벽이기 때문에 문제를 해결하기 위해 여는 것을 싫어합니다.

이것은 어딘가에 액자가 필요합니다, @nbarbettini! 내 감정도 완벽하게 포착합니다.

그리고 실제로 파일 형식이 JSON, XML 또는 무엇이든 간에 그다지 중요하지 않아야 합니다.

예, 저는 사람들에게 이것을 상기시키려고 하는 것을 싫어하지만 일부 개발자는 형식의 개념에 집착하는 것 같으며 이는 오해의 소지가 있습니다. "JSON" 프로젝트 패러다임은 실제로 "JSON 것"이 아니라 JSON을 직렬화의 선택으로 사용하여 "모델"을 설명합니다. JSON이 XML보다 간결하고 덜 수다스럽다는 사실은 그것을 (대부분의 사람들에게) 더 매력적으로 만들었습니다.

이에 따라 MSBuild는 그 자체로 XML을 기반으로 하지 않지만 디자인된 방식은 "모델"이 이 형식으로 설명되도록 하는 것입니다. 내가 "모델"이라고 말하는 이유는 두 시스템 모두 궁극적으로 메모리로 역직렬화되는 실제 모델/API 앞에 문서 모델을 배치하는 설계 결함이 있기 때문입니다. 즉, 실제로 필요한 것보다 더 많은 아티팩트와 개념을 관리해야 하고 궁극적으로 시스템이 복잡해집니다. 특정 형식(XML 또는 JSON)만 허용하도록 하드코딩하면 상황이 악화될 뿐이므로 이 제약을 완화하는 방법을 다시 모색해야 합니다.

여하튼, 모두를 위한 절름발이 일요일 아침 PSA. :stuck_out_tongue:

이 스레드의 어디에도 게시된 것을 볼 수 없었으므로 여기로 이동합니다... https://youtu.be/N9MteJH-HsQ. 변경 사항이 적용되는 이유에 대해 조금 더 설명할 수 있기를 바랍니다.

@shederman

"흥분해서 여쭤봐도 될까요? 미친 부분이 뭐죠? 요즘은 남의 생각을 물어보는 게 비합리적인가요? 아니면 제가 뭔가를 남겨둔 건가요?"

나는 설문 조사 결과를 참조하고 일반 개발자 모집단에 외삽하려고 했습니다. 내가 언급했듯이 이것은 고양이 장난감 대회에서 개와 고양이가 더 나은 투표를 실시하는 것과 대략 동일하며 전체 인구에 적용된다고 가정할 때 크고 명백한 표본 편향이 있습니다.

내 전화의 GitHub에서는 @gregoryyoung을 +1할 수 없지만 +1할 수 있습니다.

팀은 변화의 원인 중 일부가 Xamarin 인수라고 설명했는데 이는 큰 일입니다. .NET, ASP.NET 및 Xamarin 모바일/x-plat 프로젝트 간에 라이브러리를 공유할 수 있는 가능성은 엄청나며 이것이 프로젝트/빌드 파일 형식을 손상시키는 것을 의미한다면 IMHO를 거래할 가치가 있습니다.

나는 최종 의견을 형성하기 전에 도구와 최종 파일 설정이 어떻게 보이는지 지켜볼 것입니다.

@gregoryyoung 설문조사 결과를 참조하여 일반 개발자 집단으로 추정하려고 했습니다... 크고 명백한 표본 편향이 있습니다.

어떤 표본 편향이 될까요? 변경 사항을 _좋아하는_ 사람들의 Twitter 피드에 주로 게시된 곳은 무엇입니까? dev 팀이 사용하는 slack 채널에 있었던 곳은 무엇입니까?

내가 보는 주요 샘플 편견은 응답자가 아마도 참여하고, 정보를 알고, 열정적이라는 것입니다. 물론 대표적인 표본은 아니지만 중요한 표본이라고 주장하고 싶습니다. 표본 편향이 있더라도 결과를 버려야 한다는 의미입니까? 응답자의 관점이 중요하지 않다고요?

322명의 전문 .NET 개발자가 의견을 표명했습니다. (당신을 뒷받침할 어떤 증거도 없이) 그것이 대표성이 없다고 믿기 때문에 그들의 의견을 완전히 무시하시겠습니까?

분명히 다음 주에 블로그 게시물이 올라올 것이며 그때 더 구체적인 내용을 논의할 것입니다.

이런 사람들은 정신을 차려야 해요:)

나는 이 변화가 큰 것처럼 보인다는 데 동의하지만 사람들에게 보이는 것보다 훨씬 덜 영향을 미칠 것이라고 생각합니다. 팀이 cli도 포함하는 "도구"에 대해 이야기할 때 기억하십시오. 발생해야 하는 모든 변환은 참조를 추가하기 위한 "도구"인 cli에서도 수행되며, json 또는 xml에 입력하는 것보다 훨씬 낫다고 주장하며 cli에 있을 것입니다. 글로빙은 이미 msbuild에서 지원됩니다. Msbuild는 분명히 don't sdk에 포함될 것이므로 추가 설치가 없고 새 프로젝트 스토리도 동일하며 dotnet 명령은 내부에서 다른 작업을 수행합니다. (저는 마이크로소프트는 아니지만 이것은 가능성이 매우 높아 보입니다)

팀은 바보가 아닙니다. 그들은 이 변화를 가볍게 만들지 않습니다. 그들은 언어, 기본 참조 및 프로젝트 유형, 너겟 패키지의 세분성 등에 걸쳐 플랫폼의 나머지 부분과 주로 호환성 및 일관성을 _가지고_ 있습니다. 일주일 밖에 지나지 않았으며 곧 변경 사항과 추론을 자세히 설명할 것이라고 말했습니다.

사람들이 적어도 그 움직임을 완전히 비난하기 전에 실제 계획이 무엇인지 기다려 주셨으면합니다.

그리고 예, csproj/tfproj 파일을 수동으로 디버깅하고 파일 포함 및 그 모든 것에 대한 조건부 규칙과 싸웠습니다. 젠장, 사용자 정의 빌드 작업도 작성했습니다. 그러나 하루가 끝나면 비교적 단순한 project.json 시스템이 지원해야 하는 모든 복잡한 시나리오를 지원하도록 만드는 것보다 간단한 도구(cli 포함)로 복잡한 시스템을 추상화하는 것이 훨씬 쉽습니다.

다시 말해서 project.json에서 사람들이 좋아했던 단순함은 이미 사라졌고 모든 종류의 프로젝트와 시나리오가 있는 일반화된 닷넷 환경의 복잡한 현실을 지원해야 했습니다. 그들이 모든 것을 project.json에 구현했다면 기본적으로 msbuild를 다시 갖게 될 것입니다. 나는 그들이 큰 스파게티 공이 될 때까지 project.json에 기능을 추가하는 것보다 한 걸음 물러서서 빌드 시스템을 전체적으로 보는 것을 훨씬 선호합니다.

그들이 제안하는 내용을 확인한 다음 문제를 발견하면 특정 문제를 제기하십시오. :)

@aL3891

팀에서 자신의 추론과 고려된 대안, 그리고 거부된 이유를 명확하게 설명하고 여기에 제안된 제안을 고려하고 참여한다면 저는 그와 함께 할 것이며 다음과 같은 합리적인 솔루션을 지지할 것입니다. 그런 과정에서 나옵니다.

사실, 이것이 바로 내가 3일 동안 요구했던 것입니다. 의사 결정 과정과 이를 뒷받침하는 증거에 대한 통찰력. 이와 관련하여 지금까지 제공된 정보는 기껏해야 압도적입니다.

우리가 그것을 얻는다면, 나에게서 +10.

@aL3891 빠른 질문입니다. 어떤 사람들은 우리가 이러한 문제를 해결하기 위해 수요일 스탠드업에 참석해야 한다고 말했습니다. 블로그 게시물을 기다려야 한다는 말씀이신가요?

모든 사람은 이것이 모두 오픈 소스임을 기억해야 합니다. 비 msbuild가 더 낫다고 강하게 느끼면 기존 도구를 분기하고 계속 진행하십시오. 모든 흥미로운 소프트웨어 디자인 선택과 마찬가지로 논쟁의 모든 측면에 대한 찬반 양론이 있습니다. 마이크로소프트는 큰 돈을 지불하는 고객에게 반응해야 하지만 그들의 신용에 따라 이 모든 것을 오픈 소스로 만들었습니다. 다른 것이 당신을 위해 작동한다면 그것을하십시오.

@khellang이 게시한 YouTube 비디오를

게다가, 바퀴를 재발명한다는 아이디어는 매력적이지 않은 것 같았습니다. 그것이 실제로 옳은 일인 것처럼 보였을 때...그러나 다시 유산이었습니다.

.NET 스탠드업을 기반으로 하는 MSBuild 사용에 대한 새로운 비판이 있습니다. 하지만 우리는 여러 곳에서 문제를 잘 구분하고 있지만 MSBuild는 그렇지 않습니다. 대략적으로 스탠드업에 따르면 효과적이기 위해서는 모든 것에 대해 어떻게든 알아야 하며 단순히 다른 부분을 오케스트레이션하는 것만으로는 충분하지 않습니다.

한편, 나는 이것이 다른 스레드에 있어야 한다고 생각합니다. 나중에 커뮤니티와 공유되는 "내부 엔지니어링 결정"이 있는 것 같습니다. 이것은 MS가 완전히 오픈 소스를 얻지 못한다고 생각하게 만듭니다. 만약 그들이 이러한 토론을 공개적으로 했다면(그리고 사람들이 이러한 논의가 일어나고 있다는 사실을 알게 했다면) 덜 놀라웠을 것이고 우리는 이미 답을 얻었을 것입니다. 많은 이해 관계자(MSBuild에서 멀어짐으로 인해 부정적인 영향을 받는 고객)가 더 일찍 자신의 입장을 분명히 알릴 수 있었고 커뮤니티는 문제/우려 사항 및 솔루션에 대해 보다 시기 적절한 방식으로 대응할 수 있었습니다. 제시된 문제들...대신 "그것이 우리의 유일한 선택"이었습니다. 이것이 당신이 소프트웨어뿐만 아니라 개발 프로세스도 오픈 소스로 만드는 이유입니다. 이것은 "충분한 안구를 제공하면 모든 버그는 얕다"라는 격언이 작동하는 방식입니다. MS의 엔지니어링 팀이 얼마나 큰지는 모르겠지만 전체 커뮤니티보다 작으며 커뮤니티에는 엔지니어링 팀이 작업할 수 없다고 결정한 것과 같은 도전에 직면할 수 있는 진지하게 좋은 인재가 있습니다. ...아마도 그들을 위한 것이지만 커뮤니티 전체는 아닙니다. 오픈 소스는 아직 개발되지 않은 자원과 재능을 활용하는 것입니다.

반면에 내가 어딘가에서 뭔가를 놓친 것은 아닐까?

@shederman 저는 기득권을 가진 사람들이 스탠드업에 참석하고 블로그 게시물(거의 확실히 여기에 링크될 것입니다)을 주시할 것을 제안합니다.

스탠드업을 모르는 사람들은 여기로 이동하십시오: https://live.asp.net/

캘린더에 추가할 수 있으며 프로젝트 정의 변경에 신경 쓰지 않아도 볼 가치가 있습니다.

@shederman 저는 제가 누구에게 무엇을 해야 할지 말할 권한이 없다고 생각하지만 제가 무엇을 할

위에 링크된 최신 on.net 에피소드 는 몇 가지 좋은 통찰력을 제공했습니다.

앞으로 몇 달 동안 많은 조치를 취할 가능성이 가장 높은 roslyn 프로젝트 시스템 리포지토리 도 있습니다.

누군가 on.net 에피소드에 TL;DR을 가지고 있습니까?

나는 프로그래밍에 관한 비디오를 보는 것을 _싫어하는_ 매우 이례적이라고 생각합니다. 언제든 문자주세요😄

빌어먹을 지옥불! 저는 학습 방법에 있어서 IDE가 아닙니다. 😱

나는 프로그래밍에 관한 비디오를 보는 것을 매우 싫어한다고 생각합니다. 언제든지 문자 주세요 :스마일:

뭐가 문제 야? 시간은 _단_ 한 시간입니다. :이를 드러내고 웃다:

@rhires

녀석. 그것은 아마도 지난 3일 동안 이 문제에 관해 본 가장 좋은 게시물 중 하나일 것입니다!

최첨단 기술을 유지하기 위해 지불해야 하는 작은 가격이지만 각자의 비용입니다. ;)

기본 정보:
팀은 xamarin과 같은 내부 고객과 외부 고객 모두로부터 기존 프로젝트를 project.json으로 마이그레이션하는 것이 어렵다는 피드백을 받기 시작했고 project.json이 기존 프로젝트는 물론 네이티브 및 기타 도구 체인과 같은 다른 도구 체인과 함께 작동하도록 했습니다. Android와 같은 플랫폼은 msbuild에서 상당한 양의 코드(또는 개념)를 가져오는 것을 의미합니다. 이것은 많은 시간과 노력이 필요하고 수용할 수 없는 시간만큼 릴리스를 미루고 향후 작업(xamarin 스튜디오 및 모노 개발과 같은 다른 제품 및 Visual Studio 플러그인 개발자 포함)을 지연시킵니다.

그래서 대신 그들은 msbuild를 기반으로 빌드 시스템을 선택했지만 사람들이 좋아하는 것을 새 시스템에서 가져왔습니다. 타이밍에 관해서는, RC1이 만들어졌을 때도 xamarin 인수는 알려지지 않았지만 지금은 많은 것을 바꿨습니다.

그들은 또한 사람들이 project.json을 매우 좋아한다는 사실을 알고 있으며, 그 장점을 최대한 유지하기를 원합니다. 아마도 msbuild가 대상을 통해 project.json 파일도 읽을 수 있도록 할 수도 있습니다. Cli 및 VS-less 시나리오도 핵심 시나리오로 간주됩니다. 그들은 또한 다른 빌드 시스템에 대해 약간 이야기하며 목표는 사람들이 원하는 경우 msbuild 이외의 다른 것을 사용할 수 있도록 하는 것입니다.

그런 다음 그들은 RC2와 거기에 포함된 내용에 대해 조금 이야기하고 프로젝트 시스템 마이그레이션과 관련하여 다르게 할 수 있었던 일, 더 일찍 공개하고 GitHub 등에서 더 많은 대화를 나누는 것에 대해 생각합니다.

나는 그것을 보는 것이 좋습니다. 아마도 여기에 더 미세한 포인트가 누락되었을 것입니다.

@aL3891 - 훌륭한 요약에 감사드립니다. 영상으로 넘어가는 슬로건이었습니다. 나는 그들이 텍스트 요약을 작성해야 한다는 데 동의합니다. 나는 그들이 "배우고" 있고, 그들이 좋은 일이라고 말하면서도 여전히 자신의 과정을 공개하는 데 불편함을 느낀다는 것을 알아차렸습니다. 따라서 이것이 그들에게 좋은 학습 경험이 되기를 바라며 우리는 변화를 보고 그 수혜자가 될 것입니다.

@aL3891 요약 감사합니다!

최첨단 기술을 유지하기 위해 지불해야 하는 작은 가격이지만 각자의 비용입니다. ;)

아,하지만 나는 출혈 가장자리에 아니에요, 나는 거기에서 약간의 뒷면을 유지. 나 자신을 자르지 않을 만큼 충분히 뒤로, 또는 적어도 RC1 이후 .NET Core를 채택했을 때 생각했습니다.

@shederman 은 "post-RC1"이 기본적으로 nightlies 또는 소스라는 점을 감안할 때 스테이크를 정확히 어떻게 좋아합니까?

@neoKushan 저는 RC1이 출시된 이후에 .NET Core를 "채택*했습니다*. 우리는 여전히 바닐라 RC1을 사용 중입니다.

그래서 우리는 스테이크를 미디엄 레어로 좋아합니다. 그러나 우리는 요리하지 않은 한 조각으로 자르고 웨이터를 위해 소리치고 있습니다.

하지만 괜찮습니다. 웨이터에 대한 전화를 중단하고 이제 maitre'd(Microsoft 그룹 Microsoft 파트너 담당자)에게 전화를 걸어 저를 만나러 와서 의사 결정, 정보 보급 및 플랫폼 방향에 대해 논의할 수 있습니다.

우리는 아무것도 모른다!

우리는 이 문제에 대해 충분한 정보, 너무 많은 이론과 추측을 받지 못했습니다. 이 스레드를 읽고 싶지 않은 게으른 사람들을 위한 빠른 요약:

우리가 알고 있는 것

1. xproj는 csproj로 변환됩니다.
2. nuget.json 파일이 있을 수 있습니다.
3. 우리는 msbuild 있습니다.
4. 이것은 모두 단계적으로 일어날 것입니다.
5. 라이브러리는 변경되지 않습니다.
6. csproj의 모든 파일을 지정할 필요는 없습니다.

우리가 아직 모르는 것

1. csproj가 .nupkg로 컴파일됩니까?
2. csproj가 x86/x64 dotnet/dotnetcore에서 한 번에 여러 아키텍처 및 대상으로 컴파일됩니까?
3. 별도의 nuget.config 파일이 있습니까?
4. npm/gulp/bower/etc.를 실행하기 위한 명령은 어떻게 처리됩니까?
5. dotnet build 뿐만 아니라 msbuild 있습니까? 저는 @shanselman이 열망하는 '하나의 .net'을
6. 프로젝트 참조용 인텔리센스가 유지됩니까 아니면 사라질 것입니까?
7. VS 도구 또는 명령줄이 csproj를 편집할 필요가 없을 만큼 충분히 좋습니까?
8. dotnet add reference MyAssembly 도구를 얻을 수 있습니까?

나는 우리가 더 많은 정보를 얻을 때까지 이 문제를 닫아야 한다고 생각합니다.

저는 @shanselman이 열망하는 '하나의 .net'을

이거 ? :스마일: :+1: :+1: :+1:

나는 우리가 더 많은 정보를 얻을 때까지 이 문제를 닫아야 한다고 생각합니다.

하지만 하지만... 그럼 난 내 인생을 어떻게 할까??? :울다::웃는다:

@RehanSaeed

"우리가 알고 있는 것" 목록에 문제가 있으면 어떻게 합니까?

우려 사항을 제기하기 전에 "아직 모르는 것" 목록이 명확해질 때까지 기다려야 합니까?

아니면 그냥 닥치고 빨아야 할까요?

많은 분들이 원하시겠지만... 😉

내가 본 모든 것에서 결정은 100%이며 다음에서 변경할 수 없습니다.

그렇다면 "우리가 아직 알지 못하는 것"에서 더 이상 무엇이 필요합니까?

@shederman On.Net 비디오를 보고 싶을 수도 있습니다. 그것은 결정 뒤에 많은 추론을 제공합니다.

fyi: 저는 보통 더 빨리 보기 위해 속도를 1.5로 변경합니다. https://www.youtube.com/watch?v=N9MteJH-HsQ

XML 기반 프로젝트 파일을 계속 사용하려는 경우 도구가 파일 내용을 어떤 종류의 순서로 배치하도록 제안/권고/요구할 수 있는지 부탁드립니다. 그리고 "시간순"은 허용되는 순서가 아닙니다. 내가 proj 파일에서 발견한 가장 큰 고통은 파일을 병합하는 데 어려움이 있다는 것입니다. 최소한 알파벳순으로 정렬하십시오. 예, 여전히 가끔 병합 문제가 발생하지만 언제든지 "편재하는" 대신 "가끔"으로 처리하겠습니다.

@MelGrubb 우리가 알고 있는 한 가지는 새 프로젝트 레이아웃이 존재하는 모든 파일을 나열하지 않으며 project.json이 수행하는 것과 같습니다.

손으로 관리할 것으로 예상되는 모든 것은 TOML로 문의하십시오.

JSON은 구성에 대해 아무 의미가 없습니다. XML보다 훨씬 덜 의미가 있습니다.

관심 있는 사람은 RC2 비트를 사용할 수 있는 것처럼 보입니다(아직 볼 수 있는 블로그 게시물이 없음).

https://www.microsoft.com/net/core#windows

및 https://www.microsoft.com/net/download#core

내 2센트, fwiw:

나는 project.json의 단순함을 좋아했습니다. 다음은 MSBuild 기반 도구에서 보고 싶은(그리고 원하지 않는) 것입니다.

• MSBuild는 VS 또는 다른 IDE/편집기에 연결되어서는 안 됩니다. 자체적으로 설치할 수 있는 독립 실행형 도구여야 합니다. (또는 dotnet cli 설치의 일부로 포함됩니다.) 이 말은 단지 MSBuild를 얻기 위해 빌드 에이전트에 전체 VS 인스턴스를 설치해야 했기 때문입니다. 그것은 나에게 결코 의미가 없었다.
• MSBuild(또는 MSBuild가 포함된 dotnet cli) 자체는 apt-get, chocolately, homebrew, powershell 또는 bash/curl 여부에 관계없이 명령줄을 사용하여 설치할 수 있어야 합니다. 빌드 에이전트의 완전 자동화된 설정(예: circle.yml 또는 Dockerfile)의 일부로 이것을 설치할 수 없으면 장애물이 되고 고통의 원인이 됩니다.
• MSBuild는 명령줄에 매우 친숙해야 합니다. 나는 커맨드 라인에서 무엇이든 할 수 있어야 합니다. 따라서 circle.yml, bash 또는 기타 스크립트 파일에서 빌드 프로세스의 모든 것을 자동화할 수 있어야 합니다. 그리고 stdin과 stdout을 잘 사용하여 MSBuild 명령을 파이프 인/아웃할 수 있기를 바랍니다.
• VS Code(또는 다른 비 VS 편집기)에서 .NET Core 프로젝트에서 작업할 때 csproj 파일이나 다른 곳에서 VS 관련 정보가 필요하지 않아야 합니다. 프로젝트 정보, 너겟 패키지 종속성, 플랫폼 대상, 컴파일러 지시문 등은 다른 IDE/편집기를 사용하는 개발자 간에 공유할 수 있어야 합니다. 그것들은 프로젝트 파일에서 의미가 있습니다. 그러나 VS를 사용하지 않는 사람들은 VS 도구 설정을 볼 필요가 없습니다. 이는 별도의 파일에 속합니다.
• 프로젝트 파일은 이해하기 쉽고 손으로 쉽게 편집할 수 있어야 합니다. 도구는 훌륭하지만 파일을 열고 도구가 무엇을 하는지 이해할 수 있어야 합니다. 그리고 쉽게 변경할 수 있습니다.
• 기능/능력에 차이가 없다는 것을 알고 있지만 xml보다 json에 대한 강한 개인적 선호가 있습니다. 또한 json을 사용하면 다른 스택에서 오는 개발자를 유치하는 데 도움이 될 것이라고 생각합니다. 사람들이 해독하기 어려운 큰 XML 파일을 가장 먼저 보지 않고 .NET으로 끌어들이는 것은 충분히 어렵습니다. (이것은 논리적인 것보다 더 감성적이지만 중요하다고 생각합니다.) 최소한 json을 옵션으로 만들고 yoman Generator 및 기타 새 프로젝트 템플릿에서 해당 옵션을 사용하십시오. 최악의 경우 MSBuild 리포지토리에서 간단한 json 형식을 구현하는 불가피한 pull 요청을 빨리 수락하십시오.
• npm 스타일의 "스크립트"를 유지하는 것이 좋을 것이므로 개발, 테스트, 디버그, 빌드, 실행, 도커 빌드/실행 등에 사용되는 명령을 팀과 쉽게 공유할 수 있습니다. 그것들은 자체 스크립트 파일에 들어갈 수 있지만 프로젝트 파일의 일부로 (저에게는) 의미가 있습니다.

@jtbennett

"하지만 VS를 사용하지 않는 사람들은 VS 도구 설정을 볼 필요가 없습니다. 이러한 설정은 별도의 파일에 속합니다."

추가하기 위해 이제 msbuild 파일에 넣어야 할 다른 파일에도 많은 항목이 있습니다. 무시된 것은 프로젝트 파일이 계속 지원된다는 좋은 예입니다. VS에서 빌드했지만 명령줄에서는 볼 수 없는 프로젝트가 몇 개인지 말할 수 없습니다.

@jtbennett

MSBuild는 VS 또는 다른 IDE/편집기에 연결되어서는 안 됩니다.

VS에 전혀 연결되지 않고 Nuget을 통해 전달되므로 아무 것도 연결되지 않습니다.

MSBuild(또는 MSBuild가 포함된 dotnet cli) 자체는 명령줄로 설치할 수 있어야 합니다.

이것은 오늘부터 변경되지 않으며 일반적인 패키지 소스를 통해 여전히 dotnet cli를 설치할 수 있습니다.

MSBuild는 명령줄에 매우 친숙해야 합니다.

_MSBuild_는 효과적으로 빌드 자체의 일부이므로 명령줄 옵션을 전달할 필요가 없다고 생각합니다. 그러나 dot(CLI)는 분명히 명령줄 친화적이며 이것이 당신이 원하는/필요한 전부라고 생각합니다.

VS Code(또는 다른 비 VS 편집기)에서 .NET Core 프로젝트에서 작업할 때 csproj 파일이나 다른 곳에서 VS 관련 정보가 필요하지 않아야 합니다.

나는 이것에 완전히 동의합니다. "새로운" 프로젝트 형식이 훨씬 더 단순화되기를 바랍니다.

프로젝트 파일은 이해하기 쉽고 손으로 쉽게 편집할 수 있어야 합니다.

그들은 이것이 그들에게도 우선순위라고 말했습니다.

기능/능력에 차이가 없다는 것을 알고 있지만 xml보다 json에 대한 강한 개인적 선호가 있습니다. 또한 json을 사용하면 다른 스택에서 오는 개발자를 유치하는 데 도움이 될 것이라고 생각합니다. 사람들이 해독하기 어려운 큰 XML 파일을 가장 먼저 보지 않고 .NET으로 끌어들이는 것은 충분히 어렵습니다.

개인적으로 XML이 JSON보다 해독하기가 훨씬 더 쉽다고 개인적으로 생각하지만 그 중 많은 부분이 스키마(둘 중 어느 쪽이든)가 얼마나 잘 설계되었는지에 달려 있다고 생각합니다. 저는 과거에 "Element"와 같은 정말 끔찍한 요소 이름을 사용하여 정말 끔찍한 XML을 해독해야 했습니다. MSBuild가 그런 면에서 결코 최악의 범죄자는 아니지만, 확실히 많은 부분이 필요합니다. JSON을 사용하면 키 이름에 동일한 문제가 발생할 수 있습니다.

일화적으로, 나는 최근 누군가가 JSON을 XML 요소에 포함시키려는 프로젝트에서 작업해야 했습니다.

RC2 블로그 게시물이 올라왔습니다: https://blogs.msdn.microsoft.com/webdev/2016/05/16/announcing-asp-net-core-rc2/

.net 코어 게시물도 올라갑니다 https://blogs.msdn.microsoft.com/dotnet/2016/05/16/announcing-net-core-rc2/

@neoKushan 감사

@michaelvolz 나는 https://github.com/dotnet/cli/blob/rel/1.0.0/Documentation/specs/runtime-configuration-file .md

System.GC.Server(이전: gcServer) - 서버 GC를 사용해야 하는지 여부를 나타내는 부울(기본값: true).

그리고

deps 파일에 다른 형식을 사용할 수 있지만 이미 JSON 파서를 호스트에 통합하고 있다면 여기에서 다시 사용하는 것이 가장 적절해 보입니다.

_project config_에는 XML이 있지만 _runtime config_에는 .json이 있는 것이 약간 이상해 보입니다.

프로젝트에는 XML을 사용하지만 런타임에는 .json을 사용하는 것이 약간 이상하게 보입니까?

지금 합니까? :웃음:

@Mike-EEE 좋은 지적! 나는 내가 의미하는 바를 명확히 하기 위해 업데이트했습니다:키스:

@neoKushan 아니 처음에는 당신이 옳았습니다. :smile: 나는 내 냉소적이고 경계선에 비생산적인 방식으로 당신과 동의했습니다. :smirk_cat:

하지만 예... 솔루션 내에서 다른 형식을 사용하는 것은 미친 짓이라는 데 100% 동의합니다. 전반적으로 단일 형식을 사용하면 복잡성, 컨텍스트 전환, 따라서 _혼란_이 줄어듭니다. MSBuild가 다른 형식을 활성화하고 형식에 구애받지 않는 것을 보고 싶은 이유 중 하나입니다. 앗, 경고, 뻔뻔한 플러그. :이를 드러내고 웃다:

나는 당신의 성스러운 성전 @Mike-EEE의 추종자가 될 것이라고 생각합니다. 우리는 msbuild에 묶여 있기 때문에 더 좋게 만들겠습니다.

감사합니다 @sandorfr ... 거기에 있는 스레드에 자유롭게 기여해 주세요(리액션/:+1:이더라도). 나는 그곳에서 약간 외로운 느낌이 들고 확실히 경쟁의 영역으로 걸어가고 있습니다! 내 관점에서 볼 때 많은 고객이 어떤 이유에서든 내 제품을 강제로 사용한다면 채택/호감도/사용성/호감도를 높이기 위해 내 제품을 개선하는 데 매우 개방적일 것입니다. 하지만 내가 책임지는 게 아니니까. :stuck_out_tongue:

@Mike-EEE 쓰레드를 읽었는데 지금 너무 우울해요... 당신은 레거시 마인드의 레거시 세계에 발을 들였습니다 :D.

Microsoft의 사람들이 당신의 아이디어에 더 개방적이기를 바랍니다. 일이 더 간단하고 간단하게 만들어지고 내 프로젝트를 편집하기 위해 Gui가 필요하지 않은 경우에만 msbuild를 사용할 수 있기 때문입니다(예, json intellisense가 훨씬 더 좋았습니다. 일반적인 Visual Studio 프로젝트 탭보다).

당신은 레거시 마인드의 레거시 세계에 발을 들였습니다 :D.

Wellllll-said @sandorfr ... wellllll-말했습니다.

스탠드업을 모르는 사람들은 여기로 이동하십시오: https://live.asp.net/

좋아, 나는 완전한 게으름뱅이이고 마침내 이것을 지금 확인했습니다. 다음 스탠드업이 다음주인 것 같죠? 이번 주에 팀이 건너뛰나요?

@Mike-EEE 흥미롭게도 언젠가는 오늘 밤에 확실히 예정되어 있었는데 변경되었는지 궁금합니다. 나는 @shanselman을 트윗 였으면 좋겠지 만 RC2가 어제 나왔기 때문에 이번 주에는 건너뛰고 싶어할 것입니다.

오케이 쿨 @neoKushan ... 제 정신이 한 번만 머리에

슬랙에서:

jongallowway [9:31 AM] ASP.NET Community Standup이 내일 취소될 것이라고 확신합니다. shanselman과 damianedwards는 모두 OSCON에 있습니다.
...
davidfowl [9:34 AM] damianedwards: 돌아왔지만 shanselman은 oscon에 있습니다
...
jongloway [9:46 AM] 네, ASP.NET Community Standup은 5/17로 확실히 취소됩니다. 사이트를 업데이트했습니다.

@Mike-EEE는 우리의 모든 ... 불만을 처리합니다.

😆

의심스러운 점이 남아 있는 경우: https://twitter.com/shanselman/status/732585321775267842

건너뛰어야 합니다. 저는 #vslive와 OSCON에 있습니다.

project.json에서 내가 즐겨 사용하는 것이 한 가지 있습니다. 모든 파일이 프로젝트에 기본적으로 포함되어 있으며, 각 파일을 명시적으로 포함할 필요가 없습니다. 대규모 프로젝트(수천 개의 파일을 의미함)의 경우 병합 프로세스는 XML 때문에 정말 고통스러웠지만 모든 파일이 csproj에 나열되어 있기 때문 이기도 합니다.

이 측면에서 개선 사항이 있는지 알고 있습니까?

@pierrus 모든 파일이 csproj 내부에 나열되었던 시절로 돌아가고 싶지 않다고 언급되었습니다.

@MaximRuiller OK, 그것을 몰랐습니다.

@MaximRouiller하지만 그들은 할 MSBuild에서이 절대 반지 ™, I 평균 빌드 도구했던 일에 다시 가고 싶어. 😉

_애쉬 누더토그 베갈 더바툴루크, 애쉬 누더토그 베갈 김바툴,
애쉬 누드토그 vegal thrakatulûk agh burzum-ishi krimpatul._

@shederman 저는 뉴스에 대한 첫 반응부터 제 관점을 조정했습니다.

내 생각에 그들은 처음에 project.json 형식을 제공하기를 원했지만 csproj/Xamarin으로 모델을 정규화하려면 프레임워크를 더 오래 푸시해야 합니다. 더 빠른 이득은 csproj로 다시 병합하는 것이었습니다. 그들은 csproj 내부에 순수한 "데이터만"을 유지하면서 별도의 파일에 새로운 방식을 유지할 수 있습니다. 그것은 나를 위해 수행된 RC2의 방대한 작업을 설명합니다.

거의 변경되지 않는 속성을 이동하고 멋진 새 기능을 별도의 파일에 보관한다면? 우리는 정말 아무것도 잃지 않습니다. 예, 우리는 괴물에 다시 갈 것입니다... 하지만 우리는 너무 멀리 떨어져 있지 않습니다.

이에 대한 내부 지식이 없습니다. 이것은 순전히 제 추측입니다.

어쨌든... 우리는 더 이상 연간 릴리스 주기로 끝나지 않습니다. 그들이 project.json에서 csproj post-RTM으로 전환할 준비가 되었다면 더 큰 변경 사항이 post-RTM에서도 릴리스될 수 있다고 가정합니다.

MS팀 외에는 아무도 모르는 변화.

@MaximRuiller _ 가능성이 있는_ "가능한" 변경 사항을 처리할 수 없습니다.

저는 발표된 변경 사항을 적용하여 경량 빌드에서 모든 것에 MSBuild 및 xproj를 사용하도록 이동합니다.

예, 우리는 괴물에 다시 갈 것입니다... 하지만 우리는 너무 멀리 떨어져 있지 않습니다.

음, 사용 사례의 90%에서 작동하는 것을 _사용하지 않는__ 사용 사례에 대해 지나치게 복잡한 것으로 _뒤로_ 이동했다면, 한 가지 질문만 하겠습니다.

왜요?

msbuild 이미 이 작업을 잘 수행하고 있는데 dotnet build 가 MSBuild를 호출하는 이유는 무엇입니까? 왜 단순 빌드를 더 이상 사용하지 않습니까? 추가 작업을 하는 이유는 무엇입니까? 유일한 이유는 간단합니다. 우리 모두가 모든 것에 항상 MSBuild를 사용해야 한다는 결정이 내려졌기 때문입니다.

사용 사례의 90%에서 작동하는 것

[인용 필요]

사용 사례의 90%를 가정하더라도 1/10의 시간에 실패한 작업을 수행하시겠습니까?

지나치게 복잡한 것으로 돌아가다

다시 [인용 필요], 우리가 지금까지 알고 있는 유일한 것은 이것이 XML-csproj이고 파일 목록을 포함 하지 않는다는 것

msbuild가 이미 이 작업을 잘 수행할 때 dotnet build가 MSBuild를 호출하는 이유는 무엇입니까?

MSBuild가 "지나치게 복잡하다"는 말에서 "MSbuild는 이미 이 작업을 잘 수행하고 있습니다"로 바뀌었습니까? 현재 dotnet build 는 백그라운드에서 일어나는 모든 일이 여러분에게 숨겨져 있기 때문에 _쉽게 보입니다_. MSbuild로 전환해도 이것은 변경되지 않습니다. 당신이 염려하는 한 여전히 dotnet build 입니다.

프로젝트 시스템과 빌드 시스템 사이에 구별이 필요하다고 계속 말하는 사람의 경우, 실제로 MSBuild XML 파일을 프로젝트 시스템으로 사용하는 것과 MSBuild를 빌드 시스템으로 사용하는 것 사이에 차이가 있다는 사실을 받아들이고 싶지 않을 것입니다. 이미 이별이다.

사용 사례의 90%에서 작동

@shederman 제발 모든 것이 ASP.NET이라고 가정하지

@shederman 무언가 위에 심을 만드는 이유는 그것을 교체하고 싶을 때입니다. 구현을 변경할 수 있도록 추상화하십시오. 우리는 매일 그것을 합니다. 리팩토링이라고 합니다.

교체되기를 바랍니다. XML 외에도 제 기억이 맞다면 다른 것들에 비해 느린 것 같아요.

dotnet build 와 같은 경우 질문은 - 밑줄 빌드 프로세스를 변경하는 것이 얼마나 어려울까요? msbuild를 다른 것으로 대체할 수 있습니까? 얼마나 많은 덕트 테이프가 필요합니까?

우리가 덕트 테이프 1개 또는 2개를 사용하여 그러한 변경을 수행할 수 있다면 충분히 수용할 수 있습니다.

@neoKushan 우리는 MSBuild가 "지나치게 복잡하다"는 말에서 "MSbuild는 이미 이 작업을 잘 수행하고 있습니다"로

음 .. 아니야. msbuild 명령이 MSBuild를 아주 잘 실행한다고 말한 것 같습니다. 저는 MSBuild를 도구로 판단하지 않았습니다. 명확하지 않았습니까?

@neoKushan 사용 사례의 90%를 가정하더라도 1/10의 시간에 실패한 작업을 수행하시겠습니까?

아무도 실패 에 대해 아무 말도

@neoKushan MSbuild로 전환해도 변경되지 않습니다.

음, 빌드 프로세스 번호를 변경하지 않습니다. 그러나 빌드 프로세스가 작동하는 데 필요한 것(예: csproj 파일)과 수행 속도를 변경합니다.

@neoKushan 당신은 실제로 MSBuild XML 파일을 프로젝트 시스템으로 사용하는 것과 MSBuild를 빌드 시스템으로 사용하는 것 사이에 차이가 있다는 사실을 받아들이고 싶지 않습니다. 이미 분리가 있습니다.

죄송하지만 하나의 도구가 두 가지 작업을 수행하는 것이 어떻게 분리되는지 모르겠습니다.

@poke 모든 것이 ASP.NET이라고 가정하지

난 아니다. 제안된 솔루션이 간단한 빌드에서는 잘 작동하지 않는다고 말하고 있습니다. 그 중 일부는 ASP.NET 빌드입니다. 개인적으로 간단한 콘솔 앱에도 MSBuild와 같은 강력한 기능이 필요한 이유를 모르겠습니다.

@poke 당신은 이 스레드에서 의도적으로 무지한 것처럼

그러길 바랍니다. 내가 의도적으로 무지한 것은 MSBuild 사용자에게 발생하는 놀라운 이점이기 때문입니다.

@poke 모든 것이

형, 진정해요 약속할게요.

나는 단지 내가 동의하지 않는 관점이 도전받지 않도록 놔두지 않을 뿐입니다. 동요의 표시가 아님을 약속드립니다. 맙소사, 어떤 꼬맹이 _사람_이 나를 무지하다고 불러도 동요하지 않았어 😉

이 같은 꼬마

정말 재미있다.

@MaximRouiller @shederman 무언가 위에 심을 구축하는 이유는 교체하고 싶을 때입니다. 구현을 변경할 수 있도록 추상화

아 예, 그렇게 하는 것이 좋은 이유 dotnet build 가 기존 라이트 빌드를 수행하거나 구성(예: config.xml)을 기반으로 빌드 도구를 선택하도록 허용하면 좋겠습니다. MSBuild를 사용하려면 반드시 msbuild 파일을 만들고 msbuild .

음 .. 아니야. 나는 msbuild 명령이 MSBuild를 아주 잘 실행한다고 말하고 있다고 믿습니다.

이것을 컨텍스트에 적용하려면 다음을 수행하십시오.

dotnet 빌드가 MSBuild를 호출하는 이유

dotnet build 보다 훨씬 더 않습니다 "그냥", 컴파일러를 호출 DOTNET 빌드의 현재 CLI의 구현을 살펴 . 하나의 프로젝트를 구축하는 것은 dotnet build 프로세스의 일부일 뿐입니다. 결국 그 프로세스의 _part_는 msbuild 를 호출하는 것이지만 그것은 당신의 일이 아니라 CLI의 몫입니다.

저는 MSBuild를 도구로 판단하지 않았습니다.

이 스레드에서 수행한 모든 작업은 MSBuild를 도구로 판단하는 것입니다. 당신이 그런 일을 하지 않는다고 주장하는 것은 솔직히 말해서 우스꽝스럽습니다.

명확하지 않았습니까?

당신이 말하는 내용 중 명확하지 않거나 최소한 잘 생각한 내용이 거의 없습니다.

아무도 실패에 대해 아무 말도 하지 않습니다. 일부 도구는 다른 도구보다 특정 목적에 더 적합합니다.

따라서 일부 도구는 목적에 적합하지 않습니다.

MSBuild의 성능과 복잡성은 빌드의 약 10%에 적합하다고 말하고 싶습니다.

모든 Visual Studio .net 개발자가 동의하지 않을 것이기 때문에 흥미롭습니다. 당신은 MSBuild가 90%의 사용자에게 좋지 않다고 효과적으로 말하고 있습니다(귀하의 수치를 끌어내고 있다는 사실을 무시하고). 다시 말하지만 우스꽝스럽습니다.

음, 빌드 프로세스 번호를 변경하지 않습니다.

프로세스가 변경되지 않은 경우 유일한 주장은 프로젝트의 구조가 마음에 들지 않는다는 것입니다. 즉, MSbuild 또는 후드 뒤에 있는 모든 것이 완전히 관련 이 없다는 사실입니다.

그러나 빌드 프로세스가 작동하는 데 필요한 항목(예: csproj 파일)을 변경합니다.

그것은 말 그대로 사람들이 볼 수 있는 한 실제로 변하는 유일한 것입니다.

그리고 그것이 수행되는 속도.

[인용 필요]

현재 존재하지 않는 새 프로세스가 더 빠르거나 느린지 보여주세요.

죄송하지만 하나의 도구가 두 가지 작업을 수행하는 것이 어떻게 분리되는지 모르겠습니다.

하나의 도구가 두 가지 작업을 수행하지 않기 때문에 MSBuild가 빌드 시스템일 수 있지만 변경 사항은 프로젝트 시스템과 관련이 있습니다. 원하는 경우 다른 빌드 시스템을 사용하는 것을 막을 수 있는 방법은 없습니다.

난 아니다. 제안된 솔루션이 간단한 빌드에서는 잘 작동하지 않는다고 말하고 있습니다.

dotnet new
dotnet restore
dotnet build

제안된 솔루션이 "단순 빌드" 시나리오에 대해 어떻게 변경하는지 보여주세요.

그 중 일부는 ASP.NET 빌드입니다.

yo asp-net web
dotnet restore
dotnet build

개인적으로 간단한 콘솔 앱에도 MSBuild와 같은 강력한 기능이 필요한 이유를 모르겠습니다.

당신 은하지 않습니다. dotnet build 만 있으면 됩니다. 당신이 여전히 가지고있을 것입니다. 거기에는 아무것도 변경되지 않습니다.

나는 당신에게 약속합니다.

리틀 트워프

:-1:

@neoKushan 인용된 발췌문에 대한 응답과 전체 토론에 대한 의견 사이의 개념을 파악할 수 있다면 정말 좋을 것입니다. 나는 당신이 그렇게 할 _능력이 있다고 가정하고, 그래서 유일한 결론은 그것이 고의적이라는 것입니다. 그렇다면 지적으로 부정직한 전술임을 알려주십시오. 나는 당신이 그것을 알고 있기를 바랍니다. 그러나 나는 여기서 의심의 이점을 제공하고 있습니다.

또한 감기약을 반드시 복용해야 한다고 생각합니다. 우리는 프레임워크에 가장 적합하다고 개인적으로 생각하는 것에 대해 논의할 뿐이지 서로 _싸움_하려고 하지 않습니다. 사람이 아니라 논쟁을 공격하십시오. 글쎄, 그것이 내가 지금 꽤 며칠 동안 _시도_한 것입니다(최근 한 가지 경우를 제외하고, 아래 참조).

모든 Visual Studio .net 개발자가 동의하지 않을 것이기 때문에 흥미롭습니다.

웃기게도, 나는 뭔가 다른 것을 말하는 증거 를 수집했습니다. 당신은 어디에서 얻었습니까?

하나의 도구가 두 가지 작업을 수행하지 않기 때문에 MSBuild가 빌드 시스템일 수 있지만 변경 사항은 프로젝트 시스템과 관련이 있습니다. 당신이 원하는 경우 다른 빌드 시스템을 사용을 중지 아무것도 그냥 비 사소한 절대적으로 없다.

네. 그래서 우리는 동의합니다. 사소한라면 정말 좋아, 정말 것입니다.

정말 너무 무리한 요구인가요? 진짜?

당신은하지 않습니다. dotnet 빌드만 있으면 됩니다. 당신이 여전히 가지고있을 것입니다. 거기에는 아무것도 변경되지 않습니다.

그리고 dotnet build 는 정확히 무엇을 합니까? msbuild ? MSBuild를 사용하려는 경우 msbuild 사용할 수 없는 이유는 무엇입니까? 그 상황에서 dotnet build 의 목적은 정확히 무엇입니까? 도구에 무엇을 추가합니까?

리틀 트워프 👎

웃기려는 시도지만 아마도 당신이 옳을 것입니다.

@poke 무조건 사과드립니다.

인용된 발췌문에 대한 응답과 전체 토론에 대한 의견 사이의 개념을 이해할 수 있다면 정말 좋을 것입니다. 나는 당신이 그렇게 할 수 있다고 가정하고 있으므로 유일한 결론은 고의적이라는 것입니다. 그렇다면 지적으로 부정직한 전술임을 알려주십시오. 나는 당신이 그것을 알고 있기를 바랍니다. 그러나 나는 여기서 의심의 이점을 제공하고 있습니다.

말 그대로 당신이 말하는 것을 전혀 모릅니다.

또한 감기약을 반드시 복용해야 한다고 생각합니다.

...

사람이 아니라 논쟁을 공격하십시오.

:삽입RolleyEye 이모티콘여기:

웃기게도, 나는 뭔가 다른 것을 말하는 증거를 수집했습니다. 당신은 어디에서 얻었습니까?

좋아, 그럼 10%/90% 수치는 어디서 왔을까?

네. 그래서 우리는 동의합니다. 사소했다면 정말 좋았을 텐데.

msbuild로 변경하는 것과 아무 관련이 없으므로 현재 빌드 시스템을 dotnet build 에서 변경하는 데 이미 문제가 있습니다.

그리고 dotnet build는 정확히 무엇을 할까요? msbuild로 셸 아웃?

dnx 또는 roslyn 대신 msbuild를 호출하는 dotnet build 와 다른 점은 무엇입니까?

MSBuild를 사용하려는 경우 msbuild를 사용할 수 없는 이유는 무엇입니까?

그래서 지금은 MSBuild를 사용하려면? 아무것도 당신을 막을 수 없습니다. 요즘은 너겟 패키지입니다. 미쳤어. 당신이 msbuild를 얼마나 싫어하는지 감안할 때 당신이 묻고 있다는 것에 놀랐습니다.

그 상황에서 dotnet 빌드의 목적은 정확히 무엇입니까? 도구에 무엇을 추가합니까?

실제로 dotnet build 의 장점에 대해 논의하고 있습니까? dotnet build 마음에 들지 않습니까? dotnet build 의 목적을 이해하지 못하셨습니까? 그럴 가능성은 없어 보입니다. 무엇을 묻고자 하는 것입니까?

@neoKushan 그를 적대시하지 마십시오. 이것은 건설적이지 않습니다.

좋아, 그럼 10%/90% 수치는 어디서 왔을까?

제 개인적인 경험에서 나온 것입니다. 나는 지난 몇 년 동안 우리 팀과 내가 만든 빌드의 약 90%가 RC1 dotnet build 보다 더 복잡한 것이 필요하지 않다는 것을 발견했습니다.

msbuild로 변경하는 것과 아무 관련이 없으므로 현재 빌드 시스템을 dotnet build에서 변경하는 데 이미 문제가 있습니다.

명확히 해주세요. 여기서 무슨 말씀이신지 잘 모르겠습니다.

이제 MSBuild를 사용하시겠습니까? 아무것도 당신을 막을 수 없습니다. 요즘은 너겟 패키지입니다. 미쳤어. 당신이 msbuild를 얼마나 싫어하는지 감안할 때 당신이 묻고 있다는 것에 놀랐습니다.

_한숨을 쉬다_. 내 질문은 왜해야 dotnet build 때의 MSBuild에 밖으로 껍질 msbuild 그 이미 정말 잘합니까? 두 개의 명령이 한 가지 작업을 수행하는 이유는 무엇입니까?

지금까지 세 번 정도 여쭤봤는데 매번 잘못 이해하셨거나 잘못 해석하셨네요.

두 가지 다른 명령줄 명령의 동작에 대해 묻고 있습니다.
나는 왜 둘 다 같은 일을 하는지 묻고 있다
나는 그들이 둘 다 같은 일을한다면 왜 하나의 명령을 가지지 않는지 묻습니다.
나는 두 번째 명령이 둘 다 같은 일을한다면 상황에 무엇을 추가하는지 묻고 있습니다.
나는 그 맥락에서 기본 도구의 품질에 대한 판단을 내리지 않습니다. 다른 곳에서 그렇게 했을 수도 있지만
질문되는 질문은 기본 도구가 아니라 명령줄 명령 및 해당 작업에 관한 것이기 때문에 다른 곳에서 말한 판단은 질문에 영향을 미치지 않습니다.
나는 도구가 과거에 했을 수도 있고 하지 않았을 수도 있는 다른 것에 대해 논의하려는 것이 아니라 단지 미래에 하려는 의도일 뿐입니다.

한 문장으로 된 질문을 설명하는 긴 설명에 대해 유감스럽게 생각하지만 분명히 필요한 것 같습니다.

InfoQ에 대한 기사 :
"Microsoft는 project.json 실험이 실패 했으며 .csproj 파일 사용으로 다시 전환할 것이라는 결론에 도달

내가 말했듯이, 인식이 중요합니다.

내 질문은: msbuild가 이미 잘 되어 있는데 왜 dotnet이 MSBuild에 셸을 빌드해야 합니까? 두 개의 명령이 한 가지 작업을 수행하는 이유는 무엇입니까?

그들이 한 가지 일만 하지 않기 때문에?

csc가 이미 빌드 작업을 잘 수행할 때 MSBuild가 csc로 쉘을 출력해야 하는 이유는 무엇입니까? 두 개의 명령이 한 가지 작업을 수행하는 이유는 무엇입니까?

dotnet test 자체적으로 테스트를 실행하는 데 이미 훌륭한 작업을 수행하고 있는데 왜 xUnit 테스트 러너에게 쉘을 보내야 합니까? 두 개의 명령이 한 가지 작업을 수행하는 이유는 무엇입니까?

NuGet이 이미 패키지를 설치하는 작업을 잘 수행할 때 dotnet restore 가 NuGet으로 쉘 아웃되어야 하는 이유는 무엇입니까? 두 개의 명령이 한 가지 작업을 수행하는 이유는 무엇입니까?

당신은 아이디어를 얻었습니다 ... (나는 희망합니다 :wink:)

@sandorfr

@neoKushan 그를 적대시하지 마십시오. 이것은 건설적이지 않습니다.

나는 의도적으로 누군가를 적대시하는 것이 아니라 @shederman 의 주장을 지점별로 해체하고 있습니다.

사람이 아니라 논쟁을 공격하십시오.

이 시점에서 나는 @shederman 의 주장이 무엇인지 완전히 확신하지 못합니다. 우리가 어떻게든 XML이 좋지 않은 것에서 MSBuild가 나쁜 것으로 현재 dotnet build 가 나쁜 것으로 바뀌었기 때문 입니다.

계속하자.

제 개인적인 경험에서 나온 것입니다.

이것이 당신의 "증거"입니까? 굵게 표시한 것을 기억하세요.

웃기게도, 나는 뭔가 다른 것을 말하는 증거 를 수집했습니다. 당신은 어디에서 얻었습니까?

그리고 이제 "개인적 경험"입니다. 그것이 우리가 _일화적인_ 증거라고 부르는 것입니다.

저는 지난 몇 년 동안 제 팀과 제가 만든 빌드의 약 90%가 RC1 dotnet 빌드보다 더 복잡한 것이 필요하지 않다는 것을 발견했습니다.

그리고 이와 관련하여 RC2 dotnet build 또는 RTM dotnet build 또는 post-RTM dotnet build 이 어떻게 변경될 것으로 예상하십니까?

명확히 해주세요. 여기서 무슨 말씀이신지 잘 모르겠습니다.

귀하의 주장은 " dotnet build 가 Microsoft가 프로그래밍한 것 이외의 다른 작업을 수행하도록 하는 것은 사소한 일이 아닙니다."와 같은 내용인 것 같습니다. 우리 모두가 DNX를 좋아했기 때문에 DNX 시대에는 괜찮았지만 이제 Microsoft는 내부적으로 MSBuild를 사용하기를 원하고 MSBuild를 좋아하지 않는다면 MSbuild를 다른 것으로 변경하는 옵션을 원합니다. 제 요점은 이것이 새로운 것이 아닙니다. DNX에 문제가 있는 경우 이를 변경할 수도 없으므로 dotnet build 의 "문제"가 무엇이든 새로운 것은 아니므로 관련성이 없다고 생각합니다. project.json 의 구조인 _actual_ 토론으로 이동합니다. csproj

한숨을 쉬다. 내 질문은: msbuild가 이미 잘 되어 있는데 왜 dotnet이 MSBuild에 셸을 빌드해야 합니까? 두 개의 명령이 한 가지 일을 하는 이유는 무엇입니까?

@khellang 은 이미 이에 대한 답변을

dotnet build 보다 훨씬 더 않습니다 "그냥", 컴파일러를 호출 DOTNET 빌드의 현재 CLI의 구현을 살펴 . 하나의 프로젝트를 구축하는 것은 dotnet build 프로세스의 일부일 뿐입니다. 결국 그 프로세스의 _일부_는 msbuild 를 호출하는 것이지만 그것은 당신의 일이 아니라 CLI의 몫입니다.

다시, 적어도 세 번째로: dotnet build 호출은 msbuild 호출과 동의어가 아닙니다 . 그것은 당신이 말한 것처럼 "두 명령이 한 가지 일을 하는" 것이 아니며 결코 그렇지도 않습니다. 그것은 이 전체 토론의 범위 내에 있지도 않았지만 어쨌든 당신은 거기에 이르렀습니다.

실제 토론, 실제로 중요한 것은 project.json의 구조와 이것이 .csproj로 병합되는 방법입니다. 기본 빌드 시스템은 항상 dotnet build 만 있기 때문에 단순한 것을 원하는 경우 크게 관련이 없습니다.

그렇다면 msbuild가 수행하는 작업과 dotnet 빌드가 현재 수행하는 작업을 어떻게 구별할 수 있습니까? 작동 방식의 차이점은 무엇입니까? 나는 그것이 이 토론에서 빠져 있다고 생각한다. 다들 이미 알고 계시겠지만, 테이블에 올려놓으면 좀 더 명확해 질 것 같아요.

@khellang 표현한 방식이 마음에 들지만 계속해서 dotnet test 구성할 수 있습니다. project.json에 xunit과 다른 테스트 러너를 넣을 수 있으며 dotnet test 는 해당 테스트 러너를 호출합니다.

그러나 다가오는 변경 사항에 대해 들은 바에 따르면 dotnet build 와 유사한 기능은 없을 것입니다. 항상 MSBuild를 사용하여 빌드를 수행합니다. 그 이해가 옳지 않습니까?

@neoKushan 나는 의도적으로 누군가를 적대시하지 않습니다. 나는 @shederman 의 주장을 점대점으로 해체하고 있습니다

적어도 우리는 이제 당신이 무엇을 _생각_ 하고 있는지 알고 있습니다. 당신이 하고 있는 것은 _사실상_ 잘못된 표현을 하고, 입장을 왜곡하고, ​​의도적으로 오해를 하고, 일반적으로 약간 바보가 되는 것입니다. 당신의 어조는 전투적이며 의도적으로 둔합니다. 너무 많아서 한 번에 한 가지 생각으로 모든 것을 정리해야 했습니다. 웃기게도 당신은 입장을 바꾸는 것으로 오해하고 있습니다.

@neoKushan 이 시점에서 @shederman 의 주장이 무엇인지 완전히 확신할 수 없습니다. XML이 좋지 않은 것에서 MSBuild가 나쁜 것으로 바뀌었기 때문 입니다.

XML은 나쁘다. MSBuild가 나쁩니다. dotnet build 가 MSBuild 만 사용하는 경우에도 좋지 않습니다. 계속 시도하고 따라해 주세요. 그렇게 복잡하지 않습니다. 당신이 그렇게 고의적으로 둔하지 않았다면, 당신은 오래전에 그것을 이해했을 것이고 실제로 건설적인 입력을 추가할 수 있었을 것입니다.

@neoKushan 이것이 당신의 "증거"입니까? 굵게 표시한 것을 기억하세요.

음, 그건 증거가 아니라 제 개인적인 경험이었습니다. 제 증거 는 383명 중 281명의 응답자가 .NET Core를 MSBuild로 다시 옮기는 것이 나쁜 생각이라고 믿었습니다. 그리고 MSBuild가 근본적으로 망가졌다고 믿는 응답자 중 85명이 있었습니다. 그게 내 증거야. 당신은 정확히 어디에 있습니까?

"... _모든 단일_ Visual Studio .net 개발자가 동의하지 않을 것"이라는 진술을 뒷받침하려면? [강조 추가됨]

@neoKushan 실제 토론, 실제로 중요한 것은 project.json의 구조와 .csproj에 병합하는 방법입니다.

사실 _동의_합니다. 그러나 배경은 매우 중요합니다. MS가 표현한 계획은 MSBuild가 빌드 유니버스의 중심이 될 것이라는 것입니다. 나는 그것을 _좋아하지_않지만 계속 가자. 이를 감안할 때 다음과 같은 간단한 질문이 있습니다.

"MSBuild는 영원히 .NET Framework의 기본 빌드 시스템이 될까요?"

그렇다면, 우리는 단지 필요 msbuild 명령을 우리가 필요하지 않습니다 dotnet build 명령을, 그것은 완전히 불필요합니다.

그러나 어느 시점에서 MSBuild가 _One True Build System_이 아닐 수 있다는 점을 인정한다면 우리는 더 흥미로운 영역에 있게 됩니다. 그렇다면 dotnet build 를 갖는 것이 합리적입니다. 그러나 병합 csproj 및 project.json을 논의 할 때 우리가 염두에 미래를 유지하는 것이 다음 매우 중요합니다.

내가 (아마도 형편없게) 지적하려고 했던 것은 (내 생각에) 더 나은 옵션은 _project definition_ 파일과 _build definition_ 파일을 명확하게 구분하는 것입니다. 이렇게 하면 여러 빌드 엔진을 지원할 수 있는 dotnet build 더 적합합니다. 대신 모든 것을 csproj로 옮기면 MSBuild 세계에 자신을 가두는 것입니다.

그리고 예, 이 "단 하나의 진정한 빌드" 상황이 DNX에 존재한다는 것을 이해합니다. 하지만 우리가 가지고 있는 빌드가 _좋아요_했기 때문에 그 당시에는 질문하지 않았습니다. 아, 우리가 _좋아하는_ 😉. 불의를 순진하게 받아들일 때 우리가 처한 상황.

따라서 구성에 따라 여러 빌드 도구 중 하나를 사용할 수 있는 dotnet build 이 있는 상황을 고려하십시오. dotnet test 와 마찬가지로 여러 테스트 실행기 중 하나를 사용할 수 있습니다. 지금, 지금 당신은 csproj 및 project.json 병합 얼마나, 이러한 가상 세계에서 주어진? 그것이 제가 하고 싶은 토론입니다.

@rhires 매우 높은 수준에서 dotnet build :

1. 프로젝트 파일 수집
2. 증분 빌드에 대한 전제 조건이 충족되는지 확인합니다.
3. project.json을 읽습니다.
4. 대상 프레임워크를 결정합니다.
5. 각 프로젝트에 대해:
   
   
   
   1. 빌드의 종속성
   
   
   2. 증분인 경우 재구축이 필요한지 확인합니다.
   
   
   3. 출력 디렉토리를 결정합니다
   
   
   4. 소스 파일을 수집합니다.
   
   
   5. 컴파일 옵션을 결정합니다
   
   
   6. 사전 컴파일 스크립트를 실행합니다.
   
   
   7. 소스 파일 및 옵션으로 컴파일러를 실행합니다.
   
   
   8. 사후 컴파일 스크립트를 실행합니다.
   
   
   9. 보고서 출력
   
   

@shederman 감사합니다! 이 시점에서 msbuild는 이 프로세스에서/에서/에서 무엇을 추가/빼기/바꾸나요?

적어도 이제 우리는 당신이 무엇을 하고 있다고 생각하는지 알고 있습니다. 당신이 실제로 하고 있는 것은 잘못된 표현, 입장을 혼동하는 것, 의도적으로 오해하는 것, 그리고 일반적으로 약간의 바보가 되는 것입니다. 당신의 어조는 전투적이며 의도적으로 둔합니다. 너무 많아서 한 번에 한 가지 생각으로 모든 것을 정리해야 했습니다. 웃기게도 당신은 입장을 바꾸는 것으로 오해하고 있습니다.

냄비 -> 주전자

위치를 너무 많이 변경하여 스스로를 따라잡을 수 없었고, 빌드 체인의 모든 단일 측면에 대해 말 그대로 논쟁을 벌였습니다. 당신이 생각하는 것처럼 함께 하지만, 당신의 주장이 어디에서 무너지는지를 감히 지적하기 때문에 _나는_ 바보가 됩니다. 위에서 제기한 요점의 절반에 대한 응답을 여전히 기다리고 있지만, 빌드 프로세스의 다른 측면을 선택하기 위해 이동하기만 하면 됩니다.

XML은 나쁘다. MSBuild가 나쁩니다. dotnet build가 MSBuild만 사용하는 경우에도 좋지 않습니다.

_당신_ 이외의 누구도 이와 같은 것을 주장하지 않았습니다. 아무도. 그런 종류의 일이 일어날 것이라는 약간의 암시조차 없습니다. 나는 dotnet build 가 MSBuild 를 _그냥_ 호출하지 않는다고 반복해서 말했지만 dotnet build 와 msbuild 는 완전히 동의어가 아니라고 말했습니다. dotnet build 는 컴파일러를 호출하는 것보다

계속 시도하고 따라해 주세요.

계속 _당신은_ 어때요? dotnet build 가 msbuild 만 호출한다는 아이디어가 어디 있는지 보여주세요. 누가 그런 말을 했습니까? 어디서 읽었어?

제 증거는 383명 중 281명의 응답자가 .NET Core를 MSBuild로 다시 옮기는 것이 나쁜 생각이라고 믿었습니다. 그리고 MSBuild가 근본적으로 망가졌다고 생각한 응답자 중 85명이 있었습니다. 그게 내 증거야. 당신은 정확히 어디에 있습니까?

그리고 당신은 그 수치에서 10%를 뽑았죠? 이것은 귀하의 주장임을 기억하십시오.

MSBuild의 성능과 복잡성은 빌드의 약 10%에 적합하다고 말하고 싶습니다.

나중에 당신은 이렇게 말했습니다.

웃기게도, 나는 뭔가 다른 것을 말하는 증거를 수집했습니다.

그럼 이 증거는 어디에 있습니까? 나는 당신이 당신의 "증거"에서 어떻게 그 수치를 끌어냈는지 알고 싶습니다.

"... 모든 Visual Studio .net 개발자가 동의하지 않을 것"이라는 진술을 뒷받침하려면?

쉬움: https://msdn.microsoft.com/en-us/library/ms171468.aspx

Visual Studio는 관리되는 프로젝트를 로드하고 빌드하기 위해 MSBuild를 호스팅합니다.

Visual Studio를 사용하여 프로젝트를 빌드하는 경우 MSBuild를 사용합니다. 오늘날 .net 코어로 작업할 때도 RC1 VS에서도 내부적으로 MSbuild를 사용했습니다. MSbuild가 마음에 들지 않을 수도 있지만 제가 말했듯이 거의 모든 VS 개발자가 MSbuild를 알고 있든 없든 사용합니다.

MS가 표현한 계획은 MSBuild가 빌드 유니버스의 중심이 될 것이라는 것입니다.

나는 이것에 동의하지 않는다. 그들은 그것이 중심이 될 것이라고 말한 적이 없으며, 그들이 말한 것은 project.json의 일부가 결국 .csproj로 다시 돌아갈 것이라는 것뿐입니다. 이 외에는 이것이 dotnet build 를 어느 정도 변경하는지에 대해서는 아무 말도 하지 않았습니다.

"MSBuild는 영원히 .NET Framework의 기본 빌드 시스템이 될 것입니까?"

그렇다면 msbuild 명령만 필요하고 dotnet build 명령은 필요하지 않으므로 완전히 불필요합니다.

지금 여러 번 언급했듯이 dotnet build 및 msbuild 는 완전히 별개의 두 가지입니다. dotnet build 더 단지 컴파일러 툴체인 전화보다 않습니다. dotnet build의 목적은 사람들이 빌드 프로세스를 간단하게 유지하는 것입니다. 다시보다:

dotnet new
dotnet restore
dotnet build

msbuild가 dotnet CLI의 핵심 구성 요소가 되더라도 dotnet build가 상당히 복잡한 시스템에 대한 깨끗하고 간단한 래퍼라는 사실은 변하지 않습니다. 젠장, dotnet CLI가 존재하는 이유의 절반(그리고 그 이전의 DNX)은 특히 MSBuild가 궁극적으로 존재하는 명령줄 인수 지옥에서 벗어나기 위한 것입니다. 귀하의 주장은 "패키지를 curl 할 수 있는데 왜 npm install 명령이 필요한가요?"라고 말하는 것과 같습니다. 물론 원하는 경우 수동으로 모든 작업을 수행할 수 있지만 거의 아무 것도 얻을 수 없습니다. dotnet build 가 내부적으로 msbuild 를 사용한다면 어떻게 될까요? 당신은 거의 확실히 그것을 보지 못하거나 그것에 대해 알아야 할 필요가 있습니다.

이전 경험을 MSBuild와 비교할 수는 없습니다. 완전히 다릅니다. 우리는 VS를 열고, 프로젝트를 만들고, 그냥 빌드하는 데 익숙하기 때문에 (겉보기에는) 그 일로 인해 화상을 입었지만, 빌드 서버에서 동일한 프로젝트를 빌드하려고 하면 갑자기 똥에 대해 불평합니다. _그냥 작동_해야 합니다. 아마도 Microsoft가 TFS 2015에서 수행한 가장 좋은 작업 중 하나는 _MSBuild_가 아닌 _Visual Studio_에 연결되는 빌드 정의를 만든 것입니다. 왜냐하면 "그냥 작동"하기 때문입니다. 이것이 바로 이 빌드 도구 모음입니다. dotnet build 는 전체 빌드 시스템을 대체하기 위한 것이 아니며, 후드 아래에서 MSBuild 사용하더라도 프로젝트 빌드에만 관심이 있습니다. TeamCity 또는 Jenkins와 같은 것을 사용하려면 dotnet build 호출하면 되고 나머지는 dotnet이 알아서 합니다. _어떻게_ 그것은 당신에게 아무런 문제가 되지 않습니다.

유일한 것 - 그리고 내가 이것을 완전히 의미합니다. 실제로 변경되는 유일한 것은 project.json/csproj 파일입니다. _그것_입니다. 그렇기 때문에 dotnet build 실제로 무엇을 하고 MSBuild 가 좋고 나쁜지에 대해 이 모든 논쟁이 절대적으로 _무의미합니다_.

@neoKushan 그냥 그만 ...

@neoKushan 그만...

저 중 일부는 ASP.NET 팀이 쇼를 즐기고 있었기 때문에 의도적으로 스탠드업을 취소하고 답변을 제공하면 모든 것을 끝낼 수 있다고 상상하는 것을 좋아합니다. :웃다:

나의 (지금은 확고한) 불가지론적 입장에서, 양측은 이제 한동안 상대방의 요점에 대해 고의적으로 둔한 것처럼 보였습니다. 당신은 .NET Core 커뮤니티에 대한 나의 정신적 이미지를 건설적이지 않고 더 나쁘게 설정하는 데 성공하고 있습니다. 인식에 대해 이야기하십시오 ...

NuGet이 아닌 대부분의 항목은 csproj에 병합됩니다. project.json(nuget.json?)이 없으면 NuGet 항목은 어떻게 됩니까?

사용자가 원하는 방식으로 종속성을 관리할 수 있는 방법을 제공하고 NuGet이 .net 커뮤니티에서 잘 확립되었기 때문에 기본적으로 dotnet nuget 를 제공할 수 있습니다.

그러나 모든 dotnet 핵심 항목을 종속성을 관리하는 유일한 방법으로 하드 커플하지 마십시오( dotnet restore 는 dotnet nuget restore 같지 않아야 함). 많은 사람들에게 nuget은 패키지 저장소일 뿐 아니라 종속성 관리자, 사람들은 "종속성 관리자" 사용 사례에 더 생산적이고 적합하다고 생각할 수 있는 다른 선택 사항이 있습니다.

종속성 관리를 위해 IntelliSense를 유지합니까? 이것은 기본적으로 project.json에 대한 최고의 데모 기능 중 하나입니다.

논리의 용도를 변경할 수 있습니다. 저는 이것을 큰 문제로 보지 않습니다. 예를 들어 nuget.org로 이동하여 패키지를 검색하고 URL에서 ID를 복사하면 효율적입니다.

bash 또는 zsh 사용하는 사람들로부터 많은 찬사를 받을 셸 완성 기능도 제공할 수 있습니다.

dotnet nuget add S[tab] 는 S 시작하는 프로젝트 식별자에 대한 완료 목록을 제공합니다.

<NuGet> 태그를 거기에 굽고 싶다면 msbuild *proj 파일에 intellisense를 갖는 것도 가능해야 하지만, 마찬가지로 전체 생태계에 하드 커플링을 하지 마십시오. 즉, <Package>NuGetPackageId</Package> 안됩니다. t는 <NuGet>NuGetPackageId</NuGet> 와 동일하거나 이를 재정의하는 매우 간단한(그리고 매우 잘 문서화되고 지원되는) 방법이 있어야 합니다.

Paket Visual Studio 플러그인에는 nuget에서 자동 완성 기능이 있지만 작동하지만 nuget.org에서 응답을 반환하는 데 시간이 걸린다고 가정하기 때문에 어쨌든 느립니다.

종속성 관리를 위해 JSON 형식을 유지하고 있습니까? XML은 그런 종류의 일에 끔찍합니다(Maven 참조). JSON은 이러한 종속성을 나타내기 위해 더 간단합니다.

형식에 대한 아이디어를 찾고 있다면 paket.dependencies 볼 수 있습니다. 그렇지 않으면 별로 중요하지 않다고 생각합니다. project.json 편집은 packages.config 편집만큼 좋았습니다

참고로 lock 파일이 여전히 필요한 경우 사용자가 읽을 수 있고 저장소에서 확인하고 diff를 쉽게 만들 수 있습니까?

@rhires 이 시점에서 msbuild는 이 프로세스에서 무엇을 추가/빼기/바꾸기/에서/바꾸나요?

글쎄, 그것은 그들이 그것을 통합하는 방법에 달려 있습니다. 공개 정보가 선호하는 접근 방식이라고 표시되는 dotnet 빌드에 msbuild를 깊이 통합하여 "하드 잠금"을 수행하면 전체가 msbuild로 대체됩니다.

그러나 dotnet build 구성 가능하게 만들면 다음과 같이 작동할 것으로 예상합니다.

1. 프로젝트 파일 수집
2. project.json을 읽습니다.
3. 대상 프레임워크를 결정합니다.
4. 사용할 빌드 도구 결정
5. 빌드 도구로 셸 아웃
6. 보고서 출력

@neoKushan 그렇기 때문에

👍

내가 _discuss_ 하고 싶은 것은 dotnet build 가 _많은 가능한 빌드 도구 중 하나로 MSBuild에 셸 아웃할 수 있는 세상에서 project.json 및 csproj가 어떻게 보여야 하는지입니다. 괜찮아? project.json에 무엇이 있는지와 csproj에 무엇이 있는지에 대해 이야기할 수 있습니까?

왜냐하면 우리가 논의할 수 있다면 이 스레드가 실제로 건설적일 수 있다고 믿기 때문입니다.

@jmm 당신은 .NET Core 커뮤니티에 대한 내 정신적 이미지를 비건설적이고 더 나쁘게 설정하는 데 성공했습니다.

미안합니다. 그러나 시간이 있다면 다른 거대한 오픈 소스 프로젝트의 채팅 아카이브를 읽어보는 것이 좋습니다.

논쟁은 실제로 삶에서와 마찬가지로 건강한 커뮤니티의 표시입니다. 모든 사람이 맹목적으로 지도자를 따를 때 일반적으로 상황이 좋지 않습니다. 결정, 증거 및 의사 결정은 심문을 받을 수 있도록 공개되어야 합니다.

@shederman 생산적인 논의를 계속하기 위해 제안된 변경 사항의 의미를 논의하기 위해 선을 긋고 싶습니다.

여기서 핵심 토론은 "새" .csproj의 레이아웃과 형식과 project.json(구체적으로는 "프로젝트" 구조 전체)에 어떤 일이 발생하는지에 관한 것이어야 한다고 생각합니다. 빌드 시스템이 msbuild인지 아닌지, dotnet build가 작동하는 방식 등은 _this_ 문제의 범위 내에 있지 않다고 생각합니다. 그것은 그것에 대한 토론이 환영받지 못하거나 유효하지 않다는 것이 아니라 단지 이 _특정_ 문제에 속하지 않는다는 것입니다. 오히려 별개의 문제여야 합니다. 숙련된 개발자라면 누구나 증명할 수 있듯이, 버그 보고서에 여러 개의 개별 버그가 포함되어 있으면 매우 실망스럽고 일반적으로 가장 먼저 해야 할 일은 추적할 여러 문제로 분할하는 것입니다. 이것이 정말 여기에서 누락된 부분이라고 생각합니다.

내 _개인적인_ 관점에서, 나는 빌드 시스템이 무엇인지 또는 어떻게 작동하는지 상관하지 않습니다. 하는 사람들에게 무지하거나 무시하는 것처럼 들린다는 의미가 아니라 개발자 관점에서 프로젝트 구조가 올바른 한 "dotnet build"가 내 어셈블리를 뱉어낸다는 것을 알고 싶습니다. 내가 염려하는 것처럼 dotnet build -> 프로젝트 ->-> 조립. 나에게 진정으로 중요하고 이 토론의 범위가 무엇이어야 하는지(그리고 마침내 여기에서 우리가 동의했다고 생각합니다)는 그 프로젝트가 어떻게 생겼는지, 그리고 그것이 내 일상적인 워크플로에 어떤 의미가 있는지입니다.

.cs 파일을 추가했다고 해서 병합 지옥을 처리하고 싶지도 않고, _나는 상관하지 않는_ 일부 시스템이 그것에 의존하기 때문에 천 줄 길이의 XML 파일을 처리하고 싶지도 않습니다. 우리 중 누구도 그렇게 생각하지 않으며 그것은 몇 년 동안 VS 개발의 버그 베어였습니다. 우리는 오늘날의 project.json 형식에 대한 희망의 빛을 가지고 있었습니다. 왜냐하면 그것이 이전보다 _훨씬 더 나았기 때문입니다. "나쁜 옛날"이지만 동시에 우리가 스스로를 놀리지 말아야 한다고 말할 가치가 있습니다. 오늘날 project.json은 결코 _완벽하지 않습니다. 자체적인 문제가 있으며 "오래된" csproj의 문제에 대해 객관적이고 개선할 수 있는 부분과 개선할 수 있는 부분에 대해 논의할 가치가 있습니다.

확실히 _양쪽 세계의 최고_ 가능성이 있습니다.

여기서 핵심 토론은 "새" .csproj의 레이아웃과 형식과 project.json(구체적으로는 "프로젝트" 구조 전체)에 어떤 일이 발생하는지에 관한 것이어야 한다고 생각합니다.

알다시피, 이 스레드에서 몇 번 언급되었지만 오늘 아침 내 자신의 "개인적인 아하"를 공유하기 위해 다시 언급할 것이라고 생각했지만 Roslyn 기반 프로젝트 시스템 과 함께 진행 중인 다른 노력이 있습니다. -- 또는 readme 에서 더 정확한 CPS(중앙 프로젝트 시스템) . 문서를 찾아보면 프로세스보다 프로젝트 정의 노력이 더 많은 것으로 보입니다. 아마도 이것이 .json과 .csproj 사이의 모든 마법이 통합되는 곳일까요? 그러면 MSBuild가 프로세스 끝점으로 강등됩니까? _그건_ 좋지 않겠어요. :웃다:

어쨌든, 나는 그곳에서 무슨 일이 일어나고 있는지에 대한 업데이트를 받기 시작하기 위해 그 리포지토리를 시작/시청했습니다. :+1:

(이 토론을 새로운 문제로 옮겨야 하는지도 반쯤 궁금합니다.)

@neoKushan 확실히 msbuild가 관련되어 있다는 사실 자체는 문제가 되지 않습니다. 그리고 msbuild의 기능을 활용하면서 사람이 읽을 수 있고 편집 가능한 간단한 파일 형식을 유지할 수 있는 경로가 있다고 생각합니다.

저를 걱정시키는 것은 "msbuild는 전투 테스트를 거쳤습니다"와 같은 주장입니다. 일반 msbuild는 하지만 현재 xplat은 그렇지 않은 것 같습니다. 관련 github 리포지토리의 문제를 살펴보면 아직 해결되지 않았습니다. 또한 msbuild 팀은 이미 새/향상된 직렬화 형식 지원이 msbuild의 대상이 아니라 새로운 빌드 시스템(곧 발생하지 않을 예정)이 될 것이라고 말했습니다.

나는 또한 사람들이 우리가 하는 일이 종속성을 제거하는 것만 추가한다고 가정할 때 걱정됩니다. 아마도 그들은 단지 'hello worlds' 앱을 하고 있기 때문일 것입니다. 그러나 buildOptions 및 모니커에 의한 재정의와 같은 다른 옵션은 매우 강력하고 편리합니다. 현재 json 스키마 기반 편집기 경험은 말할 것도 없이 훌륭합니다.

한 가지 경로는 project.json을 대안으로 로드하는 msbuild 작업을 갖는 것입니다. 그런 다음 csproj에 해당 작업을 추가할 project.json을 활성화하려는 경우 개발자가 프로젝트 설정에서 선택하도록 합니다.

@Mike-EEE 희망이 있습니다 :)

현재의 경향은 project.json이 nuget.json이 되도록 하는 것이라고 확신합니다. 그러면 종속성 문제가 해결되고 기존 project.json 기능의 대부분은 그대로 유지됩니다.

내가 알아낼 수 없는 유일한 것은 이것이 다중 타겟팅에 어떤 영향을 미치는지 입니다. csproj 및 nuget.json은 각각이 타겟팅하는 대상을 인식하고 이해해야 합니까? 모든 대상에 대해 csproj를 사용하게 됩니까(이런!), 아니면 .csproj를 확장하여 이를 설명할 수 있습니까?

project.json은 nuget.json이 됩니다.

여기가 궁금합니다... _이_ 대화가 어디에서 일어나고 있나요? 나는 특정 형식으로 고정하기 위해 전에 너겟 팀에 합류했습니다. project.json과 관련하여 그들은 그것이 Visual Studio 도구 문제이며 해결할 수 없는 문제라고 말했습니다. 이제 역학이 변경되어 동일한 종류의 문제를 더 많이 복사/붙여넣기한 것 같습니다. :stuck_out_tongue:

내 우려를 명확히 하기 위해, 우리는 이제 JSON과 XML을 함께 혼합하여 최소한 비효율성을 생성한다는 것입니다.

여기에서 궁금해서요... 이 대화가 어디서 일어나고 있는 건가요?

글쎄, 그것은 원래 여기에 언급되었습니다: https://blogs.msdn.microsoft.com/webdev/2016/05/11/notes-from-the-asp-net-community-standup-may-10-2016/

project.json 파일이 남아 있고 NuGet에 대한 모든 패키지 참조가 포함되어 있고 이름이 nuget.json으로 변경될 수 있습니다.

그리고 이것이 바로 여기에서 논의하는 내용이라고 생각합니다. project.json에서 얼마를 가져오고 .csproj에 넣습니까? 내 프로젝트에서 project.json의 대부분은 특히 여러 프레임워크를 대상으로 하는 경우 패키지 참조였습니다. 위의 내용은 이 모든 것이 남아 있고 "기타" 비트만 제거될 것임을 암시합니다. 내 (다시: 개인) 경험에서 이러한 "기타" 비트는 프로젝트 수명 동안 실제로 많이 변경되지 않으므로 XML에 있더라도 XML이 많지 않고 상당히 정적이어야 합니다. .

다양한 구성에 대해 XML과 JSON을 혼합하고 일치시키는 것이 약간 냄새가 나는 데 동의하지만 JSON이 어떻게 사용되는지에 대한 열렬한 팬이 아니기 때문에 JSON에 대해 다소 편향되어 있습니다. 물론 개인적인 취향이지만.

글쎄, 그것은 원래 여기에 언급되었습니다 ...

아 예...물론이죠! 확인. 확인하는 중입니다. 바라건대 내일은 우리가 마침내 이것에 대해 (좋든 나쁘든!) 약간의 명확성을 얻는 날이 될 것입니다.

다른 구성에 대해 XML과 JSON을 혼합하고 일치시키는 것이 약간 냄새가 난다는 데 동의합니다.

저만 보고 이런 느낌이 드는게 아니어서 정말 다행입니다. :) 처음으로 .JSON이 프로젝트에 들어가는 것을 보는 슬픔과 싸웠을 때 그곳은 한동안 외로워 보였습니다. web-appdev 배경에서는 완전히 말이 되지만 기본 appdev는 그렇지 않으며 XML의 경우 그 반대도 마찬가지입니다.

하하... 그러고보니 위의 글을 쓰면서 예전 아카이브를 꺼내게 되네요. 여기 2014년에 제가 JSON 대신 Xaml에 대한 사례를 만들고 있습니다 . 너무 귀엽고 겸손합니다! 소년, 내가 배울 세상이 있었나요? :stuck_out_tongue: 하지만 어느 정도 진전이 있었다고 말씀드리고 싶습니다. 결국 웹 서버 구성에 사용되는 .ini를 제거했습니다 . :웃다:

@neoKushan 두 가지 가능성의 장점이 분명히 있습니다.

👯 👯 👯

@neoKushan 나는 현재의 경향이 project.json이 nuget.json이 되도록 하는 것이라고 확신합니다...내가 알아낼 수 없는 유일한 것은 이것이 멀티타겟팅에 어떻게 영향을 미치는지 입니다. csproj와 nuget.json이 알고 있어야 할까요 각 대상이 무엇인지 이해하고 계십니까?

project.json 스키마를 시작점으로 사용하여 내 관점에서 다음 항목은 빌드 정의 파일에 있어야 _아닌_ 해야 합니다.

• 소스 파일 목록
• 프로젝트 종속성
• 대상 프레임워크
• 프로젝트 명령(예: 웹, 테스트 등)
• 웹루트
• 메타데이터
• 언어 버전

다음은 빌드 정의 파일에 있어야 하는 _믿는_ 것은 아니지만 다음과 같은 경우에는 _meh_ 것입니다.

• 구성 정의
• 스크립트, 사전 및 사후

다음은 아마도 빌드 정의 파일에 _should_ 있어야 합니다.

• 컴파일 옵션(언어 버전 제외)

위의 내용은 토론을 유도하기 위한 것입니다. 개별 사항에 대해 토론하게 되어 기쁩니다. 파일의 이름과 현재 형식을 무시하는 것이 좋습니다.

@shederman "빌드 정의"가 의미하는 바를 명확히 해야 합니까? 아마도 내 용어가 맞지 않을 수 있지만 현재 project.json을 _build definition_ 파일이 아니라 _project definition_ 파일이라고 부를 것입니다(새 csproj 파일도 마찬가지입니다). 의미론적일 수도 있지만 나에게 빌드 정의는 _물건이 구축되는 방식을 정의한다고 제안하는 반면 프로젝트 정의는 프로젝트를 구성하는 요소를 정의하고 빌드 단계를 다른 것으로 남겨둡니다.

_이것은 내 프로젝트이며 이러한 항목으로 구성되며 이러한 종속성이 있습니다. 당신이 그것을 구축하는 방법은 내 관심사가 아닙니다._

어셈블리 이름이 최상위 폴더에서 오는 것과 같은 규칙을 통해 많은 프로젝트를 결정할 수 있습니다. 이러한 사고 방식을 따르면 _nuget.json_은 nuget과 관련된 모든 것이므로 패키지/종속성이 거기에 들어가고 우리 모두가 그것에 만족한다고 생각합니다.

내가 확실히 결정할 수 없는 것은 대상 프레임워크입니다. Nuget.json이 종속성 해결에만 관심이 있는 경우 다른 프레임워크를 대상으로 할 때 참조에 대해 일부 분리가 있을 수 있지만 실제로 대상으로 하는 프레임워크를 결정해야 하는지 완전히 확신할 수 없습니다. 정의_ (그것이 무엇이든간에).

그런 다음 다시 말하지만, 단순한 패키지 참조보다 너겟에 더 많은 것이 있습니다. 여기에는 패키지 _definition_ 및 버전도 포함되어 있어 라이브러리가 nuget 패키지가 _becomes_인 경우에 사용할 수 있습니다. nuget.json이 최소한 두 가지 다른 작업을 수행하고 약간의 냄새가 나기 시작하는 것처럼 보입니다. 아마도(여기서 그냥 뱉어내기만 하면 됨) csproj는 패키지, 대상 프레임워크 등의 세부 정보를 정의하고 각 대상 프레임워크는 기본적으로 너겟 패키지인 .json 파일을 가리킬 수 있습니다. 즉, 하나의 nuget.json 대신 각 프레임워크에 대해 별도의 .json 파일이 있습니다. 그것은 끔찍한 생각일 수 있습니다. 저는 특별히 생각해 본 적이 없습니다.

https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-to-project-json/ :

우리에게는 두 가지 선택이 있었습니다. 하나는 모든 .NET 프로젝트를 project.json을 사용하도록 이동하는 것이었습니다. 이를 위해서는 Visual Studio, Xamarin 및 Unity와 같은 파트너의 모든 프로젝트 유형을 다루는 도구 작업을 수행해야 합니다. 이러한 각 프로젝트 유형에 필요한 모든 빌드 시나리오를 지원하고 마이그레이션 스토리를 제공하려면 project.json을 확장해야 합니다. 또 다른 선택은 .xproj 프로젝트가 .csproj 프로젝트를 참조할 수 있고 .csproj 프로젝트가 Visual Studio 및 Xamarin Studio에서 .xproj 프로젝트를 참조할 수 있도록 브리지를 빌드하는 것입니다. 브리지에도 문제가 있습니다. 예를 들어 고객이 프로젝트를 생성할 때 .xproj 또는 .csproj를 선택해야 하므로 더 많은 선택과 복잡성이 추가됩니다.

그리고

우리의 선택을 살펴본 후 모든 .NET 프로젝트가 동일한 도구 및 빌드 시스템을 사용하도록 .NET Core 프로젝트를 .csproj/MSBuild로 이동하는 것이 더 쉽다는 것이 분명했습니다.

누락된 기능을 지원하기 위해 .csproj를 개선할 계획입니다.

• 프로젝트 시스템에 파일 목록이 없습니다.
• 프로젝트 파일에서 작업을 수행하기 위한 CLI 도구, 대부분의 시나리오에서는 파일을 편집하지 않습니다.
• 프로젝트에서 직접 패키지 빌드
• 다중 타겟팅

그리고 모든 .NET이 동일한 도구를 사용하기 때문에 MSBuild 향상을 살펴볼 수 있습니다. 우리는 도구가 지나치게 장황한 파일 등을 생성하지 않도록 하여 XML 대신 JSON을 지원하는 것에 대해 고객과 커뮤니티로부터 피드백을 요청할 것입니다. 그리고 모든 것이 동일한 도구를 사용하기 때문에 이러한 개선 사항은 모든 .NET 프로젝트에서 작동할 수 있습니다.

https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-to-project-json/#comment -71485:

.csproj가 여전히 C# 프로젝트를 의미한다고 가정하면 물론 C#이 아닌 프로젝트에 대한 다른 대상도 있을 것입니다. 맞습니까? [벤]

예. [스콧 H]

.net이 msbuild와 같은 복잡한 레거시 justForTooling 빌드 시스템에 갇히게 될까봐 조금 두렵습니다. dotNetCore를 시작하고 새로운 최신 빌드 시스템을 계획해야 할까요?
.netcore의 배송을 서두르지 않고 모든 사람에게 희망을 주고 일을 할 수 있습니다.

msbuild 파일을 자주 편집할 필요는 없지만 매우 어려울 때 선언적 접근 방식은 흐름에서 자신을 잃게 만듭니다. 제 예를 가져왔습니다. 아무도 이 https://github 와 같은 간단한 문제를 해결할 수 없는 것 같습니다
6개월 후 아무도 더티 해킹 없이 또는 추가 방식으로 작업(각각 다른 작업에 대해 알지 못하는 두 개의 다른 작업)을 실행할 수 없다면 거기에 수정해야 할 것이 있을 수 있습니다.

감사 해요

프로젝트 파일에서 작업을 수행하기 위한 CLI 도구, 대부분의 시나리오에서는 파일을 편집하지 않습니다.

:-1:

나는 당신이 일을 하는 데 도움이 되는 CLI 도구를 지지하지만 참조와 패키지를 관리하기 위해 CLI 도구를 사용하게 된다면 나는 화를 낼 것입니다. Install-package 도 훌륭하지만 패키지 이름의 절반만 입력하고 모든 버전과 함께 가능성 목록을 팝업으로 표시할 수 있다는 것은 놀라운 일이었습니다.

cli 도구는 자동화에는 훌륭하지만 npm install 또는 dotnet restore 와 같은 기본 도구를 제외하고는 작업을 수행하는 데 좋지 않은 방법입니다. dotnet buildoptions define add --framework net451 SOME_DEFINE 와 같은 것을 배워야 한다면 확실히 어렵습니다. 이것은 큰 손실입니다.

좋은 개발 스토리는 다음과 같습니다.

• 쉽게 편집 가능한 프로젝트 및 빌드 파일
• 구성 가능한 빌드 시스템
• 간단하고 잘 설계된 완벽한 cli 도구
• Great Gui, IDE 도구

가난한 사람(이전에는 실제로 훌륭했지만) 중 한 사람을 다른 사람을 받아들일 수 있게 만드는 것은 어리석은 일입니다.

Unity 및 xamarin 인수는 실제로 매우 나쁩니다. 나는 그들이 곧 .net 코어로 이동할 것이라고 생각하지 않으며, .net의 미래를 설계할 때 편의를 위해 뒤로 가는 것은 단지 절름발이일 뿐입니다.

그리고 모든 .NET이 동일한 도구를 사용하기 때문에 MSBuild 향상을 살펴볼 수 있습니다.

강제로 적용되기 전에는 MSBuild가 향상되지 않았습니다...

이 기사는 실제로 우리가 기다리는 블로그 게시물이 아니며 .net 코어가 거기에서 잘못 안내되고 있음을 확인합니다.

cli 도구는 자동화에 적합하지만 npm install 또는 dotnet restore와 같은 기본 도구를 제외하고 작업을 수행하는 데는 좋지 않습니다.

다시 한 번 저는 이 문제가 문화/선호/철학의 충돌이라고 생각합니다. 길을 따라 어딘가에 CLI가 GUI를 대체하는 좋은 아이디어가 되었습니다. 개발자가 (다시 한 번) 접근 방식을 선호하기 때문에 두 가지 모두가 실제로 필요할 때입니다. 지속적으로 문제가 되는 것처럼 보이기 때문에 이 영역에서 약간의 혁신이 확실히 필요합니다. CLI는 생성되지만 GUI는 생성되지 않으며 그 반대도 마찬가지입니다.

나에게 API를 생성하려면 일종의 프레임워크가 필요한 것 같으며 그러면 CLI 및 GUI 버전이 자동으로 생성됩니다.

우리는 그것을 부를 수 있습니다... CLIGUIAPI! :+1: :+1: :+1: #문제 해결

이 문제는 문화/선호/철학의 충돌입니다.

확실히 이것은 가능한 최상의 접근 방식으로 각 접근 방식을 해결하는 것 외에는 해결할 수 없는 문제입니다. node.js 그리고 저는 이 스택의 가장 열렬한 팬이 아닙니다. 훌륭한 cli 도구 npm 및 package.json을 사용하여 이 작업을 훌륭하게 수행했습니다. Gui 부분은 다양한 공급업체(webstorm, vs code, Visual Studio)에 의해 해결됩니다. gulp와 같은 멋진 빌드 시스템은 100% 선택 사항입니다.

아마도 나는 이것에 대해 소수일 수도 있고 아닐 수도 있지만 project.json을 좋아하지만 이유는 여기에 설명되어 있습니다. https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-to-project -json/ 나에게 많은 의미가 있습니다. 나는 우리가 좋은 경험을 하게 될 것이라고 꽤 확신하고 있어서 이것에 대해 정말로 걱정하지 않으며 이것이 이러한 새로운 프레임워크에 대한 나의 열정을 결코 감소시키지 않습니다. 사람들은 마지막 경험이 어떨지 보기도 전에 갈퀴에서 나와 세상의 끝인 것처럼 행동하는 것을 매우 빠르게 보는 것 같습니다.

얼마 전에 읽기를 중단했지만 project.json 대한 확실한 답변이 나오는 대로 이 문제를 종료하겠습니다.

dotnet restore 명령에 의해 .csproj가 생성되고 기본적으로 버전 제어에서 동기화되지 않는 project.json과 .csproj를 모두 유지하는 것은 어떻습니까? 차이점은 dotnet restore "project.lock.json"을 생성하는 대신(다른 작업을 수행하는) ".csproj" 파일을 생성(또는 업데이트)한다는 것입니다. "project.lock.json"과 ".csproj"도 둘 다 자동 생성되므로 그대로 둘 수 있습니다. 플래그는 .csproj를 생성하기 위해 dotnet restore 에서 사용할 수 있습니다. 발표에서 Microsoft는 이미 "프로젝트 파일에 대한 모든 작업을 수행하기 위한 CLI 도구, 대부분의 시나리오에서 파일을 편집하지 않을 것"이라고 말하고 있습니다. IMHO, dotnet restore 는 project.json을 입력으로 사용하는 CLI 도구에 가장 적합합니다. 장점은-

• project.json 및 .csproj 형식은 모두 변경되지 않은 상태로 유지될 수 있습니다. 즉, 새로 생성된 .csproj는 이전 버전의 Visual Studio 및 기타 도구와 호환됩니다. dotnet restore 는 .csproj 파일에 프로젝트 파일의 명시적 "포함" 목록을 삽입할 수 있습니다.
• .csproj는 버전 제어가 아닌 자동으로 생성되므로 개발자는 .csproj를 수동으로 편집하고 병합할 필요가 없습니다.

그래... 아니.

폐쇄. 할 수 있는 말은 다 했습니다.

그것이 어떻게 만들어져야 하는지 그리고 그것에 대해 이야기하는 디자인 팀에 있고 싶다면 ...

그렇지 않으면 공간이 낭비되고 특히... 받은 편지함을 가득 채우게 됩니다.

@MaximRuiller 는 소음의 양에도 불구하고 초기 질문에 답하는 데 중점을 둔 의견을 수집하기를 바랍니다.

어제 게시:

https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-to-project-json/

@neoKushan "빌드 정의"가 의미하는 바를 명확히 해야 합니까? 아마도 내 용어는 꺼져 있지만 현재 project.json을 빌드 정의 파일이라 부르지 않고 오히려 프로젝트 정의 파일이라고 부르겠습니다(새 csproj 파일도 마찬가지입니다). 의미론적일 수도 있지만 나에게 빌드 정의는 빌드 방법을 정의하는 반면 프로젝트 정의는 프로젝트를 구성하는 요소를 정의하고 빌드 단계를 다른 것으로 남겨둡니다.

내 생각에 꽤 많은 지점. 프로젝트 정의는 프로젝트가 무엇인지에 대한 순전히 선언적인 설명입니다. 메타데이터, 버전, 파일 사양 등 빌드 정의는 프로젝트를 실행 가능한 코드로 변환하기 위해 수행되는 단계입니다. 빌드 정의는 그것을 표현하기 위해 상당히 풍부한 무언가가 거의 확실히 필요합니다. 제가 가장 좋아하는 것은 코드입니다.

그러나 모든 것이 무의미해 보입니다.

전반적으로 csproj -> project.json -> csproj 전체는 .NET 채택 IMHO에서 MS를 괴롭힐 잘못된 결정 집합이었습니다. 더 푸르른 목초지를 위해 .NET을 포기하는 개발자들의 추세는 계속될 것입니다.

너무 슬퍼.

@shederman C#에 대한 Tiobe 지수 하락과 csproj로 다시 전환하기로 한 결정 사이에는 상관 관계가 없습니다. 또한 하락하는 Tiobe 지수는 C# 생태계의 건강이 악화되고 있다는 표시가 아닙니다. 더 많은 언어가 시장에 진입하면서 한 언어가 큰 시장 점유율을 유지하기가 어렵습니다.

나는 전체적인 영향에 대해 명확하지 않지만 여기에서 관심의 분리 평가가 있어야 한다는 점을 지적하고 싶습니다. csproj가 단지 내가 파일을 추가하고 있다는 의미라면, 팀원들은 빌드 프로세스와 관련된 다른 영향에 대해 우려하고 있으므로 보트를 놓치고 있는 것입니다.

csproj는 내가 선호하는 것이 아니라 용인하는 것입니다.

@jerometerry 이 자체가 쇠퇴의 원인이 될 것이라고 말한 것은 아닙니다. 그러나 .NET Core의 많은 혁신적인 변경 사항은 감소와 AWS에 대한 손실을 막는 것을 목표로 했습니다. 이러한 변경 사항은 천천히 하나씩 제거되고 있으므로 .NET Core는 점점 더 개발자를 플랫폼으로 유인할 가능성이 희박해지고 있습니다.

또한 현재까지 project.json을 도입하기로 한 결정으로 거슬러 올라갈 수 있는 잘못된 의사 결정은 좋은 징조가 아닙니다.

MS가 과거에 집중하기로 마음먹었다면, 미래에 패배했을 때 놀라지 않을 것입니다. 문제에 빠지게 한 생각은 문제에서 벗어날 수 없을 것입니다.

더 많은 언어가 시장에 진입하면서 한 언어가 큰 시장 점유율을 유지하기가 어렵습니다.

사실이지만 내 경험에 따르면 .NET에서 필요한 것보다 더 많은 피해가 우호적 인 화재로 인해 발생합니다.

BTW... 어제 스탠드업도 있었나요? live.asp.net에 로그인했지만 비디오/피드 또는 아무것도 없이 카운트다운이 재설정되었습니다...

@Mike-EEE 그들은 당신이 온다는 소식을 들었습니다 :stuck_out_tongue_winking_eye:

그들이 이것을 했다는 사실에 좌절합니다. 나는 그것에 대해 블로그에 올렸습니다: http://www.brettmorrison.com/microsofts-little-decision-is-a-big-mistake

오늘의 입장에서: https://youtu.be/YJsQ3tnS7Ew?t=38m45s

그는 여기에서 project.json을 구체적으로 언급합니다. https://youtu.be/YJsQ3tnS7Ew?t=26m12s

project.json 형식이 편집하기가 훨씬 더 간단하지만(드래그 앤 드롭 데이터 세트 원숭이인 .NET 개발 단계에 있지 않은 경우) 가장 큰 문제는 아무도 자신의 라이브러리를 . 넷코어. 지금까지 Restsharp의 한 분기가 작동하도록 관리했지만 이것은 project.json 형식을 사용합니다. JSON.NET, Structuremap, NUnit 등은 모두 개발자가 희망을 버린 것처럼 보이는 오래된 DNX 분기를 가지고 있습니다.

따라서 프로젝트 형식 dotnet 명령줄 도구가 제거될 때 .NET Core RC1/2를 릴리스 후보라고 하는 것은 약간 이상합니다. 나에게 그것은 실험적이기 때문에 여전히 베타 또는 알파 소프트웨어입니다.

vNext로 이동하는 주된 동기는 저렴한 Linux 호스팅과 Docker를 사용하는 것입니다. 대부분의 사람들은 .NET Core 버전이 누락된 너겟 참조를 통해 라이브러리에 완전히 장애가 있으므로 최대한 빨리 프로젝트 마이그레이션 도구를 사용하는 것이 좋습니다.

@yetanotherchris dnx는 rc1의 개념이었고 rc2의 dotnet cli로 변경되었으므로 현재 대부분의 dnx 프로젝트 또는 분기가 부실합니다.

project.json은 여전히 ​​여기에 있고 rc2에 필요합니다. RTM 이후에 향후 사라질 것에 대한 논의

json.net(일명 newtonsoft.json)이 작동하고 프레임워크 자체에서 사용됩니다. 내 프로젝트에서도 사용합니다.
nunit은 호환되지 않으며 모두 xunit afaik을 사용합니다.
structuremap에는 rc2 호환 라이브러리가 있습니다.

아직 rc2로 이식되지 않은 타사 항목이 많이 있지만 Microsoft는 다른 프로젝트의 타이밍과 호환 라이브러리를 만드는 시기를 제어하지 않습니다.

@yetanotherchris project.json에서 가져오기를 사용하는 경우 이전의 비 netstandard 모니커를 지정할 수 있으며 이를 사용합니다.

"frameworks": {
  "netcoreapp1.0": {
    "imports": [
      "dotnet5.6",
      "dnxcore50",
      "portable-net45+win8"
    ]
  }

아마도 많은 사람들이 아직 라이브러리 업데이트를 귀찮게 하지 않은 이유일 것입니다. 실제 RTM 전에 다른 움직이는 목표를 달성할 필요가 없습니다.

@joaudette 명령줄 도구 dotnet 아닌 분기 이름(DNX)에 대해 이야기하고 있었습니다. 많은 사람들이 NUnit을 사용합니다. 이는 MsTest 외부의 사실상의 테스트 제품군입니다. JSON.NET 또는 Structuremap 패키지를 어디에서 찾고 있는지 잘 모르겠습니다. DNX라는 비공식 버전의 Structuremap과 여기에 Newtonsoft 분기가 있으며 nuget.org에는 .NET Standard 1.0 베타가 있습니다(.net 표준은 이제 중복됨 내가 아는 한).

@neoKushan 감사합니다. 살펴보겠습니다.

내 요점은 최종 버전에서 완전히 변경될 것이기 때문에 릴리스 후보라고 부르는 것이 약간 어리석은 일이라고 생각합니다. 아마도 한 달 안에 우리는 많은 활동을 하게 될 것입니다. 이제 빌드 시스템은 이전 및 새 것과 완전히 다르지 않습니다. 비록 주로 웹 개발자인 사람으로서 저는 project.json 훨씬 선호합니다.

@yetanotherchris

(.net 표준은 내가 아는 한 이제 중복됩니다).

왜 그렇게 말합니까? Netstandard는 프로젝트 변경과 함께 사라지지 않고 그대로 유지됩니다. 향후 csproj 파일에서 netstandards를 대상으로 할 수 있습니다. Netstandard는 절대적으로 필요합니다. 그들이 project.json을 버리는 주된 이유 중 하나는 전체 .net 생태계를 통합하기 위한 것이며, 이것이 netstandard도 테이블에 가져오는 것입니다.

내 요점은 최종 버전에서 완전히 변경될 것이기 때문에 릴리스 후보라고 부르는 것이 약간 어리석은 일이라고 생각합니다.

나는 이것에 어느 정도 동의하지만 사람들이 생각하는 만큼 많이 바뀌지는 않는다고 생각합니다. 처음에는 project.json이 여전히 RTM에 있을 것이며 모든 변경 사항은 그 이후에 발생합니다. 그런 다음 변경될 것이고 아마도 거기에 요점이 있는 경우 "최종"이라고 부르는 이유를 물을 수 있습니다. 그러나 궁극적으로 모든 코드와 라이브러리, 그리고 변경되지 않는 모든 것은 단지 _definition_ 프로젝트일 뿐입니다. 처음에 생각하는 것만큼 큰 변화는 아니지만 분명히 마이그레이션의 재미가 있을 것입니다.

@yetanotherchris rc2는 미리보기이므로 타사의 미리보기 패키지도 찾아야 한다는 것을 기억해야 합니다.
https://www.nuget.org/packages/Newtonsoft.Json/9.0.1-beta1
https://www.nuget.org/packages/StructureMap.Dnx/0.5.1-rc2-final

NUnit이 나중에 지원될지는 모르겠지만 지금은 .NET Core 및 ASP.NET Core 프로젝트에서 사람들이 xunit을 사용하고 있습니다.
https://xunit.github.io/docs/getting-started-dotnet-core.html

@yetanotherchris rc1에 beta9라는 레이블이 지정되어야 한다는 데 모두 동의할 수 있다고 생각합니다. rc2는 최초의 실제 rc 품질 릴리스입니다.
project.json 등은 그 자체로 프레임워크의 일부가 아닌 도구이므로 프레임워크가 RTM인 경우에도 도구는 미리보기로 유지되고 한동안 변경될 수 있습니다.

우리가 다시 가져와도 놀라지 않을 것입니다. 아마도 project.json을 유지하고 제한된 시나리오에서만 작동합니다. 그것이 사람들이 원하는 것이라면 우리는 그 아이디어를 즐겁게 할 것입니다.

Scott Hunter, dotnetConf 2016 1일 차 기조 연설 12m24s

Mr. Hunter가 GitHub에 있는지 아는 사람이 있습니까? 그리고 제품 포럼에서 잡담을 모니터링하고 계십니까? 그 소리에서 그는 여기에서 피드백을 놓치고 있습니다.

.NET 및 Visual Studio의 프로그램 관리자로서 @coolcsh가 솔직히 여가 시간이 있는지 의심

나는 그가 주어진 피드백을 알지 못한다면 매우 끔찍할 것입니다. 모든 세부 사항이 아닐 수도 있지만 확실히 상당한 반발이 있었습니다.

모두에게 다음과 같은 기회가 있습니다.
https://blogs.msdn.microsoft.com/webdev/2016/06/08/notes-from-the-asp-net-community-standup-june-2-2016/

말하자면 팁 항아리에 달러를 넣었습니다. :stuck_out_tongue:

tugberkugurlu는 "갑자기 암흑 물질 엔터프라이즈 개발자가 비공개로 피드백을 제공하기 시작했습니다"라는 댓글을 달았을 수 있습니다. 또 다른 방법은 "우리 기업 고객들이 호환성과 우리 제품에 대한 현재 투자에 대해 타당한 우려를 제기했다"는 것입니다. '커뮤니티'가 가장 큰 몫을 하지 못한 것에 대해 불만스러워 보이지만, 뭐, 뭐니뭐니해도 기업 고객은 플랫폼, 도구 및 지원에 대한 액세스를 위해 많은 돈을 지불합니다. 그들의 우려는 무시되거나 무시되어서도 안 됩니다. 결국 MS가 목표로 하는 것은 최대한 많은 개발자가 자신이 원하는 것을 쉽게 구축할 수 있도록 하고 정의 가능한 거의 모든 도메인에서 상호 운용성과 공유를 가능하게 하려는 것입니다. 그들은 csproj를 훨씬 더 쉽게 작업할 수 있고 훨씬 더 유능하게 만들 것을 약속합니다. 이제 그들은 그것을 전달하기 위해 최선을 다했습니다.

여러 번 말했듯이 저는 대기업 고객인 대기업의 기업 개발자입니다. 우리는 이러한 변경 사항에 대해 상의하지 않았습니다. 그렇다면 "암흑물질 기업 개발자"는 정확히 누구였습니까? 그 정보는 명백히 일급비밀입니다. 007 레벨 물건.

엔터프라이즈 고객이 큰 스틱을 가지고 있다고 주장하는 것은 모두 훌륭하고 좋은 일이지만 분명히 그렇게 하는 것은 그들 중 일부에 불과합니다. 어느 것? 어떤 기준으로? 우리는 어떻게 그 특권 목록에 들어갈 수 있습니까? 파트너 레벨은 무엇입니까? 연간 지출액은 얼마입니까? 탐구하는 마음은 그들이 실제로 우리의 의견을 듣기 전에 MS에 정확히 얼마를 지불해야 하는지 알고 싶어합니까?

@shederman 엔터프라이즈 모바일 개발자입니까, 아니면 엔터프라이즈 UWP 개발자입니까? 아니면 Enterprise Unity Dev?

위의 어느 것도 아닙니다. 자산 관리 및 은행 통합을 위한 핵심 시스템을 작성합니다. 일부 온라인 물건도.

@shederman 아마도 당신이 묻지 않은 이유가 아닐까?

명확히 해주세요?

당신이 정말로 유일한 기업 DEVS의 MS가 현재 지원하는 시장의 1 %를 위해 그 일을 이동 작업입니다 건가요, UWP, 음에 대한 관심 사용자 및 게임 개발의 5 %를 애플 리케이션? 개발의 전체 스펙트럼 중, MS는 모든 것에하지만 그들의 뒤를 돌고있다?

음. 아니.

변경 사항은 _그_그룹과 대화한 후에 발생했기 때문에 질문을 받지 않은 것입니다. Microsoft는 asp 개발자뿐만 아니라 모든 개발자를 지원

예, 따라서 모든 개발자를 지원하려면 할 것입니다. 엔터프라이즈 개발자의 5%가 선택한 하위 집합과 이야기하는 것은 엔터프라이즈 개발자 전체의 의견을 측정하는 좋은 방법이 아닙니다 .

따라서 대형 은행의 의견을 들으려면 모든 개발을 UWP/Unity/Mobile로 전환해야 합니다.

말도 안돼

아마도 그들은 모든 개발자와 이야기해야 할 것입니다.

그들이 지난 2년 이상 동안 해온 일이 아닌가?

@shederman 그래서 _당신이 개인적으로_ 묻지 않았기 때문에 당신의 개발 범위를 다루는 다른 사람이 관여하지 않았음을 암시하는 것입니까?

또한, 그 숫자를 만드는 것을 그만 두십시오. _그건_ 말도 안됩니다.

@poke 누가 관련

나는 실제로 숫자가 꽤 ​​관대하다고 생각했지만 괜찮습니다.

@shederman 내 생각에 당신은 이 모든 것을 너무 많이 들여다보고 있는 것 같습니다. 지난 2년 동안 asp.net 쪽에 초점이 맞춰져 있었지만 .net core가 퍼지기 시작하면서 많은 사람들이 "이걸 어떻게 사용합니까?"라고 묻기 시작했습니다. 그것은 백룸 거래가 아니라 말 그대로 몇 년을 요구하는 사람들이었습니다. 많은 사람들이 .net core에서 더 많은 것을 원한다는 것을 확인하기 위해 주위 를

기존 자료를 플랫폼 간 이식하는 방법을 알고 싶어하는 대규모 조직의 실제 엔터프라이즈 지원 요청 문제도 있습니다. 당신이 하려고 하는 것은 프로젝트의 범위를 넘어서는 것입니다.

그것을 보는 또 다른 방법 - 그리고 내가 개인적으로 그것을 보는 방식 - 당신은 질문을 받았고 몇 달 전에 발표가 이루어진 두 번째 질문을 받았습니다. 누구와도 상의하지 않고 결정이 내려졌다고 말하는 사람들의 모든 외침에 대해, Microsoft는 여전히 세부 사항을 작업 중이며 아직 최종 조각이 정리되지 않았으며 지금이 귀하의 의견을 말할 때라고 반복해서 말했습니다. Scott Hunter는 사람들이 _정말로_ project.json을 옵션으로 원한다면 유지하는 것을 고려할 것이라고 말했습니다. 내 말을 믿지 못하겠다면 가서 dotnetconf 기조연설을 시청하세요.

@neoKushan Scott이 유지하는 것을 고려할 것이라고 말하면서 한 걸음 물러서서 고맙게 생각하지만 사람들이 이것이 원하는 것이라고 표현할 수 있는 단일 중앙 집중식 지점이 필요합니다. 그렇지 않으면 project.json 문제가 계속 나타납니다. 여기저기서 토론. 그것은 또한 그것이 제기되었을 때 모든 사람이 같은 대답을 할 수 있다는 것을 의미합니다. "이봐, 개발자가 정말로 원한다면 그것을 유지하는 것을 고려할 것입니다.

project.json 좋은 단계였습니다. 하지만 내 생각에는 순진했다. 사람들이 C++ 또는 F#으로 작성된 하이브리드 프로젝트를 원할 것이라는 인식은 필요하지 않습니다. dnx 및 nuget을 어셈블리 단위로 사용하는 것과 같은 초기 설계 결정 중 일부는 전체 닷넷 생태계에서 실현 가능하지 않았습니다. 당신이 보고 있는 것은 닷넷에 화합을 가져오는 과정에서 그들이 이러한 힘든 선택을 해야 한다는 것입니다.

내 생각에 포크와 재창조는 닷넷 생태계에 도움이 되지 않을 뿐 아니라 해칠 뿐입니다. Node and Go(특히 Go)는 균질하고 일관된 플랫폼/도구를 가지고 있기 때문에 초보자에게 매우 매력적입니다.

앞으로 5년 후에는 JSON 대 YAML이 될 것이고 그 이후에는 YAML 대 Groovy(예: gradle)가 될 것이기 때문에 전체 XML 대 JSON 인수가 어리석은 것으로 생각합니다. XML은 여러분 모두가 알고 있는 것처럼 사악하지 않습니다. MSBuild는 매우 성숙했으며 모두에게 도움이 될 많은 투자를 하고 있습니다.

즉, csproj 파일을 사용하고 편집하는 것과 동일하거나 최소한 덜 고통스러운 방법을 얻을 수 있도록 MSBuild로 많은 작업을 수행해야 합니다. 그런 다음 nuget 종속성을 nuget.json 파일로 이동합니다. 구성보다 규칙을 사용하여 "행복한 경로"에 있으면 csproj가 거의 비어 있게 됩니다. 오늘날의 web.config와 비슷합니다. 그런 다음 csproj를 조정하는 cli 옵션이 있습니다.

저에게는 project.json이 그리울 것이지만 당신이 생각하는 이유는 아닙니다. C# 프로젝트는 괜찮을 것입니다. F# 때문에 msbuild를 편집하는 것보다 컴파일 순서를 위해 project.json을 편집하는 것을 선호했기 때문에 놓칠 것입니다. 다시 말하지만 xml이 악하기 때문이 아니라 fsproj 파일에 msbuild로 인해 많은 팽창이 발생하기 때문입니다.

이 결정에 대한 나의 문제는 주로 csproj 파일이 xml/json에 관한 것이 아니라 csproj 파일에 포함하기로 선택한 것에 대해 훨씬 더 많은 방식이었습니다. 여기에는 프로젝트 정의가 포함되어 있고 IDE 설정이 포함되어 있으며 빌드 단계가 포함되어 있으며 참조가 포함되어 있습니다.

그렇게 _하지_않은_ 많은 것이 없습니다. 이것은 그것을 끔찍하게 만들었고 msbuild가 때때로 상당히 난해한 것을 처리해야 할 때만 복잡해졌습니다. .NET Core를 훌륭하게 만드는 데 관심이 있고 단순히 작업만 하는 것이 아니라 빌드 도구에 대해 프로젝트 파일을 불가지론적으로 만드는 데 관심이 있다면. 내 프로젝트가 무엇이며 빌드 방법과 별도로 무엇에 의존하는지 지정할 수 있어야 합니다. 말할 것도 없이 이것은 초기 옵션이 지금 msbuild에서 지원되는 경우에도 도구 선택을 허용하기 시작합니다.

나는 이것에 동의합니다. 결국 csproj의 핵심 문제는
그것은 모든 것을합니다.

나는 PatriotBob이 제안하는 중간 지점을 좋아합니다 ...

2016년 6월 21일 화요일 오후 1시 28분 PatriotBob [email protected]에서 다음과 같이 작성했습니다.

이 결정에 대한 내 문제는 주로 csproj 파일이 적은 방식이었습니다.
xml/json 및 csproj에 포함하기로 선택한 항목에 대한 훨씬 더 많은 정보
파일. 여기에는 프로젝트 정의가 포함되어 있고 IDE 설정이 포함되어 있습니다.
포함된 빌드 단계, 참조 포함...

그렇게 _하지_않은_ 많은 것이 없습니다. 이것은 그것을 만들었다
끔찍하고 msbuild 존재를 처리해야 할 때만 복합적입니다.
때때로 상당히 신비롭습니다. .NET Core를 좋게 만드는 데 솔직히 관심이 있다면
작업뿐만 아니라 도구를 빌드하는 데 프로젝트 파일을 불가지론적으로 만듭니다. 나는해야한다
내 프로젝트가 무엇인지, 무엇에 의존하는지 지정할 수 있습니다.
그것을 구축하는 방법. 말할 것도 없이 이것은 우리에게 선택을 허용하기 시작합니다.
초기 옵션이 지금 msbuild에서 지원되는 경우에도 마찬가지입니다.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/aspnet/Home/issues/1433#issuecomment -227511911 또는 음소거
스레드
https://github.com/notifications/unsubscribe/AKh-zsedLYg_PToadpD-_ewZPci0oHGCks5qOB8rgaJpZM4IcGCt
.

전체 XML이 나쁘고 JSON은 훌륭합니다. 나는 PatriotBobo의 말을 좋아합니다.

npm 의 package.json 에서 완전히 as/w 프로젝트를 관리하는 것은 내 프로젝트 선언, 내 프로젝트 구축, 내 프로젝트 업그레이드(예: 그린키퍼), 읽기/쓰기/파싱 데이터를 이렇게 간단하고 간결하게 만든 적이 없습니다. 내 프로젝트에 대해 설명하고 내 프로젝트를 쉽게 게시할 수 있습니다. _너무 쉽게. 우리 중 많은 사람들과 마찬가지로 내 역사는 C++/java/python/node에 있고 다른 사람들도 마찬가지입니다. 나는 지금 내 모든 프로젝트에서 npm 경험을 갈망합니다.

project.json 는 이러한 동일한 특성을 제공하기로 약속했습니다. 단순함과 강력함을 희생하지 않고 모방할 가치가 있는 모델이라고 생각합니다.

팀 .net 핵심 팀이 다른 솔루션이 이러한 특성, 탁월함 및 능력을 제공할 수 있다고 생각한다면! 그러나 진행하면서 단순함의 아름다움을 훼손하지 마십시오.

또한, 나는 거대한 스레드의 이 시점에서 내가 단지 소음일 뿐이라는 것을 이해합니다. 아마도 중재자는 그것을 닫고 더 통제된 방식으로 시련을 처리하는 것을 고려해야 합니다. 많은 좋은 피드백. 약간의 트롤링도 가능합니다 :$ :)