Aspnetcore: Microsoft.AspNetCore.App 3.0에서 제거되는 어셈블리

MVC 패키지도 추가 NuGet 패키지가 되어야 한다고 생각합니다. MVC는 훌륭하지만 바닐라 ASP.NET Core와 달리 모든 .NET 언어의 패러다임에 맞는 것은 고사하고 모든 사람의 차가 아닌 애플리케이션을 배치하는 방법에 대해 매우 독단적입니다. 공유 ASP.NET Core 프레임워크는 MVC가 없거나 두 번째 MVC 무료 버전이 있어야 한다고 생각합니다. 어떻게 생각하나요?

어떤 이점이 있을까요? 이것이 어떻게 ASP.NET Core 애플리케이션을 빌드하는 사람들의 삶을 더 좋게 만들까요?

엄청난! asp.net 코어를 사용할 때 필요한 것이 필요합니다.

@davidfowl

어떤 이점이 있을까요? 이것이 어떻게 ASP.NET Core 애플리케이션을 빌드하는 사람들의 삶을 더 좋게 만들까요?

같은 이유로 이 문제의 맨 위에 나열된 패키지를 포함하지 않습니다. 나중에 패키지를 제거하는 것보다 .NET Core 3.0과 함께 제공될 프레임워크에 더 많은 패키지를 추가하는 것이 항상 더 쉽다고 생각합니다. 가장 작은 공통 분모를 추가하여 기본 ASP.NET Core 앱을 실행한 다음 나머지를 NuGet 패키지로 제공하는 것이 어떻습니까? 이것이 개발자에게 문제가 되는 것으로 판명되면 나중에 언제든지 추가할 수 있지만 나중에 더 이상 쉽게 제거할 수 없습니다.

기본적으로 유용함과 균형을 유지해야 하기 때문입니다.

네, 바닐라 ASP.NET Core는 이미 유용하다고 생각합니다. 그럼 상관없어요 ;)

순수주의자라면 대부분의 미들웨어나 MVC 또는 SignalR이 꼭 필요한 것은 아니기 때문에 상자에 들어 있지 않을 것입니다. 기본 세트가 있어야 하는 것과 그렇지 않은 것 사이에 이 선을 그리는 것은 직감적이고 모호한 것입니다(경험에 기초하여 과거와 현재의 다른 플랫폼을 살펴보고 전화 걸기). ASP.NET Core 3.0부터 우리는 (적어도 지금 당장은) 그것들을 꺼낼 계획이 없습니다.

네, 이것이 항상 어려운 일이라는 것을 압니다. 그러나 가끔은 (Microsoft에 의한) 경향이 필요 이상으로 부풀려지는 이유가 무엇인지 확신이 서지 않습니다. 시장에서 자신의 제품을 포지셔닝하는 방식은 제품이 어떻게 인식될 것인지에 달려 있습니다. ASP.NET Core는 새로운 현대적인 구성 가능하고 유연한 웹 프레임워크로 간주되지만 모든 것을 배치하는 방법은 모든 사람에게 MVC + SignalR + Identity + EF를 강제 실행하지 않는 한 ASP.NET Core는 쓸모가 없다는 것입니다. 내 생각에 당신은 이미 선을 그려야 할 위치를 호출했습니다. 그렇기 때문에 MVC와 SignalR이 ASP.NET Core에 포함되어 있지 않고 필요할 때 추가할 수 있는 별도의 프레임워크인데 왜 지금 이 선을 흐릿하게 만들고 있습니까? 일관성이 없고 그로부터 얻을 수 있는 어떤 가치도 생각할 수 없습니다. ASP.NET Core + 번성하는 오픈 소스 에코 시스템을 홍보하는 대신 매우 좁은 웹 경험을 홍보하고 있습니다. 그것이 하는 모든 것은 당신이 원하지 않을 수도 있는 사람들에게 일을 밀어붙이게 됨에 따라 약간 다르고 더 많은 일을 하고 싶어하는 사람들에게 좌절감을 주는 것뿐입니다.

MVC를 기본 프레임워크에 넣지 않으면 사람들이 MVC를 사용하지 않는 것과 같습니다. 단일 NuGet 패키지로 만들면 아무도 NuGet에서 MVC를 가져와야 한다고 불평하지 않을 것입니다. 더 많은 사람들이 와서 나처럼 원하지 않는 것들로 기본 프레임워크를 부풀린 이유를 묻게 될 가능성이 더 큽니다.

나는 이것이 토론이고 여전히 여러분이 고려할 수 있는 것이라고 생각합니다. 따라서 한 가지 묻고 싶은 것이 있다면 이 질문을 팀에 다시 제기하고 여러분 모두가 이 문제에 대해 정말로 준비가 되어 있는지 확인하는 것입니다. 당신은 내 아이디어를 향해 부드럽게 할 수 있습니다 :)

추신: 그런 경우인지 확실하지 않지만 SignalR도 별도의 NuGet 패키지였으면 합니다. Bootstrap과 Angular2를 기본 프레임워크에 포함시키는 것과 같습니다. 이 두 제품이 Microsoft에서 개발했다면 아마 그렇게 했을 것입니다. 그러나 그것은 말이 되지 않을 것이고 제 생각에는 그것들이 제3자에 의해 수행되기 때문에 그것이 어떻게 말이 되지 않는지 알 수 있을 뿐입니다.

TBH 기본 설치에서 제거된 항목을 더 보고 싶습니다. 특히 MVC. 이것이 ASP.NET Core 위에 있는 대체 프레임워크를 더욱 매력적으로 만드는 이유입니다. 또한 ContentResult와 같은 것들이 코어가 아닌 MVC에 있는 이유가 궁금합니다. 그것은 하늘빛 함수에서 많이 사용되며 이제는 항상 ContentResult에 대해서만 MVC 항목을 참조해야 합니다.

요점은 ASPNET SDK에 MVC 항목을 포함하는 것이 실제로 부정적인 영향을 미치지 않아야 한다는 것입니다. 대부분의 개발자는 그것을 사용할 것이므로 그렇게 배송하는 것이 복원 로드를 부풀리는 것보다 선호됩니다. 원하지 않으시면 사용하지 않으셔도 됩니다. 위에 나열된 대부분의 패키지는 타사 종속성(json)을 가져오거나, 일부 무거운 측면(면도기)이 있거나, 개념적으로 ASPNET과 분리되어 있으며 종종 SDK(EFCore) 외부에서 참조됩니다.

OSS 프레임워크를 위한 평등한 경쟁의 장을 조성하기 위해 최소값을 기본값으로 설정하는 데 동의하는 만큼 균형이 맞아야 합니다. 코어(베타 및 1.0)의 초기에는 모든 것이 패키지였으며 훨씬 더 혼란스럽고 복원이 오래 걸렸습니다.

@psibernetic 물건이 분리된 패키지에 있더라도 .net 코어 설치 프로그램은 이러한 패키지를 이미 로컬 캐시에 넣을 수 있습니다.

@psibernetic 균형이 중요하다고

MVC를 단일 NuGet 패키지로 사용하는 것이 혼란스럽거나, 복원에 영원히 걸리는 경우, 또는 언급한 다른 부정적인 경우를 한 가지 말씀해 주십시오.

그리고 복원 시간에 대한 이야기 ​​...

IMHO 개발자 컴퓨터에서 약간 더 빠르게 빌드하는 것보다 빠르게 시작하는 컨테이너 또는 서버리스 아키텍처(이것이 비즈니스에 실제 영향을 미치므로)를 갖는 것이 더 중요합니다. 예, 후자도 매우 중요하며 매우 빠르기를 원하지만 중요도를 매겨야 한다면 클라우드의 프로덕션 인프라보다 개발 시스템에서 약간의 타격을 받는 것이 좋습니다. 따라서 공간을 최대한 작게 유지하는 것이 복원 시간을 줄이는 것보다 중요합니다.

어떤 이점이 있을까요? 이것이 어떻게 ASP.NET Core 애플리케이션을 빌드하는 사람들의 삶을 더 좋게 만들까요?

내 Windows 10 PC에 사전 설치된 CandyCrush와 같이 MVC를 사용하지 않는 다른 모든 사용자에게 원치 않는 블로트웨어라고 생각합니다. Asp.net 코어는 필요에 따라 미들웨어 등을 완벽하게 구성할 수 있어 덜 독선적이라고 주장했습니다. dotnet 템플릿을 사용하면 코어에 베이크할 필요 없이 MVC가 기본 포함 패키지가 될 수 있습니까?

Nancy, ServiceStack 및 Giraffe와 같은 많은 다른 프레임워크가 있습니다. 이 프레임워크는 모두 장단점이 있으며 원하지 않는/필요하지 않은 MVC 강제 설치로 인한 팽창/충돌이 없어야 합니다. 인증, 면도기, EF 등이 모두 패키지되어 있지만 MVC, 골든 자식이 핵심이 아닐 때 핵심 프레임워크의 일부가 되는 경우 일관성이 없는 것 같습니다.

MVC가 코어에 너무 밀접하게 결합되어 디커플링이 많은 작업이 될 수 있기 때문에 얻을 수 있지만 일반적으로 일부 개발자의 삶을 더 쉽게 만드는 것을 기반으로 게으르고 이전 asp.net과 매우 흡사합니다. MVC 사고방식 나는 우리가 멀리하기를 바랐습니다.

.NET Core는 .NET용 node.js의 린 모듈식 클론이어야 하지만 기능이 포함된 작고 유연한 의견 없는 코어인 번창하고 활기찬 생태계를 조성하는 특성을 복제할 의도가 없는 것 같습니다. 독창적인 웹 프레임워크와 함께 번들로 제공되지 않는 덕분에 핵심적인 이점은 자체 독립 커뮤니티와 함께 ​​건강한 수의 인기 있는 프레임워크를 즐기는 실험으로 무르익었습니다.

내 말은 ASP.NET 팀이 그들이 할 수 있는 최고의 프레임워크를 구축하고 있다고 믿게 만들지만 모든 사람이 선택한 모든 의견이나 작업을 완료하는 데 필요한 복잡성 수준에 동의하는 것은 아닙니다. .NET Core의 모든 것은 .NET에서 오는 다음 혁신을 굶주리게 하는 어떤 기술을 사용할 것인지에 대한 의견을 굽힘으로써 다른 플랫폼에서 어떤 접근 방식이 성공했는지 많은 영감을 받아 뒤늦게 알게 된 이점으로 개발되었습니다. 다음 일이 다른 플랫폼에서 관심을 모을 때 ASP.NET Core는 모든 웹에 대한 개발 모델을 사용할 것으로 예상되는 앞으로 기본 "MVC 세금"을 영원히 지불하게 되므로 성공을 복제하는 데 불리합니다. 앱 광고는 무한합니다.

Node의 가벼움은 또한 Electron, Native Mobile Apps, IOT, 셸 스크립트 등과 같은 다른 여러 사용 사례를 개발하는 데 적합합니다. 기본 설치가 부풀려질수록 다른 시나리오에서 사용하는 데 덜 유용해집니다.

IMO 기본값은 기본적으로 번들로 제공하고 기본값을 부풀리지 않고 기능(모든 사람이 활용할 수 있음)을 더 쉽게 추가하는 데 중점을 둔 간결한 모듈식 코어를 갖는 .NET Core의 원래 비전으로 돌아가야 합니다. 설치.

피드백 주셔서 감사합니다. 몇 가지 생각을 공유하겠습니다.

1. 우리는 단지 그렇게 느끼기 때문에 어셈블리를 트리밍하지 않습니다. 제거하는 각 어셈블리는 주요 변경 사항이며 2.x에서 3.0으로 업그레이드하는 비용이 추가됩니다. 다음은 Microsoft.AspNetCore.App에 포함되는 항목을 결정하는 데 사용하는 기본 원칙입니다. https://github.com/aspnet/AspNetCore/blob/master/docs/SharedFramework.md. 제거를 제안하는 어셈블리에는 공유 프레임워크에 포함하기 위한 일부 기준이 누락되었습니다. 특히 이러한 어셈블리는 (1) 서비스할 수 없는 타사 코드에 종속되어 있습니다. (2) 어셈블리 자체가 3.0에서 더 이상 사용되지 않거나 (3) 변경될 가능성이 높은 프로토콜 또는 인증 메커니즘을 구현합니다( 예를 들어 Facebook/Google/Twitter는 내일 인증 작동 방식을 변경하기로 결정할 수 있습니다.

2. Microsoft.AspNetCore.App에서 MVC를 제거하는 것은 고려 대상이 아닙니다. 모든 사용자가 애플리케이션에서 MVC를 참조하는 것은 아니지만 이것이 ASP.NET Core 제품의 핵심 부분이라고 생각합니다. 이것을 Microsoft.AspNetCore.App에 보관할 계획입니다.

3. MVC는 2.1부터 Microsoft.AspNetCore.App의 일부였지만 2.1 "빈 웹" 템플릿 에서 볼 수 있듯이 MVC를 사용할 필요가 없습니다. 공유 프레임워크에 있다고 해서 애플리케이션에서 사용하도록 강요하지는 않습니다. 대안을 사용하거나 고유한 보기 프레임워크를 작성하거나 "원시" aspnetcore API를 사용하여 HTTP 요청 및 응답을 직접 읽고 쓸 수 있습니다.

4. @dustinmoris : 나중에 패키지를 제거하는 것보다 .NET Core 3.0과 함께 제공될 프레임워크에 더 많은 패키지를 추가하는 것이 항상 더 쉽다고 생각합니다. 가장 작은 공통 분모를 추가하여 기본 ASP.NET Core 앱을 실행한 다음 나머지를 NuGet 패키지로 제공하는 것이 어떻습니까? 이것이 개발자에게 문제가 되는 것으로 판명되면 나중에 언제든지 추가할 수 있지만 나중에 더 이상 쉽게 제거할 수 없습니다.

   그것이 바로 우리가 하려고 하는 것입니다. 제거하는 것보다 추가하는 것이 더 쉽습니다. 우리는 2.0에서 너무 많은 것을 추가했으며, 우리는 앞으로의 예측 가능한 길을 위해 유지 관리 가능한 세트라고 믿는 것으로 다시 조정하고 있습니다. Microsoft.AspNetCore.App에서 제거된 대부분의 어셈블리는 여전히 NuGet 패키지로 제공됩니다. 나중에 모든 고객의 90%가 동일한 패키지를 참조한다는 사실을 알게 된다면 공유 프레임워크의 좋은 후보입니다. 그러나 지침 문서 에서 언급했듯이 API가 얼마나 사용되는지는 중요한 지표이지만 우리가 고려하는 유일한 요소는 아닙니다.

5. "바닐라"는 주관적입니다. 많은 사용자에게 MVC와 SignalR은 "바닐라"입니다.

6. 몇몇 사람들은 .NET Core가 이것 또는 저것 또는 다른 것이어야 한다고 말했습니다. 상황이 변하고, 사용자 피드백을 수집하고, 제품이 어떻게 사용되는지 관찰하고, 가장 많은 고객에게 혜택을 줄 것으로 생각되는 것과 일치하도록 기본값을 조정하려고 시도합니다. 이 문제에서 제안된 조정은 .NET Core 2.x에서 받은 피드백을 반영한 것입니다.

최종 생각: 이 문제가 모든 사람을 행복하게 만들지는 않을 것입니다. 귀하의 의견을 무시하는 것처럼 보이면 사과드립니다. 우리는 수십만 명의 고객을 보유하고 있으며 그 중 소수만이 피드백을 공유하기 위해 GitHub에 옵니다. 또한 직접 방문, 전화 통화, 이메일, 소셜 미디어, 고객 지원 요청, 블로그, Visual Studio 원격 분석 등에서 정보를 수집합니다. 이 모든 것은 우리가 결정을 내릴 때 고려하는 것의 일부이며 기본 환경의 일부이고 그렇지 않은 것입니다.

우리의 동기나 이유에 대해 명확하지 않은 것이 있으면 알려주시면 명확히 하도록 노력하겠습니다.

직접 고객과 접촉하는 경우가 너무 많은 경우 MVC 및 SignalR을 사용하는 고객이 몇 명인지 마지막으로 질문한 것이 언제입니까? 필요할 때 매우 쉽게 설치할 수 있는 하나의 단일 NuGet 패키지에 각각 포함하는 대신 확실히 유지하는 이 입장 뒤에 실제 사용 메트릭이 있습니까?

공유 런타임에 MVC를 포함하는 @dustinmoris 는 사전 컴파일된 상태로 배송됨을 의미합니다. 이는 손실될 수 있는 이점이며, 이로 인해 시작 시간이 최소한으로 증가하여 빠른 시작의 예에서 IMO가 좋지 않은 절충안이 됩니다. 도커 컨테이너. 그 외에도 모든 배포는 이제 런타임에 없기 때문에 앱과 함께 패키지를 배송해야 하므로 모든 MVC 앱의 배포 패키지 크기가 늘어납니다. 마지막으로 런타임에서 MVC에 종속된 모든 패키지도 별도의 배포 가능이어야 합니다. 전체 목록을 찾을 수 없기 때문에 이것이 몇 개인지 확실하지 않습니다.

이 모든 것이 말했고 Microsoft 또는 aspnet 팀과 제휴 관계가 0이라는 점을 염두에 두십시오. 커뮤니티에서 실제로 목소리를 높이고 이것이 주요 요구 사항임을 입증했다면 베어본 aspnetcore 런타임인 별도의 런타임이 배송되는 것을 볼 수 있었습니다. 임무는 가능한 한 많은 응용 프로그램과 개발자에게 훌륭한 경험을 제공하는 것이며 현재 공유 런타임에서 MVC의 이점 중 엄청나게 높은 비율을 차지하고 있습니다. @natemcmaster 관련 개인이 향후 GitHub 문제에 대해 투표할 수 있는 선호하는 방법이 있으며 이것이 합리적인 솔루션입니까?

@psibernetic 공유 프레임워크에서 MVC를 제거하기 위한 새로운 GitHub 문제를 시작하는 것을 환영합니다. 하지만 위에서 언급했듯이 Microsoft.AspNetCore.App에서 MVC를 제거하는 것은 우리가 고려할 사항이 아니므로 이 문제는 내에서 견인력을 얻지 못할 것입니다. 우리 팀.

@Bomret 우리가 조사한 거의 모든 실제 고객 앱은 어떤 방식으로든 MVC를 사용합니다. 공유 프레임워크에 유지하면 많은 이점이 있으며, 왜 제거해야 하는지 명확한 이유가 없습니다.

@Natemcmaster : 지금은 통화 중이지만 설명 감사합니다.
내가 그것에 대해 이야기하는 동안 이것이 메타 패키지에 관한 것임을 깨달았습니다.
공유 프레임워크.

@natemcmaster 나는 @forki , @dustinmorris , @gerardtoconnor 및 @mythz 가 내가 아직 반대 논증을 듣지 못한 매우 타당한 이유를 언급했다고 생각합니다. 프레임워크 작성자가 의견이 있는 항목을 번들로 묶는 대신 nodejs와 같이 맨 위에 구축할 수 있는 기본 웹 런타임/lib가 있으면 매우 좋았을 것입니다. 이전에 언급했듯이 노드는 너무 많이 요구하지 않지만 그 위에 구축할 수 있는 멋진 추상화를 제공하기 때문에 매우 성공적입니다. MVC는 사라지지 않고 물러날 것이며 다양한 다른 웹 라이브러리 및 프레임워크 중에서 선택해야 할 것입니다. 그것을 포함함으로써 당신은 그것에 대한 입장을 취합니다. 물론 대부분의 개발자는 더 이상 보지 않고 런타임과 함께 제공되는 그대로 사용합니다. 내 솔직한 의견으로는 정치와 마케팅처럼 들립니다. 불쾌감을 주지는 않습니다.

"Microsoft.AspNetCore.App"이라고 합니다. 두 번째 "Microsoft.AspNetCoreMVC.App"을 만들지 않겠습니까?

어쨌든 나는 선을 긋는 것이 매우 어렵다는 것을 이해하지만 여기에 대한 일반적인 피드백은 당신이 aspnet 코어로 한 것을 좋아하지만 MVC, 면도기 같은 것을 좋아하지 않는 사람들이 점점 늘어나고 있다는 것입니다. , EF 또는 signalR.

물론. api, 웹, 웹 소켓, 템플릿, db 액세스 등을 처리하기 위한 라이브러리 및 프레임워크에 대한 많은 아이디어를 제공할 만큼 커뮤니티가 활발할 것이라고 믿을 수 있습니다. 여러분은 MVC, Razor, EF 등을 가진 사람들에게 하나의 옵션을 제공할 것이지만 유일한 옵션도 기본 옵션도 아닙니다.

@natemcmaster 내 실수, 나는 실제로 여기에서 이 문제의 공유 프레임워크에 대해 이야기하고 있었습니다. 메타 패키지에도 같은 이유가 적용된다고 생각하지만 솔직히 말하면 메타 패키지 대신 개별 패키지를 이미 참조할 수 있기 때문에 그것에 대해 덜 귀찮습니다. 가능한 한 작은 컨테이너이므로 공유 프레임워크에 대한 새 문제를 여는 제안이 의미가 있습니다 👍

@natemcmaster 제가 제대로 이해했는지 빠르게 확인해 주

• 다음 .NET Core 런타임(3.0)에 구운 공유 ASP.NET Core 프레임워크가 있을 것입니다. 즉, ASP.NET Core는 환경에 .NET Core 설치의 일부로 제공됩니다.

• 또한 ASP.NET Core 앱용 NuGet 패키지 모음인 Microsoft.AspNetCore.App 및 Microsoft.AspNetCore.All 라는 메타 패키지가 있습니다.

• 공유 ASP.NET Core 프레임워크 < EF Core와 같은 항목을 포함하는 Microsoft.AspNetCore.App 메타 패키지?

• 아주 작은 API를 만들고 싶다면 EF Core, SignalR, MVC 등이 포함된 Microsoft.AspNetCore.App 메타 패키지를 포함하지 않고도 ASP.NET Core 웹 앱을 빌드할 수 있습니까?

• 여러분이 무엇을 하든, 작은 API를 실행하기 위해 ASP.NET Core에 대한 종속성이 가장 적은 Docker 컨테이너를 만드는 것이 가능할까요?

다음 .NET Core 런타임(3.0)에 구운 공유 ASP.NET Core 프레임워크가 있을 것입니다. 즉, ASP.NET Core는 환경에 .NET Core 설치의 일부로 제공됩니다.

예

또한 ASP.NET Core 앱용 NuGet 패키지 모음인 Microsoft.AspNetCore.App 및 Microsoft.AspNetCore.All이라는 메타 패키지가 있습니다.

아니요. FrameworkReference 라는 새로운 개념이 있으며 Microsoft.AspNetCore.App이 그 중 하나입니다. Microsoft.AspNetCore.All은 3.0에 존재하지 않습니다.

공유 ASP.NET Core 프레임워크 < EF Core와 같은 것을 포함하는 Microsoft.AspNetCore.App 메타 패키지?

아니요, EF는 포함되지 않습니다.

여러분이 무엇을 하든, 작은 API를 실행하기 위해 ASP.NET Core에 대한 종속성이 가장 적은 Docker 컨테이너를 만드는 것이 가능할까요?

어셈블리 트리밍 및 링커를 사용하면 예, ASP.NET Core용 패키지가 없기 때문에 패키지를 제거하는 것이 아닙니다.

@natemcmaster

우리는 단지 그렇게 느끼기 때문에 어셈블리를 트리밍하지 않습니다. 제거하는 각 어셈블리는 주요 변경 사항이며 2.x에서 3.0으로 업그레이드하는 비용이 추가됩니다.

수정을 수행할 수 있는 올바른 위치는 v3 주 버전 창 내에 있을 것입니다. 이 창은 사실상 이와 같은 변경이 발생할 수 있는 유일한 시간입니다. 즉, 다른 패키지가 제거되는 것과 같은 시간입니다.

Microsoft.AspNetCore.App에서 MVC를 제거하는 것은 고려 대상이 아닙니다. 모든 사용자가 애플리케이션에서 MVC를 참조하는 것은 아니라는 것을 알고 있습니다.

"ASP.NET Core 앱"을 만드는 경우 논리적으로 "이 패키지 참조"로 읽히는 "Microsoft.AspNetCore.App"이라고 합니다.

우리는 이것이 ASP.NET Core 제품의 핵심 부분이라고 믿습니다. 이것을 Microsoft.AspNetCore.App에 보관할 계획입니다.

이것은 ASP.NET Core의 목표가 린(lean)의 개방형 node.js-esque 스타일 에코시스템을 육성하는 것에서 멀어지는 것처럼 보이는 문제의 핵심에 점점 더 가까워지고 있습니다. 모든 사람이 ASP.NET Core 앱을 MVC 앱과 동의어로 통합하려는 것이 팀의 의도입니까? ASP.NET Core의 판매 포인트 중 일부는 "Pay to play" 및 분리된 "layering"이었지만 "ASP.NET Core App"이 영원히 = MVC App으로 의도되었음을 암시합니다.

다음과 같은 경우 패키지가 더 명시적이라면 관련된 모든 사람에게 더 명확할 것입니다.

• Microsoft.AspNetCore.App => 모든 ASP.NET Core 앱의 기반
• Microsoft.AspNetCore.Mvc => ASP.NET Core MVC 앱

그러나 "Microsoft.AspNetCore.App"이 건드릴 수 없는 경우 최소한 핵심 서버 기능만 포함된 공식 "기본" 메타 패키지(또는 FrameworkReference)(즉, 독단적인 라이브러리 없음)와 몇 가지 잠재적인 이름:

• Microsoft.AspNetCore.[베이스 | 베어 | 라이트 | 기초적인]

("핵심"도 적절했지만 이미 이 용어가 과도하게 사용되었습니다).

공식 메타 패키지/이름이 없으면 모든 ASP.NET Core 앱에 대한 권장 기반인 현재 권장되는 "Microsoft.AspNetCore.App"만큼 액세스할 수 없습니다.

제약 조건이 혁신을 낳습니다. MVC가 다른 모든 사람과 동일한 경기장에서만 실행될 수 있다면 우리 모두는 앱에 필요한 제품(패키지 제품군이라고도 함)을 쉽고 명시적으로 선언할 수 있는 기능에 액세스할 수 있습니다. 처럼:

• Microsoft.AspNetCore.Mvc+SignalR+EF

누구나 쉽게 선언하고 필요한 것만 설치할 수 있고 배후의 도구는 "Microsoft.AspNetCore.SignalR", "Microsoft.AspNetCore.EF" 메타 패키지를 결합할 수 있습니다. (또는 의도를 달성하기 위해 우수한 솔루션을 대체).

공유 프레임워크에 있다고 해서 애플리케이션에서 사용하도록 강요하지는 않습니다.

지금까지 만들어진 모든 단일체의 근거처럼 들립니다. "우리가 번들로 제공하는 모든 것을 사용할 필요는 없습니다. 단지 귀하의 편의를 위한 것입니다."

여전히 대안을 사용하고, 자신만의 뷰 프레임워크를 작성하고,

예를 들어 MVC 및 Razor에 대한 자체 "보기 프레임워크" 대안을 개발하는 동안 .NET Core에서 .NET Core를 게시하기 위해 표준 명령을 실행할 때 빌드가 실패하는 마법 같은 동작이 발생했습니다. NET Core 프로젝트, 즉:

 dotnet publish -c Release

다음과 같이 실패합니다.

EXEC(1,11): error CS0246: The type or namespace name 'System' could not be found (are you missing a using directive or an assembly reference?) [C:\src\NetC
oreWebApps\WebApp\src\WebApp\WebApp.csproj]
EXEC(1,54): error CS0518: Predefined type 'System.String' is not defined or imported [C:\src\NetCoreWebApps\WebApp\src\WebApp\WebApp.csproj]
C:\Program Files\dotnet\sdk\NuGetFallbackFolder\microsoft.aspnetcore.mvc.razor.viewcompilation\2.0.0\build\netstandard2.0\Microsoft.AspNetCore.Mvc.Razor.ViewCompilation.targets(60,5):

MVC, Razor를 명시적으로 참조하지 않거나 .cshtml 페이지를 사용하지 않고 앱을 빌드하는 것이 목적이었기 때문에 MVC에 대한 대안을 개발하고 있다는 점에서 놀라운 동작입니다.

다른 해결 방법을 시도하는 여러 GitHub 스레드를 샅샅이 뒤진 후 솔루션이 MVC Razor 컴파일 중단 빌드에서 선택 해제되는 동일한 문제를 겪고 있는 다른 사람들을 발견했습니다.

dotnet publish -c Release /p:MvcRazorCompileOnPublish=false

프로젝트를 게시할 수 있었던 이유입니다. 손상된 빌드를 수정하기 위해 다른 스위치를 시도하는 동안 .NET Core 2.0 웹 앱을 불필요하게 팽창시키는 메타데이터를 옵트아웃하여 /refs/*.dll 에 있는 150개의 .dll 만큼 게시된 공간을 줄일 수 있음을 발견했습니다. 다음을 사용하여 Razor에 필요한 메타데이터 옵트아웃:

<PreserveCompilationContext>false</PreserveCompilationContext>

따라서 기본적으로 두더지 잡기를 실행하여 프로젝트 빌드를 중단하고 MVC/Razor 앱에만 필요한 불필요한 메타데이터를 출력하는 것을 방지하기 위해 도구에 MVC를 사용하지 않는다고 알려야 하는 스위치를 찾아야 합니다. MVC 비트가 존재하지 않기 때문에 도구가 모든 앱이 MVC를 사용하고 있다고 가정할 수 없기 때문에 이러한 문제가 가능하지 않은 "기본" 메타데이터 패키지로 시작하는 것이 훨씬 더 바람직했을 것입니다.

ASP.NET Core가 여전히 대안적인 "보기 프레임워크"의 실험, 생성 및 사용을 권장하는 환영하는 플랫폼이라고 말하기는 쉽지만 MVC와 같이 규정된 의견이 있는 웹 프레임워크를 번들로 묶는 것은 생성 및 상기 대안의 사용. 떠오르는 인기 있는 대안의 수를 잠시 살펴보는 것은 플랫폼이 그들에게 얼마나 매력적인지 알 수 있는 좋은 척도입니다.

모든 ASP.NET Core 앱이 다른 모든 "보기 프레임워크"보다 MVC를 포함해야 하는 경우(ext 메서드의 단일 .cs 파일 드롭인 포함) " 그리고 번들 MVC를 사용하는 것보다 번거롭습니다. 뷰 프레임워크가 필요로 하는 다른 모든 것을 번들로 묶어야 하기 때문입니다.

요약하면 "MVC"가 옵트인되어 .App 패키지에 포함되지 않는 것이 바람직하지만, 결정을 되돌릴 수 없다면 최소한 공식 베이스라인 메타 패키지 기반을 가질 수 있습니까? 포함하지?

우리는 수십만 명의 고객을 보유하고 있으며 그 중 소수만이 피드백을 공유하기 위해 GitHub에 옵니다.

비대해진 시작 패키지에 대한 IMO의 요구가 제대로 반영되지 않고 있습니다. 일화: VS 2012, VS 2013, VS 2015, VS 2017 및 .NET Core용으로 만든 모든 C#/.NET 프로젝트 템플릿 중에서 일관되게 가장 인기 있는 템플릿 지금까지 VS.NET의 기본 빈 ASP.NET 템플릿이 충분히 비어 있지 않다는 클래식 ASP.NET에 대한 빈번한 비판이기도 한 "빈" 템플릿이 항상 있었습니다. 이것은 MVC 없이 "빈" 클래식 ASP.NET .NET Framework를 만들 수 있었던 때였지만 지금은 더 새롭고 더 가볍고 모듈식인 ASP.NET Core 프레임워크에서 MVC가 최소 권장 시작 패키지 내에 번들로 제공됩니다.

또한 직접 방문, 전화 통화, 이메일, 소셜 미디어, 고객 지원 요청, 블로그에서 정보를 수집합니다.

사람들은 종종 제거할 수 없는 복잡성과 동일시되는 팽창을 좋아하지 않습니다. 요청될 가능성이 있는 것은 프로젝트를 가능한 한 단순하게 만드는 것입니다. 이것이 초점이 되어야 하고 기본 프로젝트를 팽창시키지 않고 수행할 수 있는 것입니다.

내 경험상 명시적이라는 것이 마법 같은 동작이 포함된 부풀려진 프레임워크보다 추론하기가 더 쉽습니다. 명시적이라면 상호 작용하고, 검색하고, 읽고, 제거하고, 사용하지 않고 실행을 테스트하고(문제의 원인인지 확인하기 위해) 다른 구성의 프로젝트를 비교할 때 볼 수 있습니다. 그러나 위의 mvc/razor-less 프로젝트 빌드를 깨뜨리는 MVC 도구의 마법 같은 동작으로 인해 내 프로젝트의 어느 부분이 이를 트리거했는지, 실행 중인 이유, 비활성화하는 방법 또는 해결 방법을 알 수 없었습니다. 나는 여전히 MVC를 사용하지 않는 내 프로젝트가 MVC가 번들로 제공되어 속도가 느려지지 않거나 MVC 또는 Razor를 수용해야 하기 때문에 최적이 아닌 출력을 생성한다고 확신하지 못합니다.

Visual Studio 원격 분석 등.

존재하지 않는 기본 메타 패키지의 인기에 대한 원격 측정을 비교하는 것은 어려울 것입니다. IMO를 수행했다면 포함할 가치가 있는 충분한 인기를 얻었을 것입니다. 이전에 "Microsoft.AspNetCore.All"은 스펙트럼의 다른 쪽 끝을 목표로 하고 우주를 포함했지만 최소한의 유용한 기준선을 갖는 것보다 더 유용한 역은 아닙니다.

MVC 앱을 빌드하지 않고 기본 라인을 선택하는 옵션도 마찬가지로 액세스 가능하다면 MVC를 포함하는 더 부풀려진 스타터 옵션보다 선택하지 않는 이유는 무엇입니까?

@봄렛

프레임워크 작성자가 의견이 있는 항목을 번들로 묶는 대신 nodejs와 같이 맨 위에 구축할 수 있는 기본 웹 런타임/lib가 있으면 매우 좋았을 것입니다.

그러나 그것이 정확히 작동하는 방식입니다. 사용하려는 방식으로 애플리케이션을 자유롭게 구성할 수 있습니다. MVC를 사용하지 않으려면 미들웨어를 추가하지 마십시오. 예, 템플릿은 사용하지 않지만 원하는 것을 사용하여 원하는 대로 앱을 변경할 수 있습니다.

나는 당신이 여기에서 공유 프레임워크를 약간 잘못 해석하고 있다고 생각합니다. .NET Core와 함께 제공되는 일종의 표준 라이브러리로 보기만 하면 됩니다. Node 참조를 만들려면: Express의 현재 버전이 Node.js와 함께 번들로 제공된다고 상상해 보십시오. 사용할 _가지는_ 없지만 사용하고 싶을 때 이미 있습니다.

그리고 MVC의 경우 MVC가 실제로 ASP.NET Core에 포함하는 내용을 정확히 알지 못한다고 생각합니다. 컨트롤러와 Razor 보기를 사용하고 싶지 않다면 괜찮지만 어쨌든 앱에서 여전히 상당히 많은 MVC 기능을 사용할 것입니다.

컨트롤러와 Razor 보기를 사용하고 싶지 않다면 괜찮지만 어쨌든 앱에서 여전히 상당히 많은 MVC 기능을 사용할 것입니다.

무엇처럼?

컨트롤러와 Razor 보기를 사용하고 싶지 않다면 괜찮지만 어쨌든 앱에서 여전히 상당히 많은 MVC 기능을 사용할 것입니다.

네, 알려주세요. 우리 대부분은 핵심 미들웨어/Kestrel을 기반으로 하는 대체 프레임워크에 참여하고 있으므로 사용 중인 컨트롤러와 Razor 보기는 MVC의 작은 하위 집합입니다. 알고. F# 프레임워크인 Giraffe/Saturn & Zebra는 더 나은 라우팅과 단순화된 처리 모델로 MVC보다 더 나은 성능을 보입니다. 렌더링 시 TechEmpower에서 Zebra x2가 MVC보다 빠르기 때문에 기본적으로 유지하지 않는 것이 좋습니다. 어셈블리 트리밍/링커가 나중에 풋프린트를 줄일 수 있다면 그것은 최소한의 것이지만 기본적으로 포함되지 않은 경우 다른 프레임워크를 위한 더 공평한 경쟁의 장을 허용하고 asp.net 코어 플랫폼에 대한 최대 활용도를 얻을 수 있습니다.

@mythz 조직적 관점에서 당신 말이 맞습니다. 여기에는 몇 가지 논리적 구분이 있습니다. 그러나 모든 세분화에는 제품 기능을 개선하는 데 시간이 걸리는 상당한 복잡성과 엔지니어링 오버헤드가 추가됩니다. 대다수의 고객이 MVC 구성 요소를 활용할 것으로 예상할 때 이를 분할하는 비용은 가치가 없습니다. 그것들을 사용하지 않는 개발자의 단점은 무시할 만합니다. 설치 디렉토리에 몇 MB가 추가되고 로드하지 않는 한 런타임에 영향이 없습니다.

요점을 설명 하기 위해

@찌름
다른 사람들이 이미 썼듯이: 그렇지 않습니다. 기본 런타임과 아무 관련이 없는 항목을 번들로 묶는 것입니다. 이미지 익스프레스 프레임워크는 기본적으로 노드와 함께 번들로 제공되었을 것입니다. 생태계가 이렇게 활기차고 다양해질 것이라고 생각하십니까?

또한 기본 설치에서 MVC, SingalR 등을 제거하고 각각 "복잡성 추가"로 레이블을 지정할 수 있는 단일 NuGet 패키지로 제공하는 방법을 절대 이해하지 못합니다. 어쨌든 개발자는 대부분의 경우 추가 패키지를 설치합니다. 그리고 추가 패키지로 제공하면 복원 시간이 "상당히" 증가하더라도 어쨌든 너무 뚱뚱합니다.

@트래처

그러나 어떤 세분화

이를 세분화하는 것은 MVC의 분리이므로 ASP.NET Core 앱은 ASP.NET Core 앱을 개발하는 데 사용해야 하는 것을 규정하는 독단적인 개발자 프레임워크 없이도 최소한의 유용한 기준을 가질 수 있습니다.

제품 기능을 개선하는 데 시간이 많이 걸리는 복잡성과 엔지니어링 오버헤드가 크게 추가되었습니다.

이 내용을 명확히 하려면 MVC를 사용하지 않는 모든 ASP.NET Core 앱에서 불필요한 오버헤드를 제거하는 데 너무 많은 엔지니어링 오버헤드가 필요합니다. MVC가 "MVC에" 복잡성을 크게 추가하는 다른 모든 대체 프레임워크처럼 작동해야 하기 때문입니다.

MVC가 다른 모든 대체 프레임워크 내에서 작동해야 하는 동일한 확장성 옵션 내에서 작동하기 위해 상당한 복잡성이 필요한 경우 이는 MVC에 문제가 있음을 나타내며 더 원활하게 작동하기 위해 추가된 기능은 모든 사람의 이익에 추가될 수 있습니다. 모놀리식을 분석하는 것처럼 도구 및 런타임의 복잡성은 MVC 및 통합/도구에 속하는 위치로 추가된 복잡성이 이동하여 더 가볍고 덜 복잡합니다.

대신에 우리는 MVC가 퍼블리싱 프로젝트를 중단시키고 그것을 사용하지 않는 프로젝트의 출력을 부풀릴 수 있는 기본 도구에 확고히 자리 잡은 상황으로 끝났습니다. 다른 모든 것과 같이 작동하지 않기 때문에 MVC를 사용하고 있다고 말할 수 있는 방법이나 MVC를 사용하지 않고 있다고 말할 수 있는 방법이 없으므로 항상 가정합니다.

대다수의 고객이 MVC 구성 요소를 활용할 것으로 예상되는 경우

글쎄요, 그것은 예상될 것입니다. 다른 모든 대안에 피해를 주기 위해 Apple이 좋든 싫든 모든 사람에게 무료 U2 노래를 제공하는 것과 같이 기본 최소 권장 설치에 ​​번들로 제공되는 규정된 프레임워크입니다.

사용하지 않는 개발자의 단점은 무시할 수 있습니다.

개발자가 더 다양하고 옵션과 혁신이 있는 더 건강한 생태계의 이점을 누릴 수 있을까요?

개발자는 "ASP.NET Core 앱"이 무엇인지에 대한 추가된 혼란과 모호한 정의의 이점을 누릴 수 있습니까? "이전에는 .NET용 node.js와 비슷했지만 이제는 기본적으로 모든 앱이 웹 앱을 빌드하는 방법을 규정하는 다수의 의견이 있는 항목으로 시작하는 독단적인 단일 공급업체 프레임워크에 가깝습니다. 기본적으로 익스프레스 및 해당 종속성과 함께 사전 설치되는 앱 - 이를 사용해야 합니다."

개발자는 MVC의 특별한 케이스로부터 혜택을 얻습니까? 다른 것과 같이 설치되거나 업데이트되지 않으며 존재하고 비활성화하기 위해 주변을 뒤져야 하는 숨겨진 도구 및 마술 동작에 의존합니다. 이와 같은 특수 케이스는 우연한 복잡성을 추가합니다. 프로젝트에 대해 추론할 때 MVC가 작동하는 방식과 다른 모든 것이 작동하는 방식에 대해 다른 규칙 집합을 유지해야 합니다.

명시적이라면 가독성이 향상되고 프로젝트 구성에서 MVC 앱임을 알 수 있습니다. 예:

• Microsoft.AspNetCore.Mvc

MVC 앱임을 알려주고 모든 종속성을 설치하고 MVC가 필요로 하는 모든 맞춤형 도구를 자동 구성합니다. 이상적으로는 다른 모든 사람이 액세스할 수 있는 동일한 개방형 확장 가능 모델을 사용합니다.

기본 "Microsoft.AspNetCore.App" 프로젝트에 유지하면 모든 ASP.NET Core 앱과 영원히 연결되고 더 나은 결과를 얻기 위해 불리하게 만듭니다. ASP.NET 웹 페이지 는 몇 년 전에 ASP.NET에 추가된 또 다른 Razor 보기 프레임워크로 설치되었으며 기본적으로 침입 마법 동작이 활성화되어 있습니다. 더 이상 지원되지 않거나 다운로드 할 제공 되므로 죽은 기술의 복잡성이 클래식 ASP.NET에 영원히 포함되어 다른 활성 웹 프레임워크에 문제를 적극적으로 일으키는 경우가 남습니다. 웹 페이지가 보기 프레임워크를 깨뜨리는 것을 명시적으로 방지하기 위해 아래의 수하물을 영원히 가지고 다녀야 하는 Razor .cshtml 페이지를 사용하기 위해 연결:

<appSettings>
    <add key="webPages:Enabled" value="false" />
</appSettings>

선호도에 따라 기능 요청을 반복하려면 다음과 같이 하십시오.

1. "Microsoft.AspNetCore.App"을 모든 ASP.NET Core 앱(예: MVC 없음)에 대한 유용한 최소 기준으로 변경합니다.
2. MVC를 사용하지 않는 모든 사람이 최소한의 유용한 기준으로 사용할 수 있는 "Microsoft.AspNetCore.Base"와 같은 메타 패키지를 유지 관리합니다.

이들 중 어느 것도 고려되지 않는다면 모든 MVC 도구가 실행을 비활성화하고 방지하기 위해 확인할 수 있는 mvc:enabled = false 와 같은 프로젝트 전체 플래그를 가질 수 있습니까?

@mythz 당신은 내 입에 단어를 넣고 있습니다. 추가된 복잡성은 MVC에 대한 것이 아니라 계층 구성에 관계없이 구성 요소의 또 다른 계층을 만들고 제공하는 데 필요한 인프라, 패키징, 설치 프로그램 등을 구축하는 것입니다.

이들 중 어느 것도 고려되지 않는다면 모든 MVC 도구가 비활성화 및 실행을 방지하기 위해 확인할 수 있는 mvc:enabled = false와 같은 프로젝트 전체 플래그를 가질 수 있습니까?

비활성화되었으면 하는 도구 기능이 무엇인지 더 구체적으로 말씀해 주시겠습니까? 그것은 별도의 문제가 될 가치가 있습니다.

@트래처

추가된 복잡성은 MVC에 대한 것이 아니라 계층 구성에 관계없이 구성 요소의 또 다른 계층을 만들고 제공하는 데 필요한 인프라, 패키징, 설치 프로그램 등을 구축하는 것입니다.

즉, MVC가 작동하도록 하는 데 필요한 복잡성이 추가되었습니다.

비활성화되었으면 하는 도구 기능이 무엇인지 더 구체적으로 말씀해 주시겠습니까? 그것은 별도의 문제가 될 가치가 있습니다.

내가 만난 2가지 문제는 /p:MvcRazorCompileOnPublish=false 를 수동으로 구성해야 했기 때문에 내 프로젝트(.cshtml 페이지 제외)가 게시되지 않았습니다. 비활성화해야 하는 다른 플래그는 다음과 같습니다.

<PreserveCompilationContext>false</PreserveCompilationContext>

대부분의 마술 행동과 마찬가지로 더 많은 것이 있다고 가정하지만 내가 그것을 만났을 때만 그것들에 대해 알아냅니다.

기본적으로 MVC가 사용되지 않도록 지정하고 MVC로 인해 추가된 기본적으로 활성화된 모든 도구 또는 양보를 비활성화하는 플래그입니다.

@mythz 계속해서 해당 문제를 제출하십시오.

추가 MVC 및 SignalR dll이 사용자의 관심사인 경우 실제로 서비스 스택에 대해 유사한 공유 프레임워크를 만들 수 있습니다.

@davidfowl 정말 대단하게 들립니다. 커뮤니티에서 제공하는 프레임워크에 대한 몇 가지 다른 사용 사례를 볼 수 있었습니다. 그것에 대한 문서가 있습니까?

상상할 수 있듯이, 이 작업을 수행하는 사람의 수가 적기 때문에 일급 지원을 구축할 수 있는 대상이 아닙니다. 즉, 우리가 우리를 구축하고 그 행동을 모방하는 방법을 볼 수 있습니다.

@davidfowl 최소 기본 패키지는 모든 비 MVC 앱에 유용할 것입니다. 예를 들어 모든 프레임워크를 우회하고 응답 자체에 직접 쓰기를 원하는 다른 많은 경량 앱과 마이크로 서비스가 있을 것입니다. IMO 이 옵션은 상자에서 사용할 수 있어야 하며 제어할 수 없는 패키지 버전으로 구성된 비공식 기반에서 시작하지 않는 것이 좋습니다. 이상적으로는 외부에서 유지 관리되는 다른 접선에서 시작하는 대신 기본 패키지에서 모든 것이 추가됩니다. 그러나 이것은 외부 커뮤니티가 함께 모여 모든 비 MVC 앱 및 프레임워크에 유용한 기본 "AspNetCore" 하위 집합을 유지 관리할 수 있는 영역 중 하나일 수 있습니다.

그렇다면 사용자 지정 프레임워크를 만들려면 어디를 살펴봐야 할까요? "Microsoft.AspNetCore.App"을 만드는 데 사용된 복사본에서 시작하고 필수가 아닌 모든 라이브러리를 제거하여 최소한의 유용한 하위 집합으로 되돌리는 것만큼 쉬울 수 있습니다.

@mythz 프레임워크가 필요한 이유는 무엇

@natemcmaster 사용자 지정 공유 프레임워크를 만드는 방법에 대한 세부 정보를 도와줄 수 있습니다.

@davidfowl 이 사용자 지정을 제안

이것은 아마도 당신의 빛 버전이 빛이나 핵에 대한 다른 사람의 생각이 아닐 수도 있다는 것을 말하는 것입니다.

MVC가 기본 패키지에 속하지 않는다는 데 모두가 만장일치로 동의하는 것 같습니다. 포함된 것으로 보이는 유일한 다른 "제품"은 MVC보다 사용량이 적고 포함할 이유가 적은 SignalR입니다. 저는 각 패키지에 무엇이 들어 있는지 잘 알지 못하지만 다른 모든 것은 일반적으로 유용하고 ASP.NET Core "플랫폼"에 도움이 되는 부분으로 보입니다.

자, 여기서 건설적인 시도를 해보자는 제안을 던지겠습니다. 우리는 Microsoft.AspNetCore.App을 변경하지 않으며 대다수의 사용자가 필요로 하고 사용할 것이라고 생각합니다. 이 "핵심" 공유 프레임워크인 또 다른 계층을 소개하겠습니다(원래 https://www.nuget.org/packages/Microsoft.AspNetCore/2.2.0-preview3-35497에서 이와 같이 했습니다). 이것이 Nancy 및 ServiceStack과 같은 다른 프레임워크의 기반이 되는 공유 프레임워크입니다.

우리는 여전히 Microsoft.AspNetCore.App과 함께 기본 템플릿을 지금과 동일하게 제공할 것이지만 귀하와 같은 프레임워크 작성자는 기본 공유 프레임워크를 사용하는 다른 템플릿을 가질 수 있습니다.

추신: 이 스레드는 원격으로 시작되는 대부분의 고객을 대표하지 않으므로 여기서 단독으로 결론을 내리지는 않겠습니다. 우리는 많은 곳에서 피드백을 받고 github은 가장 목소리가 높고 열정적인 지침을 가지고 있습니다.

예, 앱을 구성하고 실행하는 데 필요한 많은 내용을 포함하는 데 더 가깝습니다. Microsoft.AspNetCore.App 의 deps에서도 다음을 사용하고 있습니다.

• Microsoft.Extensions.Primitives
• Microsoft.AspNetCore.Http
• Microsoft.AspNetCore.Http.Abstractions
• Microsoft.AspNetCore.Http.Extensions
• Microsoft.AspNetCore.Hosting.Abstractions
• Microsoft.AspNetCore.Logging.Abstractions
• Microsoft.Extensions.DependencyInjection.Abstractions
• Microsoft.Extensions.Configuration.Binder
• Microsoft.AspNetCore.Cryptography.KeyDerivation

따라서 HTTP, 호스팅, 로깅 및 구성 추상화(대부분의 HTTP 앱에 유용)와 같은 항목도 포함되는 것이 좋으며 다른 사람이 적절하다고 생각하는 모든 항목도 포함됩니다. 내 유일한 선호 사항은 MVC/SignalR을 포함하지 않는 것입니다.

이제 흥미로워집니다. David가 이미 말했듯이: 사람들은 다른
"핵심"이 의미하는 바에 대한 아이디어. 내 POV에서 나는 DependencyInjection을 생각하지 않습니다.
있어야 합니다. / 어깨를 으쓱

Am Do., 8. 2018년 11월 um 08:30 Uhr schrieb Demis Bellot <
알림@github.com>:

예, 나는 그것이 많은 필수 요소를 포함하는 것에 더 가깝다고 생각합니다.
앱 구성 및 시작 및 실행. 의 뎁스에서
Microsoft.AspNetCore.App
https://www.nuget.org/packages/Microsoft.AspNetCore.App 우리도
사용:

• Microsoft.Extensions.Primitives
• Microsoft.AspNetCore.Http
• Microsoft.AspNetCore.Http.Abstractions
• Microsoft.AspNetCore.Http.Extensions
• Microsoft.AspNetCore.Hosting.Abstractions
• Microsoft.AspNetCore.Logging.Abstractions
• Microsoft.Extensions.DependencyInjection.Abstractions
• Microsoft.Extensions.Configuration.Binder
• Microsoft.AspNetCore.Cryptography.KeyDerivation

HTTP, 호스팅, 로깅 및 구성 추상화와 같은 것들
(대부분의 HTTP 앱에 유용함) 또한 포함하는 것이 좋을 것입니다.
다른 사람이 적절하다고 생각합니다. 내 유일한 취향은 갖지 않는 것입니다
MVC/SignalR 포함.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/aspnet/AspNetCore/issues/3755#issuecomment-436898980 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AADgNOzUVEHlJNBrPD5P2BsQj6UQdqyvks5us92zgaJpZM4YAsZ1
.

@mythz 대부분은 전이적으로 포함됩니다.

@forki 😆 우리의 세계에 오신 것을 환영합니다.

우리는 Microsoft.AspNetCore.App을 변경하지 않으며 대다수의 사용자가 필요로 하고 사용할 것이라고 생각합니다.

유명한 마지막 말. 이것이 모든 잘못된 결정의 정당화입니다. "우리는 그들이 필요하다고 생각합니다".

내가 어떻게 생각하는지 알아? Microsoft는 개발자 기반을 양 개발자가 아닌 독립적인 지능형 엔지니어로 취급하기 시작해야 합니다. 그렇습니다. 여러분에게는 여러분이 무엇을 던지면 따라하고 사용할 양 개발자가 많이 있습니다. 커뮤니티를 만들고 .NET 스택에서 새로운 스타트업을 구축합니다.

때로는 파워 유저의 말을 듣는 것이 좋습니다.

그럼에도 불구하고 우리는 Microsoft.AspNetCore.App을 변경하지 않을 것입니다. 나는 여기의 요구 사항을 충족한다고 생각하는 절충안을 제안했습니다.

@forki aspnet 코어를 사용하는 경우 어쨌든 DI에 직면하게 되므로 기본적으로 편리한 방법을 포함하도록 하는 것이 좋습니다(서비스 받기, GetRequired 서비스그리고 좋아하는 것은 그 패키지에 있습니다). 그리고 F#은 누락된 T :> U 제약으로 인해 자체적으로 생성할 수도 없습니다. https://github.com/fsharp/fslang-suggestions/issues/255 그래서 ¯_(ツ)_/¯

@davidfowl이 언급한 기본 공유 프레임워크를 갖고 싶습니다... 제 생각에는 @mythz 와 @dustinmorris 가 모두 그러한 접근 방식으로 괜찮을 것이라고 생각합니다. 이것은 또한 토성 @Krzysztof-Cieslak에게 적합합니다.

당신은 어쨌든 DI에 직면

나는 알고 있고 우리는 그 논의를 여러 번 했다. 그냥 안하는게 좋을듯
;-) 하지만 그것이 무엇인지...

오전 Fr., 2018년 11월 9일, 10:57 모자 Nino Floris [email protected]
게슈리벤:

@forki https://github.com/forki aspnet 코어를 사용하는 경우
어쨌든 DI에 직면하면 편의 방법을 포함하는 것이 좋습니다.
기본값(서비스 가져오기, GetRequiredService 등이 그 안에 있습니다.
패키지). 그리고 F#은 누락으로 인해 자체적으로 생성할 수도 없습니다.
T :> U 제약 조건 fsharp/fslang-suggestions#255
https://github.com/fsharp/fslang-suggestions/issues/255 그래서 ¯_(ツ)_/¯

기본 공유 프레임워크 @davidfowl을 갖고 싶습니다.
https://github.com/davidfowl 언급... 내 생각에 @mythz
https://github.com/mythz 및 @dustinmorris
https://github.com/dustinmorris 둘 다 이러한 접근 방식으로 괜찮을 것입니다.
이것은 또한 토성 @Krzysztof-Cieslak에게 적합합니다.
https://github.com/Krzysztof-Cieslak

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/aspnet/AspNetCore/issues/3755#issuecomment-437309244 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AADgNGP3d8R0otOAuUQC7AYK6O2dzJ3mks5utVGegaJpZM4YAsZ1
.

다음을 포함하도록 원본 게시물을 업데이트했습니다.

• Microsoft.AspNetCore.Authentication.JwtBearer
• Microsoft.AspNetCore.Authentication.OpenIdConnect

이들은 공유 프레임워크에서 제거되고 NuGet 패키지로 제공됩니다. 이러한 어셈블리에는 아직 공유 프레임워크에 대한 지침에 맞지 않는 IdentityModel API에 대한 종속성이 있습니다. 우리는 IdentityModel 팀과 협력하기 시작했으며 향후 이를 공유 프레임워크에 다시 넣는 것을 고려하고 있습니다. 크레프 https://github.com/aspnet/AspNetCore/pull/6035

Microsoft.AspNet.WebApi.Client를 포함하도록 원본 게시물을 업데이트합니다. https://github.com/aspnet/AspNetCore/pull/6552#issuecomment -453177732를 참조

꼭 넣어야 하는 부분이라 헷갈리는 경우가 많습니다.

Visual Studio 말하기 - Microsoft.AspNetCore.App 노드를 열고 그 아래에 있는 모든 항목을 개별적으로 설치했을 수 있는 항목과 상호 참조해야 합니까?

집 청소를 하고 있는데 이 패키지가 있는지 확인합니다. 그렇다면 중복되는 것은 무엇입니까?

<PackageReference Include="Microsoft.ApplicationInsights.AspNetCore" Version="2.6.0-beta2" />
<PackageReference Include="Microsoft.AspNetCore.App" />
<PackageReference Include="Microsoft.AspNetCore.NodeServices" Version="2.2.0" />
<PackageReference Include="Microsoft.AspNetCore.SpaServices.Extensions" Version="2.2.0" />
<PackageReference Include="Microsoft.EntityFrameworkCore" Version="2.2.1" />
<PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="2.2.1" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="2.2.1">

SpaServices와 EntityFramework 도구가 현재 포함되어 있다는 사실에 매우 놀랐습니다(이전에는 깨닫지 못했고 훌륭합니다). 하지만 도움이 되지 않는 오래된 2.2.1 참조도 있습니다.

요점은 - Visual Studio 팀과 더 나은 조정 작업을 수행하여 이러한 메가 패키지를 이해하고 무언가를 제거하는 것이 안전하다고 알려주는 IDE가 좀 더 지능적으로 되도록 할 수 있습니까? 그런 다음 v3에서 추가해야 한다고 알려줍니다. 다시 ;-)

@simeyla 피드백 주셔서 감사합니다. 당신이 말하는 것은 주제와 관련이 있지만 정확히 이 스레드에 대한 내용은 아닙니다. 패키지 참조를 최적화하는 도구는 새로운 Visual Studio 기능이 될 것입니다. 이 기능은 이 시나리오뿐만 아니라 일반적으로 유용할 수 있으므로 이 피드백을 Visual Studio에 직접 보내는 것이 좋습니다. VS에서 "도움말 > 피드백 보내기..."를 사용하십시오. 게시물을 작성한 후 링크를 ​​공유하면 VS에서 작업하는 동료 팀에 내부적으로 전달할 수 있습니다.

3.0에서는 Microsoft.AspNetCore.App 메타패키지를 완전히 제거하고 배송할 패키지를 많이 조정할 것입니다. 2.x에서 3.0으로 업그레이드하는 방법을 문서화하기 시작했으며 3.0에서 제공되는 어셈블리 목록을 마무리하면서 이 문서를 계속 업데이트할 것입니다.

이 항목은 작업을 추적하지 않기 때문에 '토론' 이정표로 이동하지만 구현 변경 사항에 대한 세부 정보로 업데이트합니다.

Microsoft.Extensions.DependencyModel 을 목록에 추가했습니다. https://github.com/aspnet/AspNetCore/pull/10271의 일부로 변경됨

@natemcmaster @DamianEdwards에 질문하세요. 로컬에서 빌드하는 데 필요한 모든 것이 있는 템플릿에 대한 언급이 있습니다. 이러한 생각과 인증 라이브러리의 제거로 인해 인증 템플릿이 3.0에서 오프라인으로 빌드되지 않는다는 의미입니까? 어떤 인증 라이브러리도 오프라인에서 작동하지 않는다는 것을 이해하지만 너겟 캐시가 없으면 오프라인 상태에서 새 인증 템플릿을 새로 만든 후 이론적으로 빌드 실패가 발생할 수 있습니다. 좋지 않은 경험인 것 같습니다.

네, 이것이 이 변화의 결과 중 하나입니다. Preview 6(곧 제공 예정) 현재 dotnet new mvc , dotnet new razor , dotnet new web 및 기타에는 PackageReferences가 없으므로 영향을 받지 않지만 추가 옵션을 지정합니다. , --auth individual 와 같이 패키지 다운로드가 필요한 PackageReference가 나타날 수 있습니다.

우리는 여기서 의도적인 절충안을 만들고 있습니다. PackageReference가 있는 템플릿은 깨끗한 시스템에서 오프라인으로 복원되지 않지만 미리 채워진 오프라인 NuGet 캐시를 만들려고 할 때 발생하는 많은 문제도 방지하고 있습니다. dotnet-docker/issues/237, https://github.com/NuGet/Home/issues/6309 및 http://blog.ctaggart.com/2019/03/using-nuget-lock-file-for-reproducible .html).

@natemcmaster는 완전히 이해하고 추론을 얻었습니다. 잘 문서화해야 합니다. 그렇지 않으면 사람들이 dotnet new webapp --auth Individual 가 빌드되지 않는다고 말하는 초기 3.0 릴리스에서 수많은 문제가 열릴 것입니다.

Microsoft.AspNetCore.Authentication.JwtBearer가 .netcoreapp3.0에 대한 종속성을 사용하여 컴파일된 이유를 알려줄 수 있는 사람이 있습니까? .netstandard2.x에서는 안될까요? 클래스 라이브러리에서 사용하고 싶고 클래스 라이브러리를 모두 .netstandard로 유지하고 싶습니다.

@buvinghausen https://github.com/aspnet/Announcements/issues/324

@Pilchie 이 문제는 ASP.NET Core 3.0에 대한 문서에서 <PackageReference> 를 추가해야 합니다.

@Bomret 우리가 조사한 거의 모든 실제 고객 앱은 어떤 방식으로든 MVC를 사용합니다. 공유 프레임워크에 유지하면 많은 이점이 있으며, 왜 제거해야 하는지 명확한 이유가 없습니다.

MVC가 전혀 필요하지 않은 서버리스 앱, 웹 API 등을 위해 .net 코어를 사용하는 다른 상점에서는 확실히 그렇지 않습니다.

오늘 3.0을 출하했기 때문에 마감합니다.

이 목록을 문서로 옮겨야 합니다.

@davidfowl 추가되었습니다: https://docs.microsoft.com/en-us/aspnet/core/migration/22-to-30?view=aspnetcore-3.0&tabs=visual-studio#remove -obsolete-package-references

@pranavkm 목록은 실제로 정반대입니다. 더 이상 패키지가 아니지만 여전히 공유 프레임워크에 있을 가능성이 있는 것입니다.

이것은 공유 프레임워크에서 제거되었지만 이제 패키지로만 사용할 수 있는 것에 관한 것입니다.

@scottaddie 이것은 ASP.NET Core 라이브러리 작성 문서에서 참조해야 하는 목록입니다.

@DamianEdwards - https://docs.microsoft.com/en-us/aspnet/core/migration/22-to-30?view=aspnetcore-3.0&tabs=visual-studio#add -package-references-for-removed - 어셈블리?

바로 그거야 :)

파티에 늦었지만 개발을 단순화하려는 목표를 달성하는 데 도움이되지 않는 것 같습니다.

a) 이제 AspNetCore 구성 요소(예: SignalR)에 대한 개선 사항이 있는 경우 Microsoft.AspNetCore.App에 대한 새로운 "dotnet 팩"이 이를 사용하기 위해 출시될 때까지 기다려야 합니다. 그 팩에 다른?
b) 더 이상 netstandard 클래스 라이브러리(예: Auth 미들웨어)에서 AspNetCore용 유틸리티 클래스를 생성할 수 없습니다. 이제 클래스 라이브러리는 이 항목을 수용하기 위해 netcoreapp3.0이어야 합니다. 이는 유틸리티 클래스 라이브러리를 netstandard / netcore 구현으로 분할하는 것을 의미합니다.
편집: c) <Project Sdk="Microsoft.NET.Sdk.Web"> 수행하는 경우 실제로 사용 중인 팩 버전을 어떻게 정의합니까? 분명히 우리는 dotnet을 업데이트한 후 다른 분기에서 재현 가능한 빌드를 원합니다.

a) 이제 AspNetCore 구성 요소(예: SignalR)에 대한 개선 사항이 있는 경우 Microsoft.AspNetCore.App에 대한 새로운 "dotnet 팩"이 이를 사용하기 위해 출시될 때까지 기다려야 합니다. 그 팩에 다른?

SignalR은 나머지 AspNetCore와 동일한 일정으로 배송되므로 여기에 일정 변경이 없습니다.

SignalR은 나머지 AspNetCore와 동일한 일정으로 배송되므로 여기에 일정 변경이 없습니다.

그래서 이것은 단지 나쁜 예입니까? 제거된 다른 모든 NuGet 패키지에 대해서도 마찬가지입니까?

SignalR은 나머지 AspNetCore와 동일한 일정으로 배송되므로 여기에 일정 변경이 없습니다.

그래서 이것은 단지 나쁜 예입니까? 제거된 다른 모든 NuGet 패키지에 대해서도 마찬가지입니까?

나도 그렇게 생각해. 모든 .NET Core 및 ASP.NET Core 구성 요소는 동일한 배송 일정을 사용합니다. 그렇지 않은 경우 자체 패키지로 배송해야 합니다.

나도 그렇게 생각해. 모든 .NET Core 및 ASP.NET Core 구성 요소는 동일한 배송 일정을 사용합니다. 그렇지 않은 경우 자체 패키지로 배송해야 합니다.

당신의 말을 받겠습니다. 구체적인 반대 사례가 없습니다. 과거에 AspNetCore NuGet 패키지를 업데이트할 때 그런 식으로 "느끼지" 않았습니다.