Aspnetcore: 새로운 ASP.NET Core 2.0 패키지는 더 이상 .NET Desktop에서 사용할 수 없습니다.

이것은 매우 이상하고 나쁜 변경이 될 것입니다. 나는 netfx 전용 asp.net 핵심 코드를 많이 작성했으며 그 투자가 낭비되는 것을 보고 싶지 않습니다. 보다 일반적으로 .NET 고객은 가까운 미래에 ASP.NET Core와 Desktop 코드 간에 상호 운용할 수 있어야 합니다. Active Directory 또는 Office COM 자동화를 사용하거나 일부 System.Drawing 기반을 사용하여 미리보기를 수행하는 웹앱을 상상해 보십시오. 라이브러리를 만들거나 WPF 앱과 코드를 공유할 수 있습니다. 이와 같은 많은 시나리오를 생각하는 것은 사소한 일이며 우리가 단순히 무슨 일이 일어나고 있는지 오해했기를 바랍니다.

우리는 현재 AspNetCore 1.1.1에 있습니다. 즉, "현재" 지원 분기입니다. Net4XX에 대한 종속성으로 인해 2.0으로 이동할 수 없다면 2.0+3개월이 떨어지면 지원되지 않는다는 의미인가요?

WPF와 ASP.NET Core의 조합을 사용하고 두 경우 모두 전체 프레임워크를 대상으로 합니다.
가까운 장래에 2.0이 없을 것 같습니까?

그러나 전체 프레임워크 4.6.1이 netstandard 2를 지원합니까? 내가 뭔가를 놓치고 있습니까? (https://docs.microsoft.com/en-us/dotnet/articles/standard/library)

이것은 현재 도구가 업데이트되지 않은 것입니까?

그것은 완전히 괜찮을 것이며 asp.net 코어가 net standard 2에서 실행되는 것을 볼 것으로 예상됩니다. 놀라운 점은 net core app2.0으로 이동할 가능성이 있다는 것입니다. 이는 더 이상 asp.net 내부의 레거시 코드를 사용할 수 없음을 의미합니다 핵심 웹사이트

오, 그게 문제네요.. netcore2의 compat shim에 의해 조금 완화되었다고 생각합니다. 이 기능을 사용하면 이전 어셈블리를 참조할 수 있지만 여전히 모든 프로젝트를 새 프로젝트 시스템으로 이식하는 것과 많은 다른 작업을 의미합니다.

팀에서 이에 대한 추론을 듣는 것이 좋습니다.

오, 그래서 netcoreapp2.0 프로젝트가 유형 통합 덕분에 단순히 netfx 라이브러리를 참조할 수 있을 것이라고 생각하십니까? 그것은 많은 것을 설명할 것입니다. 내 질문은 그렇다면 Windows에서 실행되지만 핵심 CLR에서는 실제로 작동하는 코드의 양입니다.

와. 이것은 우리를 완전히 차단하고 기본적으로 가까운 장래에 이러한 패키지를 업데이트할 수 없도록 합니다. 현재 net462+를 타겟팅할 수 없기 때문에 MvcCore 프로젝트를 Mvc로 다시 마이그레이션해야 할 수도 있습니다.

저도 이게 굉장히 궁금합니다. 나는 이것이 중간(그리고 수명이 짧은) 단계나 큰 오해에서 실제로 이루어지기를 바랍니다. 대부분의 애플리케이션에 대한 채택도 확실히 방해가 될 것입니다.

모든 것을 Core로 옮기는 것은 (개발을 중지하지 않고) 대규모 기존 코드베이스에 너무 많은 작업이며, 우리의 주요 프로젝트에서 중간 단계 로 새로운 ASP.NET 클래스(HttpRequest, 컨트롤러 등)로 이동해야 합니다.

@DamianEdwards 또는 @davidfowl 이 여기에서 계획에 대해 언급할 수 있습니까? 또한 추가 추론을 찾는 데 문제가 있습니다.

나는 이것이 처음에 무서운 WTF 순간인 이유를 알 수 있습니다. 보이는 것보다 덜 이상하기 때문에 설명하겠습니다.

• 당신은 .NET 고객이 상호 운용할 필요가 있다고 말했습니다. 전적으로 동의합니다.
  
  
  
  • ASP.NET Core 2.0과 EVERYWHERE 간에 netstandard 라이브러리를 공유할 수 있습니다.
  
  
  • typeforwarding 및 netstandard20 때문에 ASP.NET Core 2.0에서 많은 net461+ 어셈블리를 참조할 수도 있습니다.
  
  
• WebApp이 다음을 사용해야 할 수도 있다고 말했습니다.
  
  
  
  • AD – 완전히, 이것은 LDAP를 직접 호출하려는 경우 공백입니다. Windows Auth NOW에 대해 확실히 인증할 수 있습니다. 우리는 여름 시간대에 Core 2.0을 위한 DirectoryServices 네임스페이스를 특별히 가질 계획입니다.
  
  
  • 그리기 - 완전히, 이것은 공백입니다. 우리는 여름 기간 동안 Core 2.0을 위해 이것을 가질 계획입니다. 이 때까지 이러한 netstandard 옵션은 ImageSharp, ImageResizer, Mono 옵션 등도 존재합니다.
  
  
  • COM 자동화 – 이것은 Core 2.0에서는 결코 가능하지 않았지만, 자신을 다치게 하고 싶다면 확실히 PInvoke할 수 있습니다. 정말로 자신을 해치고 싶다면 WebAPI를 net461+ 프로세스에 로컬로 지정할 수도 있습니다.
  
  
  • WFP 앱과 코드 공유 – 예. netstandard2.0에서는 완전히 가능합니다.
  
  
• 이것은 이상한 변경입니다.
  
  
  
  • 하는 느낌이지만...
  
  

이런 식으로 생각하십시오. WPF는 netstandard2.0이 아니며 net461+에 있다는 것을 알고 있으며 괜찮습니다. 최적화되어 있지만 netstandard 라이브러리를 참조할 수 있습니다. ASP.NET Core 2.0은 Core 2.0에 최적화되어 있지만 공유 라이브러리를 참조할 수 있습니다. 자마린도 똑같습니다.

.NET Core는 나란히 있으며 빠르게 움직이고 있습니다. .NET(전체) 프레임워크가 이동할 수 있는 것보다 훨씬 빠릅니다. .NET Core 2.0(.NET Standard의 SUPERSET임) 위에 ASP.NET Core 2.0을 빌드하면 NetFx 또는 Netstandard보다 빠르게 빌드할 수 있습니다.

NetCore > Net Standard > NetFx는 개발 속도와 혁신에 관한 것입니다.

포인트는 새로운 작업을 한다면 netstandard20입니다. 이전 net461+ 라이브러리가 있는 경우 그 중 대부분은 ASP.NET Core 2.0에서 참조할 수 있습니다.

.NET Framework에서 실행되는 ASP.NET Core 1.1은 2.0 릴리스 후 1년 동안 완전히 지원됩니다. 해당 워크로드는 최소 2018년 7월까지 완전히 지원됩니다.

.NET Core 2에서 누락된 나머지 큰 격차는 System.DirectoryServices 및 System.Drawing입니다. 우리는 이번 여름에 Windows의 .NET Core에서 두 가지를 모두 사용할 수 있는 Windows 호환 팩을 만들기 위해 노력하고 있습니다.

우리 모두에게 필요한 것은 net461+에서 실행하기 위해 ASP.NET Core 2.0이 필요하다고 생각하는 이유에 대한 명확한 목록/이해입니다.

.NET Standard 2.0은 모두가 기다리고 있는 .NET Core와 .NET fx 사이의 격차를 해소하는 호환성과 상호 운용성에 관한 것이라고 생각했습니다.

어떤 이유로든 사용자 지정 외부 종속성, 상용 구성 요소, 레거시 라이브러리 종속성 등 .NET 4.x가 필요한 종속성을 갖게 될 많은 고객이 있을 것입니다.

고객이 기존 .NET 4.x dep를 참조할 수 있도록 데스크톱 CLR에서 실행되는 ASP.NET Core 2.0 앱을 만들 수 없도록 하려는 의도입니까?

@shanselman 답변 감사합니다. 좋은 예가 많이 있습니다.

라이브러리에 대한 후속 조치:
모든 추상화 라이브러리가 크로스 컴파일된 상태로 유지됩니까? 예를 들어 HttpRequest 를 사용하는 경우 사용 중인 ASP.NET Core 버전(이제 최소한 TFM에 깔끔하게 매핑됨)에서 1.x 및 2.x 빌드를 유지 관리하는 것이 좋습니다. 나는 피하고 싶습니다 ... 그래서 추상화가 netstandard 에 남아 있기 를 바랍니다. 그게 일반 계획인가요?

System.Web 의 HttpRequest 가 완전히 다르기 때문에 우리는 이미 ASP.NET/MVC에 의존하는 것에 대해 여러 변형을 유지 관리하고 있습니다. 그래서 그것은 완전히 다른 라이브러리입니다(예: MiniProfiler vs. . MiniProfiler.AspNetCore ). lib 작성자의 종속성이 netstandard 에서 벗어나는 경우 유지 관리하기 위해 로드하는 변형의 수를 염두에 두고 있는지 확인하고 그 두통을 모두 피했으면 합니다.

나는 이것이 보이는 것만큼 큰 문제가 아닌 것 같아 매우 기쁩니다. 자세한 설명에 감사드립니다.

두 가지 질문/걱정이 있습니다.

• ASP.NET Core에서 .NET Framework 라이브러리를 사용하는 데 마찰이 최소화되어야 하는 것처럼 들립니다. 대단해! 반대의 경우는 어떻습니까? Mvc 및 기타 지원 ASP.NET Core 라이브러리의 부품이나 구성 요소를 포함하는 .NET Framework 또는 netstandard 라이브러리 및 응용 프로그램이 있을 수 있습니다. 그것들은 깨질 것입니다, 맞죠? 해당 시나리오를 해결하는 방법에 대한 팁이 있습니까? netstandard 라이브러리가 더 이상 ASP.NET Core 라이브러리를 사용할 수 없는 경우 포함된 ASP.NET Core 시나리오에 큰 문제인 것 같습니다.

• 비기술적 관점에서 이것은 많은 혼란을 야기할 것 같습니다. GitHub에서 활동하는 사람들 외에 Twitter에서 팔로우하는 등 다양한 플랫폼을 둘러싸고 이미 많은 혼란이 있습니다. 부분적으로만 팔로우했거나 이제 막 시작하는 개발자를 볼 수 있습니다. ASP.NET Core를 사용하려고 할 때(아마도 오래된 자습서를 따름) .NET Framework 플랫폼에서 작동하지 않을 때 속도가 매우 느려집니다. 그것에 대해 무엇을 할 수 있는지 확실하지 않습니다.

typeforwarding 및 netstandard20 때문에 ASP.NET Core 2.0에서 많은 net461+ 어셈블리를 참조할 수도 있습니다.

불행히도 이것은 전체 프레임워크용으로 컴파일 및 설계된 라이브러리가 .NET Core에서 작동한다는 의미는 아닙니다(런타임에 모든 것이 폭발할 위험이 높습니다!).

.NET Core 2.0에 다시 도입된 많은 "이전" API는 (기능적으로) 작동하지 않는 스텁입니다. 여전히 누락된 API가 많고 .NET Core에서 의도적으로 제외된 전체 영역(IdentityModel, WCF 서버, 원격, 완전한 AppDomain 지원 등)이 있다는 것은 말할 것도 없습니다.

ASP.NET Core 1.0 w/ .NET Desktop 앱을 ASP.NET Core 2.0 w/ .NET Core로 "안전하게" 마이그레이션할 수 있다고 사람들을 설득하려는 시도는 - IMHO - 거짓말입니다.

.NET Core는 나란히 있으며 빠르게 움직이고 있습니다. .NET(전체) 프레임워크가 이동할 수 있는 것보다 훨씬 빠릅니다. .NET Core 2.0(.NET Standard의 SUPERSET임) 위에 ASP.NET Core 2.0을 빌드하면 NetFx 또는 Netstandard보다 빠르게 빌드할 수 있습니다.

나는 그것이 (대부분의) 사람들이 찾고 있는 것이라고 믿지 않습니다. 많은 사람들은 빠르게 움직이는 라이브러리를 필요로 하지 않고 모든 것을 깨뜨리는 위험을 감수하지 않고 이전 항목에 우아하게 통합할 수 있는 안정적인 항목 이 필요합니다.

@daveaglick

• net461 또는 netstandard2.0 netcoreapp2.0 를 참조하는 암시적 기능이 없다는 점에서 정확합니다. 다리는 일방통행입니다. 패키지 대체를 위해 TFM을 지정하여 항상 이 문제를 해결할 수 있지만 이는 지원되는 시나리오가 아닌 분명히 탈출구입니다(많은 사람들을 차단 해제하기에 충분할지라도). 더 큰 스택( netstandard 을 대상으로 함을 의미함) 외부에서 ASP.NET Core의 하위 시스템을 지원하는 것은 우리에게 적지 않은 작업입니다.
• 혼란의 가능성은 양방향으로 발생합니다. 예를 들어 "ASP.NET Core"가 .NET Framework(.NET Core 가 아님 )에서 실행될 수 있다는 사실이 혼란스럽다는 피드백을 많이 받았습니다. 이 변경은 ASP.NET Core를 .NET Core 스택의 일부로 효과적으로 만듭니다. 즉, ASP.NET Core를 사용하는 경우 .NET Core를 사용하는 것입니다.

@shanselman BTW, 크로스 컴파일이 옵션이 아닌 이유를 말하지 않았습니다. netcoreapp2.0 의 이점을 얻을 수 있는 ASP.NET Core 구성 요소 -only API는 net46 / netstandard1.x / netstandard2.0 및 netcoreapp2.0 TFM 및 새롭고 멋진/빠른 것을 .NET Core 전용으로 만드십시오.

@NickCraver 는 현재 netstandard 를 대상으로 *.Abstractions 패키지를 떠나는 것을 계획에 포함하지 않습니다. 분리가 전반적으로 깨끗하지 않습니다. 그러나 당신이 제안한 것과 같은 마이그레이션을 시도하는 누군가의 목적을 위해 패키지 대상 대체를 사용하면 어쨌든 거기에 도착할 것입니다(그러나 내가 당신을 오해하고 있을 수 있음).

또한 단일 패키지가 이제 TFM을 피벗으로 사용하여 ASP.NET Core 1.x 및 2.0 이상을 동시에 대상으로 지정할 수 있다는 점에서 깨끗한 TFM 분할이 정확하고 이 계획의 장점이라는 점을 지적했습니다.

나는 "혼합 응용 프로그램"이라는 아이디어를 가지고 놀고 있습니다. 예를 들어 Web API를 노출하는 WPF 응용 프로그램 또는 REST API와 WCF 끝점을 모두 제공하는 서버(이전 클라이언트와의 호환성을 위한 것일 수 있음). 이러한 시나리오는 이 변경으로 불가능하게 되었으며 ASP.NET Core가 "단지 라이브러리"가 아닌 새 응용 프로그램에만 적합하도록 만듭니다.

@shanselman 이 말했듯이 @PinpointTownes 는 고객이 .NET Framework를 직접 대상으로 지정해야 하는 것과 관련하여 고객이 가지고 있는 특정 요구 사항 및 차단 요소에 매우 관심이 있습니다. 지금까지 이 보트의 고객과 함께 작업한 결과 System.DirectoryServices 및 System.Drawing 및 1번 및 2번 차단제가 표시되었으며 이를 해결할 계획이 있습니다. 그 외에도 피드백을 살펴보고 평가할 것입니다.

크로스 컴파일은 고객 및 제품 요구 사항과 균형을 이루어야 하는 오버헤드입니다. 이것이 우리가 이 피드백을 받고자 하는 이유입니다. 그러면 ASP.NET Core가 앞으로 계속 발전함에 따라 고객과 우리 모두의 환경이 어떤 모습일지 보다 구체적으로 정의할 수 있습니다.

@DamianEdwards 추가 설명에 감사드립니다. netstandard -> ASP.NET Core 라이브러리는 저에게 큰 의미가 있습니다. 여러 netstandard 라이브러리에 Kestrel(netcoreapp로 이동하는 것으로 보입니다)을 포함합니다. 또한 Razor를 여러 위치에 포함했으며 더 많은 모듈식 버전을 개발 중이라는 것을 알고 있습니다. 또한 ASP.NET Core의 "일부"이지만 외부에 많은 유틸리티가 있는 수많은 라이브러리가 있습니다.

다시 말해, netstandard 라이브러리가 ASP.NET Core 패키지를 사용하는 기능을 제거하는 것이 반대보다 훨씬 더 중요합니다. 이것은 고려 사항에서 전체 사용 사례 클래스를 제거하는 것처럼 보입니다.

@daveaglick Razor 자체(엔진)는 계속해서 netstandard 를 대상으로 합니다. 다시 말하지만, 서로 다른 플랫폼에서 큰 복잡한 그래프(예: ASP.NET Core 2.0)의 특정 하위 시스템을 지원하는 데 비용이 듭니다. 임베딩과 같은 다른 옵션(소스 임베딩, 복사 등)이 있지만 물론 여기에는 장단점이 있습니다.

다양한 사용 사례 클래스에 대해 확실히 듣습니다. 실제로 우리와 같은 스택을 설계하고 배송할 때 고려해야 할 다양한 고객 그룹이 있습니다.

여기서 @daveaglick 의 우려 사항을 공유합니다. 최신 API를 사용하려는 ASP.NET Core는 완전히 이해할 수 있지만 다른 모든 다운스트림 에서 동일한 것을 요구하는 경우에는 좀 더 복잡해집니다. 안정 또는 업그레이드 1.0 이후에는 선택의 여지가 없습니다 netcoreapp2.0 로 이용할 수 있는 가장 빠른 기차를 타게 되며 이것이 유일한 선택입니다. 사용자가 netcoreapp2.0 소비하지 않고 모든 비트(기본 추상화 포함)를 소비할 수 없다면 이는 라이브러리의 전체 라인에 대해 사실상 netstandard2.0 가 없다는 것을 의미합니다...그리고 모든 사람 그것은 그들에게 달려 있습니다.

핵심 애플리케이션 스택을 이동하지만 특히 이동하는 추상화에 반드시 동의하지는 않습니다. 추상화의 주요 요점 중 하나는 적어도 소비자로서의 내 관점에서 이와 같은 긴밀한 결합을 피하는 것입니다. netstandard2.0 에는 필요한 API가 없지만 netcoreapp2.0 에는 필요한 몇 가지 예가 궁금합니다. 몇 가지 예가 있습니까? 이것은 주로 메소드 매개변수의 새로운 유형에 관한 것입니까? 나는 충분한 추론이 있다는 것을 의심하지 않으며 매우 궁금합니다. 예를 보는 것은 우리가 거의 매일 통찰력을 갖지 못하는 유지 보수 비용을 보여주는 데 도움이 될 것입니다.

Kestrel의 경우는 더 복잡하지만 최신 API 세트에 포함해야 한다는 주장이 확실히 보입니다. Kestrel이 추진하는 작업을 감안할 때 Kestrel에 대해 계속해서 새로운 API가 생성될 것이라고 상상합니다.

@shanselman 이 말했듯이 @PinpointTownes 는 고객이 .NET Framework를 직접 대상으로 지정해야 하는 것과 관련하여 고객이 가지고 있는 특정 요구 사항 및 차단 요소에 매우 관심이 있습니다.

컨설턴트로서 저는 많은 클라이언트가 자신의 앱을 ASP.NET Core로 이동하도록 도왔고 IdentityModel / WCF 또는 AppDomain 에 의존하는 타사(비공개 소스) 라이브러리를 사용할 수 있도록 .NET Desktop을 대상으로 지정해야 했습니다. 지원하다.

ASP.NET Core 2.0에 이러한 항목이 없으면 주요 차단기가 됩니다.

API가 있어도 기능적으로 다르기 때문에 .NET Core에서 작동하지 않는 라이브러리도 있습니다. 다음은 내가 여러 번 본 구체적인 사례입니다.

.NET Core에서 RSA.Create() 는 Windows에서 RSACng 인스턴스를 반환하지만 .NET Desktop에서는 RSACryptoServiceProvider 인스턴스를 반환합니다. 그러나 BLC 자체를 포함한 많은 라이브러리는 RSA 를 RSACryptoServiceProvider 로 캐스팅하려고 시도합니다. RSACng 는 RSACryptoServiceProvider 로 캐스팅할 수 없으므로 .NET Core에서는 항상 실패합니다.

@NickCraver 특히 어떤 추상화입니까? 추상화만 이동하는 문제는 다음에 해당 추상화를 기반으로 하는 모든 것을 원하게 된다는 것입니다(말 그대로 Microsoft.AspNetCore.Http.Abstractions만 필요하고 다른 것은 필요하지 않다고 말하는 경우 제외)

@davidfowl 예, 추상화 만 가능 합니다. 예: HTTP, 호스팅, HTML 및 로깅. Microsoft.Extensions.* 는 대부분의 이전 댓글에 포함된 것 같습니다. 오늘 제가 접하고 있는 분들입니다.

구체적인 예: MiniProfiler 미들웨어는 추상화( 링크 ) 외에는 응답하지 않습니다.

맨 위에 MVC 등을 사용하고 있다면 어쨌든 netcoreapp2.0 에 있고 그것이 바로 그것입니다(그리고 IMO는 괜찮습니다). 그러나 현재 저는 API를 공유하는 곳에서 논리적으로 자유롭게 분할할 수 있으며 추상화이기 때문에 쉽게 분할할 수 있습니다. 저는 현재 분할의 팬입니다. 불필요하게 잠그지 마십시오.

헤. 컨설턴트로서 "무엇을? ASP.NET Core는 데스크톱 .NET Framework에서 실행됩니다!?"라는 말을 확실히 들었습니다. 몇 번이고 질문한다. "ASP.NET Core"의 이름에 말 그대로 ".NET Core"가 포함되어 있다는 사실은 정말 안타까운 일입니다.

어쨌든... 내가 .NET Core가 시작될 때("새롭게" 시작) 구식/레거시/깨진 API를 삭제하는 것을 좋아했던 것처럼 더 빠르고 간결한 프레임워크를 얻기 위해 이 변경 사항도 좋아합니다. 더 많은 기능과 더 높은 혁신 속도를 제공합니다.

하지만 어떤 이유로든 내년 6월 이전에 모든 코드를 .NET Core로 마이그레이션할 수 없는 모든 개발자에게 공감합니다.

여기에는 현재 병렬로 개발 중인 여러 ASP.NET Core 프로젝트에서 사용하는 .NET Framework를 대상으로 하는 엄청나게 큰 레거시 라이브러리/프레임워크가 있는 현재 클라이언트가 포함됩니다. 이러한 시스템이 프로덕션에 들어갈 때쯤이면 ASP.NET Core 1.x가 지원되지 않기 전에 a) 모든 것을 .NET Core로 이식하거나 b) 모든 것을 전체 프레임워크 ASP.NET으로 이동할 시간이 거의 또는 전혀 없을 것입니다.

여기에서 지원 1년이면 정말 충분합니까? 비슷한 사례가 또 있을 거라 생각하는데...

@khellang 이전에 언급했듯이 .NET Framework를 대상으로 하는 라이브러리/프레임워크를 계속 참조할 수 있으며 호출하는 API가 netstandard2.0 폐쇄의 일부라고 가정하면 제대로 작동합니다. 그들이 그 공간 밖의 것에 의존하는지 아십니까? 이것이 바로 이러한 API(예 System.DirectoryServices 및 System.Drawing )를 이식하는 우선 순위를 평가할 수 있도록 피드백을 받고 싶습니다.

따라서 현재 Windows 서비스 또는 WPF 데스크톱 앱에서 웹 API(예: 통신 계층) 또는 곧 출시될 asp.net 코어 소켓을 호스팅하는 것이 불가능하게 될까요? (지원되는 버전 포함).

netstandard1.x 였던 항목이 현재 netcoreapp2.0 인 항목의 목록이 곧 나올 것이라고 생각합니다.

리포지토리를 검색했는데 MVC 관련 항목이 netcoreapp2.0 인 것 같지만 HttpAbstractions, Logging, Configuration 등은 여전히 netstandard 입니다. 아니면 더 많은 변경 사항이 있습니까?

@NickCraver Extensions를 사용하고 있지만 여전히 System.Web을 사용하고 있습니다. System.Web.HttpContext 로 Microsoft.AspNetCore.Http.HttpContext 를 심을 계획이 있습니까? 얼마나 많은 API가 필요한지 알고 있습니까?

맨 위에 MVC 등을 사용하는 경우 어쨌든 netcoreapp2.0에 있고 그것이 바로 그것입니다(그리고 IMO는 괜찮습니다). 그러나 현재 저는 API를 공유하는 곳에서 논리적으로 자유롭게 분할할 수 있으며 추상화이기 때문에 쉽게 분할할 수 있습니다. 저는 현재 분할의 팬입니다. 불필요하게 잠그지 마십시오.

MVC에 대해 이야기하는 것이 아니라 기본 추상화 위에 더 많은 기능을 노출하는 다른 도우미에 대해 이야기하고 있습니다. 우리가 선택한 "추상화" 패턴의 큰 가치는 추상화 자체가 아니라 다른 것들이 그 위에 구축될 수 있다는 것입니다. 내 직감에 따르면 ASP.NET 추상화를 netstandard로 만들면 결국 모든 미들웨어도 netstandard로 만들어야 합니다.

@dasMulli Windows 서비스는 API를 이식하면 작동합니다(.NET Core에서 Windows 서비스를 지원하는 오픈 소스 라이브러리도 있음).

WPF 데스크톱 앱? (지원되는 버전 포함).

네. 이것은 더 이상 기본값이 아닙니다. .NET Core 2.0에서는 더 이상 즉시 지원하지 않습니다.

@davidfowl 나는 당신이 거기에서 올바른 부분을 보았는지 확신하지 못합니다.

하지만 여전히 System.Web을 사용하고 있습니다.

...이 분할로 인해 동일한 라이브러리에 없습니다. 최소한의 오버헤드를 달성하고 소비자에 대한 종속성 트럭 로드가 아닌 ASP.NET MVC < 6(System.Web) 및 $# MiniProfiler MiniProfiler.AspNetCore / MiniProfiler.AspNetCore.Mvc (많은 NuGet ).

MiniProfiler.Shared 에 있었던 System.Web 흔적에 대해 말씀하시는 것 같습니다. 저는 지난 밤 프레임워크 어셈블리에서 NuGet 문제가 수정될 때까지 이를 정리하려고 기다리고 있었습니다. 정리를 위해 그냥 제거했습니다 .

@DamianEdwards netstandard2.0 폐쇄에 대해 100% 동의하지는 않지만 (그들의 허가를 받아) 이식성 분석기를 실행하고 결과를 공유하게 되어 기쁩니다. 이식성 분석기는 여전히 최신 상태입니까?

ASP.Net Core는 빠르게 새로운 Python 3*가 되고 있습니다. 더 나빠질뿐입니다. 이것은 나에게 잘못된 방향으로의 움직임처럼 보입니다. 이것은 수많은 시나리오로 인해 개발자가 이동하는 대신 앞으로 몇 년 동안 "이전 플랫폼"에서 코드를 유지 관리(및 새 작성)해야 한다는 것을 의미합니다. "빠른 개발"이 의미하는 모든 것이 "빠른"/부적합한 위치에 도달하는 것이라면 아주 좋은 주장처럼 보이지 않습니다.

*나는 Python 3을 좋아하지만 거의 10년이 지났고 Python 커뮤니티는 여전히 분열되어 있습니다.

명확히 하자면, 기술적인 방해 요소(멋진 성능)가 있습니까? 아니면 향후 호환성 유지 비용을 절약하기 위한 것입니까?
나는 우리 대부분이 이 움직임이 올 것이라는 것을 알았지만 아무도 그렇게 빨리 예상하지 못했다고 생각합니다. 전환 시간이 여전히 진행 중임을 감안할 때 - 최소한 하나의 릴리스(예: 2.1이 아닌 2.0)에 대해 net* 지원을 유지하는 것이 좋습니다.

@shanselman 나는 당신의 요점을 보고 개인적으로 동의합니다. 그러나 _많은_ 사람들은 그렇게 보지 않을 것입니다.

주요 문제는 코어에서 net46 어셈블리를 호출하지 않는다는 것입니다. 대부분의 경우 compat shim이 이를 처리합니다. 문제는 기존 net46 코드와 46에서 실행되는 asp.net core 1.* 코드입니다. 누군가가 언급했듯이 netstandard의 요점은 asp.net을 포함한 코드가 모든 곳에서 실행되도록 하는 것이었습니다. 이것은 단계처럼 느껴질 것입니다. 그것에서 멀리 떨어져 있고 아마도 어떤 사람들에게는 그 비전의 실패일 수도 있습니다.

문제는 사람들이 네트 코어로 이동하는 것을 _원하지 않는_ 것입니다. 문제는 조직, 관리자, CTO 등이 그렇게 하는 데 따른 비용/이익이 그만한 가치가 있다고 확신해야 한다는 것입니다. 이식하는 데 시간이 너무 많이 소요되어 배달에 지장을 줄 뿐만 아니라 회귀 등의 위험이 발생합니다.

즉, 사람들이 움직이지 못하게 하는 것이 항상 기술적인 이유는 아닙니다. 거의 모든 프로젝트가 _기술적으로_ 거의 모든 프로젝트에서 도약할 수 있다고 말할 수 있습니다. 그러나 그 비용/납품 명세서에 동기를 부여하는 것이 문제입니다. 그것은 매우 어려운 판매일 수 있습니다. 제가 몇 번 공정한 판매를 해야 했던 것입니다. 이러한 경우 "하지만 전체 프레임워크에서 실행할 수 있습니다"라고 말할 수 있는 것이 그 움직임을 주도하는 방법이었습니다.

자신을 다치게 하고 싶다면

이것이 바로 그것입니다. Net46 개발자와 경영진은 그렇게 보지 않을 것이며, Microsoft _you_가 최신 릴리스를 따라잡기 위해 자신을 해치고 싶어하는 것으로 볼 것입니다. "그럼 움직이지 마세요."라고 말할 수도 있지만 asp.net core 1.x의 지원이 짧기 때문에 최소한 책임을 져야 하는 관리자의 관점에서는 그렇게 해야 합니다. 버그로 인해 가동 중지 또는 정보 손실이 발생합니다. (프레임워크가 책임지지 않더라도)

실제로 asp.net 코어 1.1을 추진했던 많은 개발자들은 이제 코어 없이는 2.0으로 이동할 수 없다는 배신감을 느낄 것입니다. 그것이 정당화될 수도 있고 아닐 수도 있지만 저는 단지 많은 사람들이 그렇게 느낄 것입니다.

그게 중요합니까? 이로 인해 asp.net core2/dotnet core2가 "죽게"됩니까? 아니요, 하지만 채택이 느려지고 생태계가 파괴될 것입니다. 정말 안타까운 일입니다. 나는 사람들이 2.0에 나오는 이 모든 훌륭한 것들을 사용할 수 있기를 원하고 크로스 컴파일을 순 표준으로 자르는 것이 영향을 줄 것입니다. 확실히, 이 리포지토리에서 어울리고 있는 대부분의 사람들은 문제가 없을 것입니다. Joe와 Jane 개발자, 더군다나 그들의 관리자가 문제입니다.

@DamianEdwards
이것이 혼란의 원인이라는 데 동의합니다. 여러 번 설명해야 했지만 그 결과 항상 실망한 개발자를 흥분된 개발자로 만들었습니다. 왜냐하면 그들은 새로운 멋진 것을 사용할 수 없다고 생각했기 때문입니다 그러나 그들이 할 수 있다는 것이 밝혀졌습니다.

요약하자면, 이 결정이 가볍게 내려진 것이 아니라고 확신하지만, 이렇게 해야 한다면 메시징에 대해 정말 _정말_ 조심해야 한다고 생각합니다.. 특히 1에서 asp.net 코어로 마이그레이션하는 것을 보여주어야 합니다. x는 net46에서 _매우_ 간단하고 매우 세련되었습니다. net46의 다른 netstandard 라이브러리를 프로젝트 참조로 참조하거나 그렇지 않으면 견고해야 한다는 이야기입니다. 사람들이 놀라는 것을 피하기 위해 이것을 명시적으로 표시/처리해야 한다고 생각합니다.

이식성 분석기 질문에 대한 @khellang 페이징 @terrajobst .

@khellang

예, 방금 2017용 VSIX를 업데이트했지만 여기 에서 단순히 명령줄 버전을 사용합니다.

@NickCraver 물론, netstandard를 대상으로 하는 미들웨어를 작성할 수 있습니다. ASP.NET Core가 netcoreapp2.0을 지원하는 경우 라이브러리 작성자에게 어떤 이점이 있습니까?

@aL3891 훌륭한 요약입니다! 우리 가 앞으로 가지고 있는 한 가지 큰 문제는 netstandard에도 있는 것에 대해 새로운 API를 활용하는 방법입니다. .NET Core 는 새로운 기능을 구현하는 데 필요한 새로운 API를 제공합니다(Kestrel에서 HTTP2 지원을 위한 SSLStream ALPN 지원을 염두에 두십시오). 그래서 당신은 우리가 netstandard를 계속 유지하고 가장 높은 버전(.NET Framework는 아직 지원하지 않음)을 계속 사용한다고 주장할 수 있지만, 그러면 우리는 같은 배를 타게 될 것입니다.

우리가 앞으로 가지고 있는 한 가지 큰 문제는 netstandard에도 있는 것에 대해 새로운 API를 활용하는 방법입니다. .NET Core는 새로운 기능을 구현하는 데 필요한 새로운 API를 제공합니다(Kestrel에서 HTTP2 지원을 위한 SSLStream ALPN 지원을 염두에 두십시오).

https://github.com/dotnet/corefx/issues/4721 에 따르면 SslStream 에 대한 ALPN 지원은 .NET Core 2.0에 대해 준비되지 않습니다. 이것이 결국 몇 개월 후에 구현된다고 가정하면 netcoreapp2.0 TFM을 타겟팅할 때 사용할 수 있다는 의미입니까? 이 경우 사용자가 이전 .NET Core 런타임을 사용하는 경우 초기 netcoreapp2.0 모양의 일부가 아닌 새 API를 사용하는 netcoreapp2.0 기반 라이브러리를 릴리스하기로 결정하면 어떻게 됩니까? ? 충돌할까요? 아니면 netcoreapp2.x 가 netstandard1.x 와 일치합니까? TFM 버전을 높이지 않고는 계약을 변경할 수 없습니까?

스택 및 테스트의 다른 구현에 대한 @davidfowl . 그리고 "모든 사람이 MVC를 가지고 있고 모든 종속성을 원한다고 가정"하는 대신 2개의 라이브러리 사이에서 적절한 분할로 추상화(MVC가 필요하지 않음)를 사용하기 때문입니다.

추상화가 실제로 추상화되지 않고 ASP.NET Core 자체에 너무 밀접하게 결합되어 있는 경우 해당 패키지를 제거하지 않는 이유는 무엇입니까? 그것이 전반적인 관계 목표라면 삶을 더 쉽고 명확하게 만들 수 있기 때문에 정직한 질문입니다. 단순한 구현/사용에 효과적으로 연결되어 있는 경우 별도의 패키지로 추상화를 갖는 요점을 이해하려고 합니다. Microsoft 외부의 누구도 경쟁 netcoreapp2.x 웹 서버에 리소스를 할당하고 싶어하거나 리소스를 갖고 있지 않다고 가정합니다(여기서 수정하게 되어 기쁩니다!).

netcoreapp2.x 세계에서 추상화의 요점이 무엇인지 명확히 할 수 있습니까? 아니면 단순히 2.0에서 더 이상 사용하지 않을 계획이 있습니까?

dotnet/corefx#4721에 따르면 SslStream에 대한 ALPN 지원은 .NET Core 2.0에 대해 준비되지 않습니다. 이것이 결국 몇 개월 후에 구현된다고 가정하면 netcoreapp2.0 TFM을 대상으로 할 때 사용할 수 있다는 의미입니까? 이 경우 사용자가 이전 .NET Core 런타임을 사용하는 경우 초기 netcoreapp2.0 형태의 일부가 아닌 새 API를 사용하는 netcoreapp2.0 기반 라이브러리를 출시하기로 결정하면 어떻게 됩니까? 충돌할까요? 아니면 netcoreapp2.x가 netstandard1.x와 일치합니까? TFM 버전을 높이지 않고는 계약을 변경할 수 없습니까?

ASP.NET 버전 x는 .NET Core 버전 x에 맞춰집니다. TFM은 .NET Core의 모든 릴리스에 맞게 업데이트됩니다. 결국 그렇게 취급할 수 있는 단일 제품입니다. 이는 위에서 @DamianEdwards 가 언급한 대로 우리가 하고 있는 주요 단순화 중 하나입니다. TFM을 변경하지 않고 핵심에 새 API를 추가하여 라이브러리를 구축하는 사람들을 방해하지 않습니다.

@NickCraver

스택 및 테스트의 다른 구현을 위해.

다른 구현은 무엇입니까? ASP.NET Core를 구현하는 스택의 다른 부분이 있습니까?

추상화가 실제로 추상화되지 않고 ASP.NET Core 자체에 너무 밀접하게 결합되어 있는 경우 해당 패키지를 제거하지 않는 이유는 무엇입니까? 그것이 전반적인 관계 목표라면 삶을 더 쉽고 명확하게 만들 수 있기 때문에 정직한 질문입니다. 단순한 구현/사용에 효과적으로 연결되어 있는 경우 별도의 패키지로 추상화를 갖는 요점을 이해하려고 합니다. 나는 Microsoft 외부의 누구도 경쟁 netcoreapp2.x 웹 ​​서버에 전념할 자원을 갖고 있거나 원하지 않는다고 가정합니다.

netcoreapp2.x 세계에서 추상화의 요점이 무엇인지 명확히 할 수 있습니까? 아니면 단순히 2.0에서 더 이상 사용하지 않을 계획이 있습니까?

우리는 모든 것을 단일 어셈블리에 넣을 수 있지만 리팩토링을 통해 우리가 이렇게 했다면 없었을 미래의 유연성을 얻을 수 있습니다. 그것은 심지어 다른 구현을 가질 가능성을 열어주고 장기적으로 그것을 실제로 배제하지 않습니다.

간단히 말해서, 추상화는 플랫폼 이식성이 아니라 종속성 수를 줄이는 것입니다.

TFM을 변경하지 않고 핵심에 새 API를 추가하여 라이브러리를 구축하는 사람들을 방해하지 않습니다.

여러분은 netcoreapp2.0 를 선택하고 싶다고 말했습니다. .NET Desktop 및 확장에 따라 .NET Standard와 비교하여 더 빠르게 움직이기 때문입니다. 하지만 netcoreapp2.0 대신 netcoreapp2.0 TFM을 변경하지 않고 새로운 .NET Core API를 활용할 수 없다면 netstandard2.0 ? (예: netcoreapp2.1 )

netcoreapp2.0 전용을 선택하고 싶다고 하셨습니다. .NET Desktop과 확장하여 .NET Standard에 비해 속도가 더 빠르기 때문입니다. 하지만 가능하다면 netstandard2.0 대신 netcoreapp2.0을 대상으로 하는 요점은 무엇입니까? TFM을 변경하지 않고 새로운 .NET Core API의 이점을 누리지 못하시겠습니까? (예: netcoreapp2.1)

죄송합니다. 제가 말을 잘못했습니다. netcoreapp2.0 netcoreapp2.x #$입니다.

좋아요, 지금 완전히 혼란스러워요.

죄송합니다. 말을 잘못했습니다. netcoreapp2.0이 아니라 netcoreapp2.x를 의미합니다.

이해가 잘 안되네요. ASP.NET Core 2.1 패키지와 netcoreapp2.1 TFM이 동등하다는 것을 의미합니까?

ASP.NET Core 2.1 패키지와 netcoreapp2.1 TFM이 동등하다는 것을 의미합니까?

네. 2를 같은 것으로 생각하십시오. https://github.com/aspnet/Home/issues/2022#issuecomment -299544884 참조

그렇다면 netstandard 를 사용하여 유사한 패턴을 채택하지 못하게 하는 것은 무엇입니까? IMHO: 새로운 TFM을 통해 새로운 API를 채택할 수 있고 .NET Desktop을 지원해야 하는 사람들은 여전히 ​​전체 프레임워크에서 ASP.NET Core 앱을 실행할 수 있습니다.

ASP.NET 코어 2.1/.NET 코어 2.1/.NET 데스크톱 4.7.1 -> netstandard2.1
ASP.NET Core 2.2/.NET Core 2.2/.NET 데스크톱 4.8 -> netstandard2.2 .

@PinpointTownes 데스크톱의 .NET Framework는 충분히 빠르게 제공할 수 없기 때문에 Core와 관련된 대부분의 버전 관리 문제의 핵심입니다. 그것은 거대한 사슬에서 어려운 문제입니다.

.NET Standard는 .NET Core와 같은 속도로 움직이지 않습니다. 실제로 근처에는 없습니다. .NET Standard의 이동은 따라잡을 때까지 기본적으로 모든 플랫폼을 뒤처지게 하며 .NET Framework는 가장 느리게 이동하고 가장 큰 플랫폼입니다.

포인트 토큰, .NET Framework가 얼마나 빨리 출시되어야 하는지 잘 모르겠습니다. ).

크로스 컴파일은 고객 및 제품 요구 사항과 균형을 이루어야 하는 오버헤드입니다.

시간이 되시면 크로스 컴파일로 인한 오버헤드의 정확한 특성에 대해 자세히 알고 싶습니다. 감사 해요.

우리 모두에게 필요한 것은 net461+에서 실행하기 위해 ASP.NET Core 2.0이 필요하다고 생각하는 이유에 대한 명확한 목록/이해입니다. 이러한 격차를 줄이고 모두가 성공할 수 있도록 구체적으로 작성하십시오.

현재 netstandard / netcore 버전(https://github.com/dotnet/wcf)이 거의 완료되지 않았기 때문에 전체 프레임워크 버전의 WCF 클라이언트 라이브러리가 필요합니다.

시간이 되시면 크로스 컴파일로 인한 오버헤드의 정확한 특성에 대해 자세히 알고 싶습니다. 감사 해요.

가까운 장래에 SSLStream에 대한 ALPN 지원과 같은 기능을 문자 그대로 폴리필할 수 없는 때가 올 것입니다. 또한 우리는 다리를 벌리고 API를 .NET Core에 추가하기 시작하지도 않았습니다. 지금까지 우리는 .NET Standard 및 .NET Core 2.0(.NET Standard 2.0의 전체 목적)으로 다시 포팅하는 데 어려움을 겪었습니다. . 새로운 API를 추가하고 마침내 1일 차에 ASP.NET Core에서 사용할 것입니다.

현재 netstandard/netcore 버전(https://github.com/dotnet/wcf)이 거의 완성되지 않았기 때문에 WCF 클라이언트 라이브러리의 전체 프레임워크 버전이 필요합니다.

@ctolkien 그것이 문제이고 우리가 WCF 클라이언트를 처음에 이식한 이유입니다. 당신을 막고 있는 것이 무엇인지 아십니까? 우선 순위를 정하는 데 도움이 될 좋은 기회입니다.

@davidfowl https://github.com/dotnet/wcf/issues/8

더 있을 수 있습니다. 이것은 전체 프레임워크 wcf로 전환하기 전에 우리가 부딪힌 첫 번째 장애물일 뿐입니다.

가까운 장래에 SSLStream에 대한 ALPN 지원과 같은 기능을 문자 그대로 폴리필할 수 없는 때가 올 것입니다.

그게 어떻게 문제야? AFAICT, 여기에서는 ASP.NET Core의 .NET Desktop 및 .NET Core 버전이 정확히 동일한 기능 집합을 지원해야 한다고 말한 적이 없습니다. 누락된 API(예: HTTP 2/0)로 인해 .NET Desktop에서 기능을 사용할 수 없는 경우 .NET Core 전용으로 만들고 개발자 PlatformNotSupportedException 그가 찾고 있는 기능이 사용할 수 없습니다?
모든 ASP.NET Core 패키지를 .NET Core 전용으로 만드는 것보다 훨씬 낫습니다. 비록 대부분이 새로운 BCL API를 사용하지 않을 것이지만 말입니다.

@davidfowl 제 생각에는 netcoreapp2.3 에서 문제가 해결되지 않고 netcoreapp2.4 에서 해결된다는 것이 가장 큰 두려움입니다. ASP.NET Core가 가장 빠른 기차에 초점을 맞추면 각 마이너 버전이 얼마나 오래 사랑을 받을까요? 우리가 지속적으로 업그레이드해야 한다면 모든 소비자는 지속적으로 업그레이드해야 합니다.

이는 최신 및 최고의 제품을 얻는 데는 좋지만 대부분의 회사에는 적합하지 않습니다. 따라서 우리는 ASP.NET Core의 각 소비자(최신에 의존하지 않고 유지하기 위해)에 대한 라이브러리로 많은 버전(각 부 버전)을 유지하거나 유지하기 위해 사용자를 최신 버전으로 끌어야 합니다. 이것은 검증된 환경과 같은 것에 친화적이지 않습니다.

추상화가 빠른 속도로 회전해야 하는 경우가 아니면(예시?) 연결을 끊는 것이 좋습니다. 그렇게 하면 업그레이드할 때마다 전체 생태계를 끌지 않아도 됩니다. 나는 그들이 netcoreapp 에 있을 것이 아니라 지속적으로 업데이트되고 모든 것이 밀접하게 결합될 것이라는 점에 더 우려하고 있다고 생각합니다.

추상화가 각 마이너 버전을 유지하고 고통을 (솔직히 말해서) 당신 편으로 옮기면 나는 훨씬 덜 걱정할 것입니다. 여기에 수정 사항이 포함된 의도를 자세히 설명할 수 있습니까?

@PinpointTownes :

.NET Core 전용으로 만들고 개발자에게 그가 찾고 있는 기능을 사용할 수 없음을 알리는 PlatformNotSupportedException을 던지지 않는 이유는 무엇입니까?
모든 ASP.NET Core 패키지를 .NET Core 전용으로 만드는 것보다 훨씬 낫습니다. 비록 대부분이 새로운 BCL API를 사용하지 않을 것이지만 말입니다.

안돼 안돼 제발 안돼 이는 런타임 오류이며 그다지 바람직 하지 않은 동작입니다. 우리는 라이브러리가 가능한 한 작동할 것이라는 컴파일 시간 보장을 원합니다. 이것에 대해 많은 논쟁이 있었습니다. 그것은 단순히 좋은 방법이 아닙니다. PlatformNotSupported 는 인간적으로 가능한 한 피해야 합니다.

이는 런타임 오류이며 그다지 바람직하지 않은 동작입니다.

이것은 어셈블리가 지원되지 않는 API를 사용하려고 하는 경우 ".NET Core에서 .NET Desktop 어셈블리 가져오기" 접근 방식에서 발생하는 일입니다. 단, PlatformNotSupportedException 대신 MissingMemberException 가 표시됩니다. PlatformNotSupportedException .

내 접근 방식을 사용하면 사용 중인 API가 지원되는지 여부를 컴파일 타임에 결정할 수 있는 Roslyn 분석기와 같은 것으로 최소한 더 나은 도구 이야기를 정의할 수 있습니다.

그리고 BTW, PlatformNotSupported 를 던지는 것은 정말 코너 케이스가 될 것입니다. 크로스 컴파일을 사용할 때 가장 좋은 옵션은 지원되지 않는 API를 공개 계약에서 단순히 제외하는 것입니다.

@PinpointTownes 나도 이런 생각을 했지만, 현실은 새로운 플랫폼이 출시되고 그렇게 간단하지가 않습니다. 이것을 여러 번 논의한 후 여기에서 어떻게 compat를 수행할지에 대한 생각이 크게 바뀌었습니다. netcoreapp 방향으로 이동하면 수정 사항을 마이너 버전으로 제공할 수 있습니다. 다른 방향으로 간다는 것은 .NET Desktop이 수정 사항을 제공할 때까지 기다려야 한다는 것을 의미합니다. 행운을 빕니다. 그것은 해결을 위한 매우 느린 수단입니다.

AFAICT, 여기에서는 ASP.NET Core의 .NET Desktop 및 .NET Core 버전이 정확히 동일한 기능 집합을 지원해야 한다고 말한 적이 없습니다. 누락된 API(예: HTTP 2/0)로 인해 .NET Desktop에서 기능을 사용할 수 없는 경우 .NET Core 전용으로 만들지 않는 이유는 무엇입니까?

전반부는 netstandard 입니다. netcoreapp 로 차별화하는 것이 바로 여기에서 하는 일입니다. 의도적인 예외 없이. 이 루트는 적절한 계약입니다.

당신은 그 반대가 아니라 격차가 있을 때 더 빨리 고칠 수 있고 개선할 수 있는 방향으로 가고 싶어합니다. "PlatformNotSupported" 예외는 지금부터 3개월 후에 플랫폼이 업데이트될 때까지 기다리는 대신 내일 라이브러리에서 수정할 수 있습니다. .NET Core는 실제 코드가 대부분의 경우 포워더로 별도로 제공되지 않고 함께 제공 되기 때문에 더 빠르게 지원할 수 있습니다.

[ PlatformNotSupportedException ] 누락된 API(예: HTTP 2/0)로 인해 .NET 데스크톱에서 기능을 사용할 수 없는 경우 .NET Core 전용으로 만들고 개발자에게 해당 기능이 그가 찾는 사람이 없습니까?

API 표면과 도달 범위의 단순성과 개발자 생산성의 균형을 맞춰야 합니다. 지금까지는 과거와 호환되는 API 표면을 제공하기 위해 주로 PlatformNotSupportedException 를 사용했습니다. 앞으로 분리된 기능 세트를 제공하는 방법으로 PlatformNotSupportedException 를 사용하지 않을 것입니다. 대신 기능이 없는 .NET 플랫폼 버전에 대한 지원을 중단하거나 모든 곳에서 자체적으로 지원되지 않는 독립 NuGet 패키지로 기능을 제공합니다.

netcoreapp 방향으로 가면 수정 사항을 부 버전으로 제공할 수 있습니다.

1.0 접근 방식과 어떻게 다른가요? @davidfowl 은 새로운 API에는 새로운 TFM이 필요할 것이라고 말했습니다. 즉, 새로운 .NET Core API에 의존하는 수정 사항을 얻으려면 LTS를 선택 해제해야 합니다. 정말 이상적인 상황은 아닙니다.

netcoreapp과의 차별화는 바로 여기에서 하는 일입니다.

차별화는 완벽하며 .NET Core가 ASP.NET Core의 기본 대상이 되어야 한다는 데 동의합니다. 그러나 특히 교차 컴파일과 같은 대안이 존재할 때 .NET Desktop을 완전히 버리는 것은 아닙니다.

API 표면과 도달 범위의 단순성과 개발자 생산성의 균형을 맞춰야 합니다.

확신하는. 그러나 .NET Desktop용으로 개발되고 .NET Core에서 사용할 수 없는 기능을 사용하는 레거시 라이브러리가 1.0에서와 마찬가지로 ASP.NET Core 2.0에서도 제대로 작동해야 한다는 사실과도 균형을 맞춰야 합니다.

대신 기능이 없는 .NET 플랫폼 버전에 대한 지원을 중단하거나 모든 곳에서 자체적으로 지원되지 않는 독립 NuGet 패키지로 기능을 제공합니다.

이론상으로는 괜찮습니다. 그러나 현재 중요한 기능이 부족한 플랫폼은 .NET Desktop이 아니라 .NET Core입니다. 이것은 아마도 몇 년 안에 변경될 것이지만 확실한 것은 사람들이 .NET Core 2.0에서 여전히 누락된 기능을 찾을 수 있다는 것입니다.

사람들이 .NET Framework의 .NET Core에서 누락된 것으로 간주되는 특정 항목에 대해 API를 요청할 수 있는 dotnet에 forward-port 리포지토리를 가질 가치가 있습니까?

그런 다음 피드백, 검토 및 지침은 코드 저장소의 일상적인 소음 외에 수행할 수 있습니까? 또는 일반 API 검토/사양 리포지토리(csharplang 대 roslyn과 같은 종류)

또한 "변환 문제가 있고 X api와 관련된 문제를 검색해야 합니다."로 이동하는 것이 좋습니다. 반면 corefx는 이에 대해 매우 시끄럽습니다.

[@benaadams] .NET Framework의 .NET Core에서 누락된 것으로 생각되는 특정 항목에 대해 사람들이 API를 요청할 수 있는 dotnet의 정방향 포트 리포지토리를 가질 가치가 있습니까?

나는 이것이 단순히 CoreFx의 문제라고 말하고 싶습니다. 또한 우리의 약속은 일반적으로 .NET Framework와 .NET Core 간에 형식이 공유되는 경우 새로 추가된 구성원을 .NET Framework로 이식하려는 것입니다. 매우 드문 경우에 이것이 가능하지 않을 수도 있지만, 문제는 자동으로 고려된다는 것입니다.

[@benaadams] 또는 일반 API 검토/사양 리포지토리

그만한 가치가 있는지 확실하지 않습니다. API 리뷰는 이미 다소 무거운 편입니다. 그것들을 다른 repo로 추출하는 것은 그것을 증폭시키는 것 같습니다. ASP.NET에서 새 API를 추가하는 것만큼 간단하도록 CoreFx를 계속 간소화하고 싶습니다.

이전에 언급했듯이 .NET Framework를 대상으로 하는 라이브러리/프레임워크를 계속 참조할 수 있으며 호출하는 API가 netstandard2.0 폐쇄의 일부라고 가정하면 제대로 작동합니다.

@DamianEdwards netstandard2.0 의 클로저에 없는 API는 어떻습니까? 대부분의 타사 라이브러리는 비공개 소스입니다. 모든 엣지 케이스가 netstandard2.0의 종료에 있음을 어떻게 알 수 있습니까?
@PinpointTownes 가 암시했듯이 이것은 러시안 룰렛을 하는 것과 같습니다.

@MJomaa 도구가 여기에서 도움이 될 것이지만 분명히 확실히 알 수 있는 유일한 방법은 실제로 실행하는 것입니다. 이는 실제로 .NET Standard 지원 프레임워크에서 실행되는 .NET Standard 라이브러리와 다르지 않습니다. 기존 API는 이러한 라이브러리를 테스트할 필요성을 대체하지 않습니다. netstandard 구현이 호환을 목표로 하지 않는다는 말은 아니지만 https://github.com/dotnet/standard/blob/cc9f646354fc68a13707a82323d4032b8dbfda52/netstandard/src/ApiCompatBaseline.net461.txt 와 같이 가장자리입니다.

NS 2.0에는 있지만 .NET Framework 4.6.1에는 없는 API입니다.

이 변경 사항에 대해 정말 긴장했지만 스레드를 읽은 후 이론상으로는 괜찮아 보입니다. 우리는 5개의 ASP.NET Core 앱을 가지고 있으며 그 중 4개는 전체 프레임워크에 있습니다.

.NET Core 이식성 분석기와 같은 VS에 구운 일종의 도구가 Twitter/GitHub에서 최신 정보가 아니며 이 확장이 존재한다는 사실조차 인식하지 못하는 개발자에게 도움이 될 수 있다고 생각합니다. "확장 제안" 팝업이 떠오릅니다. 하지만 사람이 이를 트리거하기 위해 어떤 조치를 취해야 할지 모르겠습니다. ASP.NET Core 2+ 앱에 net46x 라이브러리를 추가하려고 합니까?

Telerik, Syncfusion 등과 같은 타사 지원과 같이 Microsoft가 제어할 수 없는 항목은 수행 중인 작업에 따라 잠재적인 차단 요소가 될 수도 있습니다.

이 GitHub 스레드의 메시지는 FAQ 등으로 최대한 빨리 블로그 게시물에 나와야 합니다. 나는 모든 것의 최상단에 머물고 있는 것처럼 느껴지지만 이것이 우리가 net46x libs를 참조할 수 있다는 것을 의미하는지 여부를 여전히 100% 확신하지 못했습니다. 저만 헷갈린 것은 분명 아닙니다.

다른 사람들이 말한 것을 되풀이하기 위해. ASP.NET Core가 전체 프레임워크에서 실행될 수 있다는 것을 모르는 10명 이상의 개발자와 이야기를 나눴습니다. @aL3891 과 같은 경험을 했지만 개발자가 전체 프레임워크에서 ASP.NET Core를 실행할 수 있고 내부 라이브러리가 작동하는 데 정말 만족했습니다. 다시 말하지만 대다수의 사용 사례가 있는 .NET Core 2.0에 대한 메시징은 매우 중요합니다. 작업 중인 System.DirectoryServices와 같은 Windows 전용 솔루션에 대한 부분도 중요합니다. 내가 말하는 많은 NET 개발자는 .NET Core가 교차 플랫폼이고 x-plat/perf보다 작동하는 기존 코드에 더 관심이 있다는 말을 듣고 어깨를 으쓱합니다.

얘들아, 이것은 일종의 쓰레기입니다 :(
우리는 netfx와 함께 사용할 수 있는 옵션 때문에 ASP.NET Core를 기반으로 구축했으며 최대 1년 지원이 아닌 5-10년 동안 지속되는 것을 구축했습니다. 이것이 비즈니스에서 ASP.NET 이름이 의미하는 바이며 느리게 움직이는 대규모 조직에서 이달의 프레임워크보다 ASP.NET을 선택하는 이유입니다. 구체적인 사용 사례로 넘어가겠습니다.

저는 회사 내부에서 사용하고 '엔터프라이즈' 고객에게 판매하기 위해 LOB(Line of Business) 라이브러리와 응용 프로그램을 구축하는 도구 그룹에서 일하고 있습니다. 우리의 경우 대부분 정부 기관이지만 민간 부문에서도 같은 말을 듣게 될 것입니다. 우리는 "IDatabaseConnection", "IEntityProvider", "IWizardFlow", "ICodeGenerator"를 생각하여 비즈니스 패턴을 공통 추상화로 인코딩하고 이러한 플러그형 백엔드 위에 RAD 프런트엔드를 구축하는 내부 프레임워크를 가지고 있습니다.

우리 스택에서 ASP.NET Core는 '플러그인'입니다. 이는 데이터 저장소 추상화 및 호스팅 서비스 등에 사용되는 HTTP 대상입니다. 또한 '프론트엔드'이기도 합니다. 분명히 많은 LOB 앱이 웹사이트에 있으며, 웹앱을 위한 훌륭한 새 프레임워크입니다. 따라서 양방향 상호 운용성 요구 사항이 있습니다. 즉, 임의의 다른 구성 요소를 참조하는 AN-C 코드와 AN-C를 참조하는 임의의 기타 코드입니다.

우리는 Core CLR과 이식성을 전적으로 좋아하며 많은 구성 요소를 대상 또는 다중 대상 netstandard에 이식했습니다. 지금까지 Linux에서 호스팅되는 하나의 앱이 있으며 더 많이 제공되기를 바랍니다. 그러나 모든 것이 빠른 시일 내에 이식될 수 있는 방법은 없습니다! 우리는 에 의존하는 아직 살아 있고 활발하게 개발된 코드를 가지고 있습니다.

• NTLM 인증(토큰 및 SPN에 대한 고급 시나리오 포함)
• 위와 같은 System.Drawing (흥미로운 주름: 우리는 새로운 OSS 라이브러리가 지원하지 않는 TIFF와 같은 오래된 이미지 형식이 필요합니다)
• WCF/SOAP API에 연결하기 - 여전히 수없이 많습니다.
• Windows 암호화 API(RSACng, ECDSA 및 PKI 토큰용 CSP 포함)
• WPF guis - 우리 고객은 곧 Windows 10으로 전환하지 않으며 전환하더라도 스토어 앱을 원하지 않을 것입니다.
• 데이터 가져오기 및 내보내기를 위한 Microsoft Office 상호 운용성(특히 액세스 및 Excel)
• 비주얼 스튜디오 확장성
• Oracle ADO.NET 공급자와 같은 타사 플러그인

이러한 기술 중 일부는 Core CLR에서 지원되지 않습니다. 그러나 그것들 은 새로운 앱 개발의 기초가 되는 실제 기술입니다. 우리는 이 항목에 액세스할 수 있는 .NET 버전이 필요합니다. 현재 우리의 위치는 관리 가능합니다. "레거시"(실제로는 플랫폼별) 종속성을 net461 고유의 구성 요소로 분리합니다. 그런 다음 특정 비즈니스 앱은 이러한 기능이 필요한 경우 netfx에 종속되고 그렇지 않은 경우에는 종속되지 않습니다. 나는 이것이 새로운 앱에서 드문 미래를 상상합니다. 그러나 그것이 0 %라고 상상하기는 어렵습니다.

Interop이 중요하기 때문에 이 모든 작업을 csproj 및 SDK에서 수행했습니다. ASP.NET Core는 interop을 원하는 이유 인 당근입니다. 가져가는 건 말이 안 된다고 생각해요. 그리고 아니요, "한 방향으로 참조를 로드할 수 있지만 런타임에 실패할 가능성이 있습니다"는 상호 운용성이 아닙니다.

@gulbanana ASP.NET Core를 사용하는 시스템 부분이 .NET Framework와 동일한 프로세스에 있어야 하는 이유를 설명할 수 있습니까? 목록(Visual Studio 연결, 사무실 상호 운용성 등)에 감사하지만 오늘날 그 모든 위치에 ASP.NET Core가 포함되어 있습니까(위 설명에서 좋은 그림이 없음)?

또한 ASP.NET Core가 존재하기 전에 무엇을 사용하고 있었습니까? 아니면 이것은 ASP.NET을 사용하지 않고 .NET Framework의 ASP.NET Core에 5-10년을 걸었던 새로운 시도입니까? 카타나 봤어?

좋습니다. 여기에 몇 가지 구체적인 사례 연구가 있습니다. 기본적으로 많은 인터페이스 구현을 RPC로 전환하는 것은 큰 번거로움처럼 보이지만 별도의 프로세스에서 데스크톱 관련 작업을 실행하여 이러한 작업 중 많은 부분을 처리 할 수 있다고 확신합니다. 코어와 데스크톱 CLR 간에 원격 또는 이진 직렬화를 사용할 수 있는 것도 아닙니다.

NTLM/AD

Single Sign On을 위해 Windows 로그인 자격 증명을 IIS로 전달하는 브라우저에 의존하는 앱이 있으며, IIS는 이를 ASP.NET Core 웹 사이트로 전달합니다. 그런 다음 인증 프로세스의 일부는 사용자가 특정 AD 그룹에 있는지 여부와 같은 정보를 조회하는 것입니다. "windows support pack"과 이것이 이와 같은 것을 다루기 위한 것인지 여부에 대해 더 듣고 싶습니다.

시스템.도면

이것은 썸네일 및 기본 이미지 편집(회전, 워터마크 오버레이)을 생성하는 웹앱에서 사용됩니다. 사용되는 이미지의 대부분은 공룡 시대로 거슬러 올라가서 TIFF와 같은 것이 있습니다. 특정 부동산 목록 및 토지 관리와 관련하여 정부 부서에서 유지 관리하는 데이터입니다. 이 경우 애플리케이션은 처음에 ASP.NET MVC였으며 MVC 2, 4, 5 및 이제 Core를 통해 업그레이드/재작성되었습니다.

VSIX

이것은 반대로 netfx에 AN-C를 내장하는 경우입니다. 다양한 RAD 시나리오에 대해 '템플릿'을 실행하는 코드 생성을 위한 Visual Studio 확장이 있습니다. 이러한 템플릿 중 일부는 웹 개발을 위해 생성되었으며 디자인 타임에 AN-C 유형을 참조합니다(전처리기/런타임 T4를 사용하여 생성됨).

암호화

이것은 정말 in-proc이어야 한다고 생각합니다. 코드가 보안에 매우 민감한 라이선스 시나리오가 있습니다. 일반적으로 코드가 실행되는 환경과 관련하여 라이선스 파일을 해독하고 확인하는 것입니다. 이는 웹 앱과 데스크톱 앱의 백엔드에서 사용되는 공통 라이브러리입니다. 결국 .NET Core는 이 항목을 이식할 수 있을 만큼 충분한 암호화 지원을 받을 것으로 보이지만 오늘날에는 그렇지 않습니다. 예를 들어, 오늘날 우리가 가지고 있는 한 가지 옵션은 Fortinet/ePass2003 PKI 토큰 지원입니다. 여기서 미들웨어는 Core를 확실히 지원하지 않습니다(그리고 그렇게 할 시간도 없음).

오라클 ADO.NET

Oracle 백엔드와 함께 Entity Framework 6을 사용하는 것은 in-proc일 필요 는 없지만 우리 웹사이트가 데이터베이스에 접근하기 위해 추가 계층을 추가하는 것은 확실히 불편할 것입니다!

WPF 상호 운용성

우리는 요즘 모든 데스크톱 애플리케이션에서 Microsoft.Extensions.Logging을 사용합니다. 구현이 그렇지 않더라도 로깅 추상화 자체는 in-proc이어야 합니다.

ASP.NET Core 이전에 사용했던 것 - ASP.NET MVC! 우리는 돌아갈 수 있지만 모든 혜택을 포기하는 것은 큰 부끄러운 일입니다.

아키텍트로서 "ASP.NET Core가 전체 프레임워크에서 실행"이 첫 번째 버전 이후에도 지속되는지 여부를 조사하지 않은 것은 내 실수입니다. 그렇지 않을 거라고 솔직히 생각해본 적이 없어요. 2018년 초에는 Office 문서를 로드할 수 있는 지원 버전이 없을 수도 있다는 가능성을 상상하지 못했습니다...

내가 명확하지 않은 한 가지는 언급한 각 시나리오에서 ASP.NET Core가 사용되는 위치입니다.

NTLM/AD

이것은 의미가 있으며 매핑으로 끝나는 API를 이해하고 싶습니다. 이것은 단지 System.DirectoryServices입니까? 그 작업은 활발히 진행 중입니다(corefx에서 볼 수 있음).

시스템.도면

이것은 우리가 해결하고자 하는 알려진 격차입니다. 여기에는 아직 답변이 없으며 ImageSharp를 사용하여 다시 작성하는 것을 제안하지 않습니다(선택 사항이지만). 이 문제를 해결해야 합니다.

VSIX

ASP.NET Core는 어디에 있습니까? Visual Studio 확장 내에서 실행 중입니까?

암호화

이것에 대한 corefx 문제가 있습니까? 왜 그냥 이식되지 않을까요? .NET Framework와 달리 .NET Core 릴리스는 OS에서 분리되므로 중요하다고 판단되는 경우 조만간 발생할 수 있습니다. (면책 조항: 저는 이 크로스 플랫폼을 수행하는 것의 의미를 이해하기 위해 암호화에 대해 충분히 알지 못합니다).

오라클 ADO.NET

ASP.NET Core는 어디에 있습니까? Oracle 공급자가 아직 .NET Core로 이식되지 않았다는 말씀입니까?

우리는 요즘 모든 데스크톱 애플리케이션에서 Microsoft.Extensions.Logging을 사용합니다. 구현이 그렇지 않더라도 로깅 추상화 자체는 in-proc이어야 합니다.

Microsoft.Extensions.*는 netstandard로 유지되므로 여기에서 다룰 수 있습니다.

발표/토론이 없는 이유는 무엇입니까?
aspnet/.net 핵심 팀이 하는 일을 좋아하지만 @jhurdlow와 같은 두려움을 갖고 있습니다.

MEL에 대해 듣게 되어 기쁩니다. 다른 점에서-

NTLM

다음은 대부분의 응용 프로그램에서 사용되는 클래스입니다. 이론적으로 이식 될 수 있기를 희망하지만 아직 이식되지 않은 API를 아주 사소하게 사용합니다.
https://gist.github.com/gulbanana/70fe791735ee884169e2eee354a32ad2

VSIX

asp.net 코어에 특정한 codegen 템플릿은 액션/라우팅 시스템(IFileProvider 등)을 사용하여 컨트롤러와 뷰 등을 발견하고 스캐폴딩을 채웁니다. 우리는 Visual Studio 내부에서 ASP.NET 웹호스트를 호스팅하지 않고 단지 ASP.NET 응용 프로그램을 살펴봅니다.

암호화

우리가 사용하는 알고리즘이 이식 될 것이라고 생각하지만 아직 이식되지 않았습니다. 전제가 예를 들어 asp.net-core-on-netfx에 대한 지원을 중단할 장기 계획의 발표와 언제 가능할지 논의하는 것이라면 이 모든 것이 매우 다르게 보일 것입니다!

신탁

예, Oracle 포트가 발생하면 해결될 것입니다(모든 기능을 갖추고 있다고 가정).

또 하나의 사용 사례:
우리 애플리케이션 중 하나는 Access 애플리케이션에서 레거시 데이터를 가져옵니다. 현재 해당 가져오기 프로세스는 asp.net 핵심 웹 사이트의 서버에서 실행됩니다. COM interop을 사용하여 accdb/jet 엔진 재배포 가능 패키지에서 acedao.dll 를 로드하고 테이블을 엔티티 추상화로 읽은 다음 더 현대적인 SQL 데이터베이스에 저장합니다.

이것은 '절차를 벗어날 수 있지만 왜 그래야 합니까'의 또 다른 경우입니다. 우리는 본질적으로 AN-C를 WebAPI 2 웹사이트나 그 밖의 무언가에 대한 프론트엔드로 사용하고 있을 것입니다. 이 경우 과거에 대한 종속성으로 돌아갔습니다.

전반적으로 우리의 목표는 우리가 하는 일의 대부분을 .NET Core로 옮기는 것입니다. 우리는 물건을 옮기는 동안 가능한 한 많은 상호 운용성을 원합니다...

WTF!!! 😨
ASP.NET Core 2가 더 이상 Full .NET Framework 4.x를 대상으로 하지 않는다는 말씀입니까!!!
우리는 1개월 전에 ASP.NET Core 1.1로 프로젝트를 시작했고 일부 Full .NET Lib를 참조하기 때문에 .NET 4.6을 대상으로 했습니다. 그리고 우리는 ASP.NET Core 2로 업그레이드하려고 했습니다. 하지만 이 게시물에서 들은 것은... 😞
이봐, 우리는 이점(DI, 병합된 API 및 MVC, ... 강력한) 때문에 ASP.NET Core를 선택했으므로 변경 사항으로 제공하십시오.

우리는 1개월 전에 ASP.NET Core 1.1로 프로젝트를 시작했고 일부 Full .NET Lib를 참조하기 때문에 .NET 4.6을 대상으로 했습니다.

그 도서관들은 무엇을 합니까? @shanselman 의 초기 회신 https://github.com/aspnet/Home/issues/2022#issuecomment -299536123을 읽으셨습니까? .NET Core 2.0에서 일부 .NET Framework 라이브러리를 참조할 수 있습니다(API 하위 집합 내에 있다고 가정).

그 도서관들은 무엇을 합니까? @shanselman 의 초기 답장 #2022(댓글) 잘 보셨나요? .NET Core 2.0에서 일부 .NET Framework 라이브러리를 참조할 수 있습니다(API 하위 집합 내에 있다고 가정).

@davidfowl 예, @shanselman 의 의견을 읽었습니다. 우리는 회사에서 만든 일부 Lib를 사용합니다. 일부 라이브러리는 WCF를 사용하고, 모든 Lib는 안정적이고, .NET 3.5를 대상으로 하며, 우리는 이를 만질 수 없습니다.

이것은 매우 일반적인 상황이 될 것입니다. 지금까지 .NET Core와 .NET Framework에 있는 ASP.NET Core 사용자의 수에 대한 정보(원격 측정?)가 수집되었는지 알고 싶습니다.

나는 개인적으로 이것에 대해 감정적이지 않지만 몇 가지 관찰 사항은 다음과 같습니다.

• 오늘날 내가 가진 대부분의 고객은 새로운 기능에 올인하는 것을 두려워하기 때문에 asp.net 코어 1.x/전체 프레임워크 조합을 사용합니다.
• 너겟 패키지 다운로드 수에서 알 수 있듯이 asp.net 코어의 채택은 좋지 않습니다. 그 움직임으로 지금 잘 팔리지 않는 물건을 파는 것이 훨씬 더 어려울 것입니다.
• LDAP 항목을 공백으로 식별해 주셔서 감사합니다(지난 10년 동안 해당 라이브러리를 사용하는 사람을 본 적이 없지만 아마도 저만 그런 것 같습니다). 더 큰 문제는 타사 라이브러리가 될 것입니다. 이것이 사람들이 .net core로 이동하지 않는 진짜 이유가 될 것입니다.

이 모든 상황은 MS가 아무런 경고 없이 결정을 내리는 또 다른 좋은 예입니다. 일부 사람들이 체크인을 따르기 때문에 이 스레드가 여기에 있습니다.

내가 틀릴 수도 있지만 .NET Core가 이제 DNF의 관리 하에 있다고 생각했습니다. 따라서 이러한 결정은 더 이상 순전히 MS 내부가 아닙니다.

LDAP/AD 항목은 내가 지금 net462를 계속 사용해야 하는 이유입니다. 완전히 BAM -> NetCore로 가고 싶지만 이것이 단점입니다.

또한 내 프로젝트 중 하나에서 XML-RPC.net을 사용하고 있습니다. 그것은 약간의 진지한 Reflection.Emit을 사용하는데, NetCore 2가 그것을 완전히 지원할지는 확실하지 않습니다. 그래도 확실히 알아보려면 이식성 분석기를 사용해 봐야 합니다.

.NET의 미래에 영향을 미치는 이와 같은 중요한 결정이 투명성 없이 마지막 순간에 얼마나 빠르고 쉽게 일어날 수 있는지에 대해 이 모든 상황이 약간 낙담스럽습니다. .NET Standard 2.0이 호환성에 초점을 맞추고 .NET과의 격차를 해소하는 릴리스가 될 것이라는 메시지(내 이해에서)와 함께 ASP.NET Core로 마이그레이션할 때 기존 .NET 에코시스템을 판매하는 데 많은 에너지가 투자되었습니다. v4.x는 마침내 생태계가 의지할 수 있는 견고하고 안정적인 .NET 플랫폼을 생성합니다. 저는 개인적으로 .NET Standard 2.0이 출시될 때까지 .NET Core가 실제로 도약할 것이라고 믿지 않습니다. .NET Standard 2.0이 우리 모두가 기다리고 있는 "약속된 안정적인 땅"이 될 것으로 예상했기 때문입니다. 이제 ".NET Standard 2.0"은 정확히 무엇을 다루고 어떤 라이브러리가 .NET Core 전용으로 계획되어 있는지를 의미합니다.

사전에 공식 발표, 피드백 요청, 투표 또는 근거가 제공되지 않았기 때문에 이 결정은 커뮤니티 참여 또는 기존 .NET 생태계에 대한 영향 분석 없이 수행된 것으로 "표시"되며 많은 사람들을 위해 전체 생태계를 파편화할 가능성이 높습니다. 앞으로 몇 년. .NET v4.x 지원을 제거하면 많은 기업이 기존 코드 기반을 ASP.NET의 새로운 개발 모델로 마이그레이션할 수 있는 원활한 마이그레이션 경로가 제거됩니다. 이렇게 하면 .NET Core로 더 빨리 이동하도록 권장하지 않으며, 시도조차 하지 못하게 하여 .NET 에코시스템을 둘로 분리하는 대규모 조각화를 유발합니다. 이것이 거의 10년 동안 여전히 복구할 수 없는 단편화로 인해 돌이킬 수 없는 피해를 입은 Python 2/3과 어떻게 다른지 알 수 없습니다.

대부분의 기존 .NET 코드 기반은 .NET Core 1.1이 .NET v4.x를 지원하기 때문에 이러한 결정이 내려졌다는 사실을 모르는 "암흑 물질" .NET 개발자에 의해 배후에서 개발 중인 브라운필드입니다. .NET Standard 2.0의 메시징은 향상된 호환성을 약속했습니다. 이 결정의 소식과 영향이 마침내 집에 도착하면 엄청난 반발이 예상됩니다. 조직 내에서 내부적으로 .NET Core 채택을 판매해 온 많은 개발자는 막 다른 플랫폼으로 효과적으로 마이그레이션했기 때문에 배신감을 느낄 것입니다(어떤 이유로든 .NET Core로 완전히 마이그레이션할 수 없는 경우). ) 현재 마이그레이션에 필요한 리소스를 승인하도록 조직의 이해 관계자를 설득하는 기념비적인 결정에 성공한 직후 직면해야 하는 가혹한 현실입니다.

대부분의 조직은 .NET v4.x에 먼저 배포하려는 코드 기반을 "병렬로" 마이그레이션하는 동안 기존 시스템을 지속적으로 배포해야 하는 기존 코드 기반을 "진행 중"으로 마이그레이션해야 합니다. 모든 것이 안정화되고 모든 문제가 해결되면 거기에서 .NET Core로의 전체 마이그레이션을 계획할 수 있습니다.

이 결정은 또한 IMO가 .NET이 조직이 의존할 수 있는 안정적인 플랫폼이라는 신뢰를 갉아먹은 ASP.NET의 주요 변경 사항의 맥락에서 이루어집니다. 저는 .NET Core의 새로운 개발 모델을 좋아하지만, 우리에게 가장 필요한 것은 나머지 생태계가 따라잡을 수 있는 안정적인 플랫폼입니다. .NET Core는 아직 미성숙한 도구, 호환되지 않는 종속성, 런타임 문제, 오래된 문서 등으로 인해 불쾌한 계곡에 있습니다. .NET이 처음 릴리스된 초기 이후로 이렇게 불안정한 것을 본 적이 없습니다.

.NET 개발자가 더 원하는 것이 무엇인지에 대한 설문조사를 실행하지 않는 이유는 무엇입니까? 즉, 견고하고 안정적인 세련된 플랫폼입니까, 아니면 새로운 기능을 더 빨리 제공하는 "빠르게 움직이는" 플랫폼입니까? .NET v4.x로 기능을 백포팅하는 것에 대해 걱정할 필요가 없도록 하는 데 훨씬 적은 노력이 필요하다는 것을 이해합니다. .NET v4.x 또는 .NET Core에서 실행할 수 있는 기간 지원.

이 배는 항해했습니까 아니면 ASP.NET Core 2.0을 그대로 유지하는 옵션이 있습니까? 즉, .NET Standard 2.0에서 다루는 대부분의 라이브러리 및 추상화와 함께 다음 ASP.NET Core 3.0 릴리스에서는 다음 플랫폼이 .NET Core 전용이 될 것이라고 발표합니까? 이를 통해 조직은 계속해서 ASP.NET Core 2.0을 채택하고 채택할 수 있으며 생태계의 나머지 부분이 안정적이고 잘 지원되는 도구 및 라이브러리를 따라잡을 수 있으며 .NET Core 전용 플랫폼/ 기능이 시작됩니다.

.NET Core 2.0에서 일부 .NET Framework 라이브러리를 참조할 수 있습니다(API 하위 집합 내에 있다고 가정).

이것은 불확실성을 낳습니다. 자신의 평판과 시스템의 상태 및 안정성을 위험에 빠뜨리고 .NET Core로의 전체 마이그레이션을 시도하려는 사람은 거의 없습니다. 정확히 어떤 종속성이 실행되고 실행되지 않을지에 대한 불확실성이 존재합니다. .NET Core는 가까운 미래에 더 많은 사람들이 .NET v4.x를 계속 사용한다는 것을 의미합니다.

이것이 궁극적으로 어떻게 진행될지, 이 결정이 전체 .NET 에코시스템에 미칠 진정한 영향이 무엇인지는 잘 모르겠지만, 외부 커뮤니티의 개입 없이 이와 같이 광범위한 영향을 미치는 중요한 결정이 발생할 수 있다는 사실은 우려스럽습니다.

나는 너희들이 당신의 사용자 기반을 분기하는 데 조금 덜 열중했으면 좋겠다.

라이브러리를 만들 때 내 관점은 가능한 한 많은 사람들이 가능한 한 많은 장소에서 사용하기 쉽게 만드는 것입니다. 목이 아프지만(Newtonsoft.Json에서 #if 컴파일러 지시문을 검색하면 1300개 이상의 결과를 얻을 수 있음) "그냥 작동합니다"는 강력한 판매 포인트입니다.

.NET 개발자가 더 원하는 것이 무엇인지에 대한 설문조사를 실행하지 않는 이유는 무엇입니까? 즉, 견고하고 안정적인 세련된 플랫폼입니까, 아니면 새로운 기능을 더 빨리 제공하는 "빠르게 움직이는" 플랫폼입니까? .NET v4.x로 기능을 백포팅하는 것에 대해 걱정할 필요가 없도록 하는 데 훨씬 적은 노력이 필요하다는 것을 이해합니다. .NET v4.x 또는 .NET Core에서 실행할 수 있는 기간 지원.

진정한 질문, ASP.NET Core 1.x는 현재 .NET Framework 및 .NET Core를 지원합니다. 위에서 언급한 안정적인 플랫폼이라고 가정해 보겠습니다. 버그 수정과 두 런타임 모두 지원했지만 더 많은 기능을 얻지는 못했습니다. 그것으로 충분할까요?

ASP.NET Core 및 .NET Core는 현재 .NET용으로 빠르게 움직이는 기능이 풍부한 플랫폼입니다. 운영 체제에 종속되지 않고 신속하게 혁신하고 더 빠르게 출시하는 데 필요한 민첩성을 제공하는 .NET 버전입니다.

이 배는 항해했습니까 아니면 ASP.NET Core 2.0을 그대로 유지하는 옵션이 있습니까? 즉, .NET Standard 2.0에서 다루는 대부분의 라이브러리 및 추상화와 함께 다음 ASP.NET Core 3.0 릴리스에서는 다음 플랫폼이 .NET Core 전용이 될 것이라고 발표합니까? 이를 통해 조직은 계속해서 ASP.NET Core 2.0을 채택하고 채택할 수 있으며 생태계의 나머지 부분이 안정적이고 잘 지원되는 도구 및 라이브러리를 따라잡을 수 있으며 .NET Core 전용 플랫폼/ 기능이 시작됩니다.

우리는 항상 피드백에 열려 있으며 ASP.NET Core 2.0은 아직 출시되지 않았습니다. ASP.NET Core 3.0이 .NET Framework를 삭제한 릴리스라면 상황이 더 나아질까요? @gulbanana 및 @ikourfaln 의 ​​피드백 중 일부를 보면 이식되지 않을 가능성이 있는 기술이 있으므로 .NET Core에서 절대 작동하지 않습니다. .NET Framework를 거의 영원히 지원한다는 의미가 아닙니까? 1년 뒤에도 똑같은 토론을 하지 않을까요? 그때쯤이면 .NET Core를 지원하는 생태계나 라이브러리가 더 커져서 영향이 덜할까요? 업데이트되지 않는(또는 소스 코드가 손실된) 엔터프라이즈 라이브러리는 어떻습니까? 1년 안에 바뀔까요?

라이브러리를 만들 때 내 관점은 가능한 한 많은 사람들이 가능한 한 많은 장소에서 사용하기 쉽게 만드는 것입니다. 목이 아프지만(Newtonsoft.Json에서 #if 컴파일러 지시문을 검색하면 1300개 이상의 결과를 얻을 수 있음) "그냥 작동합니다"는 강력한 판매 포인트입니다.

@JamesNK 에 대한 공격은 없지만 JSON.NET은 JSON 파서이며 대부분 단일 패키지입니다(몇 가지 더 있다는 것을 알고 있습니다). ASP.NET Core에는 200개 이상의 패키지가 있습니다.

실례지만 저는 아르바이트를 하고 있는 1인입니다. 당신의 문제는 더 어렵지만 기하급수적으로 더 많은 자원을 가지고 있습니다.

이것을 읽고 우리가 가진 의존성을 살펴본 후에 이것이 좋은 생각이라는 확신이 훨씬 덜합니다.

계획대로라면 System.DirectoryServices netstandard / netcoreapp 로 앱을 이식할 수 없습니다( CoreFX 문제 #2089 here ). 따라서 ASP.NET Core 1.x로 이식할 수 있지만 2.0으로 이동할 수는 없습니다. 여기에서 응용 프로그램을 살펴보십시오. Opserver, Stack Overflow 자체, 내부 응용 프로그램...이 시점에서 2.0이 출시될 예정이므로 준비된 것은 없습니다. 이번 주 스탠드업에 따르면 DirectoryServices와 같은 중요한 사항은 2.x 이후 릴리스에서 계속 이어질 것입니다.

그래서 1.0과 2.0 사이에 이사를 준비하던 곳에서 갈 수 없는 곳으로 바뀌었습니다. 예, 준비가 되지 않았습니다. ASP.NET은 HTTP를 통해 필요한 비트를 노출하는 방법입니다. ASP.NET은 그 자체로 필요한 것이 아닙니다. 저는 .NET을 웹용으로 만 사용하는 것이 아니라 플랫폼용으로 사용하고 있습니다. 많은 사람들이 그렇듯이. 플랫폼은 사용자가 요구하는 다양한 사용 사례에 대한 준비가 되어 있지 않으므로 사용자를 해당 플랫폼에 강제로 사용하는 것은 고통과 차단을 야기합니다.

결론은 AD 인증(플랫폼의 큰 부분)이 필요한 경우 1.x 라인에서 포기했다는 것입니다. 그것이 내가 우리 앱으로 향했던 곳입니다...하지만 이것이 방향이라면 목적지에서 필요한 비트를 사용할 수 있을 때까지 여기에 노력을 기울이는 것은 의미가 없습니다.

System.DirectoryServices , System.Drawing 와 같은 중요한 항목과 사람들이 필요로 하는 다른 주요 항목 이 ASP.NET Core 2.0으로 준비될 수 있다면 제 생각은 많이 바뀝니다. 그것들이 나중에 고려된다면(현재 일정에서 알 수 있듯이) 그렇게 될 때까지 .NET Framework를 계속 지원하십시오.

빠르게 움직이는 것이 좋습니다. 나는 그것을 좋아한다. 지금 프로덕션에서 알파를 실행 중입니다. 그러나 처음부터 사용 사례에서 작동하지 않는 경우에는 아무 것도 중요하지 않습니다.

개인적으로 고군분투하는 한 가지는 "안정된 플랫폼"과 "새로운 기능"입니다. 한편으로 우리는 플랫폼이 안정적이고 신뢰할 수 있고 호환되기를 원하지만 다른 한편으로는 2.x 기능이 없기 때문에 아무도 1.x에 머물기를 원하지 않습니다. ASP.NET Core 2.x에는 그 방향으로 사람들을 끌어들이는 매우 매력적인 기능이 있습니까? 아니면 1.x에서보다 더 많은 기능을 가지고 있다는 사실입니까(새롭고 빛나기 때문에)?

후자라면 그 사람들이 안정성에 신경을 쓰나요? 대답이 예인 경우 ASP.NET Core 1.x가 충분하지 않은 이유는 무엇입니까?

저는 .NET을 웹용으로만 사용하는 것이 아니라 플랫폼용으로 사용하고 있습니다. 많은 사람들이 그렇듯이. 플랫폼은 사용자가 요구하는 다양한 사용 사례에 대한 준비가 되어 있지 않으므로 사용자를 해당 플랫폼에 강제로 사용하는 것은 고통과 차단을 야기합니다.

동의하지만 ASP.NET Core 2.x에서 .NET Framework 지원을 중단하는 것과 어떤 관련이 있다고 생각하십니까? 더 많은 종속성이 온라인 상태가 되면 플랫폼이 발전함에 따라 광범위한 런타임 세트가 이점을 얻을 수 있으므로 어떤 의미에서는 모든 곳에서 작동할 것입니다. 모든 버전의 ASP.NET Core 애플리케이션에서 갑자기 이러한 기능을 활용할 수 있습니다.

후자라면 그 사람들이 안정성에 신경을 쓰나요? 대답이 예인 경우 ASP.NET Core 1.x가 충분하지 않은 이유는 무엇입니까?

모든 사람은 항상 새로운 기능, 새로운 기능의 가능성, 또는 적어도 나중에 더 많은 것을 얻을 수 있는 옵션이 있다는 것을 알고 싶어합니다. 플랫폼을 닫고 "안정"/"유지 관리 모드로 전환하면 사람들은 더 이상 관심을 기울이지 않는 것으로 봅니다.

ASP.NET Core 2.x에는 그 방향으로 사람들을 끌어들이는 매우 매력적인 기능이 있습니까? 아니면 1.x에서보다 더 많은 기능을 가지고 있다는 사실입니까(새롭고 빛나기 때문에)?

지원 - 그것이 우리가 지불하는 것입니다.

대답이 예인 경우 ASP.NET Core 1.x가 충분하지 않은 이유는 무엇입니까?

지원이 출시된 지 약 1년 후에 종료되기 때문입니다(위의 Scott에 따르면). 그리고 그때쯤이면 스택 오버플로 이식을 거의 끝낼 수 있을 것입니다.

그것은 ASP.NET Core 2.x가 .NET Framework 지원을 중단하는 것과 어떤 관련이 있습니까?

내가 있어야 할 라이브러리가 없기 때문입니다. 그리고 언제가 될지 모르겠습니다. 그래서 나는 1.x에 갇혀 있었고 지원이 끝날 때까지 시한 폭탄이 있습니다. 지원이 종료되기 전에 1.0에서 2.x(또는 3.x)로 이식할 충분한 시간이 있습니까? 아마 아닐 것입니다.

대규모 코드베이스는 단순히 중지하고 이식할 수 없으며 시간이 필요하며 단계적으로 이루어져야 합니다. ASP.NET Core에 .NET 4.6.x 포트를 수행하는 것은 중간 단계로 가능했습니다. 한 번에 코어로 이동하는 것은 훨씬 더 어렵고 더 오래 걸리며 더 오래 지속되는 가지와 더 많은 고통을 필요로 합니다. 단계적으로 이 작업을 수행할 수 없다면 솔직히 말해서 지금은 버려진 ASP.NET 5 라인에서 벗어나는 것을 볼 수 없습니다. 시간, 비용 및 개발에 미치는 영향을 정당화할 수 있는 방법이 없습니다.

많은 OSS 작성자도 나와 비슷하다고 생각합니다. 이는 우리 일상 업무의 연장선입니다. 플랫폼을 사용하지 않거나 도그푸딩하지 않으면 라이브러리가 훨씬 더 나빠지거나 생성되지 않습니다. 그리고 우리는 오늘 우리가 보내는 회사 시간으로 그것을 유지하는 시간을 정당화할 수 없습니다. 그리고 우리가 만드는 모든 라이브러리는 프로덕션 단계에서 요구하는 것에서 비롯됩니다. 사용 사례를 중단하는 생태계는 갑작스러운 것은 아니지만 계속 추가되는 다운스트림 영향이 많습니다.

현재 제 견해는 2018년 7월경까지 작동하는 새로운 플랫폼이 있다는 것입니다. 그 후: 저는 아무것도 모릅니다. 그때까지는 제가 필요한 것을 netstandard / netcoreapp 에서 사용할 수 있기를 바랍니다 . 지원이 종료되기 전에 이식할 충분한 시간이 있기를 바랍니다. 나는 희망을 품은 것이 아니라 우리 회사를 위한 플랫폼 결정을 내리기 위해 돈을 받았고, ASP.NET Core는 이 변경 사항과 작동할 버전에 대한 날짜가 없는 (우리에게) 나쁜 선택입니다.

한 줄 요약을 제공하겠습니다. .NET 전체 프레임워크 지원이 없으면 ASP.NET Core는 향후 2년 동안 사용 사례에 대해 지원되는 플랫폼을 제공하지 않습니다.

짧은 버전은 이렇습니다.

우선 순위 1: 이것은 net461 에서 작동해야 합니다. ifdef, perf가 무엇이든 상관 없습니다.
우선 순위 2. .NET Core 2.0에서 10배 더 빠르게 만들 수 있다면 정말 좋습니다. 사람들이 플랫폼을 선택하거나 가능하면 마이그레이션해야 하는 큰 이유입니다.

여기서 중요한 것은 장기적인 지원을 위해서는 속도가 느리더라도 전체 프레임워크 에서 계속 작동해야 한다는 것입니다.

우선 순위 1: net461에서 작동해야 합니다.

그리고 .NET Core가 net461과 완전히 호환된다면(이유 내에서); 따라서 net461용으로 작성된 모든 것이 Core에서 작동했습니다. 그러면 괜찮을까요?

기본적으로, 그 시점에서 당신은 side-by-side 및 자체 포함을 할 수 있기 때문에 net4x보다 더 안정적인 플랫폼을 갖게 됩니다(x-plat의 터치도 가능). net461에는 전체 시스템이 4.6.1, 4.6.2, 4.7 등으로 변경되었습니다.

분명히 무언가가 작동하지 않을 것입니다. 부분적 신뢰처럼 - 그러나 그것은 결코 효과가 없었습니다.

진정한 질문, ASP.NET Core 1.x는 현재 .NET Framework 및 .NET Core를 지원합니다. 위에서 언급한 안정적인 플랫폼이라고 가정해 보겠습니다. 버그 수정과 두 런타임 모두 지원했지만 더 많은 기능을 얻지는 못했습니다. 그것으로 충분할까요?

Ubuntu / Redhat과 같은 ASP.NET Core 2.0의 LTS 릴리스가 5년 이상 지원하는 LTS 릴리스를 보고 싶습니다. 이는 생태계의 나머지 부분이 채택에 전념할 수 있는 확고한 호환 가능한 목표를 제공할 것입니다.

저는 개인적으로 미래의 .NET Core 전용 기능보다 안정적인 .NET Standard 2.0에 더 관심이 있습니다. 모든 것이 다시 작동하고 도구가 손상되지 않고 인기 있는 .NET 개발로 돌아가고 싶기 때문입니다. .NET 패키지는 모두 지원을 제공하며 주변 배포 및 호스팅 솔루션이 개선되었으며 솔루션 구축을 시작할 수 있는 안정적인 ASP.NET Core에 사용할 수 있는 풍부한 문서, 게시물, 비디오 및 지식 기반이 있습니다.

1년 뒤에도 똑같은 토론을 하지 않을까요? 그때쯤이면 .NET Core를 지원하는 생태계나 라이브러리가 더 커져서 영향이 덜할까요? 업데이트되지 않는(또는 소스 코드가 손실된) 엔터프라이즈 라이브러리는 어떻습니까? 1년 안에 바뀔까요?

이상적인 세계에서 .NET v4.x 및 .NET Core는 모두 가까운 장래에 ASP.NET Core를 지원하며 .NET Core 전용 패키지에서만 사용할 수 있는 새로운 .NET Core 전용 기능일 뿐입니다. 그러나 MS가 .NET 4.x를 남겨두고 공식적으로 헤어지기 전에 ASP.NET 2.0 LTS 릴리스가 차선책이 될 것입니다. 정의에 따르면 아무도 아직 존재하지 않는 새로운 기능에 의존하지 않으므로 아무도 .NET Core 전용 v3.0으로 강제로 업그레이드하지 않을 것입니다.

1개의 플랫폼만 지원해야 하는 자유로 인해 개발자가 지속적으로 새로운 기능 스트림을 통해 가장 최신의 최신 버전을 채택하도록 유도하는 새로운 기능을 잠재적으로 제공할 수 있습니다. 개인적으로 저는 ASP.NET이 현재 가지고 있는 기능에 만족하고 있습니다. 저는 모든 것이 다듬어진 안정적인 버전에 더 관심이 있어 다시 생산적으로 돌아가 항상 움직이는 플랫폼을 쫓는 대신 솔루션 개발에 집중할 수 있습니다.

먼저 @davidfowl 이 스레드에 뛰어들고 일어서서 질문을 하는 등의 일을 해주셔서 감사합니다. 많은 Q를 묻는 열띤 커뮤니티가 있을 때 개입하지 않고 '목표물'이 되는 것을 피하기 쉽습니다. 건설적으로 참여해주셔서 감사합니다. /나 당신에게 경의를 표합니다.

이 대화에서 나오는 두 가지 주요 요점/스레드를 봅니다.

1. vnext에서 .NET 데스크탑 지원을 요청합니다. (여기에 있는 답변의 99%입니다)
2. 그러한 중요한 결정에 대한 커뮤니티 협의가 부족합니다. (여기에 2 또는 3개의 응답이 있습니다).

TL;DR;

• 중요한 vnext 변경 사항으로 더 개방적일 수 있습니까?
• 이러한 vnext 변경 사항에 대해 커뮤니티의 일부 RFC에 시간을 할당하십시오.

@mythz 는 (이 시점에서) ~ 가장 최근 ~ 2번째 가장 최근 댓글에 대한 시작 문장에서 이를 멋지게 표현했습니다.

.NET의 미래에 영향을 미치는 이와 같은 중요한 결정이 투명성 없이 마지막 순간에 얼마나 빠르고 쉽게 일어날 수 있는지에 대해 이 모든 상황이 약간 낙담스럽습니다.

이것은 개인적으로 저에게 정말 큰 충격을 주었습니다. 저는 이러한 전화를 plz하는 MS의 적절한 사람들로부터 몇 가지 공식 답변/코멘트를 원합니다. "우리"는 친숙한 얼굴, 친숙한 이름, 그리고 꽤 공평한 말 등 이 커뮤니티에서 오랫동안 함께해 왔으며 모두 동일한 긍정적인 목표를 추구하고 있습니다. 나는 "우리"가 꽤 크고 대가족이라고 계속해서 말할 것입니다.

그래서 저는 MS가 취한 새로운 방향(OSS-all-the-things 등)과 최근 12/18개월 동안의 일부 메가 uber-.NET-threads(읽기: 커뮤니티 토론 경험에서 배우기)에 대해 생각합니다. ) ... "우리"는 모두 함께 이 일에 참여하고 있으며 이러한 진짜 큰 일 ™️ 중 일부는 미리 공개적으로 논의될 것입니다.

따라서 이러한 중대한 결정 사항 중 일부를 미리 공개적으로 논의할 수 있습니까? 긍정적인 커뮤니티 상담과 토론을 하시겠습니까?

참고: 나는 이 프로젝트가 민주주의가 아니며 _결정_이 MS에 의해 이루어진다는 점을 인정합니다. 문제 없다. 나는 _그_를 비판하지 않는다. 그 이전 단계에 대해 이야기하고 있습니다. 또한 RFC 등을 위해 _모든 것_을 요구하는 것이 아닙니다. 이 스레드가 시작된 것과 같은 이상한 주요 티켓 항목일 뿐입니다.

그러나 MS가 .NET 4.x를 남겨두고 공식적으로 헤어지기 전에 ASP.NET 2.0 LTS 릴리스가 차선책이 될 것입니다. 정의에 따르면 아무도 아직 존재하지 않는 새로운 기능에 의존하지 않으므로 아무도 .NET Core 전용 v3.0으로 강제로 업그레이드하지 않을 것입니다.

이해가 안 돼요. 릴리스에 존재하지 않기 때문에 아직 아무도 ASP.NET 2.0의 기능에 의존하지 않습니다. 그래서 ASP.NET Core 1.x가 그 버전이 아닙니까? 전체 프레임워크, 코어 1.0 및 코어 2.0에서 실행되며 ASP.NET Core 2.x의 디딤돌 역할을 할 수 있습니까?

@onovotny

모든 사람은 항상 새로운 기능, 새로운 기능의 가능성, 또는 적어도 나중에 더 많은 것을 얻을 수 있는 옵션이 있다는 것을 알고 싶어합니다. 플랫폼을 닫고 "안정"/"유지 관리 모드로 전환하면 사람들은 더 이상 관심을 기울이지 않는 것으로 봅니다.

예, 하지만 .NET Framework가 OS 구성 요소에 연결된 큰 안정적인 지원을 받을 때 동일한 수준의 품질을 보장하기는 정말 어렵습니다. @terrajobst 가 말했듯이 일부는 확실히 어느 시점에서 이식되지만 나머지는 파악해야 합니다. 사실 ASP.NET Core는 한 번에 전체 스택을 개선할 수 있는 기능이 있기 때문에 .NET Core에서 가장 잘 실행됩니다. 지금까지 2개의 런타임 간에는 큰 성능 차이가 있으며 .NET Framework 지원으로 인해 아직 새 API에 대한 종속성을 사용하지 않았습니다. 앞으로 나아가면서 .NET Framework에 표시되거나 표시되지 않을 수 있는 새로운 API를 추가할 것이며 가장 안정적이고 느리게 움직이는 런타임(.NET Framework)의 속도로 발전하고 싶지 않습니다.

@NickCraver

지원이 출시된 지 약 1년 후에 종료되기 때문입니다(위의 Scott에 따르면). 그리고 그때쯤이면 스택 오버플로 이식을 거의 끝낼 수 있을 것입니다.

그것이 완전히 정확한지 확신할 수 없습니다. 2.0을 사용할 수 있으면 1.1이 계속 지원됩니다. 그래서 당신이 말하는 이 "지원"은 무엇입니까? 유료 지원을 의미합니까 아니면 문제가 발생하면 문제를 해결할 것이라는 의미입니까?

내가 있어야 할 라이브러리가 없기 때문입니다. 그리고 언제가 될지 모르겠습니다. 그래서 나는 1.x에 갇혀 있었고 지원이 끝날 때까지 시한 폭탄이 있습니다. 지원이 종료되기 전에 1.0에서 2.x(또는 3.x)로 이식할 충분한 시간이 있습니까? 아마 아닐 것입니다.

내가 말했듯이 해당 라이브러리는 .NET Core 버전에 관계없이 켜집니다. 당신이 말하는 것은 최신 버전의 ASP.NET Core(무엇이든 간에)를 사용하고 .NET Core에 충분한 라이브러리가 있을 때까지 .NET Framework에서 지원되기를 원한다는 것입니다. 특정 시나리오에 쉽습니다.

대규모 코드베이스는 단순히 중지하고 이식할 수 없으며 시간이 필요하며 단계적으로 이루어져야 합니다. ASP.NET Core에 .NET 4.6.x 포트를 수행하는 것은 중간 단계로 가능했습니다. 한 번에 코어로 이동하는 것은 훨씬 더 어렵고 더 오래 걸리며 더 오래 지속되는 가지와 더 많은 고통을 필요로 합니다. 단계적으로 이 작업을 수행할 수 없다면 솔직히 말해서 지금은 버려진 ASP.NET 5 라인에서 벗어나는 것을 볼 수 없습니다. 시간, 비용 및 개발에 미치는 영향을 정당화할 수 있는 방법이 없습니다.

ASP.NET Core 회전 버전은 이에 어떤 영향을 줍니까? 우리가 3.0에서 .NET Framework 지원을 중단했다면(이 스레드에서 사람들이 회피하는 것처럼 보임) 상관없이 동일한 막다른 골목에 있지 않을까요? ASP.NET Core 2.0 응용 프로그램은 1년 동안 프레임워크에서 실행되도록 이식되었으며 3.0이 나오면 업그레이드할 수 없습니다. 어쨌든 .NET Framework에서 실행되고 ASP.NET Core 2.0이 종료된 경우 에도 지원되는 ASP.NET Core 1.1.x를 사용하면 이 작업을 수행할 수 있습니다.

현재 제 견해는 2018년 7월경까지 작동하는 새로운 플랫폼이 있다는 것입니다. 그 후: 저는 아무것도 모릅니다. 그때까지 내가 필요한 것을 netstandard/netcoreapp에서 사용할 수 있기를 바랄 뿐입니다. 지원이 종료되기 전에 이식할 충분한 시간이 있기를 바랍니다. 나는 희망을 품은 것이 아니라 우리 회사를 위한 플랫폼 결정을 내리기 위해 돈을 받았고, ASP.NET Core는 이 변경 사항과 작동할 버전에 대한 날짜가 없는 (우리에게) 나쁜 선택입니다.

1년만 더 있으면 모두에게 충분한 시간입니까? 이것은 내가 이 스레드에서 얻는 느낌이 아닙니다.

우선 순위 1: ifdef, perf가 무엇이든 상관없이 net461에서 작동해야 합니다.
우선 순위 2. .NET Core 2.0에서 10배 더 빠르게 만들 수 있다면 정말 좋습니다. 사람들이 플랫폼을 선택하거나 가능하면 마이그레이션해야 하는 큰 이유입니다.

여기서 중요한 것은 장기적인 지원을 위해서는 속도가 느리더라도 전체 프레임워크에서 계속 작동해야 한다는 것입니다.

.NET Framework가 오늘날처럼 잘 작동하는 유일한 이유는 .NET Framework를 의도적으로 지원했기 때문입니다. 무료로 제공되는 것이 아니라 "코어에서 더 빠른 것"이 아니라 .NET Framework에서 작동할 수 있도록 시스템을 의도적으로 설계해야 했습니다. 아직 확인하지 못하더라도 아직 .NET Framework에 존재하지 않는 API에 대한 종속성을 사용하기로 결정하고 결정하면 2 사이의 기능 격차가 커질 것입니다. 우리는 @PinpointTownes 가 말한 대로 할 수 있고 이러한 기능 격차가 나타날 때 NotSupportedException 를 던질 수 있지만 IMO는 꽤 나쁜 경험입니다.

우리는 ASP.net MVC5 앱을 ASP.net 핵심 전체 프레임워크로 이식하여 Azure Service Fabric과 원활하게 작동하도록 하는 데 많은 개발 예산을 투자했습니다. 전체 프로젝트는 웹 애플리케이션을 이식하는 데 몇 주가 소요되는(솔직히 어색한 VS2015 도구와 씨름하는) 여러 달이었습니다.

작동한 유일한 이유는 현재 ASP.net 코어에서 SignalR을 실행하고 있기 때문에 전체 프레임워크가 지원되었기 때문입니다( @davidfowl 낙담). 내가 말할 수 있는 한, SignalR은 여전히 ​​Asp.net Core에서 지원되지 않습니까?

그런 다음 우리는 새로운 VS2017 도구로 마이그레이션하는 데 일주일 정도를 보냈습니다. 괜찮은.

_지금까지는 제품에 대한 개선 사항이 전혀 없으며 Microsoft 플랫폼 및 도구 요구 사항에 맞게 코드 모양을 조정하는 것뿐입니다._

이제 12개월 이내에 내가 할 수 있다는 보장도 없이 기능이 없는 개발 노력을 더 많이 수행해야 하고, 손을 흔드는 무리에 따라 그리고 할 수 있어야 한다고 말하는 건가요? 고맙지 만 사양 할게.

첫째, 사람들이 현재 ASP.net 코어에서만 작동하는 ASP.net 코어 전체 프레임워크에서 사용하고 있는 Microsoft 브랜드의 모든 것을 가져옵니다. 둘째, 생태계가 원하는 대로 ASP.net 코어를 채택하는 것을 방해하는 다른 요소(있는 경우)를 찾으십시오. 그런 다음 논의 중인 Netfx에 대한 지원을 중단합니다.

우리는 @PinpointTownes 가 말한 대로 할 수 있고 이러한 기능 차이가 나타날 때 NotSupportedException을 던지기 시작할 수 있지만 IMO는 꽤 나쁜 경험입니다.

그것은 정확히 내가 말한 것이 아닙니다. 크로스 컴파일을 할 때 ifdefs 는 확실히 특정 플랫폼에서 사용할 수 없는 API를 제외하는 기본 옵션이어야 하지만 어떤 이유로든 이 API 서명이 공개적으로 있어야 하는 경우 계약하면 NotSupportedException 로 갈 수 있습니다.

이해가 안 돼요. 아무도 아직 ASP.NET 2.0의 기능에 의존하지 않습니다.

대부분의 개발자가 ASP.NET Core로 마이그레이션하기 전에 종속성이 지원하는 안정적이고 호환성이 높은 .NET Standard 2.0을 기다리고 있을 것으로 예상합니다. 그들은 .NET Core 1.1이 EOL되고 MS가 이전 DNX/.NET Core 버전에 대한 장기적인 지원을 제공한 좋은 기록이 없다는 것을 알고 채택하기를 원하지 않을 것입니다. 생태계의 나머지 부분이 안전하게 채택할 수 있는 호환성이 높은 안정적인 LTS 릴리스가 있는 경우 기업은 시스템을 실행하는 데 필요한 모든 것을 갖추고 있어야 하며 모든 것을 갖추게 되므로 .NET Core vNext로 업그레이드할 의무를 느끼지 않을 것입니다. v2.0에 필요하고 시간이 되면 ASP.NET Core 2.0/.NET v4.6에서 향후 .NET Core 전용 버전으로 마이그레이션을 계획하는 것이 훨씬 더 쉬울 것입니다.

@mythz

저는 개인적으로 미래의 .NET Core 전용 기능보다 안정적인 .NET Standard 2.0에 더 관심이 있습니다. 모든 것이 다시 작동하고 도구가 손상되지 않고 인기 있는 .NET 개발로 돌아가고 싶기 때문입니다. .NET 패키지는 모두 지원을 제공하며 주변 배포 및 호스팅 솔루션이 개선되었으며 솔루션 구축을 시작할 수 있는 안정적인 ASP.NET Core에 사용할 수 있는 풍부한 문서, 게시물, 비디오 및 지식 기반이 있습니다.

거기 있는 모든 것에 동의하지만 이 결정이 당신의 말에 어떤 영향을 미치는지 모르겠습니다. 다 똑같은 걸 원해 👍 .

1개의 플랫폼만 지원해야 하는 자유로 인해 개발자가 지속적으로 새로운 기능 스트림을 통해 가장 최신의 최신 버전을 채택하도록 유도하는 새로운 기능을 잠재적으로 제공할 수 있습니다. 개인적으로 저는 ASP.NET이 현재 가지고 있는 기능에 만족하고 있습니다. 저는 모든 것이 다듬어진 안정적인 버전에 더 관심이 있어 다시 생산적으로 돌아가 항상 움직이는 플랫폼을 쫓는 대신 솔루션 개발에 집중할 수 있습니다.

맞습니다. ASP.NET Core 1.x가 아닌가요? 1.x에서 지원이 확장된다면 충분하지 않을까요? netstandard 1.x인 ASP.NET Core 1.이 .NET Core 2.0(이미 실행 중인)에서 실행되도록 하고 1년 정도 더 지원할 수 있습니다.

그것은 정확히 내가 말한 것이 아닙니다. 크로스 컴파일을 진행할 때 ifdef는 특정 플랫폼에서 사용할 수 없는 API를 제외하는 데 확실히 선호되는 옵션이어야 하지만 어떤 이유로든 공개 계약에 이 API 서명이 필요한 경우 다음을 수행할 수 있습니다. NotSupportedException으로 이동하십시오.

공개 API 노출에 대해 이야기하지도 않습니다. 나는 netstandard에 존재하지 않을 호출해야 하는 API에 대해 이야기하고 있습니다. #ifdef는 여기서 도움이 되지 않습니다. 격차가 커지면 그냥 던집니다.

@davidfowl 완전히 유효한 질문 - 답변:

유료 지원을 의미합니까 아니면 문제가 발생하면 문제를 해결할 것이라는 의미입니까?

문제에 대한 활성 수정 - 1.x가 우리가 깨뜨린 모든 것에 대한 수정을 받습니까, 아니면 일부 경우 수정을 위해 업그레이드하라는 메시지를 받습니까? (참고: 이는 DirectoryServices와 같은 라이브러리가 있을 때까지 수행할 수 없는 업그레이드입니다. 가능하더라도 무료 또는 심지어 저렴하지는 않지만 최소한 몇 달은 걸릴 것입니다.) 우리는 크고 빠르며 프레임워크에서 휴식을 찾을 것입니다. 우리는 수년간 모든 메이저 및 마이너 릴리스를 가지고 있습니다. 지원은 우리에게 매우 중요합니다.

당신이 말하는 것은 최신 버전의 ASP.NET Core를 사용하고 싶다는 것입니다.

아니요, 작동 하는 버전과 앞으로의 경로를 원합니다. 1.x에서는 전반부만 있습니다. 이 문제까지 두 번째는 일종의 가정이었습니다.

ASP.NET Core 회전 버전은 이에 어떤 영향을 줍니까?

전체 프레임워크에 대한 지원을 중단하는 경우 지원을 유지하기 위해 대대적인 변경을 해야 하기 때문입니다.

우리가 3.0에서 .NET Framework 지원을 중단했다면(이 스레드에서 사람들이 회피하는 것처럼 보임) 상관없이 동일한 막다른 골목에 있지 않을까요?

아마도? 요점은 다이빙을 하기 전에 사용 사례에서 패리티를 유지하는 것입니다. 제 경력입니다. 상대방이 우리를 지원하지 않을 때 뛰어내리라고 말할 수 없습니다. 그것은 내 책임이 아닐 수 있습니다. 우리의 사용 사례가 2.x 기간에 지원되었다면 앞으로 나아갈 길이 분명하고 ASP.NET Core에 베팅하는 것이 훨씬 더 안전합니다.

1년만 더 있으면 모두에게 충분한 시간입니까?

시간의 절대적인 길이는 실제로 중요하지 않습니다. 유스 케이스 호환성 + 시간(IMO)이어야 합니다. 우리의 사용 사례가 오늘 작동했다면(예: AD 인증) 2년이면 충분합니다. 그러나 현재로서는 그렇지 않으므로 지금부터 임의의 시점이 괜찮다는 데 동의하는 것은 기껏해야 시기상조입니다.

무료로 제공되는 것이 아니라 "코어에서 더 빠른 것"이 아니라 .NET Framework에서 작동할 수 있도록 시스템을 의도적으로 설계해야 했습니다. 아직 확인하지 못하더라도 아직 .NET Framework에 존재하지 않는 API에 대한 종속성을 사용하기로 결정하고 결정하면 2 사이의 기능 격차가 커질 것입니다.

그렇다면 불쾌하지 않지만 왜 그렇게 말하고 문제를 종료하지 않습니까? 그 말은 더 이상 논의할 것이 없는 것 같고 우리 시간은 다른 곳에서 보내는 것이 좋습니다. 그렇지 않은 경우 명확히 해 주시겠습니까?

주요 문제는 오늘 또는 현재 제안된 대로 출시 시점에 워크로드를 netstandard 로 이식할 수 없다는 것입니다. 이미 가지고 있는 것이 작동하지 않는다면 왜 새로운 기능에 신경을 쓰겠습니까? 팀은 성능에 대해 계속 이야기하지만(정말 대단합니다.) 빠르게 달리는 데 사용할 수 없는 것은 그다지 중요하지 않습니다.

아키텍처/플랫폼 책임자로서 저는 우리가 할 베팅을 결정해야 합니다. 현재 이것은 나쁜 베팅입니다. 버전 1이 당신을 지원하지만 버전 2는 지원하지 않지만 언젠가 는 지원하게 될 때, 그것은 다른 사람들의 시간과 돈으로 만드는 정말 나쁜 도박입니다. 적어도 우리는 기능, 에코시스템 및 지원을 위해 .NET을 선택했습니다. 현재, 새로운 단어에서 우리는 3가지 모두에서 1로 바뀌었습니다. 생태계는 아직 거기에 없으며(API 표면, libs), 지원은 보장된 업그레이드 경로 없이 우리가 사용하는 것보다 훨씬 짧습니다. 알 수 없는 시간입니다.

@jahmai

작동한 유일한 이유는 현재 ASP.net 코어에서 SignalR을 실행하고 있기 때문에 전체 프레임워크가 지원되었기 때문입니다( @davidfowl 낙담). 내가 말할 수 있는 한, SignalR은 여전히 ​​Asp.net Core에서 지원되지 않습니까?

SignalR 2조차도 ASP.NET Core에서 지원되지 않습니다(사람들이 해킹하여 작동하게 만들기는 하지만). SignalR은 아직 개발 중이며 ASP.NET Core 2.0과 함께 나오지도 않습니다. 나중에 나올 예정입니다.

이제 12개월 이내에 내가 할 수 있다는 보장도 없이 기능이 없는 개발 노력을 더 많이 수행해야 하고, 손을 흔드는 무리에 따라 그리고 할 수 있어야 한다고 말하는 건가요? 고맙지 만 사양 할게.

ASP.NET Core 2.0에 필요한 기능이 있습니까? 아니면 결국 다음 ASP.NET Core로 업그레이드해야 하고 그 시점에서 .NET Framework에서 작동하지 않을 것이라고 추측하고 있습니까?

첫째, 사람들이 현재 ASP.net 코어에서만 작동하는 ASP.net 코어 전체 프레임워크에서 사용하고 있는 Microsoft 브랜드의 모든 것을 가져옵니다. 둘째, 생태계가 원하는 대로 ASP.net 코어를 채택하는 것을 방해하는 다른 요소(있는 경우)를 찾으십시오. 그런 다음 논의 중인 Netfx에 대한 지원을 중단합니다.

netstandard 2.0의 일부로 중요한 API를 식별하여 .NET Framework를 대상으로 하는 라이브러리가 대부분 바이너리 호환 가능하도록 많은 작업이 수행되었습니다. 물론 WCF, WPF 등과 같이 작동하지 않는 영역이 있지만 일부 연구를 수행하고 라이브러리의 ~60%가 netstandard 2.0과 호환되는 API이므로 도움이 될 것입니다. @terrajobst) 및 .NET Core 2.0에서만 작동할 수 있습니다.

맞습니다. ASP.NET Core 1.x가 아닌가요? 1.x에서 지원이 확장된다면 충분하지 않을까요?

저는 .NET Standard 2.0이 .NET 4.x와의 호환성을 연결하는 안정적인 플랫폼이 될 것이라고 예상했으므로 LTS 지원이 그 주변에 있을 것이라는 것이 더 합리적입니다. 아무도 1.1/.NET v4.x가 릴리스 중간에 중단될 것으로 예상하지 않으므로 릴리스되기 전에 .NET 4.x 지원을 해제하지 않고 최신 버전이 릴리스될 때 LTS를 발표하는 것이 예의입니다. 하나는 그런 이전 버전을 회고하면서 LTS를 수행합니다.

.NET Core 패키지를 별도의 *.Core 패키지로 유지 관리하고 있다는 것을 알고 있으므로 기본 NuGet 패키지에 병합하는 순간 최신 .NET Core 버전을 따르는 별도의 릴리스 주기를 유지할 수 있습니다. 우리는 공식적으로 지원할 안정적인 릴리스에 전념하고 있으므로 현재 .NET Standard가 아닌 .NET Standard 2.0에서 예상했던 가까운 미래에 지원할 수 있는 버전이 있다는 확신이 필요합니다. 1.1/1.3/1.6 믹스. 안정적인 플랫폼의 신호가 아닌 .NET Standard 버전 관리 기대치를 깨는 2.0과 호환되지 않는 1.7/8 스톱 갭 릴리스가 있었던 것도 기억합니다.

저는 .NET Standard 2.0이 많은 사람들이 찾는 고도로 호환되는 표면적과 매우 필요한 안정성을 제공할 예정임을 걱정스럽게 기대해 왔습니다.

SignalR 2조차도 ASP.NET Core에서 지원되지 않습니다(사람들이 해킹하여 작동하게 만들기는 하지만). SignalR은 아직 개발 중이며 ASP.NET Core 2.0과 함께 나오지도 않습니다. 나중에 나올 예정입니다.

당신이 그 진술을 어떻게 의도했는지는 모르겠지만, 나는 그것이 내 우려를 강화시킨다고 생각합니다.

ASP.NET Core 2.0에 필요한 기능이 있습니까? 아니면 결국 다음 ASP.NET Core로 업그레이드해야 하고 그 시점에서 .NET Framework에서 작동하지 않을 것이라고 추측하고 있습니까?

어떤 이유로 인해 netstandard2로 이동하고 싶습니다. 그러려면 웹 앱을 asp.net core 2로 이동해야 합니다. 맞죠?

netstandard 2.0의 일부로 중요한 API를 식별하여 .NET Framework를 대상으로 하는 라이브러리가 대부분 바이너리 호환 가능하도록 많은 작업이 수행되었습니다. <...>

물론, 저는 netstandard로 수행되는 작업을 좋아하지만 netstandard에서 누락된 것이 있는 경우 이를 필요로 하는 응용 프로그램에서 전체 프레임워크를 대상으로 지정할 수 있기 때문에 해결할 수 있습니다. 이제 Xamarin.iOS, Xamarin.Android, net46, Asp.net core 1.1에서 공유되는 소수의 순수 netstandard 1.3 라이브러리(저희 소스)가 있습니다. net46 항목을 포함하여 특정 프레임워크 대상 라이브러리를 사용하여 netstandard에서 누락된 기능을 보완할 수 있기 때문입니다. asp.net 핵심 웹 앱에서.

우리가 이러한 netstandard 라이브러리를 가지고 있는 _ 유일한 _ 이유는 (이전에 언급했듯이) 거대한 웹 애플리케이션을 이식해야 하기 때문입니다. 다른 플랫폼을 위해 플랫폼별 코드 기반을 확장할 필요가 없고 대신 netstandard 체인을 계속해서 올라가고 싶습니다. asp.net core 2로 이동할 수 있는 경로가 없기 때문에 netstandard 1.3에 얽매이고 싶지 않습니다.

문제에 대한 활성 수정 - 1.x가 우리가 깨뜨린 모든 것에 대한 수정을 받습니까, 아니면 일부 경우 수정을 위해 업그레이드하라는 메시지를 받습니까? (참고: 이는 DirectoryServices와 같은 라이브러리가 있을 때까지 수행할 수 없는 업그레이드입니다. 가능하더라도 무료 또는 심지어 저렴하지는 않지만 최소한 몇 달은 걸릴 것입니다.) 우리는 크고 빠르며 프레임워크에서 휴식을 찾을 것입니다. 우리는 수년간 모든 메이저 및 마이너 릴리스를 가지고 있습니다. 지원은 우리에게 매우 중요합니다.

지원에 문제가 있다고 생각하지 않습니다. 실제로 이것이 큰 문제가 될 것이라고 생각하지 않으며 사람들이 내기를 하는 데 더 자신감을 갖게 된다면 1.x에 대한 지원을 더 긴 기간으로 연장할 가치가 있을 것입니다.

아니요, 작동하는 버전과 앞으로의 경로를 원합니다. 1.x에서는 전반부만 있습니다. 이 문제까지 두 번째는 일종의 가정이었습니다.

모든 종속성이 이식될 때까지 1.x를 유지해야 한다는 의미입니다. 아니요?

@NickCraver 모든 불만 사항은 ASP.NET Core가 아닌 .NET Core에서 누락된 사항에 대해 이야기하고 있습니다. .NET Core 1.x 및 ASP.NET Core 1.x에서 이러한 2개의 엔터티는 함께 제공되지만 완전히 분리됩니다. v1이 무언가를 지원하고 v2가 지원하지 않는 것에 대한 유효한 우려 외에 특별히 ASP.NET Core 2.0을 사용하려는 단 한 가지 이유도 듣지 못했습니다. .NET Core로만 이식할 수 없는 또 다른 이유가 있다면(전체 프레임워크에서 ASP.NET Core를 개발하는 동안 몇 가지 새로운 종속성을 사용했을 수 있습니다.) 예제로 이식되지 않습니다).

그렇다면 불쾌하지 않지만 왜 그렇게 말하고 문제를 종료하지 않습니까? 그 말은 더 이상 논의할 것이 없는 것 같고 우리 시간은 다른 곳에서 보내는 것이 좋습니다. 그렇지 않은 경우 명확히 해 주시겠습니까?

저는 .NET Framework를 지원해야 하는 이유, 지원해야 하는 기간을 파악하기 위해 여기에서 답장을 하고 있습니다. 나는 여전히 그 시간 프레임에 대해 이 스레드에서 혼합된 느낌을 받고 있습니다. 또한 "ASP.NET Core 1.x로 강등됨"에 대해 이해할 수 있는 일반적인 두려움이 있지만 2.x에 필요한 특정 기능과 관련하여 구체적인 것은 없습니다.

.NET Core와 ASP.NET Core를 결합할 때 내가 좋아하는 주요 사항 중 하나는 버전 관리 및 명명 광기의 일부를 해결한다는 것입니다. 많은 사람들은 ASP.NET Core가 .NET Framework에서 실행된다는 사실조차 모릅니다. 즉, 다양한 요구 사항을 가진 많은 고객이 있고 그들의 피드백에 귀를 기울입니다.

@mythz

저는 .NET Standard 2.0이 많은 사람들이 찾는 고도로 호환되는 표면적과 매우 필요한 안정성을 제공할 예정임을 걱정스럽게 기대해 왔습니다.

물론, 하지만 내가 말했듯이 1.x의 ASP.NET Core, .NET Core 및 .NET Standard는 완전히 분리되어 있습니다. .NET Standard 라이브러리를 지원하는 모든 버전의 .NET Core에서 모든 .NET Standard 라이브러리를 사용할 수 있습니다. 따라서 .NET Core 2.0이 새로운 LTS인 경우에도 ASP.NET Core 1.x가 지원된다고 선언할 수 있습니다.

@jahmai

어떤 이유로 인해 netstandard2로 이동하고 싶습니다. 그러려면 웹 앱을 asp.net core 2로 이동해야 합니다. 맞죠?

아니오, 옳지 않습니다. 웹앱을 ASP.NET Core 2.0으로 이동하지 않고 원할 때마다 netstandard 2로 이동할 수 있습니다.

우리가 이러한 netstandard 라이브러리를 가지고 있는 유일한 이유는 (앞서 언급했듯이) 거대한 웹 애플리케이션을 이식해야 했기 때문입니다. 다른 플랫폼에 대한 플랫폼별 코드 기반을 확장하지 않고 대신 netstandard 체인 위로 계속 이동하고 싶습니다. asp.net core 2로 이동할 수 있는 경로가 없기 때문에 netstandard 1.3에 얽매이고 싶지 않습니다.

netstandard 1.3에 집착할 필요가 없습니다. 2가지가 관련이 없습니다.

버전 1이 지원하지만 버전 2는 지원하지 않지만 _언젠가는 지원하게 될 때, 그건 정말 나쁜 도박입니다....

이것이 문제의 핵심이라고 생각합니다. 우리는 격차( DirectoryService 등) 중 _일부_가 알려져 있고 해결될 것이라는 의견을 받았습니다. 그보다 더 구체적인 것이 필요합니다.

나는 .NET Core를 대상으로 하는 ASP.NET Core에 대해 괜찮고 로드맵이 명확한 경우 2.0 보트를 놓치고 이러한 격차(그리고 어떤 격차)가 해결될 것으로 예상할 수 있는지 확인합니다(다시, 이전에 이식할 충분한 시간이 있다고 가정). 1.X는 지원되지 않습니다).

현재 상황으로 볼 때 WCF에 대해 차단된 문제는 2015년 5월 이후 정체되어 있으며 결코 해결되지 않을 수 있습니다.. 우리를 효과적으로 좌초시킵니다.

@davidfowl

아니오, 옳지 않습니다. 웹앱을 ASP.NET Core 2.0으로 이동하지 않고 원할 때마다 netstandard 2로 이동할 수 있습니다.

훌륭한. 이 경우 Microsoft가 고객에게 적절한 2.x 마이그레이션 경로(예: SignalR)를 제공할 때까지 1.x가 지원되도록 하는 한(모든 종류의 버그 수정 및 운영 지원), asp.net 코어 2가 필요합니다.

모든 종속성이 이식될 때까지 1.x를 유지해야 한다는 의미입니다. 아니요?

맞습니다. 그러나 그것은 알려진 기간이어야 합니다. 우리는 날짜가 없습니다. 우리가 지금까지 들었던 것은 "2.0에는 없다"는 것뿐입니다...그래서 좋지 않습니다. 예를 들어 System.DirectoryServices 는 2015년 중반부터 요청되었으며 여전히 누락되었지만 사용자가 가장 원하는 대로 반복되는 경우가 많습니다( System.Drawing 가 뒤따름). .NET Standard 2.0을 ~60% API 패리티로 가져오고 있지만 사용자가 요청한 비트가 누락되면 무엇이 중요한지에 대한 혼합 신호를 보내는 것이 가장 확실합니다.

모든 불만 사항은 ASP.NET Core가 아닌 .NET Core에서 누락된 사항에 대해 이야기하고 있습니다.

그것은 잘못된 것입니다. 지원되는 플랫폼에서 실행하는 데 필요한 비트(예: AD 인증)가 필요합니다. 빠진 것은 후자의 지원입니다. 1.x에 대한 지원은 확실히 저의 주요 관심사입니다. 지원되는 경로나 예상 일정이 없습니다.

나는 우리가 1년 안에 똑같은 토론을 할 것이라고 생각한다

나는 그것이 사실이라고 생각하지 않는다. 문제는 오늘 이식할 수 없다는 것입니다. API가 없습니다. 이식할 수 있는 단일 시점이 없는 한 미래에 대한 논의는 약간 무의미합니다. ASP.NET Core의 .NET 전체 프레임워크 지원은 패리티가 있고 대부분의 사용자가 이전할 수 있게 되면 더 이상 사용되지 않을 것으로 예상합니다. 그리고 나는 그 릴리스가 사람들이 넘어갈 수 있는 긴 지원 기간을 가질 것으로 예상합니다.

DirectoryServices, Drawing 등이 2.x에 나온다면 대단합니다. 해당 릴리스는 .NET Framework를 지원하고 LTS 릴리스여야 합니다. 그리고 3.x는 전체 프레임워크 지원을 중단해야 합니다.

.NET Core와 ASP.NET Core를 결합할 때 내가 좋아하는 주요 사항 중 하나는 버전 관리 및 명명 광기의 일부를 해결한다는 것입니다. 많은 사람들은 ASP.NET Core가 .NET Framework에서 실행된다는 사실조차 모릅니다. 즉, 다양한 요구 사항을 가진 많은 고객이 있고 그들의 피드백에 귀를 기울입니다.

충분히 공평하지만 "그것이 작동합니까?"에 부차적인 모든 광기. 현재로서는 회사 번호입니다. ASP.NET 및 .NET Core/Standard/무엇이든 Microsoft 내부의 2가지 세트일 수 있지만(완전히 이해합니다) 개발자에게는 여전히 1개의 플랫폼입니다. ASP.NET 측에서는 많은 사람들에게 유용한 API가 필요하지만 아직까지는 없습니다. 이 이동은 사용 가능한 API를 더욱 줄입니다. ASP.NET 팀은 원하는 것을 얻을 수 있지만 우리가 필요로 하는 것을 희생해야 합니다.

@ctolkien @NickCraver

이것이 문제의 핵심이라고 생각합니다. 우리는 일부 격차(DirectoryService 등)가 알려져 있고 해결될 것이라는 의견을 받았습니다. 그보다 더 구체적인 것이 필요합니다.

맞습니다. 그러나 그것은 알려진 기간이어야 합니다. 우리는 날짜가 없습니다. 우리가 지금까지 들었던 유일한 것은 "2.0에는 없다"는 것입니다...그래서 그것은 좋지 않습니다. 예를 들어 System.DirectoryServices는 2015년 중반부터 요청되었으며 여전히 누락되었지만 사용자가 가장 원하는 대로 반복되는 경우가 많습니다(System.Drawing에 이어).

이러한 격차는 .NET Core 자체와 관련이 있으며 이러한 종속성을 언제 사용할 수 있는지 알지 못하는 불안을 이해할 수 있습니다. 그렇기 때문에 우선 순위를 지정하는 데 도움이 될 것입니다. 좋은 소식은 netstandard 2.0과 netcoreapp2.0이 다른 라이브러리를 더 쉽게 이식할 수 있도록 그룹 작업을 수행했다는 것입니다. 2.0을 출시한 후에는 매우 호환되는 기반 위에 많은 코드를 포팅하여 다른 종속성을 불러오는 것이 훨씬 더 쉬울 것으로 예상합니다.

CSOM 은 netcore 2에서 실행됩니까? 그것은 우리와 내가 한 번도 들어본 적이 없는 영역에 대한 거대한 방해 요소가 될 것입니다.

@davidfowl 나도 그렇게 되기를 진심으로 희망하지만, 우리 회사를 거기에 걸지는 않습니다. 그 일이 일어나기 전에 지원을 중단하고 그 이후가 아니라 저는 강력하게 동의하지 않습니다. 많은 소비자를 위한 중요한 API가 배치 된 후 3.x 시간 프레임에서 이러한 일이 발생하는 것은 완전히 타당하다고 생각합니다. 준비가 되기 전에 그렇게 하면 입양이 중단됩니다.

중요한 API가 준비될 때까지 2.x(또는 적극적으로 개발/수정된 모든 것)가 전체 프레임워크를 지원할 것이라고 가정 하고 1.0을 채택하는 길에 있었습니다. ). 하지만 이 시점에서 스택에서는 그렇게 할 수 없습니다. 그것은 잘못된 가정이었습니다. 포트의 미래가 불확실한 상황에서 저는 양심적으로 팀에게 .NET Core를 사용하라고 말할 수 없습니다. 정말 그러고 싶지만 현재로서는 위험과 고통의 가치가 없습니다.

@NickCraver

ASP.NET Core의 .NET 전체 프레임워크 지원은 패리티가 있고 대부분의 사용자가 이전할 수 있게 되면 더 이상 사용되지 않을 것으로 예상합니다. 그리고 나는 그 릴리스가 사람들이 넘어갈 수 있는 긴 지원 기간을 가질 것으로 예상합니다.

여기서 "대부분의 사용자"는 무엇입니까? 지원을 중단할 수 있을 때까지 다루어야 하는 종속성 목록은 무엇입니까? 귀하의 목록은 이 목록의 다른 사용자와 다릅니다. 또한 일부 사람들은 영원히 또는 .NET Core가 .NET Framework 패리티에 도달할 때까지(비현실적임) 말할 것으로 예상합니다. 나는 여전히 ASP.NET Core 1.x가 그 목적에 충분하다고 주장할 것이고 우리는 그 때까지 지원을 확장 해야 합니다 .

그것은 잘못된 것입니다. 지원되는 플랫폼에서 실행하는 데 필요한 비트(예: AD 인증)가 필요합니다. 빠진 것은 후자의 지원입니다. 1.x에 대한 지원은 확실히 저의 주요 관심사입니다. 지원되는 경로나 예상 일정이 없습니다.

이 시나리오에서 누락된 ASP.NET 구성 요소는 무엇입니까? 1.x 대 2.x라고 말할 때 ASP.NET Core 대 .NET Core를 언급하면 ​​유용할 것입니다.

DirectoryServices, Drawing 등이 2.x에 나온다면 대단합니다. 해당 릴리스는 .NET Framework를 지원하고 LTS 릴리스여야 합니다. 그리고 3.x는 전체 프레임워크 지원을 중단해야 합니다.

이전에 이것을 언급했는데, ASP.NET Core 1.x가 이에 충분하지 않기 위해 어떤 ASP.NET Core 기능이 필요합니까?

ASP.NET 및 .NET Core/Standard/무엇이든 Microsoft 내부의 2가지 세트일 수 있지만(완전히 이해합니다) 개발자에게는 여전히 1개의 플랫폼입니다.

동의하지만 영향을 적절하게 평가할 수 있도록 이 논의에 대한 FUD를 정리해야 합니다. ASP.NET Core 1.x는 .NET Standard 1.x(1.0 - 1.6) 및 .NET Framework 4.5.1을 대상으로 합니다. 이는 해당 버전의 netstandard 및 .NET Framework를 지원하는 모든 플랫폼에서 실행할 수 있음을 의미합니다. 이는 ASP.NET Core 1.x가 .NET Core 2.0에서 실행됨을 의미합니다.

@smbecker

CSOM은 netcore 2에서 실행됩니까? 그것은 우리와 내가 한 번도 들어본 적이 없는 영역에 대한 거대한 방해 요소가 될 것입니다.

나는 그것이 무엇인지 전혀 모른다. https://msdn.microsoft.com/en-us/library/ff798388.aspx입니까? 그렇다면 명시적으로 지원하기 위한 작업이 수행되지 않았습니다. .NET Core 2.0의 .NET Framework 호환성을 기반으로 작동할 수도 있지만 내 생각에는 .NET Core로 이식되지 않을 것입니다(5분 동안 살펴본 결과). 하지만 내가 틀릴 수 있습니다.

여기서 "대부분의 사용자"는 무엇입니까? 지원을 중단할 수 있을 때까지 다루어야 하는 종속성 목록은 무엇입니까? 귀하의 목록은 이 목록의 다른 사용자와 다릅니다. 또한 일부 사람들은 영원히 또는 .NET Core가 .NET Framework 패리티에 도달할 때까지(비현실적임) 말할 것으로 예상합니다. 나는 여전히 ASP.NET Core 1.x가 그 목적에 충분하다고 주장할 것이고 우리는 그 때까지 지원을 확장해야 합니다.

가장 많이 누락된 API부터 시작하겠습니다. 이것이 대부분의 사람들에게 차단을 일으키는 원인입니다. 우리에게 그것은 1위인 DiretoryServices입니다. 그것이 거기에도 없다면 커뮤니티에 정말 나쁜 징조입니다. 목록이 다르다는 데 동의하지만 1 번도 포함하지 않으면 ...

이 시나리오에서 누락된 ASP.NET 구성 요소는 무엇입니까? 1.x 대 2.x라고 말할 때 ASP.NET Core 대 .NET Core를 언급하면 ​​유용할 것입니다.

이전에 이것을 언급했는데, ASP.NET Core 1.x가 이에 충분하지 않기 위해 어떤 ASP.NET Core 기능이 필요합니까?

전체 프레임워크(따라서 필요한 라이브러리)를 지원하는 최신 ASP.NET Core에 대한 지원을 의미합니다. 모듈, 면도기 페이지 등을 원하기 때문에 2.x가 되기를 바랍니다 . 우리는 2.x 기능을 많이 사용합니다. 그러나 이 시점에서 유일한 옵션은 1.x인 것 같습니다. ASP.NET 5에서 ASP.NET Core로, 모든 작업 라이브러리가 있는 전체 프레임워크에서 한 번에 netcoreapp 로 이동할 수 없습니다. 너무 많아 비용이 너무 많이 듭니다. 너무 위험해 그리고 지금 우리는 지원 창 내에서 그 비싸고 위험한 움직임을 할 수 있는지 확신할 수 없습니다. 그것은 나쁜 상황입니다. 너무 나빠서 움직이지 않는 것이 좋습니다(현재 상황에서). 정말 불행한 일이라고 생각합니다.

이 시나리오에서 누락된 ASP.NET 구성 요소는 무엇입니까? 1.x 대 2.x라고 말할 때 ASP.NET Core 대 .NET Core를 언급하면 ​​유용할 것입니다.

• 일부 Microsoft.Authentication.* NuGet 패키지를 통해 AD 인증/쿼리를 처리할 수 있는 방법이 없다면 그것은 큰 문제입니다. 저는 현재 같은 배를 타고 있지만 .NET 462 위에 .NET Core 1.1을 실행하고 있기 때문에 해낼 수 있습니다. 그 외에 지원되는 수단을 통해 AD 그룹, 메타데이터를 어떻게 쿼리할 수 있습니까? 나는 corefx repo에서 System.DirectoryServices 에 대해 많은 일이 일어나고 있다는 것을 보았으므로 적어도 그것에 대해 만족합니다.

• System.Data.Common.DbDataAdapter / SqlClient.SqlDataAdapter . 현재는 전체 .NET Framework 위에 있는 .NET Core에서 실행할 때만 액세스할 수 있습니다. DbDataReader / SqlDataReader 를 계속 사용할 수 있기 때문에 더 편리한 것 같아요.

기본적으로 ASP.NET Core 2.x를 사용하는 동안 전체 .NET Framework 없이도 AD 인증을 처리하는 일부 지원 방식이 보장된다는 것을 알고 있어야 합니다.

나는 오늘 이것에 대해 많이 생각했고, 내 관심사가 여기 있는 대부분의 사람들과 다르다는 것을 알게 되었습니다(그 관심사가 그다지 중요하지 않거나 더 중요하지 않다는 것은 아닙니다).

나는 여전히 netstandard 에서 ASP.NET Core 패키지를 사용하는 유스 케이스에 갇혀 있습니다. 이 문제까지 나는 netstandard 가 라이브러리에 대한 사실상의 목표라고 (아마도 잘못) 가정했습니다. 즉, 라이브러리 작성자의 의도된 동작은 필요하고 강력한 이유가 없는 한 netstandard 를 대상으로 하는 것입니다. 이렇게 하면 Framework뿐만 아니라 Xamarin 및 UWP와 같은 다른 플랫폼과의 호환성도 보장됩니다. .NET Standard 2.0에 대한 작업은 다양한 런타임의 API 노출 영역을 생각할 필요가 없는 공통 대상으로 통합하려고 시도함으로써 이를 지원하는 것으로 보입니다.

나에게 이 변화는 뭔가 다른 신호를 보낸다. 결국 ASP.NET Core는 라이브러리일 뿐이며 공통 netstandard 노출 영역을 지원하지 않는 "필수적이고 강력한 이유"가 있을 수 있습니다. 그러나 이것은 또한 가장 눈에 띄는 Microsoft 개발 .NET 라이브러리 중 하나이며 "우리는 가장 최신의 것을 원하므로 netstandard 지원을 중단할 것입니다"라고 말함으로써 다른 모든 라이브러리 개발자(또는 최소한 저에게는 그렇습니다) 아마도 netstandard 를 지원하기 위해 열심히 노력하는 것을 멈추고 핵심 런타임을 목표로 삼기 시작해야 할 것입니다. Microsoft가 그다지 신경 쓰지 않는데도 왜 그 모든 호환성 문제에 신경을 쓰겠습니까? .NET Core 4 수명. 그리고 아마도 그것이 최선일 것입니다. 여러 런타임과 대부분 통합된 API 노출 영역을 사용한다고 생각했던 것과는 확실히 다릅니다.

이 문제는 ASP.NET Core에 ASP.NET 컨텍스트 외부에서 직접적으로 유용한 라이브러리가 많이 포함되어 있다는 점을 고려할 때 더욱 심화됩니다. 그것들이 고립되어 사용되도록 의도된 적이 있다고 가정하는 것은 잘못된 것일 수도 있지만, 그것들을 느슨하게 하는 것은 끔찍한 수치일 것입니다. 이를 사용하려는 라이브러리 작성자는 자신의 대상을 .NET Core로 전환하거나 netstandard 를 유지하고 이에 대한 액세스 권한을 느슨하게 결정해야 합니다. 나는 많은 사람들이 대안 플랫폼에 대해 더 세분화된 라이브러리 지원을 선택할 것이라고 생각합니다. 적어도 지원 라이브러리에 대해 서로 다른 플랫폼을 대상으로 하는 것이 너무 어렵다는 설명을 이해했다면.

마지막으로, 가능한 한 빨리 새로운 API가 ASP.NET과 함께 rev에 추가될 것이라는 여기 댓글에 대해 다소(조금 덜) 걱정이 됩니다. 특히 이러한 새 API는 netstandard 또는 .NET Framework에 포함되지 않을 수 있습니다. 레거시 및 호환성 문제가 삭제되거나 느슨해지면 수행할 수 있는 몇 가지 흥미로운 일이 있을 수 있다는 것을 확실히 이해합니다. 하지만 솔직히 말해서 ASP.NET Core 팀이 앞서 나가는 경우가 많다는 인상을 받았습니다. 그것이 반드시 나쁜 것은 아니지만 뒤로 물러나야 하는 여러 광범위한 결정으로 이어졌습니다. 나는 이것이 시간이 지남에 따라 런타임 세트를 크게 분열시키는 결과를 가져오는지 궁금하지 않을 수 없습니다. 또한 Xamarin, Mono, UWP 등).

이 전체 스레드로 인해 netstandard 대신 .NET Core를 중심으로 .NET의 미래에 대한 이해의 방향이 바뀌었습니다. 어쩌면 내가 극단적이고 앞으로 몇 주 안에 완화될 수도 있고, 심지어 그것이 의도한 입장이고 그것이 최선일 수도 있습니다. 어느 쪽이든, 저는 현재 나가서 내 자신을 위해 .NET Core를 대상으로 하고 싶은 유혹을 받습니다. 여기에서 읽은 모든 것에서 앞으로 나아가는 것에만 집중하십시오.

@NickCraver

전체 프레임워크(따라서 필요한 라이브러리)를 지원하는 최신 ASP.NET Core에 대한 지원을 의미합니다. 모듈, 면도기 페이지 등을 원하므로 2.x가 되기를 바랍니다. 우리는 2.x 기능을 많이 사용합니다.

지금은 1.1.1입니다(2.0에는 모듈이 없음). Razor Pages는 좋은 제품이고 다른 하나는 SignalR입니다. 이 2가지가 이 작업의 일부로 가장 고통스럽다고 생각합니다.

ASP.NET 5에서 ASP.NET Core로, 모든 작업 라이브러리가 있는 전체 프레임워크에서 한 번에 netcoreapp으로 이동할 수 없습니다. 너무 많아 비용이 너무 많이 듭니다. 너무 위험해 그리고 지금 우리는 지원 창 내에서 그 비싸고 위험한 움직임을 할 수 있는지 확신할 수 없습니다. 그것은 나쁜 상황입니다. 너무 나빠서 움직이지 않는 것이 좋습니다(현재 상황에서). 정말 불행한 일이라고 생각합니다.

그래도 되나요? 종속성이 이식되었다는 가정 하에 ASP.NET Core 1.x에서 2.x 또는 3.x로의 이동은 간단합니다. 일반적으로 ASP.NET Core로 이동할 계획이라면 1.1로 이동하는 것이 좋은 첫 번째 단계이며 이를 피하기 위해 작업을 저장하지 않아도 됩니다.

@snickler

기본적으로 ASP.NET Core 2.x를 사용하는 동안 전체 .NET Framework 없이도 AD 인증을 처리하는 일부 지원 방식이 보장된다는 것을 알고 있어야 합니다.

System.DirectoryServices가 .NET Core에서 지원될 때까지 .NET Framework에서 ASP.NET Core 1.x를 사용할 수 없는 이유가 있습니까?

System.DirectoryServices가 .NET Core에서 지원될 때까지 .NET Framework에서 ASP.NET Core 1.x를 사용할 수 없는 이유가 있습니까?

그것이 내가 현재 하고 있는 일이다. 필요하지 않은 경우 .NET Framework에 대해 걱정할 필요가 없기를 바랍니다. 현재 Mono에는 System.DirectoryServices.AccountManagement 네임스페이스가 없기 때문에 내 Windows 컴퓨터로 제한됩니다. 같은 맥락에서 Windows의 제약 조건을 벗어나 System.DirectoryServices.AccountManagement 를 사용할 수 있습니까? 그 작은 조각으로 인해 MVC 프로젝트와 Xamarin.iOS 앱을 로컬로 디버깅하는 동안 컴퓨터 간에 이동해야 합니다.

일반적으로 ASP.NET Core로 이동할 계획이라면 1.1로 이동하는 것이 좋은 첫 번째 단계이며 이를 피하기 위해 작업을 저장하지 않아도 됩니다.

우리가 작동하는 다른 플랫폼으로 업그레이드할 때까지 지원이 있었다는 것을 알았다면 전적으로 동의합니다. 지금 당장은 .NET Core 세계에서 언제 필요한 비트를 사용할 수 있을지 알 수 없으므로 지금 시간 제한을 설정하고 해당 비트가 언제 올지 모르는 것은 약속에 베팅하는 것 입니다. 그것이 핵심 문제입니다. 포팅을 허용하는 지원되고 겹치는 릴리스가 있다면 기꺼이 투자하겠습니다. API가 존재하기 전에 지원이 중단된다면, 우리는 알 수 없는 양의 활주로와 함께 믿음의 격차를 뛰어 넘는 것입니다.

나는 그것이 오늘날 netcoreapp2.0 에서 작동하지 않는다는 것을 알기 때문에 DirectoryServices를 계속 참조하고 있습니다. 물론 같은 배에 떨어지는 다른 것들이 있을 것입니다. 일부 플랫폼에서는 몇 년 동안 ASP.NET Core + 전체 프레임워크 + 지원이 필요합니다. 1.x에서는 많은 이득을 얻지 못하고 실제로는 거의 얻지 못합니다. 성능은 이미 ~18ms 내에 페이지를 렌더링하고 전송 시간에 의해 왜소하기 때문에 멋진 인수가 아닙니다. 그러나 2.0은 꽤 좋은 항목을 제공합니다. Razor 페이지와 플러그인의 가능성은 이식하기에 매우 매력적입니다. 정당화될 만큼.

지금 당장은 지원을 받을 수 있는 유일한 버전(더 긴 지원이 있는 1.1.x는 이 스레드를 읽은 후 예상한 것입니다)은 이동할 가치가 없습니다. 오늘날 우리가 있는 곳까지 오기 위해서는 기본적으로 많은 시간과 노력이 필요할 것입니다. 2.x는 최소한 우리가 활용하고자 하는 적절한 개선 사항과 비트를 제공합니다. 이사 비용을 정당화하는 데 도움이 됩니다.

이미 ~18ms 안에 페이지를 렌더링하기 때문에 성능은 멋진 인수가 아닙니다.

사소한 OT에 대해 ~18ms @NickCraver 에서 페이지를 렌더링할 수 있는 방법을 알고 싶습니다. 굉장해

@daveaglick

나는 여전히 netstandard에서 ASP.NET Core 패키지를 사용하는 유스 케이스에 갇혀 있습니다. 이 문제까지 나는 netstandard가 라이브러리의 사실상의 목표라고 (아마도 잘못) 가정했습니다. 다시 말해, 라이브러리 작성자의 의도된 동작은 필요하고 설득력 있는 이유가 없는 한 netstandard를 대상으로 하는 것입니다. 이렇게 하면 Framework뿐만 아니라 Xamarin 및 UWP와 같은 다른 플랫폼과의 호환성도 보장됩니다. .NET Standard 2.0에 대한 작업은 다양한 런타임의 API 노출 영역을 생각할 필요가 없는 공통 대상으로 통합하려고 시도함으로써 이를 지원하는 것으로 보입니다.

여기에서 변경된 사항은 없습니다. 사실 우리가 다른 플랫폼에서 실행하고자 하는 많은 라이브러리 는 여전히 netstandard입니다. 위의 내용 중 일부를 다시 읽으면:

• Microsoft.Extensions.*(로깅, DI, 구성, FIleProviders 등)
• 엔터티 프레임워크
• SignalR 클라이언트(.NET Framework, Xamarin, UWP 등에서 실행해야 함).

.NET Standard는 어디에서나 실행되는 라이브러리를 작성하는 사실상의 방법입니다. 라이브러리 작성자는 가능한 한 가장 광범위한 플랫폼 도달 범위를 얻기 위해 netstandard를 목표로 삼아야 합니다. 도서관 저자는 도달 여부를 결정해야 합니다. 이것이 JSON.NET과 같은 라이브러리가 netstandard1.x 및 .NET Framework 2.0을 지원하는 이유입니다. 그들은 위에서 언급한 @JamesNK 처럼 일이 "정상 작동"하도록 하기 위해 더 많은 노력을 기울입니다.

일부 장소에서 netstandard에서 멀어지는 ASP.NET Core는 이러한 API가 UWP 애플리케이션을 위한 것이 아니며 우리는 확실히 (예를 들어) 테스트하지 않는다는 진술에 가깝습니다. 또한 .NET Core와 ASP.NET Core가 함께 버전이 지정되는 단일 제품이라는 것을 확고히 하려고 합니다(이름에 Core가 있기 때문에). .NET Core와 .NET Framework를 모두 지원하는 ASP.NET Core 1.x에서는 해당 메시지가 약간 흐릿하고 많은 사람들(특히 신규 개발자)에게 혼란을 야기했으며 라이브러리 격차 문제를 완화하기 위해 그렇게 했습니다.

이 문제는 ASP.NET Core에 ASP.NET 컨텍스트 외부에서 직접적으로 유용한 라이브러리가 많이 포함되어 있다는 점을 고려할 때 더욱 심화됩니다. 그것들이 고립되어 사용되도록 의도된 적이 있다고 가정하는 것은 잘못된 것일 수도 있지만, 그것들을 느슨하게 하는 것은 끔찍한 수치일 것입니다. 이를 사용하려는 라이브러리 작성자는 자체 대상을 .NET Core로 전환하거나 netstandard를 유지하고 이에 대한 느슨한 액세스를 결정해야 합니다. 나는 많은 사람들이 대안 플랫폼에 대해 더 세분화된 라이브러리 지원을 선택할 것이라고 생각합니다. 적어도 지원 라이브러리에 대해 서로 다른 플랫폼을 대상으로 하는 것이 너무 어렵다는 설명을 이해했다면.

나는 그것들이 여전히 넷스탠다드라고 생각합니다. 어떤 것이 그렇지 않습니까?

나는 이것이 시간이 지남에 따라 런타임 세트를 크게 분열시키는 결과를 가져오는지 궁금하지 않을 수 없습니다. 또한 Xamarin, Mono, UWP 등).

netstandard 가 발전할 것이라고 생각하지만 .NET Framework는 항상 새로운 API를 얻는 마지막 버전이 될 것입니다(Xamarin 및 Mono는 항목을 추가하는 데 매우 빠릅니다).

@snickler

그것이 내가 현재 하고 있는 일이다. 필요하지 않은 경우 .NET Framework에 대해 걱정할 필요가 없기를 바랍니다. 현재 Mono에는 System.DirectoryServices.AccountManagement 네임스페이스가 없기 때문에 내 Windows 시스템으로 제한됩니다. 같은 맥락에서 Windows의 제약 조건을 벗어나 System.DirectoryServices.AccountManagement를 사용할 수 있습니까? 그 작은 조각으로 인해 MVC 프로젝트와 Xamarin.iOS 앱을 로컬로 디버깅하는 동안 컴퓨터 간에 이동해야 합니다.

dotnet/corefx에서 이와 같은 문제를 제출해야 합니다. 당신의 의존성이 이식될 것이라고 가정하는 것은 (많이 사용되지 않는 한) 잘못된 일입니다.

@davidfowl 질문: ASP.NET Core 2.0을 사용하여 파일 -> 새 프로젝트를 만들고 AD에 대해 인증하고 싶습니다. 이것이 가능할까요? 이 기능이 없는 Microsoft 플랫폼 출시는 상상할 수 없습니다.

거기 있는 모든 것에 동의하지만 이 결정이 당신의 말에 어떤 영향을 미치는지 모르겠습니다. 나는 그 모든 것을 원한다

.NET v4.x에 대한 지원을 중단하면 널리 사용되는 마이그레이션 경로가 중단되고 .NET 에코시스템이 더욱 세분화되어 많은 개발자와 조직이 이를 채택할 수 없게 되어 더 넓은 커뮤니티 지식 풀과 ASP 투자가 줄어들 것입니다. 많은 .NET 개발자가 기존 ASP.NET v4.x 코드 기반을 무기한 지원해야 하기 때문에 .

.NET Core의 시장 점유율이 작을수록 라이브러리 유지 관리자가 지원하는 우선 순위가 낮고 일부는 다음으로 인해 더 이상 ASP.NET Core로 마이그레이션을 고려할 수 없는 조직에서 일하는 경우 지원하지 않을 가능성이 높습니다. 이것은 차례로 패키지에 따라 다른 사람에게 영향을 미치는 식입니다. 이는 모두 안정적인 플랫폼이 없고 장기적인 지원이 보장되지 않아 인기 있는 마이그레이션 경로가 중단되어 ASP.NET Core 채택에 대한 부담이 증가하는 부작용입니다.

여기 있는 모든 사람들이 .NET 에코시스템이 번성하기를 원한다고 생각하지만, 알려진 수량, 높은 호환성, 안정적인 LTS 릴리스를 사용할 수 있다는 것은 앞으로 몇 년 동안 해로운 영향을 미칠 실수입니다.

@davidfowl 감사합니다 - 귀하의 의견은 많은 도움이 됩니다. 이 변경의 일부로 대부분의/모든 지원 라이브러리가 netstandard 에서 벗어나고 있다는 것을 (분명히 부정확하게) 수집했습니다. 나는 꽤 많이 사용하고 다른 사람들도 알고 있으므로 그들이 사용하지 않는다는 소식을 듣는 것은 반가운 소식입니다.

@NickCraver 오늘 AD에 대해 어떤 종류의 인증을 사용하고 있습니까? OpenIdConnect, WsFed, NTLM, 기타?

@Tratcher AD 인증, DirectoryServices를 통해(그룹 구성원 자격 등을 쿼리해야 함 - 표준 비트)

@mythz 나는 그것이 합리적이라고 생각하고 ASP.NET Core 1.x의 지원 수명을 연장하면 대부분의 경우를 처리하기에 충분할 것이라고 생각합니다.

어느 시점에서 왜 이 결정을 내려야 하는지 알지만 너무 시기상조이며 다음과 같은 경우에 가장 행복할 것이라고 생각합니다.

• ASP.NET Core 2.x는 LTS이며 마지막으로 전체 프레임워크를 지원합니다(이미 미리 보기에 있었기 때문에 너무 멀리 가지 않았음). 올해 후반에 SignalR도 지원하므로 점프를 위한 대상 프레임워크가 됩니다. ASP.NET에서 ASP.NET Core로
• 3.x는 전체 프레임워크에 대한 지원을 중단하고 상위 종속성이 마이그레이션될 때 릴리스됨

단순히 ASP.NET Core 1.1에 대한 지원을 확장하는 것만으로는 해당 플랫폼이 많은 ASP.NET 마이그레이션의 대상이 될 만큼 충분히 성숙/채택되지 않았기 때문에 충분하지 않습니다(제 경우에는 SignalR이 차단기임).

lulz에 대해서만 EntityFramework 6(내가 작업한 ASP.NET Core 1.0 앱에서 많이 사용되는 것을 본 적이 있음)을 최신 preview2 .NET Core 야간 빌드와 함께 사용해 보았습니다. 뭔지 맞춰봐...

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.0</TargetFramework>
    <NetStandardImplicitPackageVersion>2.0.0-*</NetStandardImplicitPackageVersion>
    <RuntimeFrameworkVersion>2.0.0-preview2-002093-00</RuntimeFrameworkVersion>
    <PackageTargetFallback>net45;net461</PackageTargetFallback>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="EntityFramework" Version="6.1.3" />
    <PackageReference Include="System.Configuration.ConfigurationManager" Version="4.4.0-*" />
  </ItemGroup>

</Project>

전체 프레임워크용으로 설계 및 컴파일된 어셈블리가 .NET Core에서 완벽하게 작동하는 척하지 마십시오. 사소한 경우(hello world 앱 읽기)가 작동할 수 있지만 대부분의 경우 누락된 API 또는 작동하지 않는 API로 인해 차단됩니다. .

절대적으로 끔찍한 것은 런타임에 작동하지 않는다는 것을 깨닫게 될 것이라는 것입니다. 어떤 경우에는 전혀 명확하지 않을 수도 있습니다. 예를 들어 .NET Core의 SqlClient 는 TransactionScope 를 사용한 앰비언트 트랜잭션 참여나 분산 트랜잭션을 지원하지 않습니다. EF 6이 작동하도록 하는 방법을 찾아도 TransactionScope 전혀 효과적이지 않으며 DB 호출이 필요한 격리 수준을 사용하지 않습니다.

나는 이 움직임에 대한 나의 우려에 대해 여기에 2센트를 더할 필요가 있다고 생각합니다. WPF에서 개발된 새로운 영역 중 일부가 포함된 주로 Windows Forms인 데스크톱 응용 프로그램이 있습니다. 해당 응용 프로그램에 15년 이상의 노력이 있었고 WinForms에서 완전히 벗어나려면 몇 년이 걸릴 것입니다. 그렇지 않았으면 좋겠지만 그렇습니다. 우리는 새로운 웹 인터페이스와 기존 WinForms 응용 프로그램에서 비즈니스 및 데이터 액세스 계층을 사용할 수 있도록 코드베이스에 더 많은 모듈성을 구축하기 위해 노력해 왔습니다. 나는 새로운 웹 애플리케이션을 위해 곧 ASP.NET Core로 이동하려고 했지만 방금 언급했듯이 .NET v4.6.x를 대상으로 하는 기존 코드베이스의 대부분을 사용해야 합니다. System.Drawing 및 System.Security.Cryptography를 사용하고 있다는 것을 알고 있습니다. 또한 위에서 언급한 방식으로 TransactionScope를 많이 사용합니다.

MEF에 의존하지 않고도 웹 응용 프로그램의 영역을 별도의 어셈블리로 캡슐화하는 기능과 같은 ASP.NET Core의 이점을 모두 얻을 수 있기를 고대했습니다. 이 외에도 많은 이유가 있지만 그 중 하나가 정말 좋은 이유입니다. 그러나 응용 프로그램을 ASP.NET Core로 전환하면 WinForms를 사용하여 백엔드 코드의 이식성을 유지해야 하기 때문에 가까운 장래에 1.x에 고정될 것입니다. 저는 주로 웹 제품에 중점을 두었기 때문에 WMI 등과 같은 항목에 연결하는 위치를 말할 수 없으며 이식성 문제에 영향을 미치는지 여부를 알 수 있지만 우리는 코드베이스 내에 있습니다. 우리는 지금 정말 흥미로운 단계에 있으며 내가 마지막으로 해야 할 일은 우리 기능의 모든 웹 버전을 ASP.NET MVC 5에 개발하고 일부 버전으로 이식해야 하는 많은 새로운 레거시 코드를 축적하는 것입니다. 미래의 노력.

우리가 더 이상 WinForms를 사용하지 않는 경우에도 .NET Standard를 대상으로 하지 않도록 하는 많은 용도가 있을 것이라고 확신합니다. 우리는 Microsoft 파트너이며 여러 가지 방법으로 우리 제품에 대해 Microsoft와 직접 협력하므로 여기서 우리가 하는 일에 대해 너무 자세히 설명하고 싶지는 않지만 @ 와 좀 더 개인적인 토론을 하고 싶습니다. @davidfowl 이 하는 일에 대한 자세한 정보가 필요하면 저는 또한 MS Build에 참석할 예정이며 참석하실 경우 그곳에서 만나 이야기를 나눌 수 있습니다.

나는 당신이 이러한 종류의 도전에 당신의 스택을 사용하는 회사를 고려하지 않았다고 생각합니다. 그러나 완전한 면책 조항: 저는 앞서 언급한 이식성 분석기를 실행하여 코드베이스 내에서 이식성을 유지해야 하기 때문에 우리가 실제로 막힌 부분을 확인하려고 합니다. 해당 검사에 실패한 .NET Framework API 목록을 기꺼이 제공해 드리겠습니다.

무아하하. 웃어야 할지 울어야 할지 모르겠다...

다음은 작동하지 않는 사소한 23줄 EF 6 앱에 대해 ApiPort 분석 도구에서 생성한 보고서입니다.

크로스 컴파일은 고객 및 제품 요구 사항과 균형을 이루어야 하는 오버헤드입니다. 이것이 우리가 이 피드백을 받고자 하는 이유입니다. 그러면 ASP.NET Core가 앞으로 계속 발전함에 따라 고객과 우리 모두의 환경이 어떤 모습일지 보다 구체적으로 정의할 수 있습니다.

이 문제가 열리기 전에 피드백 프로세스가 있었습니까?

우리는 모두 1.1에 대한 시간 프레임 및 지원에 대해 이야기하고 있지만 ASP.NET Core가 전체 프레임워크를 아예 삭제할 것이라는 사실은 저에게 엄청난 놀라움으로 다가왔습니다.

내가 이해한 것은 핵심 프레임워크가 크로스 플랫폼 플레이, 즉 Windows와 연결되지 않은 전체 프레임워크의 하위 집합으로 구성된 새로운 프레임워크라는 것입니다. 2.0 릴리스는 대부분의 API를 다시 얻을 수 있는 곳에서 우리 모두가 기다려온 릴리스였습니다.

ASP.NET Core는 프레임워크 API의 작은 표면 영역에 의존하여 모든 곳에서 실행할 수 있는 새로운 웹 프레임워크인 이 새로운 프레임워크의 개밥이었습니다.

핵심 프레임워크가 전체 프레임워크와 거의 동등해지면 모든 새 API가 netstandard에 추가되어 결국 두 프레임워크에 모두 포함될 것이라고 예상했습니다. 우리는 모두 netstandard를 목표로 하기 시작할 것이고 모든 것이 무지개와 유니콘이 될 것입니다.

이제 ASP.NET을 찾으려면 dogfood netstandard도 아니고 프레임워크별로 진행됩니다. eh :/

@로하츠

단순히 ASP.NET Core 1.1에 대한 지원을 확장하는 것만으로는 해당 플랫폼이 많은 ASP.NET 마이그레이션의 대상이 될 만큼 충분히 성숙/채택되지 않았기 때문에 충분하지 않습니다(제 경우에는 SignalR이 차단기임).

SignalR이 ASP.NET Core 1.x에서 작동했다면? 당신이 필요로 하는 플랫폼에 대해 미성숙한 다른 것은 무엇입니까?

@millman82 공유해주셔서 감사합니다. .NET Framework 지원이 잠시 중단되기 전의 버전에서 멈춘 것처럼 들립니다. 따라서 여기에서 2.x 호환을 유지하고 3.x에서 삭제하는 제안 중 일부는 귀하에게 적합하지 않을 수도 있습니다. ASP.NET Core 1.x를 계속 사용하지 않는 이유는 무엇입니까? 당신의 항구에 필요한 것이 무엇입니까? 아니면 @NickCraver 와 같은 관심사입니까(2.x가 이를 지원하지 않으면 내기를 하는 것에 대해 긴장하게 됩니다).

@jkells

핵심 프레임워크가 전체 프레임워크와 거의 동등해지면 모든 새 API가 netstandard에 추가되어 결국 두 프레임워크에 모두 포함될 것이라고 예상했습니다. 우리는 모두 netstandard를 목표로 하기 시작할 것이고 모든 것이 무지개와 유니콘이 될 것입니다.

그것은 멀리 가져 오는 것이 아니며 시간 구성 요소가 누락되었습니다. 결국 각자의 일정에 따라 배송되는 모든 프레임워크에 포함됩니다.

이제 ASP.NET을 찾으려면 dogfood netstandard도 아니고 프레임워크별로 진행됩니다. eh :/

이 스레드에서 여러 번 언급했듯이 그 중 일부는 여전히 netstandard를 대상으로 합니다.

ASP.NET Core 1.x를 계속 사용하지 않는 이유는 무엇입니까?

당신은 할 수 없습니다 - 2.0이 떨어질 때부터 1년 동안 지원이 중단됩니다(2.0이 다음 LTS라고 가정).

@davidfowl 확실히 그 부분이 상당합니다. 우리는 또한 현재 웹 애플리케이션에서 OData 및 SignalR을 사용하며, 이전하기 전에 ASP.NET Core에 있어야 합니다. 그러나 내가 원하지 않는 한 가지는 ASP.NET Core 1.x에 대한 지원이 중단되고 현재 지원되지 않는 사용 중인 프레임워크 부분에 마이그레이션 경로가 없을 때 림보에 갇히는 것입니다. 저는 ASP.NET Core가 ASP.NET 도매를 대체할 것으로 예상합니다. 그것은 길 아래 어딘가에 있을지도 모르지만 그것은 오고 있습니다. 이제 ASP.NET MVC 5에서 UI를 다시 작성하고 싶지 않다는 것을 알고 있습니다(지금은 몇 가지가 있지만 크기가 작기 때문에 이동하기 쉽습니다). 몇 년 후에 ASP.NET Core에서 다시 작성합니다. ASP.NET의 수명이 다하면.

지금 Core 1.x를 대상으로 하는 경우 중간에 확장되는 경우 ASP.NET Core 1.x의 EOL이 도착할 때 마이그레이션 경로가 존재하지 않으면 잠재적으로 심하게 화상을 입도록 설정할 수 있습니다. 우리는 아마도 마이크로 서비스로 그 중 일부를 탐색할 수 있지만 물론 자체적인 우려가 있습니다.

@ctolkien

당신은 할 수 없습니다 - 2.0이 떨어질 때부터 1년 동안 지원이 중단됩니다(2.0이 다음 LTS라고 가정).

2.0이 떨어질 때 지원에서 벗어나지 않는다고 잠시 가정하십시오. 충분하지 않습니까?

그러나 내가 원하지 않는 한 가지는 ASP.NET Core 1.x에 대한 지원이 중단되고 현재 지원되지 않는 사용 중인 프레임워크 부분에 마이그레이션 경로가 없을 때 림보에 갇히는 것입니다.

해당 문장에서 1.x를 2.x로 바꿉니다. 1년 안에 모든 종속성이 이식될 것이라고 생각하십니까?

해당 문장에서 1.x를 2.x로 바꿉니다. 1년 안에 모든 종속성이 이식될 것이라고 생각하십니까?

그러나 전혀 그렇지는 않지만 더 이상 .NET Full을 대상으로 할 수 없을 때 그렇게 할 것으로 예상합니다. 왜 그것을 밀어붙이려는지 이해하지만 누락된 종속성이 이식되지 않았기 때문에 회사에서 새 버전으로 전환할 수단 없이 지원이 중단되는 무언가를 채택할 것으로 기대할 수는 없습니다.

누락된 종속성이 이식되지 않았기 때문에 회사에서 새 버전으로 전환할 수단 없이 지원되지 않는 것을 채택할 것이라고 기대할 수는 없습니다.

왜 지원에서 떨어질까요? 내 가상의 세계에서는 .NET Framework에서 ASP.NET Core 1.x를 더 오래 지원할 것입니다.

왜 지원에서 떨어질까요? 내 가상의 세계에서는 .NET Framework에서 ASP.NET Core 1.x를 더 오래 지원할 것입니다.

내 질문은 얼마나 더 오래입니까? 또한 팀은 SignalR 및 OData와 같은 필수 종속성을 ASP.NET Core 1.x로 가져오고 누락된 모든 종속성이 실제로 이식될 때까지 지원을 유지할 만큼 충분히 큰 팀입니까? 지금 .NET 전체 지원을 중단하려는 이유에 대해 이전에 만든 주장에 반대하는 것 같습니다. 솔직한 질문...

내 질문은 얼마나 더 오래입니까? 또한 팀은 SignalR 및 OData와 같은 필수 종속성을 ASP.NET Core 1.x로 가져오고 누락된 모든 종속성이 실제로 이식될 때까지 지원을 유지할 만큼 충분히 큰 팀입니까? 지금 .NET 전체 지원을 중단하려는 이유에 대해 일찍이 제기한 주장에 반대하는 것 같습니다. 솔직한 질문...

난 임의의 숫자를 버릴거야, 3 년. ASP.NET 팀은 Odata 통합을 소유하고 있지 않고 odata 팀이 소유하고 있으므로 제가 답변을 드릴 수 없습니다. SignalR의 경우 ASP.NET Core 1.x를 대상으로 할 수 있다고 생각합니다.

내가 보는 문제는 각 사람이 서로 다른 "누락된 종속성" 집합을 가지고 있어 모든 사람에 대한 .NET Framework 지원을 중단해도 "괜찮은" 시기에 대해 추론하는 것이 불가능하다는 것입니다. 또한 이러한 종속성 중 일부는 CSOM과 같이 이식되지 않을 수 있습니다.
물론 1.x 기차에 있으면 버그 수정과 사소한 기능을 얻을 수 있지만 대부분의 작업은 최신 주요 ASP.NET Core에서 계속 발생합니다.

또한 이 중 어느 것도 ASP.NET Core 1.x와 함께 .NET Core 2.0 또는 .NET Standard 2.0을 사용하는 것을 방해하지 않습니다. 이 스레드 상수는 ASP.NET Core와 .NET Core를 통합하기 때문에 모든 사람이 이 사실을 알고 있는지 확인하고 싶습니다(.NET Core만 대상으로 하려는 이유 중 하나임).

내가 보는 문제는 각 사람이 서로 다른 "누락된 종속성" 집합을 가지고 있어 모든 사람에 대한 .NET Framework 지원을 중단해도 "괜찮은" 시기에 대해 추론하는 것이 불가능하다는 것입니다.

목록이 무엇인지 알아보기 위해 생태계를 참여시키십시오(아니요, 이 문제는 그것을 할 장소가 아닙니다). Microsoft 소유 종속성인 경우 이식합니다. 그렇지 않은 경우 소유자에게 연락하여 계획을 알리고 마이그레이션 가이드를 지원합니다(아무것도 하지 않는 경우 Microsoft의 잘못이 아님). 이 과정을 거치는 시간에 ASP.net core 1.x를 지원합니다. 나는 많은 사람들을 화나게 하지 않고 당신의 목표를 달성하는 다른 방법을 볼 수 없습니다. 이것은 올바른 일을 하기 위해 높은 수준의 주의와 주의가 필요한 큰 제안입니다.

개인적으로 .NET Framework 대 .NET Standard 대 .NET Core에 대해 훨씬 더 많은 혼란이 있다고 생각합니다. .NET Framework를 대상으로 할 수 있음을 보았을 때 "하지만 이것은 ASP.NET Core이므로 .NET Framework를 사용할 수 있는 이유"라고 말한 적이 없습니다. 위의 차이점은 대부분의 고객 기반에서 훨씬 더 혼란스럽습니다. 나는 ASP.NET Core가 하는 모든 것을 사랑합니다. 또한 플랫폼 독립성에 관한 .NET의 방향을 좋아합니다. 혼란의 영역이 잘못 기술되어 있다고 생각합니다. 사용자 기반의 대부분은 수행 중인 작업의 특성과 프레임워크 내에서 대상으로 하는 API로 인해 이식할 수 없는 코드가 어느 정도 있을 것입니다.

내 기본 설정은 .NET Core 및 .NET Standard 및 .NET Framework 내에서 API 패리티를 위해 작업하는 것입니다. 또한 사람들이 목표로 삼아야 할 대상을 파악하십시오. 앞서 말했듯이 약간 다른 방식으로 .NET Standard는 반창고처럼 느껴집니다. 결국 .NET Core가 유일한 "프레임워크" 옵션이 될 것으로 예상하고 그런 일이 발생하면 .NET Framework 및 .NET Standard가 중단됩니다. 저와 저는 발표 이후로 목소리를 낸 대부분의 사람들과 함께 ASP.NET Core 측에서 수행하는 작업의 이점을 계속해서 누릴 수 있기를 원합니다. 제거됩니다.

필자가 WMI와 같은 것에 의존하는 경우와 같이 예외적으로 간주되는 경우는 팀이 생각하는 것만큼 예외적이지 않다고 생각합니다. 다시 말하지만, 나는 조사를 하고 무엇이 빠져 있는지 볼 것이고(비록 이전에 잘못된 이식성 결과를 제공한 게시물이 정확성에 대해 약간 우려했지만) 더 사적인 매체에서 기꺼이 당신에게 보고할 것입니다.

결론적으로, 우리는 이것을 사용하기를 원하기 때문에 이것에 열정적입니다.

개인적으로 .NET Framework 대 .NET Standard 대 .NET Core에 대해 훨씬 더 많은 혼란이 있다고 생각합니다. .NET Framework를 대상으로 할 수 있음을 보았을 때 "하지만 이것은 ASP.NET Core이므로 .NET Framework를 사용할 수 있는 이유"라고 말한 적이 없습니다. 위의 차이점은 대부분의 고객 기반에서 훨씬 더 혼란스럽습니다. 나는 ASP.NET Core가 하는 모든 것을 사랑합니다. 또한 플랫폼 독립성에 관한 .NET의 방향을 좋아합니다. 혼란의 영역이 잘못 기술되어 있다고 생각합니다. 사용자 기반의 대부분은 수행 중인 작업의 특성과 프레임워크 내에서 대상으로 하는 API로 인해 이식할 수 없는 코드가 어느 정도 있을 것입니다.

우리는 많은 고객을 보유하고 있으며 평생 .NET을 본 적이 없는 새로운 개발자도 있습니다. 그것이 우리가 Microsoft로서 하려고 하는 것이기 때문에 우리는 모든 사람을 수용해야 합니다. .NET Framework에서 실행되는 사람들은 그것이 작동한다는 것을 알고, 사랑하고 이해하므로 ASP.NET Core가 .NET Framework에서 실행된다는 것을 확실히 이해해야 합니다. go 또는 node (이 시점에서 거의 0개의 레거시가 있음)와 같은 것입니다.

내 기본 설정은 .NET Core 및 .NET Standard 및 .NET Framework 내에서 API 패리티를 위해 작업하는 것입니다. 또한 사람들이 목표로 삼아야 할 대상을 파악하십시오. 앞서 말했듯이 약간 다른 방식으로 .NET Standard는 반창고처럼 느껴집니다. 결국 .NET Core가 유일한 "프레임워크" 옵션이 될 것으로 예상하고 그런 일이 발생하면 .NET Framework 및 .NET Standard가 중단됩니다. 저와 저는 발표 이후로 목소리를 낸 대부분의 사람들과 함께 ASP.NET Core 측에서 수행하는 작업의 이점을 계속해서 누릴 수 있기를 원합니다. 제거됩니다.

이러한 일은 모두 병렬로 발생합니다. ASP.NET Core는 "모든 것"이 .NET Framework에서 .NET Core로 이식될 때까지 기능 작업을 중지하지 않습니다. ASP.NET은 동일한 상자의 일부로 제공되므로 .NET Core에서 사용할 수 있는 API를 계속 혁신하고 활용할 것입니다.

이 스레드에 대한 몇 가지 트렌드 아이디어는 다음과 같습니다.

• 나는 당신이 .NET Framework를 영원히 지원하기를 바랍니다.
• 내 응용 프로그램에 필요한 종속성이 이식될 때까지 .NET Framework를 지원하고 싶습니다.
• 1년만 더 있으면 .NET Framework 지원(ASP.NET Core 3.x)을 중단하기에 충분한 시간입니다.

우리가 발표를 작성하지 않았지만(이는 우리의 잘못임) 발표가 오고 있다는 사실도 있습니다(약속합니다. 주말을 탓합니다).

나는 또한 여기 대부분의 사람들에게 API 패리티가 어떻게 생겼는지 모릅니다. 제 추측으로는 사람들마다 다를 것입니다. .NET Framework는 Windows에 연결된 15년 이상 된 견고하고 안정적인 엔터프라이즈 기술입니다.
.NET Core는 최신 경량 크로스 플랫폼 마이크로 서비스를 작성하도록 만들어졌으며 라이브러리 이식이 더 쉬울 수 있도록 더 호환성이 있도록 천천히 진화해 왔습니다. 즉, 호환성 측면에서 .NET Framework에 접근하는 것이 무엇을 의미하는지 또는 그것이 목표인지도 모르겠습니다(원래는 아니었음). 어느 시점에서 .NET Framework 위에서 ASP.NET Core를 사용할 수 없으며 .NET Core와 호환되지 않는 다시 작성할 수 없는 일부 종속성이 있습니다. 애플리케이션은 ASP.NET Core를 염두에 두고 설계할 때(가까운 미래에) 이를 고려해야 합니다.

내가 작업하는 프로젝트와 관련하여 1.1에 대한 훨씬 더 긴 기간의 지원은 적절한 완화가 될 것입니다. 1년 안에 netfx 의존성을 없앨 수 있을 것 같지는 않지만 당신이 밀짚맨으로 제안한 +3년으로 훨씬 더 가능성이 높습니다. 모든 것이 2.0 레벨에서 먼저 통합되는 릴리스가 있으면 정말 좋을 것입니다. 모든 것이 더 쉽게 이식되어야 하는 지점입니다! 나는 한 조직에 대해서만 말하고 있지만 "2.0은 LTS 릴리스가 될 것입니다. 3.0은 netfx를 삭제할 것입니다"는 기본적으로 FUD의 원인이 아니라 평소와 같이 우리에게 비즈니스가 될 것입니다.

또한 @PureKrome 이 이 참여에 대한 감사에 대해 말한 것을 되풀이하고 싶습니다. 이는 매우 유익한 토론이었습니다.

패리티 주제에 대해 - 나는 이전에 .net 코어가 .net 프레임워크 수준의 호환성에 접근 하지 않을 것이라고 가정했지만 asp .net 코어가 두 가지 모두를 계속 지원할 것이기 때문에 괜찮습니다.

커뮤니티로서 우리는 기본적으로 asp.net core를 사용하기 위해 .net core를 사용하는 것이지 그 자체의 장점을 위해서가 아니라고 생각합니다. 당신이 말했듯이 그것들은 하나의 제품이고, 나는 core clr을 선택한다면 장점과 단점이 있는 그 제품의 선택적인 부분이라고 생각했을 것입니다.

하룻밤 자고 나면 -

나는 개인적으로 오래된 .net 프레임워크를 뒤로하고 최신 런타임을 위한 최상의 웹 프레임워크를 작성하는 것이 좋은 생각이라고 생각합니다.

하지만 확실히 위험하고 여기에서 일부 고객을 잃을 수도 있다는 것을 알고 있습니다. 변경).

..그리고 네 - 이것에 대한 의사 소통은 (평소와 같이) 개선할 수 있는 것이었습니다(독일어에 대한 이 문장의 가장 정중한 버전) ;)

+1

나는 개인적으로 오래된 .net 프레임워크를 뒤로하고 최신 런타임을 위한 최상의 웹 프레임워크를 작성하는 것이 좋은 생각이라고 생각합니다.

나는 강력하게 동의합니다. 내 희망은 이것이 점진적인 변화가 되었기를 바랍니다. 예를 들어 Kestrel이 먼저 perf(http.sys 기반 호스팅 남아 있음)에 대한 지원을 중단한 다음, netstandard2.0에 대한 이식/호환성 테스트 노력이 시작되는 동안 API 및 기능 개선을 위해 mvc/*를 따릅니다.

훌륭한. 이 경우 Microsoft가 고객에게 적절한 2.x 마이그레이션 경로(예: SignalR)를 제공할 때까지 1.x가 지원되도록 보장하는 한(모든 종류의 버그 수정 및 >운영 지원), 나는 >편안하게 입찰하고 있습니다. asp.net core 2가 필요할 때까지.

+1

.NET Core로만 이식할 수 있습니다(전체 프레임워크에서 ASP.NET Core를 개발하는 동안 예제로 이식되지 않을 몇 가지 새로운 종속성을 사용했을 수 있음).

전적으로 동의합니다.
지금은 좋은 결정이라고 생각합니다. 이상적인 시나리오에서는 1년 이상의 지원이 필요하다고 생각합니다. 커뮤니티의 신뢰를 위해 2-3년과 포팅될 정보에 대한 정보는 모릅니다.
.net 461 지원이 없습니다.

@dasMulli

나는 강력하게 동의합니다. 내 희망은 이것이 점진적인 변화가 되었기를 바랍니다. 예를 들어 Kestrel이 먼저 perf(http.sys 기반 호스팅 남아 있음)에 대한 지원을 중단한 다음, netstandard2.0에 대한 이식/호환성 테스트 노력이 시작되는 동안 API 및 기능 개선을 위해 mvc/*를 따릅니다.

우리는 .NET Framework에 대한 성능 테스트도 실행하지 않습니다... .NET Core 및 .NET Standard에 대한 이식 테스트 및 개선 사항은 어쨌든 이루어지므로 IMO는 .NET Framework 지원이 중단되는지 여부와 관련이 없습니다. 그것이 유일한 목표이기 때문에 우리 는 그러한 시나리오에 레이저 초점을 맞춥니다.

@gulbanana

모든 것이 2.0 레벨에서 먼저 통합되는 릴리스가 있으면 정말 좋을 것입니다. 모든 것이 더 쉽게 이식되어야 하는 지점입니다! 나는 한 조직에 대해서만 말하고 있지만 "2.0은 LTS 릴리스가 될 것입니다. 3.0은 netfx를 삭제할 것입니다"는 기본적으로 FUD의 원인이 아니라 평소와 같이 우리에게 비즈니스가 될 것입니다.

ASP.NET Core 2.0이 필요한 이유는 무엇입니까(.NET Standard 및 .NET Core 2.0은 잊음)?

asp.net core 2.0의 기능은 특별히 필요하지 않습니다. 2.0 웨이브와 함께 제공되는 더 간단한 빌드 프로세스와 상호 운용성을 갖고 싶습니다. netcoreapp2.0에서 실행되는 경우 asp.net 코어 1.1이 netstandard2.0 라이브러리를 사용할 수 있습니까? 아무도 테스트하거나 관심을 기울이지 않는 것이 아니라 '표준' 및 지원되는 시나리오로 간주됩니까?

기본적으로 1.1이 LTS가 된다면 '글쎄, 당신은 2.0 API를 사용하여 이것을 할 수 있다'와 함께 지금부터 18개월 후에 종료되는 문제에 대해 걱정합니다.

asp.net core 2.0의 기능은 특별히 필요하지 않습니다. 2.0 웨이브와 함께 제공되는 더 간단한 빌드 프로세스와 상호 운용성을 갖고 싶습니다. netcoreapp2.0에서 실행되는 경우 asp.net 코어 1.1이 netstandard2.0 라이브러리를 사용할 수 있습니까? 아무도 테스트하거나 관심을 기울이지 않는 것이 아니라 '표준' 및 지원되는 시나리오로 간주됩니까?

물론 효과가 있을 것입니다. 내가 내내 말했듯이 3가지가 오늘 완전히 분리되었습니다. 다음은 .NET Standard 2.0 패키지로 이식된 System.Configuration API 버전을 사용하여 .NET Core 2.0에서 ASP.NET Core 1.1을 실행하는 샘플 프로젝트입니다.

https://github.com/davidfowl/AspNetCore1OnNetCore2

.NET Core와 .NET Framework 사이에 자동 interop 계층이 있는 경우(런타임에 예외를 던질 수 있는 현재 계층이 아니라 자체적으로 만든 내부 WebAPI 호출이 아닌) 이를 수락하는 것이 더 행복합니다. 일종의 래퍼 ("WowNET"?) 4.6 종속 코드를 별도의 .dll에 유지해야 하지만 성능을 희생시키면서 레거시를 실행할 수 있습니다(LOB 앱의 경우 주요 관심사가 아님). 이것이 기술적으로 가능하다고 생각하십니까?

또한 이 변경이 전체 프레임워크 자체가 수명 종료에 가까워지고 대부분의 API가 .NET Standard로 이동되면 레거시 구성 요소가 되는 것 외에 다른 중요한 역할을 수행하지 않을 것임을 의미하는지 궁금합니다.

기본적으로 1.1이 LTS가 된다면 '글쎄, 당신은 2.0 API를 사용하여 이것을 할 수 있다'와 함께 지금부터 18개월 후에 종료되는 문제에 대해 걱정합니다.

그게 항상 걱정입니다. 대답은 항상 "그것은 의존한다"이다. 버그 수정은 그에 따라 가중치가 부여되며 큰 기능은 해당 버킷에 더 자주 포함될 것입니다.

@로하츠

.NET Core와 .NET Framework 사이에 자동 interop 계층이 있는 경우(런타임에 예외를 던질 수 있는 현재 계층이 아니라 자체적으로 만든 내부 WebAPI 호출이 아닌) 이를 수락하는 것이 더 행복합니다. 일종의 래퍼 ("WowNET"?) 4.6 종속 코드를 별도의 .dll에 유지해야 하지만 성능을 희생시키면서 레거시를 실행할 수 있습니다(LOB 앱의 경우 주요 관심사가 아님). 이것이 기술적으로 가능하다고 생각하십니까?

https://docs.microsoft.com/en-us/windows/uwp/porting/desktop-to-uwp-root 와 비슷하지만 .NET Core 및 .NET Framework용입니다. 우리는 ASP.NET이 IIS에서 coreclr을 부스트랩하는 데 사용된 .NET Framework shim인 Helios를 지원할 때 매우 유사한 작업을 수행했습니다. COM과 string[] args를 통해 Main 메서드에 전달하는 구조가 혼합되어 있지만 작동하도록 하는 해킹은 꽤 추악했습니다. 모두 기술적으로 가능하지만. 동일한 런타임이 아니며 개체를 앞뒤로 전달할 수 없기 때문에 어떤 종류의 충실도를 기대하는지 잘 모르겠습니다. 또한 동일한 프로세스에서 2개의 GC, 2개의 Jits 톤 더 많은 dll을 실행하고 있으며 프로세스 외부에서 무언가를 수행하여 얻는 것이 무엇인지 잘 모르겠습니다.

또한 이 변경이 전체 프레임워크 자체가 수명 종료에 가까워지고 대부분의 API가 .NET Standard로 이동되면 레거시 구성 요소가 되는 것 외에 다른 중요한 역할을 수행하지 않을 것임을 의미하는지 궁금합니다.

이기는 커녕. .NET Framework는 Windows 구성 요소이므로 Windows의 속도로 발전하고 제공됩니다. 우리는 .NET Framework 4.7(https://blogs.msdn.microsoft.com/dotnet/2017/04/05/announcing-the-net-framework-4-7/)과 많은 새로운 기능을 출시했습니다. 사실 .NET Core는 다른 것과 연결되어 있지 않기 때문에 더 빨리 제공될 수 있고 제공될 것이므로 API, 런타임 기능 등이 먼저 표시됩니다. 이것이 결국 .NET Standard 및 .NET Framework에 적용되지 않는다는 의미는 아닙니다. 도착하는 데 시간이 더 오래 걸릴 뿐입니다. .NET Framework가 제자리에서 업데이트된다는 사실 때문에 변경 사항을 포팅할 때 매우 신중합니다. 업데이트가 자동으로 10억 대의 머신으로 푸시될 때 변경 사항이 있으면 모든 애플리케이션이 중단될 수 있습니다 😉 . .NET Core를 사용하면 프레임워크가 나란히 있으므로 애플리케이션이 최신 기능이나 수정 사항을 얻으려면 최신 버전을 선택해야 합니다. 거기에는 훨씬 더 많은 자유가 있습니다.

현재 ASP.NET Core 1.x에 있는 net4x 라이브러리와 비교하면 2.0: EntityFramework 6에서는 작동하지 않습니다. EFCore에는 우리가 사용하는 누락된 기능이 많이 있습니다(예: 가로채기/수명 주기 후크). 그래서 우리는 잠시 동안 EF6에 갇혀 있습니다.

그리고 @PinpointTownes 의 게시물에 따르면 EF6은 현재(개발 중인) ASP.NET Core 2.x 버전에서 작동하지 않습니다.

@nphmuller 그러면 더 많은 종속성이 이동할 때까지 ASP.NET Core 1.x를 계속 사용하게 됩니다(EF Core에 필요한 항목의 수와 상태가 무엇인지 모르겠습니다).

@davidfowl 물론입니다. 그 시간 동안 ASP.NET Core 1.x의 지원 기간이 지나지 않으면.
주요 기능은 가로채기(수명 주기 후크)입니다. 다른 누락된 기능은 더 쉽게 해결할 수 있습니다. 가로채기는 백로그에 있지만 릴리스와 관련이 없습니다. 그리고 내 직감은 그것이 한동안 구현되지 않을 것이라고 말합니다.

@gulbanana : 커뮤니티로서 우리는 기본적으로 asp.net core를 사용하기 위해 .net core를 사용한다고 생각합니다. 그 자체의 장점은 아닙니다.

자신을 위해 말하십시오. .NET Core의 주요 이점은 서버의 Windows에서 벗어나는 것입니다.

그리고 내 생각에, 더러운 Mac 소유 히피들. 😝

@bradwilson 그리고, 내 생각에, 더러운 Mac 소유 히피들.

스스로 말하세요, 우리 중 일부는 히피가 아닙니다 ;P

하지만 예, Windows(또는 실제로 IIS 및 http.sys)를 이스케이프하는 것은 xcopy 배포, perf 등과 함께 .NET Core에서 원하는 것입니다.

별도의 서비스에서 이전 코드를 격리하거나 ASP.NET Core로 이식하면 새롭고 반짝이는 이유가 아닌 다른 이유가 있습니다.

@PinpointTownes 는 참조 오류입니다. https://github.com/aspnet/Home/issues/2022#issuecomment -299810945에 따라 System.Configuration을 참조하면 어떻게 됩니까? EF6은 모든 것이 ye'olde GAC/Full Framework 번들에 있기 때문에 종속성이 없다고 말합니다.

@benaadams 및 @PinpointTownes 가 실패하는 이유는 System.Configuration.ConfigurationManager가 .NET Framework에서 예상하는 DLL 이름이 아니기 때문입니다. System.Configuration의 포트가 유효한지 확실하지 않습니다.

      "system.configuration.configurationmanager/4.4.0-preview2-25308-01": {
        "dependencies": {
          "System.Security.Cryptography.ProtectedData": "4.4.0-preview2-25308-01"
        },
        "runtime": {
          "lib/netstandard2.0/System.Configuration.ConfigurationManager.dll": {}
        },
        "compile": {
          "ref/netstandard2.0/System.Configuration.ConfigurationManager.dll": {}
        }

예, Windows가 아닌 서버를 실행할 수 있다는 것은 훌륭하고 큰 장점입니다. 하지만 asp.net 코어가 없으면 서버 에서 무엇을 실행하시겠습니까? .net 코어용 Nancy도 kestrel, UseOwin() 등을 통해 asp.net 코어에 의존합니다.

ASP.NET Core를 사용하지 않는 여러 마이크로서비스를 만들었습니다. 작업을 수행하기 위해 대기열을 폴링하는 작업자 프로세스와 같은 것입니다.

이것은 공정하지 않습니다. 우리는 로드맵을 따르고 있으며 이전에는 그것에 대해 아무 말도 하지 않았습니다!!
이전에 말했다면 .NET 4.x 라이브러리가 필요하기 때문에 프로젝트에서 ASP.NET Core를 사용하지 않을 것입니다.
우리의 계획에는 새로운 기능이 필요하기 때문에 프로젝트를 ASP.NET Core 2로 업데이트하는 것이 포함됩니다.
.NET 4.x도 대상으로 하려면 ASP.NET Core 2가 필요합니다. 가능하지 않은 경우 ASP.NET Core 1.x의 지원은 어떻습니까? 모든 새로운 기능을 추가할 계획입니까 아니면 버그만 수정할 계획입니까?

우리의 계획에는 새로운 기능이 필요하기 때문에 프로젝트를 ASP.NET Core 2로 업데이트하는 것이 포함됩니다.

어느 것?

@PinpointTownes 는 참조 오류입니다. #2022(코멘트)에 따라 System.Configuration을 참조하면 어떻게 됩니까?

<Reference Include="System.Configuration" /> 를 추가하면 GAC에서 해결할 수 없는 것처럼 보이기 때문에 효과가 없습니다(즉, 동일한 예외가 발생함).

System.Configuration의 포트가 유효한지 확실하지 않습니다.

따라서 공식적인 결론은 ... System.Configuration 를 사용하는 경우 .NET Core에서 .NET Framework 4.x용으로 작성된 라이브러리를 사용할 수 없다는 것입니다.

@PinpointTownes System.Configuration 버전이 배송되고 있는지조차 확신할 수 없습니다(패키지에 있는 버전). 아마도 그럴 수도 있고 아닐 수도 있습니다(corefx에서 시작하는 토론입니다). 나는 단지 당신의 샘플이 왜 그렇게 망가졌는지 말해주고 있을 뿐입니다.

첨가 GAC에서 해결할 수 없는 것처럼 보이기 때문에 효과가 없습니다(즉, 동일한 예외가 발생함).

AFAIK, SDK 프로젝트의 GAC 참조에 대한 기본 지원이 없습니다. 활성화 방법은 https://github.com/dotnet/sdk/issues/987#issuecomment -286307697을 참조하세요.

따라서 공식적인 결론은... System.Configuration을 사용하는 경우 .NET Core에서 .NET Framework 4.x용으로 작성된 라이브러리를 사용할 수 없다는 것입니다.

제 결론은 위에서 제공한 샘플을 사용하여 CoreFX에 대한 문제를 열어야 한다는 것입니다.

@davidfowl 답변 감사합니다
EF Core의 일부 필요한 기능 및 도우미는 특히 매핑 데이터(자체 포함 형식 매핑)를 위해 2.0에서 계획됩니다.
어쨌든 나는 ASP.NET Core 1.x의 로드맵에 대한 명확한 아이디어가 필요합니다. 우리 팀은 혼란스럽고 걱정하고 있습니다.

개인적으로 고군분투하는 한 가지는 "안정된 플랫폼"과 "새로운 기능"입니다. 한편으로 우리는 플랫폼이 안정적이고 신뢰할 수 있고 호환되기를 원하지만 다른 한편으로는 2.x 기능이 없기 때문에 아무도 1.x에 머물기를 원하지 않습니다. ASP.NET Core 2.x에는 그 방향으로 사람들을 끌어들이는 매우 매력적인 기능이 있습니까? 아니면 1.x에서보다 더 많은 기능을 가지고 있다는 사실입니까(새롭고 빛나기 때문에)?

@davidfowl 나는 signlarR이 그러한 기능 중 하나라고 생각합니다. 적어도 이전 프로젝트에는 있었을 것입니다. 그러나 사람들이 코어로 전환할 준비가 될 때까지 asp.net 1.1에서 실행할 수 있다고 확신한다면 1.1(2018?)에 대한 지원 기간이 비교적 짧기 때문에 많은 우려가 있다고 생각합니다. 또한 사람들을 조금 진정시킬 패치를 위해 덮여 있습니다.

나는 또한 .net core 2.0에서 asp.net core 1.1 지원을 더 강조할 가치가 있다고 생각합니다. 사람들에게 좋은 마이그레이션 경로를 제공합니다. asp.net 5 on 46 >asp.net core 1.x on 46 > .net core 2.0의 asp.net core 1.x > .net core 2의 asp.net core 2. 그렇게 하면 많은 사람들이 걱정하는 위험을 줄일 수 있습니다.

나는 첫날부터 이것을 따르고 있으며 이러한 모든 토론과 설명 후에도 ( @davidfowl 감사합니다 ) 우리 중 많은 사람들이 버스 아래에 던져지고 있다고 느낍니다.

Full/desktop .NET 프레임워크에서 느슨하게 잘라야 하는 이유를 이해합니다. 젠장, 나는 그것이 ASP.NET에 권한을 부여하는 방법이라는 데 동의하지만, 처음부터가 아니라 지금 이것이 어떻게 결정되고 있는지 알지 못합니다.

물론 우리 고객들은 두 시나리오 모두에서 심각하게 불평할 것이지만 저는 "사용할 수 있고, 천천히 마이그레이션하고 가능한 경우 교체하는 데 투자합니다"에 베팅하는 것보다 "새 반짝이는 것을 사용할 수 없습니다"가 되고 싶습니다. 그것이 거짓임을 알아내십시오.

나는 이것이 처음부터가 아니라 지금 어떻게 결정되고 있는지 보지 못합니다.

추측:

.NET Core 1.x에서는 전체 프레임워크 라이브러리를 실행할 수 없으므로 완전히 중단되었을 것입니다.

.NET Core 2.x에서는 대부분 전체 프레임워크를 실행할 수 있고 .NET Standard 1.x - 2.0 라이브러리를 실행할 수 있으므로 큰 문제가 아닙니다.

.NET Core 2.0에서 전체 프레임워크 라이브러리를 실행하는 것과 관련된 모든 문제는 dotnet/corefx 에 제출해야 합니다.

주요 시나리오는 "클라우드의 최신 웹 앱"이며, 종종 타사 종속성이 많지 않은(또는 "코드일 뿐"인 경우가 많습니다).

지금까지 대부분의 논의는 BCL 가용성에 중점을 두었지만 우리 중 많은 사람들이 .NET 환경에서 종종 뒤처지고 거의 항상 뒤떨어지는 타사 구성 요소(예: 복잡한 비디오, 오디오 하위 시스템과의 낮은 수준 통합)에 의존합니다. 지원되지 않을 가능성이 높은 낮은 수준의 기술에 의존합니다.

ASP.NET Core 1을 사용하여 최신 서비스를 개발하고 있으며 Libs용 .NET 표준을 대상으로 하고 서비스 종속성에 따라 전체 .NET 또는 .NET Core에 배포하도록 선택합니다.

지원되지 않는 기능/구성 요소를 찾는 경우 전체 .NET을 쉽게 대상으로 지정할 수 있기 때문에 여기에 내기를 걸 수 있습니다. 그리고 Full .NET에 머무르는 것은 몇 년 안에 피해야 할 결정처럼 보이기 때문에 장기 플랫폼에 베팅했습니다.

_.NET Core 2.x에서는 대부분 전체 프레임워크를 실행할 수 있고 .NET Standard 1.x - 2.0 라이브러리를 실행할 수 있으므로 큰 문제가 아닙니다._

@benaadams 대부분의 BCL을 사용할 수 있는 것과 Full .NET용으로 빌드된 라이브러리를 사용할 수 있는 것(내부적으로 .NET Standard 2.0/유형 통합에서 지원되지 않는 기능을 사용할 수 있음) 사이에는 큰 차이가 있습니다.

이 결정이 ASP.NET 4에서 ASP.NET Core 2.0으로 쉽게 마이그레이션하는 데 영향을 미치지 않는 것 같습니까?
내가 관리하는 많은 응용 프로그램은 ASP.NET Core 2.0으로의 업데이트를 통해 실제로 이익을 얻을 수 있지만 ASP.NET Core에 대한 OWIN/Katana 지원이 없기 때문에 수동으로 마이그레이션해야 하고 너무 많은 작업이 필요합니다. @damianh 는 https://github.com/aspnet/AspNetKatana/issues/27 에서 유사하게 제안했습니다.

EF6(공간용) 및 디렉터리 서비스가 필요하고 적절한 SignalR을 기다리고 있기 때문에 전체 프레임워크에서 실행 중입니다(현재 지원되지 않는 버전을 사용하지만 작동함). 나는 한동안 다른 차단기를 확인하지 않았지만 아마도 더 있을 것입니다.

내가 이해하는 한 우리는 이제 asp.net core 2.0으로 이동하고 그것이 나올 때 signalr를 받는 것이 차단될 것입니다.

우리는 dnx, RC1에서 RC2로, json을 csproj로 옮긴 후 마침내 우리가 숲을 벗어난 것처럼 느껴졌습니다... 지금은 그렇게 많지 않습니다.

나는 이 변화가 결국 온다는 것을 이해할 수 있지만 asp.net 코어가 견인력을 얻으려고 할 때 정말로 지금이 그것을 할 때입니까? 또한 내 직감에 따르면 EF Core는 아직 충분히 성숙하지 않았고(그리고 확실히 공간적으로는 그렇지 않음) 코어 지원에 베팅하는 사람은 libs 이식과 관련하여 더 많은 위험을 감수하고 있습니다.... 이 전환을 위해 다른 버전을 기다리는 것 같습니다. 전체 프레임워크에서 신호 r은 말할 것도 없고 EF Core 및 기타 포트가 따라잡을 수 있는 약간의 안정성과 기회를 제공합니다.

대부분의 기업이 전체 프레임워크에서 asp.net 코어(그런데 훌륭함)를 실행하고 있으며 우리와 비슷한 위치에 있을 수 있습니다.

ASP.NET Core용 고속 열차로의 이동을 감안할 때 LTS 및 현재 버전을 도입하게 되며 이 인스턴스의 지원 길이는 어떻게 됩니까?

나는 내가 netfx에서 실행하기 위한 요구 사항이 없는 미개발 솔루션을 작업하고 있는 운이 좋은 경우라고 생각합니다. 하지만 가능하다면 항상 가지고 있는 것이 좋았습니다. 나에게 방해가 되는 유일한 것은 내가 netfx를 대상으로 하는 Windows 서비스이지만 이에 대한 계획이 있습니다.

나는 이 변화가 잘못된 방향으로 가고 있다고 느낀다. netstandard가 따라잡을 때까지 일부 기능은 핵심 독점이라는 것을 이해합니다. 그러나 이 핵심 전용 경로로 가는 것은 분열된 생태계를 만드는 미끄러운 경사입니다.

이 변경으로 인해 내가 마음에 들지 않는다는 진술이 나옵니다. netcoreapp만 대상으로 하는 것이 좋습니다.

나도 내 의견을 쓰고 싶었다.

.net 프레임워크를 삭제하기에는 너무 이르다고 생각합니다. .net 프레임워크 + .net 코어를 함께 지원하는 것이 어떤 문제인지는 모르겠지만 이 결정이 AspNet Core로의 마이그레이션을 조금 더 어렵게 만들 것이라고 생각합니다. 일부 회사는 다음과 같이 생각하기 때문입니다. ".net 코어로 AspNet Core를 시작합시다.. 심각한 문제가 있는 경우(예: 필수 라이브러리가 향후 지원하지 않을 경우) 항상 .net 프레임워크로 돌아갈 수 있습니다." 그러나 이제는 더 이상 가능하지 않으며 기업은 AspNet Core로 시작하는 것을 주저할 것입니다. 또한 이 결정으로 인해 .netstandard의 가치가 낮아질 수 있습니다.

@hikalkan

일부 회사는 다음과 같이 생각하기 때문입니다. ".net 코어로 AspNet Core를 시작합시다.. 심각한 문제가 있는 경우(예: 필수 라이브러리가 향후 지원하지 않을 경우) 항상 .net 프레임워크로 돌아갈 수 있습니다."

하지만 항상 ASP.NET Core 1.1을 사용할 수 있습니까?

또한 이 결정으로 인해 .netstandard의 가치가 낮아질 수 있습니다.

왜 그럴지 모르겠습니다. 앞서 말했듯이 교차 절단 라이브러리는 여전히 .NET Standard와 모든 .NET 구현에서 작동해야 하는 API를 대상으로 합니다.

물론, 그들은 asp.net core 1.1을 사용할 수 있습니다. 그러나 "ASP.NET Core의 최신 버전은 2.x이지만 .net 프레임워크를 대상으로 하려면 ASP.NET Core 1.x를 사용해야 합니다"라고 말하는 것은 좋지 않습니다. "MVC 5.x 사용"이라고 말하는 것과 크게 다르지 않습니다. :)

나는 .net 핵심이 미래라고 생각하지만(미래가 아니라 지금이라도!) .net 프레임워크를 중단하기 시작했습니다(이 결정은 .net 프레임워크가 더 이상 사용되지 않는 것처럼 커뮤니티에서 이해될 것입니다).

하지만 항상 ASP.NET Core 1.1을 사용할 수 있습니까?

명확한 이점이 없습니다. 먼저 아직 성숙하지 않았기 때문에 내기입니다.
둘째, ASP.Net Core의 개발자는 오래된 도구로 작성하고 뒤에 머물기를 원하지 않을 것입니다.
나는 몇 가지에 관심이 있습니다.

1. 우리는 이미 ASP.Net Core, Dapper 등의 미개발 프로젝트에서 완전히 작업하고 있습니다.
   그러나 다른 프로젝트에서는 비즈니스 로직이 4.6 어셈블리에 있습니다. 위에서 읽은 것처럼 참조하는 데 문제가 없어야 합니다. 잘 이해했길 바랍니다.
2. 시그널R . DirectoryServices, MS 올리언스, Azure.
3. 위의 대화와 관련이 없을 수도 있지만 UWP 데스크톱 응용 프로그램 또는 UWP의 데스크톱 브리지로 Kestrel 또는 기타 HttpListener를 사용하여 ASP.Net Core를 로컬로 호스팅하고 싶습니다.

나는 이것에 대한 의사 소통에 꽤 실망했다고 말해야합니다. 나는 우리가 그 결정과 함께 살 수 있다고 생각하지만 그것은 아무데도 나오지 않았습니다.

7월에 우리 팀은 .NET Core에서 수년간 읽어온 멋진 내용을 모두 포함하여 ASP.NET Core 2.0에서 실행될 미개발 12-18개월 프로젝트에 대한 작업을 시작합니다.

그러나 그동안 우리는 .NET Framework 라이브러리를 호출하기 위한 래퍼 역할을 하는 기존 제품의 중심인 ASP.NET MVC Core 1.0 앱을 보유하고 있습니다.

나는 그들의 계획이 앱을 ASP.NET MVC Core 2.0으로 업그레이드하고 .NET Framework 구성 요소를 교체할 때 새 앱의 일부가 되도록 하는 계획임을 팀과 확인했습니다. 이제 우리는 프로젝트를 완료하기 전에 EOL될 ASP.NET MVC Core 1.0을 사용하고 있습니다.

내 의견을 논하기 직전에 한 부분에 대해 명확히 하고 싶습니다.
ASP.NET Core를 계속 사용하려면
.Net 4.5 이상을 대상으로 하는 dll을 참조할 수 없으며 현재처럼 작동하도록 할 수 있습니까?

@louislewis2 아니요, 정확하지 않습니다. $ netstandard2.0 지원되는 API 공간 내에 있는 한 net45 - net461 라이브러리를 사용할 수 있습니다. 해당 라이브러리를 다시 컴파일할 필요가 없습니다.

@bradwilson 설명해주셔서 감사합니다. 그러면 오늘 밤에 확실히 잠을 더 잘 잘 수 있을 것입니다.
많은 라이브러리가 우리가 통제할 수 없기 때문에 큰 문제가 되었을 것입니다.

이제 아주 안심이 됩니다 :)

@shanselman @DamianEdwards @davidfowl 아직 이식되지 않은 우리가 사용하는 항목 목록은 system.management dll에 있는 항목입니다. 특히 하드웨어 식별자를 사용합니다. 이 식별자는 Azure Service Bus와 전체 ​​라이선스 서버 및 클라이언트 패키지에 대한 자동 링크 생성에 사용됩니다. 현재 API가 아닌 상태에서 심각한 문제가 발생할 수 있다고 생각합니까?

https://github.com/dotnet/corefx/issues/3324
https://github.com/dotnet/corefx/issues/14762

이것은 전체 프레임워크에서 몇 가지 앱을 계속 실행하는 가장 큰 문제입니다.

이것은 우리를 곤란한 상황에 빠뜨립니다.

저는 우리 마이크로서비스를 Kestrel(레거시 호환성 이유) 위에 있는 ASP.Net 4.5 자체 호스팅 프로세스에서 전체 자체 호스팅 ASP.Net Core 1.x로 이식하는 중입니다. 그러나 지금은 전체 프레임워크에서 이러한 작업을 실행해야 합니다. 그리고 거기에는 그럴만한 이유가 있습니다.

우리는 이미 인프라의 일부이며 변경될 수 없는 많은 하드 Windows 종속성을 가지고 있습니다. 여기에는 NTLM 인증, 이벤트 로그 로깅 등이 포함됩니다. ASP.Net Core 2.x가 netstandard 지원에서 벗어나면 아예 하지 않는 것이 좋습니다. 문제는 적극적으로 개발된 완전한 프레임워크 대안이 없다는 것입니다. Katana는 죽고 느립니다(비교하여).

누군가가 .Net Framework용 Kestrel만큼 빠른 HTTP 서버를 알려줄 수 있다면 확실합니다. 그러나 그것은 존재하지 않습니다. 따라서 ASP.Net이 이 변경으로 인해 나와 같은 실제 프로덕션 고객을 뒤로하고 있다는 사실을 받아들여야 합니다.

스택에 파이프라인 및 스팬과 같은 모든 새로운 기능이 필요한 경우 netstandard 라이브러리로 제공되어야 합니다. netstandard2.0이 아닌 netcoreapp2.0에 있는 ASP.Net Core 2.x에서 사용하는 API는 무엇이며 그 동안 해당 API를 netstandard2.0 확장 라이브러리로 만들 수 없는 이유는 무엇입니까?

MS가 이 표준을 사용하지 않는 주력 제품을 출시하기 위해 모든 프레임워크에 걸쳐 (순) 표준 작업에 2년을 보냈다고 진지하게 말하고 있습니까?

이 문제 때문에 GitHub 팀에서 문제 섹션에 대한 페이지 매김 기능을 추가할 것이라고 생각합니다.

@mattnischan

저는 우리 마이크로서비스를 Kestrel(레거시 호환성 이유) 위에 있는 ASP.Net 4.5 자체 호스팅 프로세스에서 전체 자체 호스팅 ASP.Net Core 1.x로 이식하는 중입니다. 그러나 지금은 전체 프레임워크에서 이러한 작업을 실행해야 합니다. 그리고 거기에는 그럴만한 이유가 있습니다.

ASP.NET Core 1.x를 계속 사용할 수 있습니까?

스택에 파이프라인 및 스팬과 같은 모든 새로운 기능이 필요한 경우 netstandard 라이브러리로 제공되어야 합니다. netstandard2.0이 아닌 netcoreapp2.0에 있는 ASP.Net Core 2.x에서 사용하는 API는 무엇이며 그 동안 해당 API를 netstandard2.0 확장 라이브러리로 만들 수 없는 이유는 무엇입니까?

.NET Framework에 없는 API가 .NET Standard에 나타나면 어떻게 사용하시겠습니까?

@stefan2410

ASP.NET Core 1.x를 사용할 수 있습니까? 어떤 ASP.NET Core 2.0 기능이 필요합니까? 그냥 SignalR입니까?

향후 2년 동안 앱을 그대로 유지하되 완료되면 .NET Framework 라이브러리를 해당 .NET Core로 교체합니다. 이렇게 하면 비즈니스 로직 등을 두 앱 간에 공유할 수 있습니다.
2018년 7월이 ASP.NET MVC Core 1.0 지원 마감일이므로 이 작업을 수행할 수 없습니다.

다시 한 번, 가상의 세계에서 1.x의 수명을 연장합니다.

앱을 ASP.NET MVC Core 2.0으로 업그레이드하고 .NET Framework 구성 요소를 교체할 때 새 앱의 일부가 되도록 합니다.
Core 2.0은 .NET Framework를 지원하지 않으므로 이 작업도 수행할 수 없습니다.

실제로 ASP.NET Core 2.0이 필요합니까? 아니면 .NET Core 2.0인가요?

.NET Framework에 없는 API가 .NET Standard에 나타나면 어떻게 사용하시겠습니까?

우리의 계획은 다음과 같았습니다. 그들이 들어갈 때까지 기다리십시오. 그것은 단지 시간 문제라고 앞서 말씀하셨죠? 안정성을 위해 일정량만큼 블리딩 엣지를 지연시키는 것은 괜찮을 것입니다. 적어도 영구적으로 뒤처지는 것보다 훨씬 낫습니다.

@davidfowl
ASP.Net core 2.0으로 이동하겠습니다. 다른 해결책이 없습니다. 나는 팀에게 진화 뒤에 머물라고 말할 수 없으며 우리는 ASP.Net Core를 오랫동안 기다렸습니다.
비즈니스 로직 4.6 어셈블리 참조에 문제가 없는 한.
Azure/Amazon 라이브러리, MS Orleans 문제가 아니라 SignalR, DirectoryServices가 필요합니다.
또한 위의 대화와 관련이 없을 수도 있지만 데스크톱 앱이 UWP 데스크톱 응용 프로그램이나 UWP의 데스크톱 브리지로 Kestrel/HttpListener를 사용하여 ASP.Net Core를 로컬로 호스팅하기를 원합니다.
XAML용 코드를 다시 작성할 수 없으며 Electron을 사용하고 싶지 않습니다.

ASP.NET Core 1.x를 계속 사용할 수 있습니까?

어떤 기간 동안? 이벤트 로그가 netstandard로 만드는 것과 같은 것을 볼 수 없습니다.

.NET Framework에 없는 API가 .NET Standard에 나타나면 어떻게 사용하시겠습니까?

이게 일이야? netstandard20은 문서에 따르면 여전히 net461에서 실행되는 것으로 보입니다. netstandard20의 API가 새로운 기능을 구현하기에 충분하지 않다는 말씀이신가요? 아니면 아직 공개되지 않은 프레임워크를 넘어 netstandard를 이동할 계획이 있습니까?

우리의 계획은 다음과 같았습니다. 그들이 들어갈 때까지 기다리십시오. 그것은 단지 시간 문제라고 앞서 말씀하셨죠? 안정성을 위해 일정량만큼 블리딩 엣지를 지연시키는 것은 괜찮을 것입니다. 적어도 영구적으로 뒤처지는 것보다 훨씬 낫습니다.

라이브러리는 표준 위에 작성할 수 있습니다. 표준 자체의 내용을 변경해야 하는 경우 .NET Framework를 포함한 모든 .NET 구현에서 채택하는 데 훨씬 더 오랜 시간이 걸립니다. 다음 두 가지를 의미할 수 있습니다.

• .NET Standard는 가장 느린 구현 속도로 발전할 것입니다.
• .NET Standard는 다른 속도로 발전할 것이며 .NET Framework는 마지막으로 따라잡을 것입니다.

물론 라이브러리를 작성할 수 없다는 의미는 아닙니다. 지원하려는 .NET Standard 버전을 선택할 때 이러한 주의 사항을 고려해야 한다는 의미입니다.

또한 위의 대화와 관련이 없을 수도 있지만 데스크톱 앱이 UWP 데스크톱 응용 프로그램이나 UWP의 데스크톱 브리지로 Kestrel/HttpListener를 사용하여 ASP.Net Core를 로컬로 호스팅하기를 원합니다.

UWP의 ASP.NET Core는 현재 로드맵에 없으므로 여기서 무슨 일이 일어날지 말할 수 없습니다. HttpListener 는 .NET Standard 2.0의 일부이므로 작동할 가능성이 있습니다.

잠시 시간을 내어 여기에서 의견과 피드백을 주신 모든 분들께 감사의 말씀을 전하고 싶습니다. 우리는 앞으로 나아갈 길을 찾는 동안 당신의 인내와 함께 정말 감사합니다. 이 변경 사항이 경고 없이 너무 힘들고 너무 늦을 의도가 아니었음을 알아 주십시오. 사후 판단은 20/20이며 우리가 지금 알고 있는 것을 알았다면 더 일찍 정보를 전달했을 것입니다. 앞으로 더 열심히 하도록 하겠습니다.

이번 주 후반에 2.0.0-preview1 릴리스와 함께 발표로 게시하기 전에 여기에서 받은 피드백을 기반으로 한 계획이 있습니다. 그런 일이 발생하면 해당 계획에 대한 토론을 용이하게 하기 위해 새 문제를 열 ​​것입니다. 하지만 지금은 여기에서 계속해서 귀하의 생각과 피드백을 공유하십시오.

• .NET Framework에서 ASP.NET Core 1.x에 대한 지원이 최소 1년 더 연장됩니다(2019년 7월까지). 우리는 이를 매년 재평가하고 ASP.NET Core 1.x 지원을 종료하기 12개월 전에 통지할 것을 약속합니다(따라서 2018년 7월까지 2020년 7월까지 12개월 더 연장할지 여부를 발표할 예정 입니다). 이미 2020년에 대해 이야기하고 있다는 사실에 놀라는 사람이 있습니까? 아니요? 좋아요, 저만요. )
• 새로운 SignalR은 ASP.NET Core 1.x를 대상으로 하고 완전히 지원됩니다(올해 말 출시 예정).
• System.Web 에서 하는 것처럼 새로운 언어 버전 등을 지원하도록 ASP.NET Core 1.x를 계속 업데이트할 것입니다.
• .NET Core 1.x에서 실행되는 ASP.NET Core 1.x는 2018년 7월까지 지원됩니다(변경 사항 없음).
• .NET Framework의 ASP.NET Core 1.x가 지원되는 한 .NET Core 2+에서 실행되는 ASP.NET Core 1.x가 지원됩니다.
  
  
  
  • 이는 .NET Framework에서 실행을 지원하는 동안 지원되는 .NET Core에서 지원되는 ASP.NET Core가 항상 겹치도록 하여 고객이 지원되는 비트를 유지하면서 시간이 지남에 따라 이식할 수 있도록 하기 위한 것입니다.
  
  
• .NET Core 1.x 지원(런타임)은 변경되지 않습니다. 2018년 7월에 종료됩니다. ASP.NET Core 1.x를 실행하는 고객은 해당 시점에서 .NET Core 2.0으로 이동하거나 .NET Framework에 있어야 합니다(또는 .NET Core 2.0에서 ASP.NET Core 2.0으로 이동).
• 올해 System.DirectoryServices 및 System.Drawing 를 .NET Core로 이식할 예정입니다.
• 그 이후에 .NET Core로 이식할 항목 목록에는 현재 ServiceBase (.NET Core Windows 서비스 지원)가 포함되어 있습니다. 다음 타임라인 외에는 아직 타임라인이 없습니다(목록을 작업하면서 타임라인이 더 구체적으로 표시됨). 고객 피드백을 기반으로 이 목록을 작성합니다.
• 현재 System.ServiceModel (서버 측 WCF)를 .NET Core로 이식할 계획이 없습니다. .NET Core용 WCF는 계속 향상되고 피드백을 기반으로 하는 기능(예: HTTP 메시지 암호화)이 추가될 수 있습니다.

@DamianEdwards @davidfowl 문제의 큰 부분은 수개월의 계획과 개발 노력이 필요할 수 있다는 점입니다. 많은 조직이 다음 단계에서 벗어날 수 없는 ASP.NET Core로 이전하는 데 드는 막대한 기회 비용을 희생해야 한다는 것입니다. .NET 4.x는 모든 시스템 종속성을 실행할 수 있다고 확신할 수 있는 유일한 플랫폼이기 때문에.

지금까지 MS는 ASP.NET 4.x의 개발이 중단되었는지 여부와 향후 모든 개발 노력이 ASP.NET Core에 투자될지 여부가 불확실한 ASP.NET의 미래로 .NET Core를 적극적으로 마케팅해 왔습니다. 시스템을 최신 상태로 유지하기 위해 많은 마이그레이션이 진행 중입니다. 많은 사람들이 모든 노력의 결과로 EOL'된 플랫폼으로 효과적으로 마이그레이션한 경우 버스 아래로 던져진 것처럼 느낄 것입니다. 이는 .NET Core로의 전환을 시작하는 데 가장 큰 역할을 한 개발자/컨설턴트와 조직 모두에게 피해를 줄 것입니다. 지금은 ASP.NET Core 2.0에서 아무것도 필요하지 않을 수 있지만 시스템을 위한 여유 공간이 있고 모든 노력에 대해 몇 가지 새로운 기능에 액세스할 수 있기를 확실히 원할 것입니다.

또한 IMO가 .NET의 가장 큰 자산 중 하나로 간주되어야 할 때 기존 "레거시" 코드가 책임으로 간주되는 이유를 이해할 수 없습니다. 기존 .NET 라이브러리를 실행할 수 없는 경우 .NET Core는 그다지 매력적이지 않을 것입니다. . Java는 언어 자체의 고유한 약점보다 더 중요한 JVM의 방대하고 안정적인 생태계로 인해 여전히 강력합니다.

MS가 발표될 때까지 널리 알려지지 않은 .NET 4.x 지원 중단으로 인한 반발을 느끼기 시작했다고 생각하지 않습니다. GitHub 개발을 적극적으로 따르는 대부분의 개발자는 그런 다음 새로운 기능을 보는 데 더 관심이 있을 것으로 예상합니다. 그들은 상호 운용성이 있고 기존 코드 기반에 대한 원활한 마이그레이션 경로가 있는지 확인합니다. 나는 매우 놀랐지만 발표된 후 이 결정으로 인해 열이 나지 않는다면 아마도 많은 사람들이 이로 인해 상처를 받지 않을 것이기 때문에 그것이 옳은 결정일 수도 있습니다.

ASP.NET Core 2.0 안정/호환 릴리스에 초점을 맞춘 다음 후속 버전의 .NET Core 전용 미래를 발표하는 것은 너무 많은 노력이 필요합니까? 전혀 예측할 수 없는 상황에서 이 상황에서 하는 것이 공정한 일인 것 같습니다.

@DamianEdwards 업데이트와 명확한 계획에 감사드립니다. 나는 그것에 동의하지 않지만, 그래도 당신이 그것을 배치해 주셔서 감사합니다.

여기에는 여전히 근본적인 차이가 있습니다. 1.x에 대한 포트는 거의 완전히 측면 포트이며 우리를 위한 기능이 거의 없습니다. 2.x는 몇 가지 가치 있는 업그레이드가 있는 곳이고 우리는 여전히 우리가 그렇게 할 수 있다는 보장이 없습니다. 전체 프레임워크 종속성으로 인해 1.x로 포팅하는 데에만 상당한 시간, 비용 및 노력을 소비할 가능성이 큽니다. 나는 우리 회사와 그런 도박을 하지 않을 것입니다. 현재 ASP.NET 4.x에서 지원하는 것보다 적은 지원을 받게 될 수도 있습니다.

변경되지 않는 한 우리 앱은 ASP.NET Core로 이동하지 않을 것이며 모든 라이브러리는 이에 대한 dogfood 부족으로 인해 훨씬 ​​더 나빠질 것입니다.

이 결정을 재고하시기를 진심으로 바랍니다. 언젠가 우리가 .NET Core 플랫폼 개발을 돕기 위해 헌신한 수천 시간의 개인 시간을 Stack Overflow에서 활용할 수 있기를 바랍니다.

@NickCraver

전체 프레임워크 종속성으로 인해 1.x로 포팅하는 데에만 상당한 시간, 비용 및 노력을 소비할 가능성이 큽니다.

이 스레드 전체에서 System.DirectoryServices를 핵심 항목 중 하나로 호출했습니다. 이식하는 데 오랜 시간이 걸리거나 절대 이식되지 않을 종속성이 있다고 가정합니다. 2.0이 .NET Framework를 지원한다면 이러한 종속성이 1년 안에 이동할 것입니까?

2.x는 몇 가지 가치 있는 업그레이드가 있는 곳이고 우리는 여전히 우리가 그렇게 할 수 있다는 보장이 없습니다.

어느 것? 전환을 용이하게 하기 위해 ASP.NET Core 1.1로 다시 포팅하는 중요한 사항에 대해 논의하고 있었기 때문에 알아두면 좋을 것입니다.

변경되지 않는 한 우리 앱은 ASP.NET Core로 이동하지 않을 것이며 모든 라이브러리는 이에 대한 dogfood 부족으로 인해 훨씬 ​​더 나빠질 것입니다.

나는 stackoverflow.com에 대해 아무것도 모르지만 ASP.NET Core를 일부 부분에 사용할 수 있도록 조각을 분리할 수 있습니까("마이크로 서비스"라고 말하고 싶지 않습니다)?

@mythz

이는 조직과 .NET Core로의 전환을 시작하는 데 가장 큰 역할을 한 개발자/컨설턴트 모두에게 피해를 줄 것입니다.

ASP.NET Core를 의미합니까? 또는 .NET 코어?

@davidfowl ASP.NET Core를 의미했지만 ASP.NET Core/.NET 4.x에서 먼저 마이그레이션한 다음 나중에 .NET Core에서 단계적 마이그레이션을 계획하는 개발자에게도 영향을 미칩니다.

말하자면 ASP.NET Core/.NET Core에는 SAML을 처리하기 위한 라이브러리가 없습니다. 타사 IdP를 통해 SSO를 처리해야 하는 요구 사항이 있지만 이것이 가능할지는 모르겠습니다.

@davidfowl ASP.NET Core를 의미했지만 ASP.NET Core .NET 4.x에서 먼저 마이그레이션한 다음 나중에 .NET Core에서 단계적 마이그레이션을 계획하는 개발자에게도 영향을 미칩니다.

왜 그럴지 모르겠습니다.

나는 그 계획이 아마도 내 조직이 플랫폼에서 벗어나는 것을 피하기에 충분할 것이라고 생각합니다. 가장 중요한 것은 남아 있는 netfx dep를 다시 작성하거나 제거할 수 있는 지원 기간(=보안 패치)이 더 길다는 것입니다. 하지만 여전히 모든 것이 복잡하고 개념적으로 이상합니다. 지금부터 3년 후에 Excel 문서를 수집하거나 앱에 웹 서버를 포함할 수 있는 웹 사이트를 구축하려는 경우 어떻게 될까요? netcoreapp 대신 표준 위에 구축된 Orleans와 같은 다른 프레임워크는 어떻게 됩니까?

ASP.NET Core에서 실제로 사용하기에 충분하지 않은 경우 netstandard2.0에서 왜 그렇게 많은 작업이 수행되었는지 심각하게 이해하지 못합니다.

3년 후 Excel 문서를 수집할 수 있는 웹사이트를 구축하려는 경우 어떻게 될까요?

말하기 어렵다. 그것을 소유한 팀에 대해 말할 수는 없지만 아마도 .NET Core로 이식되고 크로스 플랫폼에서 작동할 것입니다.

또는 앱에 웹서버를 포함시키려면?

HttpListener 는 netstandard 2.0의 일부입니다.

netcoreapp 대신 표준 위에 구축된 Orleans와 같은 다른 프레임워크는 어떻게 됩니까?

.NET Framework, UWP, .NET Core, 모노 등에서 실행할지 여부를 결정하는 것은 프레임워크에 달려 있습니다. 선택 사항입니다. Orleans는 .NET Core와 함께 제공되지 않습니다. ASP.NET Core는 그렇습니다. 그 제품들은 하나이며 동일합니다.

우리(그리고 우리 고객들)에게 어려운 결정이 될 것은 내가 현재 가지고 있는 도서관이 아니라 6개월 후에 내가 필요한 도서관에 관한 것입니다. 아직 netstandard 를 지원하지 않는 라이브러리와 프레임워크가 많습니다. 예를 들어 프로젝트를 시작한 지 한 달이 지났을 때 우리는 EF Core는 고사하고 EF6에서는 가깝지 않은 몇 가지 기능이 NHibernate에 필요하다는 것을 깨달았습니다. 그렇다면 전체 .NET에서 ASP.NET Core 1.x를 대상으로 하는 옵션은 무엇입니까?

미래에 ApiPort가 있는 것 같습니다.

그렇다면 전체 .NET에서 ASP.NET Core 1.x를 대상으로 하는 옵션은 무엇입니까?

네.

말하기 어렵다. 그것을 소유한 팀에 대해 말할 수는 없지만 아마도 .NET Core로 이식되고 크로스 플랫폼에서 작동할 것입니다.

맞습니다. 하지만 이식되지 않은 라이브러리의 생태계에 대한 액세스를 제공할 가치가 있는지 여부를 결정하는 것은 asp.net 팀의 권한입니다.

맞습니다. 하지만 이식되지 않은 라이브러리의 생태계에 대한 액세스를 제공할 가치가 있는지 여부를 결정하는 것은 asp.net 팀의 권한입니다.

.NET은 크고 오래되었으므로 ASP.NET 팀이 .NET 에코시스템에 존재하는 라이브러리의 숨결에 대해 이야기할 것이라고 기대할 수 없습니다. 비현실적이야. 방금 CSOM(https://msdn.microsoft.com/en-us/library/office/jj163123.aspx)이 이 스레드의 일부로 무엇인지 배웠고 이식될 것인지 의심스럽습니다. 확실한.

.NET Framework에서 ASP.NET 1.1에 대한 지원을 확장하면 이 문제를 약간 완화하는 데 도움이 되지만 .NET Core의 ASP.NET Core로 제대로 이동하려면 일부 종속성 을 격리해야 하기 때문에 도움이 된다고 생각합니다(미래).

그 점은 이미 길게 논의되었으므로 라이브러리는 따로 남겨두겠습니다. 우리의 경우(amilia.com, 전자 상거래 SaaS) 타사 도구는 이미 눈에 띄었고 현재로서는 전체 프레임워크에서 ASP.NET Core를 실행할 수도 없습니다. 나는 이것이 정당한 이유처럼 들리지 않는다는 것을 인정하지만, 우리가 다루어야 하는 제약입니다.

이론적으로 이러한 도구(예: 프로파일러, 모니터링, 빌드 서버 등)를 .NET Core를 지원하는 대안으로 교체할 수 있지만 더 시급한 문제를 해결하는 데 몇 개월을 투자하고 싶습니다. 우리는 결국 ASP.NET Core/.NET Core로 마이그레이션할 것이지만 지금은 상당히 움직이는 대상입니다.

이 시점까지는 ASP.NET Core 가 데스크톱 프레임워크에서 계속 실행될 수 있을 것이라는 기대가 생겼습니다. 따라서 우리가 어떤 종류의 찻잎을 읽어야 하는지 알 수 없습니다. 그것은 비현실적이었습니다 :/

예를 들어, ASP.NET Core가 .NET Core에서만 실행될 수 있다는 생각 자체가 미친 것은 아니지만, 우리는 이전에 들어본 적이 없습니다. 모든 공개 정보는 .NET Framework에서 제대로 실행되었으며 이를 변경해야 한다는 표시가 없었습니다.

.NET은 크고 오래된 것이므로 ASP.NET 팀이 .NET 에코시스템에 존재하는 라이브러리의 숨결에 대해 말할 것이라고 기대할 수 없습니다. 비현실적이야

이것이 .NET 4.x를 계속 지원해야 하는 좋은 이유가 아닙니까? 호환성/상호 운용성의 부담은 .NET Core가 이전 라이브러리와 상호 운용할 필요가 없도록 하고 기존의 인기 있는 .NET 라이브러리를 .NET Core( MS 및 외부 작성자용).

@mythz

이것이 .NET 4.x를 계속 지원해야 하는 좋은 이유가 아닙니까? 호환성/상호 운용성의 부담은 .NET Core가 이전 라이브러리와 상호 운용할 필요가 없도록 하고 기존의 인기 있는 .NET 라이브러리를 .NET Core( MS 및 외부 작성자용).

그렇기 때문에 1.1 의 수명에 대한 ASP.NET Core가 연장되었습니다(영구적으로는 아니지만). SignalR이 ASP.NET Core 2.0을 사용하는 주요 이유 중 하나로 명시되어 있기 때문에 SignalR이 작동하는지 확인하겠습니다. 동시에 ASP.NET Core가 장기적으로 원하는 위치가 아닙니다. 의도는 항상 통합 .NET Core 플랫폼의 일부로 제공하는 것이었습니다.

@gulbanana

이 시점까지는 ASP.NET Core가 데스크톱 프레임워크에서 계속 실행될 수 있을 것이라는 기대가 생겼습니다. 따라서 우리가 어떤 종류의 찻잎을 읽어야 하는지 알 수 없습니다. 그것은 비현실적이었습니다 :/

.NET Framework의 ASP.NET Core는 불행히도 이식을 용이하게 하는 스톱 갭 솔루션으로 전달되지 않았습니다. 일부 종속성이 절대 이식되지 않을 것이라고 가정하는 경우 논리적인 결론인 영원히 지원되는 플랫폼으로 의도된 적이 없습니다.

그렇기 때문에 1.1 의 수명에 대한 ASP.NET Core가 연장되었습니다(영구적으로는 아니지만).

문제는 그것으로 충분한지 여부입니다. 현재 버전은 기본적으로 호환/안정된 릴리스가 제공되기 전에 EOL'되었습니다.

기존 투자의 가치가 고려되고 있다고 생각하지 않습니다. EOL 플랫폼으로 마이그레이션하기 위해 모든 노력을 기울일 사람이 누가 있겠습니까? Devs는 기존 브라운필드 시스템에서 무기한 작업할 것이며 기본적으로 현재 ASP.NET v4.x 기술이 더 이상 사용되지 않을 것이며 . NET 4.x 지원이 중단되고 막다른 플랫폼으로의 마이그레이션을 고려하거나 권장하는 것은 무책임합니다.

@davidfowl

.NET Framework의 ASP.NET Core는 불행히도 이식을 용이하게 하는 스톱 갭 솔루션으로 전달되지 않았습니다. 일부 종속성이 절대 이식되지 않을 것이라고 가정하는 경우 논리적인 결론인 영원히 지원되는 플랫폼으로 의도된 적이 없습니다.

실수가 발생합니다. 괜찮습니다. 이제 문제는 많은 사람들이 이러한 가정을 했고 논리적이지만 잘못된 결론 때문에 ASP.NET Core 만 사용하고 있다는 것입니다. 얼마나 많은지 알 수 있을 것 같습니다./

asp.net 코어 2/ .net 코어 2를 너무 오래 기다렸는데 결과가 너무 우울합니다.

@mythz

기존 투자의 가치가 고려되고 있다고 생각하지 않습니다. EOL 플랫폼으로 마이그레이션하기 위해 모든 노력을 기울일 사람이 누가 있겠습니까?

내년에 3.0이 나오면 ASP.NET Core 2.0이 .NET Framework에서 EOL되는 것에 대해 같은 주장을 할 수 없나요? ASP.NET Core 1.1에서 1년이 충분하지 않다고 말하는 경우 ASP.NET Core 2.0에서 1년이 괜찮다고 제안하는 이유는 무엇입니까?

Devs는 기존 브라운필드 시스템에서 무기한 작업할 것이며 기본적으로 현재 ASP.NET v4.x 기술이 더 이상 사용되지 않을 것이며 . NET 4.x 지원이 중단되고 막다른 플랫폼으로의 마이그레이션을 고려하거나 권장하는 것은 무책임합니다.

ASP.NET 4.x 기술이 쓸모 없게 될 것이라는 말을 누가 들었습니까? 우리가 바라는 것이 있다면 그들은 그렇지 않습니다. 특히 MVC는 몇 가지 새로운 기능과의 개념 호환성을 강조합니다. ASP.NET Core는 Katana와 매우 흡사합니다(실수는 아닙니다). Web Forms에 대해 이야기하고 있다면 MVC는 어떻습니까?

컨설팅 경험이 없지만 종속성을 사용할 수 없다면 동의할 것입니다. 이를 고려하여 응용 프로그램을 다시 설계해야 합니다.

@xyting 설명해주실 수 있나요?

@davidfowl

내년에 3.0이 나오면 ASP.NET Core 2.0이 .NET Framework에서 EOL되는 것에 대해 같은 주장을 할 수 없나요? ASP.NET Core 1.1에서 1년이 충분하지 않다고 말하는 경우 ASP.NET Core 2.0에서 1년이 괜찮다고 제안하는 이유는 무엇입니까?

나는 오랫동안 ASP.NET Core 1.1이 ASP.NET Core 2.0 및 .NET Standard 2.0에 대한 임시 솔루션일 뿐이라고 가정했습니다. .NET 4.x에서 누락된 핵심 기능 - 이 스레드가 기본적으로 그 가정을 파괴할 때까지. .NET 4.x 호환성을 ASP.NET Core 2.0까지 유지하는 것은 이상적이지 않지만 아무도 예상하지 못한 현재 릴리스에서 종료하는 것보다 훨씬 낫습니다.

ASP.NET 4.x 기술이 쓸모 없게 될 것이라는 말을 누가 들었습니까? 우리가 바라는 것이 있다면 그들은 그렇지 않습니다.

MS는 ASP.NET Core에 초점을 맞춘 것처럼 보이는 모든 새로운 발표와 기능을 사용하여 .NET Core에 대한 모든 공격적인 마케팅을 수행합니다. 이전 ASP.NET WebForms/MVC가 공개적으로 개발되고 있습니까? 이전 ASP.NET WebForms/MVC와 .NET Core에 어느 정도의 개발 노력이 투자되고 있습니까? 최근에 본 모든 것, 모든 주간 스탠드업, 비디오 자습서는 ASP.NET Core에만 초점을 맞춘 것 같습니다. 이전 ASP.NET WebForms 또는 MVC 기술을 사용하여 새로운 미개발 프로젝트를 시작하는 것이 확실히 편하지 않다는 것을 압니다.

MS가 아니길 바란다면 명확한 로드맵으로 더 잘 전달해야 합니다. 지난 몇 년 동안 ASP.NET이 얼마나 불안정했는지(이 문제는 완벽한 예임)를 감안할 때 공식적인 약속과 발표 없이는 미래가 무엇인지 알 수 없습니다.

버전 1이 전체 프레임워크에서 실행되지 않았더라면 더 좋았을 것이라고 생각하는 사람이 있습니까? 네이밍 때문에 기대도 안했는데 이제 맛을 보았고 잃어버려서 실망스럽습니다.

나는 당신이 어디에서 왔는지 알 수 있습니다. 당신은 가능한 한 빨리 전체 스택을 반복하기를 원합니다. 당신은 전체 스택을 제어하고 끌고 갈 짐이 없는 많은 미개발 분야 웹 프레임워크와 경쟁하고 있습니다. System.Web의 짐을 버리는 것이 ASP.NET Core가 흥미로운 주된 이유 중 하나입니다.

그것에 대해 자고 나는 우리의 사용법이 괜찮을 것이라고 말할 수 있습니다. 우리가 필요로하는 종속성 은 모두 2.0에서 작동해야합니다.

동시에 ASP.NET Core가 장기적으로 원하는 위치가 아닙니다. 의도는 항상 통합 .NET Core 플랫폼의 일부로 제공하는 것이었습니다.

.NET Core가 .NET의 미래 플랫폼이라는 것을 이해하는 데 초능력자가 필요하지는 않지만... 처음부터(또는 "항상"이라고 표현한 대로) 의도가 ASP.NET Core를 . NET Core에서, 그것은 내가 본 어떤 매체에서도 확실히 전달되지 않았습니다.

나는 말 그대로 모든 단일 ASP.NET 스탠드(Hanselman 및 Glenn이 3시간 동안 Docker 문제를 해결하는 것을 포함하여... 나는 인생이 없기 때문에)의 매분을 보았습니다. 저는 블로그를 읽고, 항상 Twitter를 사용하고, 1년에 2번 이상의 회의, 사용자 그룹 참석 등을 하고 ASP.NET Core의 의도로 전달된 것을 한 번도 들어본 적이 없습니다. 대신 "두 플랫폼 모두에서 실행된다"는 말을 계속해서 들었고, 당연히 사람들은 누군가가 의자 아래에서 의자를 꺼낸 것처럼 느낍니다. 나는 심지어 ASP.NET Core에 대해 이야기하고 "두 플랫폼 모두에서 실행된다"고 말했는데, 이제는 내가 이 길을 안내한 모든 사람에 대해 죄책감을 느낍니다. 나는 ITT 사람들이 최첨단에 있을 가능성이 있고 이러한 종류의 뉴스를 가장 수용할 것이라고 말하고 여기에 많은 반발이 있습니다. 이 뉴스가 연결되어 있지 않고 ITT보다 더 보수적일 가능성이 있는 개발자와 관리자에게 전해지기 때문에 상황이 더 나빠질 것 같습니다.

커뮤니케이션 부족과 일부 시나리오에 대한 지원 부족 외에도 많은 반발이 이 발표의 시기에 기인한다고 생각합니다. .NET Core 2는 아직 RTM도 되지 않았으며 이미 유일한 장기적 경로로 간주되었으며 본질적으로 ASP.NET Core용 전체 프레임워크에 시한 폭탄이 놓였습니다. 나는 밤잠 외에 놀 수 있는 무언가가 생기면 우리의 두려움이 많이 해소될 수 있다고 생각합니다.

VS의 .NET Core 2+에서 net461+ 라이브러리를 참조할 때 "실행하고 작동하는지 확인"하는 것보다 더 나은 도구 사용 경험이 필요하다고 생각합니다. 461개 이상의 어셈블리도 마찬가지입니다!" 죽음에 판매됩니다. 우리가 참조한 것의 누락된 API를 분석할 수 있는 것, 컴파일 시간 오류를 제공하는 것, 이상적으로는 존재하는 경우 compat nupkg까지 제안하는 것(예: 위의 EF6 예에서 System.Configuration... 작동하도록 하십시오 :smile:). 분명히 컴파일 시간에 모든 것을 분석할 수 있는 것은 아니지만(위에서 언급한 분산 트랜잭션 시나리오는 미리 분석하기 힘든 것으로 마음에 떠오름), 더 많이 분석할 수 있으면 더 좋습니다. Immo가 PlatformNotSupportedException 에 대해 수행한 것과 netstandard2에 대해 누락된 net461 API가 좋을 것입니다.

그냥 내 2 센트. 제가 과민반응을 하고 있기를 바랍니다. 우리는 ASP.NET Core를 사랑하고 그것을 사용하는 데 방해가 되는 어떤 것도 원하지 않기 때문에 궁극적으로 우리 중 많은 사람들이 실망할 뿐입니다. ❤️

이미 나열된 우려 사항에 제 목소리를 합치면 다음 달에 새로운 ASP.NET MVC 프로젝트를 시작하고 ASP.NET MVC가 포함된 일반 .NET Framework가 될 것입니다. 고객은 Microsoft가 다음과 관련하여 올바른 일을 하는 것을 신뢰하지 않기 때문입니다. 장기 계획.

고객 조직은 여전히 ​​Windows 7 배포를 사용하고 있으며 이 프로젝트는 예외입니다. 웹 프로젝트의 대부분은 실제로 UNIX에서 Java와 함께 수행되고 .NET은 대부분 데스크톱 응용 프로그램에서 사용되기 때문입니다.

이러한 유형의 불확실성은 Windows 8 .NET 스택 및 UWP의 깨진 역사를 누적시켜 .NET 미래에 대한 보다 안정적인 대안을 찾는 조직 CTO의 관심을 증가시킵니다.

이러한 유형의 조직에서 ASP.NET Core에서 작동하도록 처음부터 모듈을 작성하도록 강요하는 경우 고객에게 내가 제어할 수 없는 문제에 대해 체면을 잃는 대신 보다 안정적인 로드맵이 있는 것을 채택하도록 조언할 수 있습니다.

@davidfowl 이 변경 사항이 프로젝트의 99%에서 제대로 작동할 수도 있습니다. 하지만 "두 플랫폼에서 모두 실행된다", "필요하다면 전체 프레임워크와 함께 사용할 수 있다"라는 문구로 판매됐다. asp.net 코어의 전체 프레임워크 버전이 마이그레이션할 수 없는 프로젝트를 위한 것이라는 것은 누구나 알고 있었고 괜찮습니다. 그리고 사람들은 그것을 염두에 두고 계획했습니다.

이 변경은 코드 측면에서 최악은 아닐 수도 있지만 더 많은 일반 개발자가 뉴스를 볼 때 엄청난 폭풍을 일으킬 가능성이 큽니다. 그리고 그것은 코드에 관한 것이 아니라 약속된 것에 관한 것입니다. 그리고 그 약속은 "net 또는 core를 실행하고 netstandard를 모두 결합하여"였습니다.

@DamianEdwards @davidfowl 계획을 공유해 주셔서 감사합니다.

1.x의 SignalR은 지원되지 않는 버전을 대체하는 데 큰 도움이 되었으며 현재 ServiceBase도 사용하고 있으므로 ServiceBase가 다음 목록에 있다는 소식입니다!

우리는 EF6과 공간에 크게 의존하고 있기 때문에 우리가 필요한 기능 세트가 생길 때까지 1.x에 머물러 있을 것입니다....

그러나 반쯤 재미있는 측면에서 이것은 결국 이를 위해 더 많은 마이크로 서비스 배포를 강요할 수 있습니다. 우리 LOB 고객이 우리 제품을 작동시키기 위해 IIS에 몇 개의 API를 더 설치해야 하는 이유를 설명하기를 기대하지 않습니다....

너무 빨리 보이고 여러 사람들이 언급했듯이 블로그 게시물이 떨어질 때 상당한 반발을 일으킬 것이기 때문에 이것이 보류될 수 있기를 정말로 바랍니다.

또한 처음부터 이것이 전체 프레임워크에서 실행되고 동료들에게 같은 내용을 설교해 왔다는 느낌이 들었을 때 약간 강세를 느꼈다고 말해야 합니다. asp.net 코어의 혼란스러운 명명 선택에 대해 설명합니다.

@shanselman @davidfowl 나의 가장 큰 고충은 NHibernate입니다. EF Core가 출시된 후에도 여전히 유일하게 가장 발전된 완전한 기능을 갖춘 O/R 매퍼입니다.

@shanselman @DamianEdwards 저는 ASP.NET MVC 4에서 최신 버전이 무엇이든 간에 사이트를 업그레이드하는 것에 대해 생각하기 시작하는 과정에 있습니다(5인지 1인지 혼란스럽습니다). SyncFusion과 Telerik 라이브러리를 모두 참조하고 있기 때문에 여전히 전체 .net 프레임워크를 실행해야 합니다. SyncFusion은 PDF 파일을 표시하고 Telerik은 Word .docx 파일을 생성합니다. 다른 사람들이 지적했듯이 이 문제를 처리하기 위한 Microsoft의 전략이 "시도하고 작동하는지 확인"하는 것은 합리적이지 않습니다. 타사 코드의 대규모 코드 기반이기 때문에 모든 프로덕션이 제대로 작동할 것이라고 보장할 수 없습니다.

SyncFusion 지원은 일반적으로 매우 훌륭하지만 Telerik의 지원은 그렇지 않으며 .net 코어와 함께 작동하게 할 수 있다면 놀랄 것입니다. .net core에서 지원되지 않는 Apis가 무엇을 사용하는지 알 수 없습니다. 타사 제품의 핵심인 최종 사용자로서 플러그를 꽂기만 하면 필요한 작업을 수행합니다.

솔직히 물건을 자주 다루지 않는 고객(저는 주로 WPF를 사용합니다)에게는 이 모든 것이 매우 혼란스럽습니다. 다양한 비호환성과 함께 너무 많은 다른 버전이 있습니다. 누군가가 지적했듯이 UWP XAML과 비슷하지만 WPF XAML과 완전히 호환되지 않습니다.

개발자에게 좋지 않으며 개발자가 Microsoft에 대한 신뢰를 잃게 만드는 또 다른 원인입니다(지난 몇 년 동안 많은 것 중 하나). 사람들이 서버에서 사용해야 할 수 있는 방대한 도구 라이브러리가 있기 때문에 ASP.NET은 전체 .net 프레임워크에서 확실히 실행되어야 한다고 생각합니다. 제 경우에는 새로운 ASP.net 기능에 업데이트가 필요한 경우 최신 ASP.net 항목을 사용하기 위해 필요한 경우 최신 버전의 .net 프레임워크로 쉽게 업데이트할 수 있습니다.

개발자에게 전달되는 모든 메시지는 사람들이 완전히 뛰어들기 전에 훨씬 더 명확해야 합니다.

...스테판

.NET Framework의 ASP.NET Core는 불행히도 이식을 용이하게 하는 스톱 갭 솔루션으로 전달되지 않았습니다. 일부 종속성이 절대 이식되지 않을 것이라고 가정하는 경우 논리적인 결론인 영원히 지원되는 플랫폼으로 의도된 적이 없습니다.

저는 개인적으로 이 문제에 나열된 변경 사항에 문제가 없습니다. 여기에서 많은 답변을 읽었기 때문에 추론을 이해하고 이해합니다. 그러나 방금 말씀하신 내용은 궁극적으로 문제의 핵심이 무엇인지 강조합니다. 즉, Microsoft 전체의 잘못된 커뮤니케이션입니다(귀하 또는 _특정_ 개인의 잘못이 아님을 인정합니다).

어쩌면 내가 뭔가를 놓치고 있을지도 모르지만, 모든 사람이 살펴보고 가지고 놀 수 있도록 github에 코드를 두는 것보다 "공개적으로 개발"하는 것이 더 중요합니다. 바로 이 문제가 사람들을 놀라게 하는 변경 사항이 어느 날 코드에 나타났기 때문에 생성되었지만 분명히 당신과 .net 팀의 모든 사람들이 그것에 대해 알고 이해했기 때문에 오랜 시간이 걸렸습니다. 문제는 우리의 나머지 단순한 필사자들이 그것에 완전히 눈이 멀었다는 것입니다.

설상가상으로, 대부분의 개발자가 지식과 정보를 얻기 위해 github에 너무 많은 관심을 기울이지 않는 것 같습니다. 따라서 이 변경은 이미 여기에서 언급한 것보다 훨씬 더 많은 사람들을 놀라게 할 것입니다. 나는 이 문제를 해커뉴스의 RSS 피드에 올렸기 때문에 내가 직접 발견한 것뿐입니다.

MSDN의 블로그 게시물을 따라가는 사람은 누구나 2.0이 출시되고 있다는 것을 알게 될 것이며 asp.net 코어와 이전에 "누락된" 모든 것 사이의 간극을 메우는 성배라고 볼 것이지만 전혀 인식하지 못합니다. 본질적으로 특정 워크플로에 대한 주요 변경 사항입니다. asp.net core 2.0의 설계에서 실제로 무슨 일이 일어나고 있는지에 대한 세부 정보는 거의 없습니다. 이번 주 후반에 Build에서 더 자세한 정보가 나올 것 같은데요? 희망할 수 밖에 없습니다.

.net slack은 정보를 제공하는 또 다른 리소스이지만 실제로 진행되고 있는 정보를 최신 상태로 유지하기에는 다소 시끄럽습니다. 개발자 참여 및 질문에 적합하지만 뉴스 소스는 아닙니다.

트위터와 소셜 미디어는 또 다른 정보 출처이지만, 다시 이 github 문제가 나타날 때쯤이면 이미 누군가가 이미 내린 결정에 대해 우려를 제기하고 사람들을 놀라게 했기 때문입니다.

우리가 이 정확한 문제를 겪은 것은 이번이 처음이 아닙니다. 다시 csproj로 변경하여 발생한 실패를 기억하십니까? 나는 그 변화에 대한 논쟁에 끼어들고 싶지 않지만 사람들을 놀라게 한 변화의 또 다른 예입니다. 너무 잘 전달되지 않아 오늘날까지 많은 사람들이 그것이 동일한 csproj가 아니라는 것을 깨닫지 못합니다. "나쁜 옛날"에서.

내가 여기서 제안하려고 하는 것이 무엇인지 완전히 확신할 수 없지만 .net의 공개 개발에서 확실히 "누락된" 무언가가 있습니다. Microsoft는 개발자에게 리소스와 문서를 제공하는 일을 훌륭하게 수행하지만 완제품과 출하된 제품에 대해서만 제공합니다. 로드맵, 계획 회의, 프레임워크의 디자인과 방향을 결정하는 모든 것은 "선택된 파트너" 등의 언급과 함께 비공개로 수행되는 것 같습니다. 모든 회의가 스트리밍되고 전 세계적으로 방송되어야 한다고 말하는 것은 아니지만 내린 결정과 그 이면의 근거를 가능한 한 빨리 커뮤니티에 쉽게 전달하는 더 나은 중간 지점이 있을 수 있습니다. 정말 _원하는_ 사람들을 위해 요약하고 최신 정보를 유지합니다. 이러한 결정이 내려지면 정기적으로 업데이트되는 MSDN(또는 다른 곳)의 전용 블로그일 수 있습니다.

이에 대한 가장 큰 문제 중 하나는 작년에 ASP.NET Core가 발표된 거의 모든 회의에서 .net Framework와 .net Core 모두에서 실행되는 asp.net Core를 보여주는 슬라이드를 발표했다는 것입니다. 지난 해 Ignite 의 Microsoft ASP.NET Core 1.0으로 웹 개발을 살펴보십시오 . 7시 50분경에 슬라이드가 보입니다.

나를 위한 가장 큰 쇼스토퍼는 System.DirectoryServices, ServiceBase, EF6(EF Core가 준비되지 않음), ClosedXML(엑셀 시트 생성용)입니다.

.NET Framework에서 ASP.NET Core 1.x에 대한 지원이 최소 1년 더 연장됩니다(2019년 7월까지). 우리는 이를 매년 재평가하고 ASP.NET Core 1.x 지원을 종료하기 12개월 전에 통지할 것을 약속합니다(따라서 2018년 7월까지 2020년 7월까지 12개월 더 연장할지 여부를 발표할 예정입니다)(참고: 우리가 이미 2020년에 대해 이야기하고 있다는 사실에 놀란 사람이 있습니까? 아니요? 좋아요, 저만요.)

@DamianEdwards 발표해주셔서 감사합니다.

현재 우리 회사는 .NET Framework 4.6.2에서 ASP.NET Core 1.1을 사용하여 여러 클라이언트를 위한 엔터프라이즈 애플리케이션을 개발하고 있습니다. 해당 프레임워크 콤보에 대한 지원이 최소 2019년까지 지원되고 2020년까지 연장될 수 있다는 소식을 듣고 큰 안도감을 느꼈습니다.

올해 System.DirectoryServices 및 System.Drawing을 .NET Core로 이식할 예정입니다.

이것이 우리가 지금 .NET Framework를 대상으로 하는 두 가지 유일한 이유 입니다. 이것들이 .NET Core 2로 완전히 포팅된다면 내년에 우리 애플리케이션을 ASP.NET Core 2로 안전하게 포팅할 수 있을 것이라고 확신합니다.

많은 ppl이 MS 개발자라는 기본 규칙을 어긴 것 같습니다. 최소한 V2가 될 때까지는 제품/포크에 커밋하지 마십시오.

하지만 예, 기업 고객을 소외시키는 것에 대해 이야기하십시오! 그들이 MS를 사용하는 모든 이유는 이전 버전과의 호환성 때문입니다.

ASP.NET을 실행하는 대부분의 ppl은 Linux에서 실행되는 경우 신경 쓰지 않습니다. 그리고 ASPNET Core와의 속도 비교가 포함된 블로그 게시물을 본 경우 레거시 .NET을 지원하지 않는 것을 본다면 이전 크로스 플랫폼을 읽는 것조차 하지 않았을 것입니다.

롤캣.

많은 사람들에게 새로운 세계로의 원활한 마이그레이션 경로를 제공하기 위해 ASP.NET Core 2.0을 net46x에서 완전히 실행하는 것은 가치가 있다고 생각합니다. 많은 사람들이 ASP.NET Core 2.0 및 .NET Core 2.0이 오늘날의 많은 격차를 줄이고 마이그레이션을 허용할 것이라는 희망으로 기다리고 있었다고 생각합니다. ASP.NET Core 2.0에서 모든 것을 netcoreapp2.0으로 이식해야 하는 경우 팀에 엄청난 속도 저하가 발생하고 실행 가능성을 위태롭게 할 수도 있습니다.

그러나 이것이 ASP.NET Core 3.0이 있을 수 없다는 것을 의미하지는 않습니다. 그 직후에는 새롭고 빛나는 미개발 분야에서 작업하고 빠른 트랙에 있기를 원하는 모든 사람들을 위해 netcoreapp2.0만 대상으로 합니다.

두 가지 버전의 ASP.NET Core(2.0 및 3.0)를 나란히 사용하는 것은 (적어도 잠시 동안은) 정말 좋은 일이 될 수 있습니다. 새 버전의 MVC는 본질적으로 전체 .NET에서도 실행되는 ASP.NET Core MVC 2.0이기 때문에 MSFT가 현재 MVC 5 스택을 더 빠르게 단계적으로 제거할 수 있습니다.

많은 사람들에게 새로운 세계로의 원활한 마이그레이션 경로를 제공하기 위해 ASP.NET Core 2.0을 net46x에서 완전히 실행하는 것이 가치가 있다고 생각합니다.

ASP.NET Core 1.x에서 이식하는 것보다 원활하게 만드는 것은 무엇입니까?

많은 사람들이 ASP.NET Core 2.0 및 .NET Core 2.0이 오늘날의 많은 격차를 줄이고 마이그레이션을 허용할 것이라는 희망으로 기다리고 있었다고 생각합니다.

호환성을 위해 수행된 작업의 대부분은 .NET Core 2.0 및 .NET Standard 2.0에서 수행되었습니다. ASP.NET Core 2.0에는 솔직히 그렇게 많은 새로운 기능이 없습니다. SignalR을 ASP.NET Core 1.x(어쨌든 포스트 2.0임)로 백포트할 예정이라고 합니다. 단지 인식의 문제입니까?

두 가지 버전의 ASP.NET Core(2.0 및 3.0)를 나란히 사용하는 것은 정말 좋은 일입니다.

이것이 우리가 1.1과 2.0으로 하는 일입니다(숫자 뒤집기).

새 버전의 MVC는 본질적으로 전체 .NET에서도 실행되는 ASP.NET Core MVC 2.0이기 때문에 MSFT가 현재 MVC 5 스택을 더 빠르게 단계적으로 제거할 수 있습니다.

MVC 5는 사라지지 않을 것이며 더 이상 사용되지 않습니다. .NET Framework가 존재하는 한 지원됩니다. 여전히 IIS 통합 파이프라인(System.Web에서) 내에서 ASP.NET Core 프로젝트를 실행할 수 없으며 System.Web에서 MVC 5와 동일한 작업을 모두 수행하지 않으므로 실제로 특정 시나리오를 대체하지 않습니다. .

@davidfowl 전체 .NET 및 netcoreapp2.0을 대상으로 하는 ASP.NET Core 1.x 앱을 만들어 모든 종속성이 net46x인 현재 레거시 앱을 먼저 ASP.NET Core로 마이그레이션하고 천천히 마이그레이션할 수 있습니까? 모든 것이 netstandard2.0에 있을 때까지 netstandard2.0을 대상으로 하는 종속성을 차례로 지정하면 ASP.NET Core 1.x 앱을 2.x로 업그레이드할 수 있습니다(그리고 그 일부로 net46x에 대한 대상을 삭제할 수 있음)?

그렇다면 스레드를 잘못 이해 한 것 같습니다. 나는 이것이 실제로 대부분의 사람들이 여기에서 추구하는 것이라고 생각합니다.

@dustinmoris 네 할 수 있습니다. 사람들이 겪고 있는 주요 관심사는 마이그레이션이 가능한 경우 ASP.NET Core 1.x에서 지원이 종료되기 전에 ASP.NET Core 2.x로 마이그레이션하지 않으면 어떻게 되는지입니다.

@alexwiese 아 그렇군요 잘됐네요. 그렇다면 지금 여기서 우리가 논의하고 있는 것은 무엇입니까? 대상으로 삼을 프레임워크를 논의하기 보다는 ASP.NET Core 1.x의 지원 기간에 대해 논의해야 합니다. ASP.NET Core 1.x는 원하는 경우 MSFT가 쉽게 변경할 수 있는 것입니다. :)

편집하다:
@DamianEdwards 는 스레드에서 이것을 조금 더 작성했습니다.

.NET Framework에서 ASP.NET Core 1.x에 대한 지원이 최소 1년 더 연장됩니다(2019년 7월까지). 우리는 이를 매년 재평가하고 ASP.NET Core 1.x 지원을 종료하기 12개월 전에 통지할 것을 약속합니다(따라서 2018년 7월까지 2020년 7월까지 12개월 더 연장할지 여부를 발표할 예정입니다)(참고: 우리가 이미 2020년에 대해 이야기하고 있다는 사실에 놀란 사람이 있습니까? 아니요? 좋아요, 저만요.)

나에게 좋은 소리. 1년 더 지원하기로 약속한 다음 주기적으로 재평가하십시오. 나에게 완전히 의미가있다.

이 스레드의 모든 게시물을 읽었습니다. 여전히 한 가지 질문에 대한 답이 없습니다. 왜 이러한 결정이 내려졌습니까? 나는 그것이 기술적인 문제로 인해 필요하다는 결론을 내릴 수 있습니다. 명명의 '혼란'이 문제인 경우 Microsoft는 더 나은 PR 담당자를 고용하고 이 스레드에서 팀이 하는 것처럼 엉터리를 휘젓는 것을 중단해야 합니다.

그렇다면 netstandard2.0에서 ASP.NET core 2.0을 차단한 기술적인 문제는 무엇입니까? 소프트웨어 영역에서 불가능한 것은 없습니다. 따라서 .NET 전체에서 수행할 수 없는(따라서 netstandard20에 포함될 수 없는) 솔루션을 생각해내지 못할 수도 있습니다. 네, 시간과 노력이 필요하지만 사용자 모두가 이 결정으로 인해 사용자에게 얼마나 많은 시간/노력을 투자해야 하는지에 대한 이 결정의 부작용을 실제로 깨닫지 못했다는 느낌이 듭니다.

이 결정에는 또 다른 단점이 있습니다. ASP.NET Core는 netstandard의 소비자가 아니므로 netstandard의 동인이 아닙니다. 그것은 netstandard 를 추종자로 만들고 ASP.NET core는 그것에 의존하지 않기 때문에 의미가 거의 없습니다. 넷스탠다드2.0.

그리고 죄송합니다 @davidfowl 님 , 좋은 말씀이신 건 압니다만 사람들에게 계속해서 ASP.NET core 1.x를 제안하는 것은 당신이 제안한 사람들의 상황이 어떤 것인지 전혀 모른다는 것을 보여줍니다. 사람들은 마이그레이션할 수 없습니다. 확실한 기한 없이는 원활한 경로가 있는지 모르기 때문에 ASP.NET core 1.x로 이동합니다. 현재 생각하는 것보다 더 오랫동안 해당 플랫폼에 머물러 있어야 할 수도 있습니다(종속성을 이식해야 함 등.). 이것만으로도 Microsoft의 '약속'에 기반하여 ASP.NET core 1.xa로의 전환을 결정합니다. 인터넷에 연결된 코드를 위한 API입니다. 그들은 Microsoft가 보안 결함을 수정할 것이기 때문에 3년 이내에 오늘 빌드한 앱을 실행할 수 있는지 여부를 알아야 합니다(예를 들어).

솔직히 말해서 .NET 에코시스템 내에서 또 다른 혼돈 클러스터를 시작하고 싶은 충동을 느끼지 않습니다. 우리는 안정성, 신뢰성, 신뢰성이 필요합니다. "오늘 작성한 코드는 그대로 5년 동안 실행될 것입니다." 예, 일부 사람들에게는 그것이 어리석게 들린다는 것을 압니다. 그러나 그것이 현실입니다. 이 지구에는 이미 소프트웨어 패키지를 유지 관리할 개발자보다 더 많은 소프트웨어 패키지가 있으며 그 격차는 점점 벌어지고 있습니다. 조직이 ASP.NET Core를 웹 스택으로 사용하기로 결정하고 이를 사용하여 작성된 코드가 5년 이내에 실행되기를 희망한다고 단순히 가정할 수 는 없습니다. 조직은 더 이상 그렇게 하지 않습니다. 신뢰할 수 있고 다음을 제공합니다. 그들은 해당 기간 내에 전체 앱을 다시 작성할 수 없다는 것을 알고 있으므로 그러한 보증이 필요합니다.

Microsoft는 이 스레드를 통해 이 문제에 대한 끔찍한 PR을 보여주었지만, 그 확신을 줄 수는 없습니다. 그리고 앞으로 \build에서 아무리 많은 노력을 기울이더라도 울타리 반대편에 있는 우리는 Microsoft Marketing != 모든 것이 내일 작동할 것이라는 보장을 배웠습니다.

@FransBouma 기술적 문제가 있다고 생각하지 않고 netcoreapp2.0만 대상으로 한 동기는 MSFT가 원하는 만큼 빠르게 이동할 수 있는 유일한 트랙이기 때문인 것 같습니다. 이는 ASP.NET Core 2.x가 이전 .NET 세계의 다른 어떤 웹 스택보다 훨씬 빠르게 이동할 수 있음을 의미하기 때문입니다. 이 빠른 훈련에 참여할 수 없다면 ASP.NET Core 1.x를 더 오래 사용할 수 있습니다(현재 2019년까지 지원됨).

@davidfowl 및 @shanselman 이 언급한 @FransBouma 는 .NET Core에 새로운 API가 빠른 속도로 추가되고 있으며 ASP.NET Core 2.x는 그 중 일부를 사용하므로 netcoreapp20을 대상으로 하고자 합니다. 이러한 API를 netstandard2x에 추가하려면 .NET Framework 및 기타 플랫폼이 따라잡아야 하며 이동 속도가 느리기로 악명이 높습니다.

저는 토론의 This is Good Thing 측에서 제 목소리를 추가하겠습니다. 이유는 다음과 같습니다.

• 팀은 단지 그것을 위해 이것을 하는 것이 아닙니다. 최신 웹 애플리케이션, API 및 마이크로서비스를 구축하고 이러한 기능이 전체 Windows .NET Framework에 포함되기를 기다리는 사람들에게 매우 유용한 .NET Core에서 롤링할 준비가 된(또는 거의 준비된) 새로운 기능과 최적화가 많이 있습니다. 출시를 몇 개월 늦출 것입니다.
• 이 스레드에서 볼 수 있는 많은 불만 사항은 작성자가 실제로 의미하는 바가 _".NET Core 2.0에서 X를 수행하는 방식을 변경해야 합니다"일 때 ".NET Core 2.0에서 X를 수행할 수 없습니다"의 변형입니다. _. 예, 변경해야 합니다. 아니, 나쁜 일이 아니다. ASP.NET MVC 응용 프로그램에 PDF 또는 DOCX 파일과 관련된 작업을 수행하는 작은 개별 기능이 있고 _정말_ 더 나은 방법을 찾을 수 없는 경우(시도한 적이 있습니까?), 중단하십시오. 기능을 Windows Server의 전체 .NET에서 실행되는 마이크로서비스로 내보내고 .NET Core 애플리케이션에서 HTTP API로 호출합니다. 응용 프로그램을 분해하고 특정 기능을 작은 독립형 서비스로 이동하는 것은 해결 방법도 아니며 _범용 모범 사례입니다._
  
  
  
  • NB 내가 말할 수 있는 한, OpenXML 패키지는 이제 .NET Standard를 지원하므로 Word/Excel/무엇이든 사용하는 것이 불가능해서는 안 됩니다.
  
  
• .NET Core 2.0은 아직 적절한 공개 미리 보기가 아니므로 LDAP 또는 시기상조로 보이는 모든 것을 지원하지 않는다고 불평합니다. 3분기에 RTM이 출시되고 여전히 AD 또는 Kerberos와 상호 작용할 수 있는 방법이 없는 경우(하지만 더 이상 2008년이 아니기 때문에 최신 토큰 기반 인증 시스템으로 마이그레이션하는 것에 대해 생각해 보세요).
• ASP.NET MVC 4.5에서 ASP.NET Core 2.0으로의 원활한 마이그레이션이 _is_ 있습니다. 그것은 ASP.NET Core 1.0이라고 합니다(그리고 나는 상황에 따라 1.0에 대한 장기적인 지원에 대한 약속이 있어야 한다는 데 동의합니다). 1.0을 사용하여 앱을 빌드하고 Windows Server 2012 R2의 IIS 8.5에서 통합 파이프라인의 전체 .NET에서 실행할 수 있습니다.
  
  
  
  • 전체 .NET이 따라잡아 ASP.NET Core 2.x를 실행할 수 있습니다. 또는
  
  
  • 의존하는 타사 기술이 무엇이든 .NET Core를 지원합니다(또는 .NET Core를 지원하는 동등한 기술로 대체될 수 있음).
  
  
• 팀이 외부 종속성, 내부 회사 정책 또는 정책 또는 단순한 관성에 의해 어려움을 겪을 수 있지만 전 세계에는 최신 기술을 사용하여 애플리케이션, 서비스 및 API를 구축하려는 개발자가 수백만은 아니더라도 수십만이라는 사실을 기억하십시오. 아키텍처 패턴 및 새로운 기술 플랫폼(클라우드/에지/IoT/etc), ASP.NET Core 2.0이 매우 적합합니다. 그들은 빠르고 확장 가능하며 크로스 플랫폼을 원합니다. 그런 것들은 많은 사람들에게 중요합니다. 타사 제어 공급업체나 오픈 소스 프로젝트가 아직 코드를 이식하지 않았다는 이유로 Microsoft에 빠르게 확장되는 시장을 무시하도록 요청하는 것은 어리석은 일입니다.

@dustinmoris 는 netstandard에 빠른 웹 스택을 생성하기 위한 API가 부족하다고 제안합니다. 그렇다면 우리 모두는 더 큰 문제를 안고 있습니다.

@alexwiese 내가 말했듯이, 나는 완전한 스레드를 읽었고 따라서 당신이 참조하는 게시물도 읽었습니다. 나는 그들이 말하는 것을 알고 그들의 요점을 볼 수 있지만 내린 결정은 사용자가 자신의 물건으로 무엇을 하고 있는지 전혀 모른다는 것을 보여줍니다. 저는 몇 년 동안 직접 제품을 만들고 있으며, 시간이 지나면 구식의 구식 없이 더 빨리 물건을 잘라내고 싶어지는 지점에 도달한다는 것을 알고 있습니다. 하지만 그렇게 하면 결과가 따르며, 지난 14년 동안 제가 배운 한 가지는 하위 호환성이 소프트웨어 제품이 가질 수 있는 가장 큰 기능 중 하나라는 것입니다. 많은 사람들이 귀하의 플랫폼을 결정할 것입니다. 그게 그렇게 중요하고 괜찮다고 생각하지 않을 수도 있지만 현실이 다르기 때문에 그렇게 보지 못하는 사람들이 많이 있습니다.

asp.net 핵심 팀이 빨리 움직여서는 안 된다는 것이 아니라 asp.net core 1.x로 이동할 때 많은 사람들의 가정을 깨는 방식으로 수행하기 때문입니다.

@FransBouma 마이크로소프트 사용자가 마이크로소프트 제품으로 무엇을 하고 있는지 마이크로소프트보다 더 잘 알고 있다고 생각하는 이유는 무엇입니까?

@마크렌들

팀은 단지 그것을 위해 이것을 하는 것이 아닙니다. 최신 웹 애플리케이션, API 및 마이크로서비스를 구축하고 이러한 기능이 전체 Windows .NET Framework에 포함되기를 기다리는 사람들에게 매우 유용한 .NET Core에서 롤링할 준비가 된(또는 거의 준비된) 새로운 기능과 최적화가 많이 있습니다. 출시를 몇 개월 늦출 것입니다.

그렇다면 이러한 슈퍼 듀퍼 API를 .net 표준 2.0 패키지로 만들고 nuget에 게시하는 것이 어떻습니까?

마이크로소프트 사용자가 마이크로소프트 제품으로 무엇을 하는지 마이크로소프트보다 더 잘 알고 있다고 생각하는 이유는 무엇입니까?

아 몰라, 이 스레드의 게시물을 읽으면서?

@FransBouma

이는 netstandard에 빠른 웹스택을 생성하기 위한 API가 없음을 나타냅니다. 그렇다면 우리 모두는 더 큰 문제를 안고 있습니다.

netstandard는 그 표준을 지원하고자 하는 플랫폼에서 구현해야 하는 기능 목록에 불과하기 때문에 netstandard에 부족한 것이 없다고 생각합니다. 이론상으로 우리는 원하는 만큼 빨리 netstandard를 이동할 수 있고 사양에 더 많은 것을 추가할 수 있지만 현실적으로 모든 플랫폼이 이러한 새로운 사양을 따라잡는 것은 불가능합니다.

따라서 문제는 ASP.NET Core 2.x가 netstandard2.0(현재 가장 높은 값)에 커밋하고 거기에 정의된 모든 것이 붙어 있다는 것을 알고 있는지, 아니면 ASP.NET Core 2.x만 수행하는지입니다. netstandard2.0 이상일 수 있는 netcoreapp2.x에 커밋합니다. 잠시 후 나는 netcoreapp의 새로운 반짝이는 것들을 따라잡을 새로운 netstandard(3.x?)가 다시 있을 것이라고 확신하지만, 그것은 훨씬 더 많은 시간이 걸릴 것이고 왜 모든 asp.net 프레임워크가 진행을 느리게 해야 합니까? . 사람들에게 netstandard를 준수하는 보다 장기적인 지원을 제공하는 두 번째 스택이 있는 한 정말 빠르게 움직이는 ASP.NET Core 스택을 갖는 것은 일종의 좋은 일입니다.

@FransBouma 아, 죄송합니다. 샘플 크기가 이렇게 큰 줄 몰랐습니다. 결정이 마음에 들지 않는 사람들에 대한 강한 편견이 있는 댓글 257개? 그것에 대해 논쟁하기 어렵습니다.

면책 조항: 저는 빅 데이터 전문가가 아닙니다.

@davidfowl :

이 스레드 전체에서 System.DirectoryServices를 핵심 항목 중 하나로 호출했습니다. 이식하는 데 오랜 시간이 걸리거나 절대 이식되지 않을 종속성이 있다고 가정합니다. 2.0이 .NET Framework를 지원한다면 이러한 종속성이 1년 안에 이동할 것입니까?

예, 다른 것이 있습니다. System.Directory 서비스는 가장 많이 요청된 네임스페이스도 준비되지 않았기 때문에 내가 지적한 것입니다. 다른 모든 사람들은 더 나쁩니다. API 이식성 분석기는 우리가 실행할 수 있는 VS 2017용으로 업데이트되지도 않습니다. 이식할 수 있는지 확인 하는 분석기는 아직 투자되지 않았으며 이미 지원을 중단하고 있습니다.

어느 것?

Razor 페이지는 거대합니다. 여러 번 언급했습니다.

나는 stackoverflow.com에 대해 아무것도 모르지만 ASP.NET Core를 일부 부분에 사용할 수 있도록 조각을 분리할 수 있습니까("마이크로 서비스"라고 말하고 싶지 않습니다)?

아니요, 이것은 실제로 불가능합니다. 우리는 API 호출을 만들고 사물 사이에 오버헤드를 추가하여 18ms 안에 렌더링하지 않습니다. 나는 언제든지 아키텍처를 검토하게 되어 기쁩니다. 그것이 합리적인 방법이 아니라는 것을 알 수 있을 것입니다.

나는 이것을 더 일찍 설명했다고 생각했지만 여기에 또 있습니다.

진화해야 하는 netstandard의 일부인 모든 API는 천천히 발전할 것입니다. netstandard 위에 구축할 수 있고 어디에서나 실행할 수 있으며 괜찮습니다. http 클라이언트, SSL 스트림, Int, String, Array, LINQ 또는 NET Standard에 존재하는 기본 요소에 대한 새 API가 필요한 순간 ​​새 .NET Standard 버전을 생성해야 하고 구현이 필요합니다. 시행할 것이라는 데 동의합니다. 이제 모노, .NET Core, .NET Framework, UWP 등 대부분을 소유하고 있기 때문에 세상의 끝이 아닙니다. 하지만 Unity와 같은 다른 제품도 있습니다(아마도 다른 제품). 각 .NET 카테고리에는 고유한 시간 프레임과 배송 주기가 있으며, 각각 고유한 별도의 제품이므로 무시할 수 없습니다.

그러나 이제 새 API가 온라인 상태가 되면 새 netstandard 버전이 생성된다는 아이디어를 얻었습니다. 라이브러리에서 이러한 새 API를 사용하려는 경우 모든 플랫폼에 대한 지원을 즉시 잃게 됩니다. 교차 컴파일하고 폴리필을 시도할 수 있지만 모든 변경 사항에 대해 확장되지는 않습니다.

이것이 API를 netstandard로 가져오는 과정이 어떤 것인지에 대한 아이디어를 제공하기를 바랍니다. @terrajobst 는 계획이 무엇인지 더 잘 알고 있을 것입니다.

@DamianEdwards 및 @shanselman Service Fabric 및 단위 테스트는 어떻습니까?

우리의 경우 핵심 프로젝트이지만 .Net Framework 4.5에서 4.6.(무언가)까지 사용하는 SF 애플리케이션이 많이 포함된 대규모 마이크로 서비스 프로젝트가 있습니다. SF는 현재 netcoreapp을 지원하지 않으므로 .Net Framework를 사용해야 했지만 뒤처지고 싶지 않았기 때문에 .Net Core 프로젝트를 사용했습니다.

(또 다른 문제는) 우리 서비스가 .Net Framework이고 MS Fakes가 netcoreapp에 대해 사용할 수 없기 때문에 우리의 모든 단위 테스트는 정상(또는 레거시라고 말해야 하는) .Net Framework 프로젝트입니다. 거의 모든 라이브러리는 netstandard 1.0에서 1.6에 있습니다.

다시 클라이언트 앱은 Xamarin Forms + UWP를 사용하고 있으며 netstandard를 사용하여 라이브러리가 호환되도록 관리 했습니다.

이것은 우리가 멈춰서 .Net Core 2.0, netcoreapp2.0 및 netstandard 2.0으로 업그레이드할 수 없다는 것을 의미합니까?

@NickCraver

Razor 페이지는 거대합니다. 여러 번 언급했습니다.

나는 이것을 이해하지만 당신이 모든 스택 오버플로를 면도기 페이지로만 변환할 것이라는 것을 믿을 수 없습니다. 오늘날 이미 MVC를 사용하고 있다면 일반 보기로 이식하고 더 많은 종속성이 온라인 상태가 되면 면도기 페이지로 이식하는 것이 좋습니다. razor 페이지가 설계된 방식으로 인해 컨트롤러 작업에서 razor 페이지로 이동하는 것이 간단합니다.

예, 다른 것이 있습니다. System.Directory 서비스는 가장 많이 요청된 네임스페이스도 준비되지 않았기 때문에 내가 지적한 것입니다. 다른 모든 사람들은 더 나쁩니다. API 이식성 분석기는 우리가 실행할 수 있는 VS 2017용으로 업데이트되지도 않습니다. 이식할 수 있는지 확인하는 분석기는 아직 투자되지 않았으며 이미 지원을 중단하고 있습니다.

무엇이 중요한지 알 수 있도록 해당 종속성 목록을 에스컬레이션하세요.

@아부

이것은 우리가 멈춰서 .Net Core 2.0, netcoreapp2.0 및 netstandard 2.0으로 업그레이드할 수 없다는 것을 의미합니까?

당신은 ASP.NET Core 2.0을 의미했고? .NET Core 2.0 및 .NET Standard 2.0은 여기에 실제로 적용되지 않습니다.

예, ASP.NET Core 1.x를 유지해야 합니다.

호환성을 위해 수행된 작업의 대부분은 .NET Core 2.0 및 .NET Standard 2.0에서 수행되었습니다. ASP.NET Core 2.0에는 솔직히 그렇게 많은 새로운 기능이 없습니다. SignalR을 ASP.NET Core 1.x(어쨌든 포스트 2.0임)로 백포트할 예정이라고 합니다. 단지 인식의 문제입니까?

@davidfowl 내 생각에 당신은 마이그레이션해야 한다는 말을 들었을 때 Windows 개발자의 마음을 강타하는 두려움을 엄청나게 과소평가하고 있다고 생각합니다. _특히_ 새 스택이 이전 스택과 기능 패리티에 도달하지 않고 언제 발생할지 알 수 없는 경우. 이것은 기본적으로 전체 .NET Framework에서 ASP.NET Core의 EOL-ing을 발표합니다. 그리고 그것이 장기적인 계획은 아닐지 모르지만 기능으로 발표되었고 사람들은 그것이 한동안 유지될 것이라고 생각했습니다. 우리가 말하는 대로 로드맵이 바뀌고 있습니다. 회의가 열릴 것입니다.

명목상으로 유지 관리되는 데이터베이스 커넥터와 SDK 때문에 지원해야 하는 역겹도록 오래된 것들이 있습니다. 이러한 공급업체 중 일부는 기존 제품을 유지 관리하는 것보다 기존 기능의 30%, HTML5 인터페이스 및 새로운 일련의 버그가 포함된 새로운 API를 출시할 가능성이 훨씬 더 높습니다. 또는 경쟁업체를 인수하고 제품을 출시한 후 신속하게 EOL할 수 있습니다. 이러한 공급업체 중 일부는 알아볼 수 있을 정도로 큽니다. 우리는 좋은 코드를 많이 가지고 있지만 그 코드 중 일부는 우리가 항상 통제할 수 있는 것은 아니기 때문에 최선의 노력에도 불구하고 Windows 슬럼에도 있습니다. 오래된 기술은 단순히 우아하게 은퇴하는 것이 아닙니다. 그것은 당신의 침대 아래, 우리 옷장과 키보드 아래에 숨어 있습니다.

나는 나머지 부분보다 .NET Standard의 가능한 부업을 알리는 이 움직임에 대해 더 우려하고 있습니다. .NET Standard는 처음에 다양한 구현을 기능 패리티에 점점 더 가깝게 만드는 동시에 소비자가 진화하고 성장하는 플랫폼으로 마이그레이션할 수 있도록 하는 것처럼 보였습니다. 이제 .NET Core 기능의 이정표에 불과한 것처럼 들립니다. .NET Standard 전용 라이브러리에 대한 실행 파일을 대상으로 지정할 수 없거나 원하지 않습니다. 그리고 .NET Standard와 관련된 계획이 훨씬 줄어들고 대신 이미 변경하기에는 너무 늦었기 때문에 ASP.NET에서 사용된 모든 항목에 고무 스탬프가 찍힌 것처럼 들립니다. 결국 이미 생산에 들어갈 것입니다.

다른 개발자는 컴파일러 지시문으로 코드를 뿌리고, 코드를 플랫폼별 라이브러리로 분할하고, 여러 대상으로 컴파일해야 합니다. 내 무례한 부분은 ASP.NET Core 팀이 다중 대상 지정 및 다중 플랫폼 시나리오에 대한 더 나은 런타임 및 도구 지원에 관심을 가질 수 있도록 독식하기를 원합니다. 그리고 당신의 팀이 그것을 원하면 우리가 그것을 얻을 수 있습니다. 제 실질적인 부분은 최소한 .NET Standard를 대상으로 하는 ASP.NET Core의 주기적 릴리스가 있어야 한다고 말합니다. 어쨌든 실제 _stable_ 릴리스를 만들어야 합니다. 아무도 git에서 마스터 브랜치를 컴파일하고 프로덕션에 배포하지 않을 것입니다. .NET Standard의 더 작은 반복을 수행하고 태그가 지정된 ASP.NET 릴리스와 일치시키지 않는 이유는 무엇입니까?

또한 데스크톱용 새 ASP.NET이 있습니까? 모든 팡파르는 ASP.NET Core가 유일한 ASP.NET인 것처럼 들렸습니다. 이제 .NET Core에 있지 않는 한 ASP.NET에서 새로운 것을 얻지 못할 것 같습니다. 그리고 그것은 많은 비즈니스 전략을 바꿀 것입니다. 로드맵과 관련하여 많은 혼란이 일어나고 있습니다.

MVC 5는 사라지지 않을 것이며 더 이상 사용되지 않습니다. .NET Framework가 존재하는 한 지원됩니다.

예, 우리는 오래된 것들이 그곳에 남을 것이라는 것을 잘 알고 있습니다. 일반적으로 그렇게 하며 감사합니다. 그러나 새로운 것이 "전체" 프레임워크에 포함될 것인지 여부는 매우 중요합니다. 우리는 상황이 어디로 가고 있는지 알아야 합니다. 우리는 기차를 끝까지 타고 싶지 않고 그제서야 앞으로 나아갈 방법을 생각합니다. 승객들도 걱정해야 합니다. 그리고 .NET Core와 .NET Framework 간의 격차로 인해 많은 사람들이 미래에 대해 불확실합니다. 1년 반 전에 .NET Core에서 기능의 특정 부분이 지원될 시기에 대해 질문했습니다. 개인적으로 작업을 하면 받아들여질 수 있냐고 물어보기도 했다. 커뮤니케이션이 부족했습니다. 나는 아직도 그것에 무슨 일이 일어날 지 전혀 모른다. 지원되는 시나리오 및 타임라인에 대한 이러한 유형의 불확실성은 우리가 작성하는 코드에 큰 차이를 만듭니다. 데스크톱 프레임워크의 어떤 섹션이 우선 순위가 낮은지 알면 상태 업데이트를 기다리는 대신 마이그레이션할 충분한 시간을 줄 수 있습니다.

요컨대, 나는 당신이 하고 있는 일과 그 이면의 목표를 지지합니다. 그리고 우리가 여기 와서 당신이 내린 결정에 대해 매우 좋은 이유가 있다고 불평하는 것이 어렵다는 것을 압니다. 그러나 많은 사람들이 개척자 기차에 탈 수 없기 때문에 타지 않을 것이고, 다른 사람들은 그것이 어디로 가는지 모르기 때문에 타지 않을 것입니다.

@davidfowl 추측합니다. .Net Framework에서 핵심 프로젝트(신규)를 무엇이라고 합니까? 그것이 무엇이든, 게시물에서 내가 이해한 것은 netstandard vNext가 이를 지원하지 않는다는 것입니다.

@markrendle 우리는 실제 고객입니다. 우리는 사람들에게 일이 작동하지 않을 것이라고 말하고 있습니다. 내 구조를 당신보다 더 잘 알기 때문에 오만한 댓글은 도움이 되지 않습니다. 귀하의 포인트:

팀은 단지 그것을 위해 이것을 하는 것이 아닙니다. 최신 웹 애플리케이션, API 및 마이크로서비스를 구축하고 이러한 기능이 전체 Windows .NET Framework에 포함되기를 기다리는 사람들에게 매우 유용한 .NET Core에서 롤링할 준비가 된(또는 거의 준비된) 새로운 기능과 최적화가 많이 있습니다. 출시를 몇 개월 늦출 것입니다.

이러한 것들을 지지하는 것에 반대하는 사람 은 아무도 없습니다. 우리의 불만은 일반적으로 새로운 기능을 조건부로 추가하는 것이 아니라 지원 중단에 대한 것입니다.

이 스레드에서 볼 수 있는 많은 불만은 작성자가 실제로 의미하는 바가 ".NET Core 2.0에서 X를 수행하는 방식을 변경해야 합니다"인 경우 ".NET Core 2.0에서 X를 수행할 수 없습니다"의 변형입니다. 예, 변경해야 합니다. 아니, 나쁜 일이 아니다. ASP.NET MVC 응용 프로그램에 PDF 또는 DOCX 파일로 작업을 수행하는 작은 개별 기능이 있고 그 작업을 수행하는 더 좋은 방법을 실제로 찾을 수 없는 경우(해 본 적이 있습니까?) 기능을 Windows Server의 전체 .NET에서 실행되는 마이크로서비스로 내보내고 .NET Core 애플리케이션에서 HTTP API로 호출합니다. 응용 프로그램을 분해하고 특정 기능을 작은 독립형 서비스로 이동하는 것은 해결 방법이 아니라 범용 모범 사례입니다.

이것은 너무 멀리 떨어져있어 어디서부터 시작해야할지 모르겠습니다. 우리 페이지는 "마이크로 서비스"에서 훨씬 느리고 더 비쌉니다. 이러한 설정으로 페이지를 렌더링하는 것보다 GC에서 훨씬 더 많은 시간을 소비합니다. 이것은 또한 전체 프레임워크 종속성이 모든 페이지 렌더링의 중요한 부분이 아니라는 가정을 합니다. 잘못된 가정입니다.

.NET Core 2.0은 아직 적절한 공개 미리 보기가 아니므로 LDAP 또는 시기상조로 보이는 모든 것을 지원하지 않는다고 불평합니다. 3분기에 RTM이 출시되고 여전히 AD 또는 Kerberos와 상호 작용할 수 있는 방법이 없는 경우(하지만 더 이상 2008년이 아니기 때문에 최신 토큰 기반 인증 시스템으로 마이그레이션하는 것에 대해 생각해 보세요).

우리는 그들이 거기에 없을 것이라고 들었 습니다. 일어서는 것을 지켜보십시오. 또는 "Future"라는 레이블이 붙은 GitHub를 살펴보세요. 이 잘못된 결정이 3분기에 배송될 것이기 때문에 우리는 지금 불평하고 있습니다.

ASP.NET MVC 4.5에서 ASP.NET Core 2.0으로 원활하게 마이그레이션됩니다. 그것은 ASP.NET Core 1.0이라고 합니다(그리고 나는 상황에 따라 1.0에 대한 장기적인 지원에 대한 약속이 있어야 한다는 데 동의합니다).

장기 지원이 막다른 골목이 아니라는 것을 의미하지는 않습니다. 수명이 다한 1.x에서는 여전히 쉽게 좌초될 수 있습니다. 이 경우 전체 프레임워크에 대한 지원이 더 오래 지속되었을 것입니다.

전체 .NET이 따라잡아 ASP.NET Core 2.x를 실행할 수 있습니다.

netcoreapp 을(를) 타겟팅하고 있으며 그런 일은 일어나지 않습니다.

...또는 의존하는 모든 타사 기술이 .NET Core를 지원합니다(또는 .NET Core를 지원하는 동등한 기술로 대체될 수 있음).

이러한 라이브러리는 종종 사람들의 통제와 시간 예산을 벗어납니다. Microsoft의 라이브러리도 업그레이드되지 않습니다 . install.ps1이 작동하기 때문에 새 프로젝트 시스템에서 작동하도록 패키지를 업그레이드하기 위해 지금 SQL 팀과 싸우고 있습니다. 이러한 간단한 수정 사항조차 적용할 수 없다면 netstandard 포트에 문제가 있는 것입니다.

팀이 외부 종속성, 내부 회사 정책 또는 정책 또는 단순한 관성에 의해 어려움을 겪을 수 있지만 전 세계에는 최신 기술을 사용하여 애플리케이션, 서비스 및 API를 구축하려는 개발자가 수백만은 아니더라도 수십만이라는 사실을 기억하십시오. 아키텍처 패턴 및 새로운 기술 플랫폼(클라우드/에지/IoT/etc), ASP.NET Core 2.0이 매우 적합합니다. 그들은 빠르고 확장 가능하며 크로스 플랫폼을 원합니다. 그런 것들은 많은 사람들에게 중요합니다. 타사 제어 공급업체나 오픈 소스 프로젝트가 아직 코드를 이식하지 않았다는 이유로 Microsoft에 빠르게 확장되는 시장을 무시하도록 요청하는 것은 어리석은 일입니다.

그것을 바보라고 부르는 것은 비하하고, 무례하고, 필요 없는 것입니다. 이것은 우리의 삶입니다. 이것들은 우리의 앱입니다. 이것들은 우리가 몇 년 또는 수십 년 동안 만들어 낸 것들이며 출시 전에 갑자기 우리는 전망이 우리에게 시간 제한이 있음을 알게되었습니다. 말할 것도 없이 많은 불확실성이 도입됩니다. 그것은 당신이 당신의 경력에서 정말로 원하는 것이 아닙니다.

모든 점은 이해가 되지만, 이 우주에서는 모든 것이 더 적은 에너지를 필요로 하는 상태로 갈 것이라는 것을 기억하십시오. 그런 다음 그 상태가 당신이 가고 싶은 곳인지 확인하십시오. 왜냐하면 우리는 어떤 식으로든 그곳에 갈 것이기 때문입니다.
따라서 특정 상태를 달성하려면 현재 상태를 유지하는 데 필요한 것보다 적은 에너지가 필요한지 확인하십시오.

누군가 IRC에서 이것을 제쳐두고 언급한 후 이 전체 스레드를 읽었습니다. 아직 이에 대한 공식적인 발표를 본 적이 없습니다. 그리고 저는 완전히 실망했습니다.

저는 .NET Core를 관찰하면서 새로운 SDK 및 런타임에 대한 경험을 얻고 macOS 및 Linux에서 이러한 프로젝트를 실행하기 위해 참여하고 .NET Framework에서 .NET Standard/.NET Core로 소규모 프로젝트를 변환했습니다. .

내 큰 목표는 .NET Core 1.0 또는 1.1에서 [아직] 사용할 수 없는 구성 요소 힙을 사용하는 대규모 엔터프라이즈 웹 서비스입니다. 여기에는 다음이 포함됩니다.

• 인증 및 사용자 관리에 사용되는 Active Directory( System.DirectoryServices )
• Entity Framework 6( EntityFramework ), EF Core는 아직 우리가 사용하는 많은 기능을 지원하지 않기 때문입니다.
• OData ( Microsoft.Data.Services / System.Data.Services ) v1-3, 우리가 사용하는 클라이언트 자바스크립트 라이브러리는 v4를 (아직) 지원하지 않으며 WebAPI OData는 설정하기 훨씬 더 복잡합니다.
• 웹 서비스 자체 업그레이드 기능을 위한 IIS 관리( System.Web.Management ) 및 .NET Remoting( System.Runtime.Remoting ) - 독립 실행형 응용 프로그램으로 추출할 수 있지만.
• 시그널R
• 사용자 정의 IHttpHandler s 및 IHttpModule s, ASP.NET Core에 상응하는 것이 무엇이든 간에, 아마도 일종의 미들웨어에 맞게 조정되어야 합니다.
• ASP.NET WebAPI의 확장성을 사용하는 모든 사용자 지정 항목.
• net46만 지원하고 일부 기본 어셈블리가 있으며 .NET Core 2.0에서 작업할 확률이 약 0%인 서버에서 Microsoft.TeamFoundationServer.ExtendedClient 를 사용할 수도 있다고 생각합니다.
• 등.

이 서비스의 크기와 복잡성으로 인해 .NET Core로의 모든 마이그레이션은 점진적이어야 하며 아마도 새로운 ASP.NET-Core-2.0 API를 사용해야 할 수도 있습니다. 아직까지는 아직 이르지 못했습니다.

.NET Framework에서 ASP.NET Core를 실행하는 기능을 제거한다는 것은 ASP.NET Core 1.x가 실행 가능한 디딤돌이 아닌 경우 마이그레이션을 빅뱅 스타일로 수행해야 함을 의미합니다. "새 런타임에서 새 프레임워크 실행" 전에 "이전 런타임에서 새 프레임워크 실행" 단계를 즉시 잃게 됩니다. 이것은 모든 대규모 시스템에 대한 끔찍한 변경 관리 전략입니다.

.NET Core가 패리티에 도달했거나 거의 패리티에 가까우면 .NET Framework 지원이 중단된 경우에는 그다지 신경 쓰지 않겠지만 충분히 고급 응용 프로그램에 대해서는 여전히 뒤쳐져 있고 2.0이 그런 것을 만들기에 적합한 장소가 아니라고 생각합니다. 획기적인 변화.

@davidfowl

나는 이것을 이해하지만 당신이 모든 스택 오버플로를 면도기 페이지로만 변환할 것이라는 것을 믿을 수 없습니다. 오늘날 이미 MVC를 사용하고 있다면 일반 보기로 이식하고 더 많은 종속성이 온라인 상태가 되면 면도기 페이지로 이식하는 것이 좋습니다. razor 페이지가 설계된 방식으로 인해 컨트롤러 작업에서 razor 페이지로 이동하는 것이 간단합니다.

앱 간에 공유되는 많은 라이브러리 등이 여기에서 작동합니다. 스택 오버플로는 많은 애플리케이션입니다(메인 웹사이트는 거의 완전히 단일 앱이지만 회사로서: 우리는 관련되고 소통하는 많은 것을 가지고 있습니다.

무엇이 중요한지 알 수 있도록 해당 종속성 목록을 에스컬레이션하세요.

네, 그렇게 하고 있습니다. 그러나 그것이 마지막 종속성은 아닐 것입니다. 그것 없이는 일부 앱에 로그인조차 할 수 없기 때문에 가장 큰 차단기일 뿐입니다. 첫 화면 차단기입니다. 이번 주(오늘 아침에 출시된 후) 앱 전체에 이식성 분석기를 완전히 사용해 보겠습니다. 하지만 더 우울할 것 같습니다. 이와 같은 움직임이 고려되기 전에 분석기가 현재 툴링에 대해 업데이트된 경우에도 도움이 될 것입니다.

데이터가 도움이 됩니다. 이 결정이 바뀔 가능성이 0이 아닌 한 더 많은 데이터를 얻으려고 노력하겠습니다. 그렇다면 더 이상 시간을 투자하지 않도록 알려주십시오.

참고로 OData는 아직 netcoreapp을 지원하지 않는 또 다른 라이브러리입니다.

실제로 여전히 System.Web을 기반으로 하고 있으며(ASP.NET Core에서 OWIN 미들웨어를 통해 사용해야 함) 지원을 약속했습니다(https://github.com/OData/WebApi/issues/939 참조).

여전히 언급할 가치가 있습니다. 특히 Microsoft에서 제공하기 때문에 더욱 그렇습니다.

편집: @yaakov-h가 2분 더 빨라서 OData에 대해 언급한 것에 대해 +1

나는 몇 가지 이유로 여전히 여기에 답장을 하고 있다

• 난 상관
• 잠은 약한 자의 것이다 😆
• 인터넷상의 누군가가 틀렸기 때문에 FUD를 불러야 합니다.

@NickCraver

앱 간에 공유되는 많은 라이브러리 등이 여기에서 작동합니다. 스택 오버플로는 많은 애플리케이션입니다(메인 웹사이트는 거의 완전히 단일 앱이지만 회사로서: 우리는 관련되고 소통하는 많은 것을 가지고 있습니다.

Razor 페이지 tbh를 사용할 수 없음을 의미합니다. ASP.NET Core 2.0에는 많은 작은 기능이 있지만 1.x로 다시 포팅되지 않는 큰 기능이나 수정 사항은 없습니다. EOL은 매우 현실적이며 개인적으로 앞으로 .NET Framework를 지원하는 ASP.NET Core 2.0이 도움이 될 것이라고 생각하지 않습니다. 우리는 여기서 방향 변경에 대해 논의하고 있습니다. .NET Framework를 영원히 지원하든 말든, 그 사이에는 정말 아무 것도 없습니다.

@dustinmoris 는 그 뿐만이 아닙니다. 기대치의 문제이기도 하다. 귀하의 사용 사례는 다른 모든 사람과 동일하지 않을 수 있습니다.

저는 aspnetcore 1.* 앱을 개발 중이며 .NET 데스크탑을 런타임(엔터프라이즈용 LOB)으로 사용하고 있습니다.

그리고 .net 코어 런타임, netstandard 등의 차이점이 무엇인지 이해합니다.

내 마이그레이션은 흐름/비전/기타를 통합하고 .net 코어로 이동한 후(가능한 경우) aspnetcore 선택의 결정적인 시나리오였기 때문에 먼저 aspnet 코어(.net 데스크탑 대상)로 마이그레이션했습니다.

이 문제는 aspnetcore 1.*이 항상 "두 프레임워크에서 모두 실행"되는 것으로 마케팅되었으며 다음(버전 또는 연도) 삭제에 대한 경고가 전혀 없었기 때문에 이 문제는 약간 예상치 못한 것입니다.
나는 최소한 사용되지 않는 -> 더 이상 사용되지 않는 주기 또는 지원되지 않는 기능(괜찮습니다)을 기대했습니다.

.net(및 웹 스택을 위한 aspnet 선택)의 좋은 점은 기존 코드베이스와 라이브러리를 활용할 수 있다는 것입니다.
일부는 내부적이며 대상(.net core/netstandard)이 너무 유동적일 때 마이그레이션할 실제 투자 수익이 없습니다.
일부는 외부적이고 변경하기 어렵습니다. netcoreapp2 클로저에서 작동하지 않으면 사용할 수 없습니다.

게다가 내 아이디어는 netcoreapp2 netstandard2 $ 에 통합되었습니다.
libs가 아직 없는 경우 netstandard2로의 마이그레이션 평가를 시작하려면 어떻게 해야 합니까? 미리 보기 비트 및 약속을 기반으로 마이그레이션을 평가하기가 어렵습니다(최근 몇 년 동안 약속의 안정성에 대한 신뢰가 낮아짐).

나는 완전히 그린필드와 다른 시나리오라는 것을 이해하지만, 그린필드의 경우 일부 라이브러리를 재사용하고 싶습니다. 기존 시스템(excel/pdf/etc)과 상호 작용해야 하기 때문에 scracth에서 모든 것을 다시 작성하지 않아야 하기 때문입니다.
또는 최신 추세이기 때문에 마이크로 서비스를 rpc로 추가하십시오. 왜냐하면 상황이 더 복잡해지기 때문입니다(즉, 기존 라이브러리를 래핑하도록 강요받지 않고 평가하고 수행하고 싶은 동시 선택입니다). 아키텍처를 변경하는 것뿐만 아니라 가치를 제공해야 합니다(aspnetcore 개발 흐름은 훌륭하고 생산적임).

생태계에 대한 개인적인 평가에서 사용 사례의 경우 .net core 및/또는 netstandard lib의 사용 가능성은 atm이 너무 낮습니다(모든 사람이 무료 nuget.org oss pkg를 사용하는 것은 아닙니다). 따라서 새 스택으로 열심히 마이그레이션해야 하는 경우 다른 스택(비용/이점/미래/신뢰/기타)도 평가해야 합니다.

저는 TODO 웹 앱을 작성하고 있을 뿐만 아니라 .NET을 사용합니다. 왜냐하면 저는 수년 간의 준비를 했기 때문에 한 가지를 변경할 수 있습니다(이 경우 aspnetcore, 나머지는 이 반복에 대해 그대로 둡니다).
모든 것을 변경하는 것은 내 시나리오에서 재앙의 비법이며, 그렇게 해야 할 때 lib가 존재하는 다른 스택(자바/노드)으로 마이그레이션하는 것이 더 합리적인지 실제로 평가를 시작해야 합니다.

원활한 마이그레이션에는 시간이 걸립니다. 저는 미래의 aspnet 코어에 대한 비전을 좋아합니다. 그러나 명확한 경로(또는 그것에 대한 의심)가 없으면 내부적으로 판매하기가 어렵습니다.

즉, .net 데스크탑을 남겨두고 더 빠르게 이동하고 더 많은 새 사용자를 선택하기 위해 aspnet 팀이 좋은 도박을 할 수 있습니다(또는 노드/자바에 대한 흐름을 잃지 않음).
그러나 확실히 느린 링에서 개발자의 삶을 더 어렵게 만들 것이며 이것은 aspnet 팀 호출(그들의 제품)입니다.
내 피드백은 그렇게 하지 않고 fw를 지원하기 위해 열심히 노력한다는 것입니다. 왜냐하면 개발자로서 저는 신뢰와 안정성이 필요하고 지난 몇 년 동안 .net 생태계(netcore/project.json 뿐만 아니라 또한 마케팅/전도사가 신뢰를 낮추는 데 도움이되지 않았습니다)

@yaakov-h

ASP.NET Core(1.x 또는 2.x)로 이식하기로 결정했다면 다른 프로세스가 필요합니다. ASP.NET Core는 System.Web에서 실행되지 않으므로 동일한 프로젝트에서 점진적 포트를 수행할 수 없습니다.

.NET Core가 패리티에 도달했거나 거의 패리티에 가까우면 .NET Framework 지원이 중단된 경우에는 그다지 신경 쓰지 않겠지만 충분히 고급 응용 프로그램에 대해서는 여전히 뒤쳐져 있고 2.0이 그런 것을 만들기에 적합한 장소가 아니라고 생각합니다. 획기적인 변화.

그것을 버릴 적절한 시간이 없습니다. .NET Framework와 패리티에 도달하기 위한 것이 아니며 이식하지 않을 종속성이 있을 가능성이 큽니다. 이를 감안할 때 내 질문은 응용 프로그램을 다시 설계합니까 아니면 현실적으로 영원히 .NET Framework를 유지해야 합니까?

@davidfowl 은 업스트림 종속성에 전적으로 의존합니다. 이 시점에서 우리는 영원히 .NET Framework에 머물 것입니다.

흥미롭게도 대부분의 타사 제품에는 이미 netstandard 릴리스가 있습니다. .NET Framework에서 우리를 유지하는 것은 주로 Microsoft 종속성이며 그 중 일부는 반쯤 포기된 것 같습니다(예: OData).

@NickCraver 비하 하거나 모욕하려는 것이 아닙니다. 나는 이것이 늦은 변화라는 점에 감사하며, 커뮤니티의 어느 부분이 영향을 받든 실망스럽고, 내가 영향을 받는다면 나도 소란을 피우게 될 것입니다. 나는 (내가 일하는 곳에서는 여전히 ASP.NET WebAPI 5.2.3을 사용하고 있음) 상황에 대한 나의 견해가 덜 감정적입니다.

이런 식으로 보세요. 오늘 다음 Stack Exchange(무엇이든 간에) 빌드를 처음부터 시작하려는 경우 ASP.NET Core 팀에서 사용하려는 netcoreapp20 에 있는 항목이 아닙니다( UTF8Strings 및 Pipelines 및 낮은 할당, 비동기, _fast_ 프리미티브(약간 추측하고 있음))가 전체 .NET보다 더 매력적으로 보이나요? .NET Core 2.0이 일반적으로 전체 .NET 4.7.1보다 더 합리적이지 않습니까? 진화하고 변화에 빠르게 적응할 수 있는 웹 스택과 지원에 대해 걱정해야 하는 거의 20년에 걸친 레거시 코드가 포함된 느리게 움직이는 기본 기술에 돌이킬 수 없이 묶인 웹 스택 중 어느 것을 선택하시겠습니까?

@ZigMeowNyan

나는 나머지 부분보다 .NET Standard의 가능한 부업을 알리는 이 움직임에 대해 더 우려하고 있습니다. .NET Standard는 처음에 다양한 구현을 기능 패리티에 점점 더 가깝게 만드는 동시에 소비자가 진화하고 성장하는 플랫폼으로 마이그레이션할 수 있도록 하는 것처럼 보였습니다. 이제 .NET Core 기능의 이정표에 불과한 것처럼 들립니다. .NET Standard 전용 라이브러리에 대한 실행 파일을 대상으로 지정할 수 없거나 원하지 않습니다. 그리고 .NET Standard와 관련된 계획이 훨씬 줄어들고 대신 이미 변경하기에는 너무 늦었기 때문에 ASP.NET에서 사용된 모든 항목에 고무 스탬프가 찍힌 것처럼 들립니다. 결국 이미 생산에 들어갈 것입니다.

그것들은 실제로 정말 좋은 점이며 고려할 가치가 있는 것입니다. .NET Standard가 제외되는 것과 아무 관련이 없다는 것을 이해해야 합니다. 단지 물리학일 뿐입니다. 각 .NET 플랫폼이 자체 속도로 이동하는 경우 최신 .NET Standard를 사용하면 느리게 이동하는 프레임워크가 작업을 덜 자주 수행하게 됩니다. 그것은 모두가 내면화해야 하는 것입니다. 그렇다고 해서 덜 유용한 것은 아닙니다. 그것은 단지 짐승의 본성일 뿐입니다. 이러한 부담을 제거하는 유일한 방법은 단일 구현과 단일 배송 일정을 갖는 것입니다.

다른 개발자는 컴파일러 지시문으로 코드를 뿌리고, 코드를 플랫폼별 라이브러리로 분할하고, 여러 대상으로 컴파일해야 합니다. 내 무례한 부분은 ASP.NET Core 팀이 다중 대상 지정 및 다중 플랫폼 시나리오에 대한 더 나은 런타임 및 도구 지원에 관심을 가질 수 있도록 독식하기를 원합니다. 그리고 당신의 팀이 그것을 원하면 우리가 그것을 얻을 수 있습니다. 제 실질적인 부분은 최소한 .NET Standard를 대상으로 하는 ASP.NET Core의 주기적 릴리스가 있어야 한다고 말합니다. 어쨌든 실제 안정적인 릴리스를 만들어야 합니다. 아무도 git에서 마스터 브랜치를 컴파일하고 프로덕션에 배포하지 않을 것입니다. .NET Standard의 더 작은 반복을 수행하고 태그가 지정된 ASP.NET 릴리스와 일치시키지 않는 이유는 무엇입니까?

우리는 같은 일을 합니다. 우리는 여전히 많은 라이브러리에 대해 netstandard를 목표로 하고 있으며 여기에는 ifdef가 포함되어 있습니다. 그러나 다른 사람들은 2.x 기간에 새로운 API를 활용할 수 있도록 netstandard를 대상으로 합니다.

요컨대, 나는 당신이 하고 있는 일과 그 이면의 목표를 지지합니다. 그리고 우리가 여기 와서 당신이 내린 결정에 대해 매우 좋은 이유가 있다고 불평하는 것이 어렵다는 것을 압니다. 그러나 많은 사람들이 개척자 기차에 탈 수 없기 때문에 타지 않을 것이고, 다른 사람들은 그것이 어디로 가는지 모르기 때문에 타지 않을 것입니다.

솔직한 질문(Microsoft가 아닌 제 질문입니다)입니다. 새로운 기능보다 호환성을 선호하십니까? 그렇다면 왜 ASP.NET Core를 선택합니까?

또 다른 간단한 생각: 이와 같은 모든 스레드에는 "오래된" .NET 지원에 대한 양보가 이루어졌기 때문에 다른 그룹의 사람들이 화를 내는 동등하지만 반대되는 스레드가 있습니다.

흥미롭게도 대부분의 타사 제품에는 이미 사용 가능한 netstandard 릴리스가 있습니다. .NET Framework에서 우리를 유지하는 것은 주로 Microsoft 종속성이며 그 중 일부는 반쯤 포기된 것 같습니다(예: OData).

😞

@마크렌들

• 이 스레드에서 볼 수 있는 불만 중 상당수는 작성자가 실제로 의미하는 바가 ".NET Core 2.0에서 X를 수행하는 방식을 변경해야 함"인 경우 ".NET Core 2.0에서 X를 수행할 수 없습니다"의 변형입니다. . 예, 변경해야 합니다. 아니, 나쁜 일이 아니다. ASP.NET MVC 응용 프로그램에 PDF 또는 DOCX 파일로 작업을 수행하는 작은 개별 기능이 있고 그 작업을 수행하는 더 좋은 방법을 실제로 찾을 수 없는 경우(해 본 적이 있습니까?) 기능을 Windows Server의 전체 .NET에서 실행되는 마이크로서비스로 내보내고 .NET Core 애플리케이션에서 HTTP API로 호출합니다. 응용 프로그램을 분해하고 특정 기능을 작은 독립형 서비스로 이동하는 것은 해결 방법이 아니라 범용 모범 사례입니다.
NB 내가 말할 수 있는 한, OpenXML 패키지는 이제 .NET Standard를 지원하므로 Word/Excel/무엇이든 사용하는 것이 불가능해서는 안됩니다.<<

다른 사람들이 이미 말했듯이 멋진 디자인의 아키텍처를 변경하는 것은 좋은 계획이 아닙니다. 우리의 경우 WPF 애플리케이션 테스트와 서버 간에 코드를 공유합니다. 우리가 차이를 더 많이 만들수록 유지해야 하는 것이 더 복잡해집니다.

PDF, DocX 생성에 사용할 수 있는 최고의 도구를 조사하는 데 많은 시간을 할애했으며 개방형 XML을 사용하는 것만큼 간단하지는 않습니다. 타사 라이브러리를 사용하는 이유는 타사에서 개발한 수만 줄의 코드가 있고 개발/유지관리/테스트할 필요가 없기 때문입니다. 그게 요점입니다.

.net 버전 관리가 매우 복잡해졌습니다. 앞으로 ASP.net이 전체 .net 프레임워크에서 사용될 수 있을지 확실하지 않습니다. 서버와 데스크톱 응용 프로그램 간에 코드를 공유해야 하기 때문에 최신 버전의 ASP.Net을 사용할 수 없다는 의미입니까? 이것은 단기적으로는 문제가 되지 않지만 장기적으로는 보안 개선 등으로 인해 최신 버전에서 너무 멀어지고 싶지 않습니다. 내 보트에는 전체 프레임워크와 어떤 형태의 호환성이 필요한지 다른 사람들이 많이 있다고 확신합니다.

내가 하는 일을 명확히 하기 위해 다양한 WPF 앱과 내 서버 간에 공유되는 세 개의 자체 라이브러리가 있습니다. 이 시점에서 내가 사용하고 있는 Apis가 .net 코어에서 사용 가능하거나 사용 불가능할 수 있는지 전혀 모릅니다. 그런 다음 해당 라이브러리에서 docx 및 pdf를 생성하기 위해 Telerik 및 SyncFusion의 WPF 도구의 전체 데스크톱 버전을 사용합니다. 이러한 도구에서 사용하는 기능의 일부 또는 전부는 .net core에서 사용 가능하거나 사용하지 못할 수 있습니다. 수도 있고 아닐 수도 있는 응용 프로그램을 개발하는 것은 매우 어렵습니다. Microsoft는 .net에 뛰어난 기본 프레임워크를 가지고 있으며 .net 코어 뒤에 있는 이유를 이해하고 있습니다. Microsoft는 이전 버전과의 호환성의 중요성을 잊은 것 같습니다.

스테판

@마크렌들

아, 죄송합니다. 귀하의 표본 크기가 그렇게 큰지 몰랐습니다. 결정이 마음에 들지 않는 사람들에 대한 강한 편견이 있는 댓글 257개? 그것에 대해 논쟁하기 어렵습니다. 면책 조항: 저는 빅 데이터 전문가가 아닙니다.

내가 당신에게 무슨 짓을 했는지 모르지만, 이렇게 옹알이를 하거나 낮은 수준의 징징거릴 필요는 없습니다. 이 스레드는 단지 예일 뿐입니다.

@stefanolson

.net 버전 관리가 매우 복잡해졌습니다.

이것은 우리 모두 가 동의할 수 있는 몇 안 되는 것 중 하나라고 생각합니다.

.Net Core x로 이식하려고 합니다.
우리의 가장 큰 문제는 다음과 같습니다.
NewRelic (.Net Core 계획이 없으므로 alt를 찾아야 함)
NH (EF Core에 기능이 없는 경우).
ServiceBase (여름에 .Net Core 2에 나올 것 같습니다)

우리는 중간에 Core 1.0을 목표로 삼고 NH, EF 업그레이드를 기다리거나 창의력을 발휘해야 할 것 같습니다.

Razor 페이지 tbh를 사용할 수 없음을 의미합니다. ASP.NET Core 2.0에는 많은 작은 기능이 있지만 1.x로 다시 포팅되지 않는 큰 기능이나 수정 사항은 없습니다. EOL은 매우 현실적이며 개인적으로 앞으로 .NET Framework를 지원하는 ASP.NET Core 2.0이 도움이 될 것이라고 생각하지 않습니다. 우리는 여기서 방향 변경에 대해 논의하고 있습니다. .NET Framework를 영원히 지원하든 말든, 그 사이에는 정말 아무 것도 없습니다.

Razor 페이지보다 조금 더 커서 이동할 이유가 없습니다 . 이 두 가지가 모두 존재하는 (현재) 시나리오는 없습니다.

1. 우리는 내내 지원됩니다
2. 반대쪽에 실제 업그레이드가 있습니다.

사실 ASP.NET Core는 생태계 없이는 그다지 유용하지 않습니다. 텍스트를 다시 렌더링하는 컨트롤러를 갖는 것은 훌륭하지만 많은 시나리오에는 유용하지 않습니다. API가 필요합니다. 우리는 도서관이 필요합니다. 우리는 생태계가 필요합니다. 그래서 처음에 .NET을 선택했습니다 .

이 변경 사항은 현재 사용 사례를 완전히 지원하는 프레임워크에서 아직 준비되지 않은 프레임워크로 진행됩니다. 준비도 얼마 남지 않았습니다. 그리고 준비가 되었는지 테스트하기 위한 미리보기도 일반적으로 제공되지 않습니다. 준비될 것에 대한 약속 을 파악하기 위한 마이그레이션은 사용할 수 없습니다. 우리는 많은 약속을 믿고 있으며 많은 약속이 불타버릴 것입니다. 그것은 이러한 것들을 마케팅하는 최악의 방법입니다. 과도한 약속과 과도한 전달(전반적인 경험)입니다.

ASP.NET Core가 훌륭하다고 생각합니다. 멋진 일을 하고 계십니다. 운이 좋게도 일부 도움이 되었습니다. 그러나 이 시점에서 이 스위치는 나쁩니다. 이식될 것이라고 생각하는 모든 것이 실제로 2.x 시간 프레임에 이식된다면 훌륭합니다. 그런 다음 3.x에서 변경하십시오. 대안이 준비되기 전에 이식하고 EOL 수명선을 종료할 기한을 설정하는 것은 좋지 않습니다. 사람들에게 유지 관리 -> EOL 버전으로 이식하라고 말하는 것은 좋지 않습니다.

지금 변경하지 마십시오. .NET이 이것보다 낫습니다. 여기 있는 모든 사람이 귀하를 걱정하는 것만큼 귀하도 사용자에 대해 관심을 갖고 있음을 보여주십시오. 우리가 돕고 싶지 않았다면 여기에 있지 않았을 것입니다.

@FransBouma 당신은 Microsoft가 수많은 GitHub 문제 스레드보다 훨씬 더 명확한 그림을 제공하는 기술로 사람들이 하는 일에 대한 원격 측정, 피드백 및 기타 데이터의 방대한 데이터베이스를 가지고 있다는 것을 잘 알고 있어야 합니다. 지적하는 것은

아 몰라, 이 스레드의 게시물을 읽으면서?

.net 버전 관리가 매우 복잡해졌습니다. 앞으로 ASP.net이 전체 .net 프레임워크에서 사용될 수 있을지 확실하지 않습니다. 서버와 데스크톱 응용 프로그램 간에 코드를 공유해야 하기 때문에 최신 버전의 ASP.Net을 사용할 수 없다는 의미입니까? 이것은 단기적으로는 문제가 되지 않지만 장기적으로는 보안 개선 등으로 인해 최신 버전에서 너무 멀어지고 싶지 않습니다. 내 보트에는 전체 프레임워크와 어떤 형태의 호환성이 필요한지 다른 사람들이 많이 있다고 확신합니다.

다양한 .NET 런타임 간의 코드 공유 스토리는 .NET Standard입니다. 라이브러리는 .NET Core 및 .NET Framework에서 공유되는 코드를 대상으로 해야 합니다.

Microsoft는 이전 버전과의 호환성의 중요성을 잊은 것 같습니다.

문제는 ASP.NET Core가 이전 버전과 호환되도록 의도된 적이 없다는 것입니다... 그래서 ASP.NET 4.x에서 그렇게 큰 패러다임 전환이 있었던 것입니다. 이전 버전과의 호환성이 상위 비트라면 .NET Framework에서 ASP.NET 4.x를 사용하는 것이 더 나을 것 같습니다. 이는 가까운 장래 에 지원되며 Windows가 살아있는 한 보안 패치가 적용됩니다.

의도 한 것이 아니더라도 1.0은 이전 버전과 매우 호환되었습니다! 이는 생태계의 방대한 유산 전체를 지원했으며 우리는 이를 높이 평가했습니다. 그 당시에는 아무도 자신의 케이크를 나눠주거나 먹지 않아도 되는 것처럼 보였습니다.

@NickCraver

Razor 페이지보다 조금 더 커서 이동할 이유가 없습니다. 이 두 가지가 모두 존재하는 (현재) 시나리오는 없습니다.

자세히 설명해 주시겠습니까?

사실 ASP.NET Core는 생태계 없이는 그다지 유용하지 않습니다. 텍스트를 다시 렌더링하는 컨트롤러를 갖는 것은 훌륭하지만 많은 시나리오에는 유용하지 않습니다.

그것도 정말 빨리 할 수 ​​있어요 😉

ASP.NET Core가 훌륭하다고 생각합니다. 멋진 일을 하고 계십니다. 운이 좋게도 일부 도움이 되었습니다. 그러나 이 시점에서 이 스위치는 나쁩니다. 이식될 것이라고 생각하는 모든 것이 실제로 2.x 시간 프레임에 이식된다면 훌륭합니다. 그런 다음 3.x에서 변경하십시오. 대안이 준비되기 전에 이식하고 EOL 수명선을 종료할 기한을 설정하는 것은 좋지 않습니다. 사람들에게 유지 관리 -> EOL 버전으로 이식하라고 말하는 것은 좋지 않습니다.

2.x(지원) 및 3.x(삭제)가 1.x(지원) 및 2.x(삭제)보다 나은 이유를 모르겠습니다. 저에게 설명해 주시겠습니까? 그게 무슨 차이가 있습니까?

ASP.NET 변형의 장기적인 지원에 관심이 있는 사람들을 위한 몇 가지 //BUILD 2017 세션 권장 사항:

• T6009 ASP.NET Web Forms 업데이트
  
  
  
  • 즉, 그들은 여전히 ​​완전한 .NET 웹 플랫폼을 개발 중입니다.
  
  
• ASP.NET Core에 대한 T6072 지원: LTS란 무엇입니까?
  
  
  
  • 제 생각에는 지금 미친 듯이 업데이트되고 있다고 생각합니다 :grimacing:
  
  

@davidfowl :

그게 무슨 차이가 있습니까?

2.0 이후 에 출시될 가장 중요한 누락 API 중 일부를 약속했기 때문에?

@yaakov-h

2.0 이후에 출시될 가장 중요한 누락 API 중 일부를 약속했기 때문에?

ASP.NET Core에서 어떤 것이 있는지 알려주시겠습니까?

@davidfowl System.DirectoryServices, System.Drawing은 위에서 언급했습니다.

솔직한 질문(Microsoft가 아닌 제 질문입니다)입니다. 새로운 기능보다 안정성과 호환성을 선호하십니까? 그렇다면 왜 ASP.NET Core를 선택합니까?

나는 이것이 아주 좋은 질문이라고 생각한다. 전체 .NET 프레임워크가 오늘날 필요한 모든 것을 제공한다면 왜 완전히 다른 스택으로 마이그레이션하는 데 열심입니까? .NET Core와 ASP.NET Core의 이름이 .NET int 없이 달랐다면 마이그레이션 문제에 대해 논쟁하는 사람들이 훨씬 줄어들 것이라고 생각합니다. 더 빠르게 움직이는 Go 또는 Node.js 웹 스택으로 마이그레이션할 수 없다고 불평하는 사람은 아무도 없습니다.

@davidfowl 이 ASP.NET MVC 5.x와 역호환되는 것과 .net 프레임워크와 역호환되는 것은 별개입니다. .net 프레임워크를 삭제하는 것은 큰 일입니다...

2.x(지원) 및 3.x(삭제)가 1.x(지원) 및 2.x(삭제)보다 나은 이유를 모르겠습니다.

2.x가 곧 출시될 것이기 때문입니다.

@davidfowl System.DirectoryServices, System.Drawing은 위에서 언급했습니다.

그것들은 ASP.NET Core 1.x 또는 2.x와 아무 관련이 없으며 온라인 상태가 되면 둘 다에서 실행됩니다.

내가 말했듯이, 나는 단지 FUD와 그것의 일부를 부르기 위해 여기에 있습니다. 이 스레드는 너무 커져서 아무도 일부 응답에서 사실을 볼 수 없습니다.

@FransBouma 당신은 Microsoft가 수많은 GitHub 문제 스레드보다 훨씬 더 명확한 그림을 제공하는 기술로 사람들이 하는 일에 대한 원격 측정, 피드백 및 기타 데이터의 방대한 데이터베이스를 가지고 있다는 것을 잘 알고 있어야 합니다. 지적하는 것은

@markrendle 원격 측정은 마술이 아닙니다. ppl/dev가 전환하지 않는 이유, 다른 스택으로 전환한 이유, 프로젝트의 중요성, 스택을 얼마나 좋아하는지(컨설팅이나 oss를 통해 다른 사람을 돕는) 또는 그들이 하는 일을 측정할 수 없습니다.

이 스레드는 바로 피드백입니다.

2.x(지원) 및 3.x(삭제)가 1.x(지원) 및 2.x(삭제)보다 나은 이유를 모르겠습니다. 저에게 설명해 주시겠습니까? 그게 무슨 차이가 있습니까?

@davidfowl 시간.
조금 안정될 시간. 사물을 평가하는 시간. 한 번에 한 가지를 변경할 시간입니다. netstandard2 패키지를 rtm과 함께 사용할 시간입니다. 라이브러리를 netstandard1(어려움) 대신 netstandard2(더 쉬움)로 이동할 시간입니다. 나를 위해 한 번에 한 가지 물건을 바꿀 때입니다.
당신은 aspnet을 사용하지만 내 제품은 aspnet일 뿐만 아니라 많은 라이브러리와 절충안 및 생태계의 조합입니다.

2.x가 곧 출시될 것이기 때문입니다.

그게 무슨 상관이야? 2.0이 연말이나 1월에 나온다면? 차이가 날까요? 2.0에서 1.x가 가치가 없는 이유는 무엇입니까?

@yaakov-h @shanselman 이 말한 곳 에서 언급되었습니다(강조 내)

AD – 완전히, 이것은 LDAP를 직접 호출하려는 경우 공백입니다. Windows Auth NOW에 대해 확실히 인증할 수 있습니다. 우리는 여름 기간 동안 Core 2.0을 위한 DirectoryServices 네임스페이스를 특별히 가질 계획입니다.
그리기 - 완전히, 이것은 공백입니다. 우리는 이것을 Core 2.0에서 여름 기간 에 가질 계획입니다. 이 때까지 이러한 netstandard 옵션은 ImageSharp, ImageResizer, Mono 옵션 등도 존재합니다.

@davidfowl 버전이 아니라 .net 코어 및 생태계의 날짜와 성숙도에 관한 것입니다.

@hikalkan

죄송합니다. 매우 높은 수준의 POV에서 이해하지만 기술적인 관점에서는 이해하지 못합니다. 아마도 이것은 기술적인 논의가 아닌가?

@enricosada

조금 안정될 시간. 사물을 평가하는 시간. 한 번에 한 가지를 변경할 시간입니다. rtm과 함께 netstandard2 패키지를 사용할 시간입니다. 라이브러리를 netstandard1(어려움) 대신 netstandard2(더 쉬움)로 이동할 시간입니다. 나를 위해 한 번에 한 가지 물건을 바꿀 때입니다.
당신은 aspnet을 사용하지만 내 제품은 aspnet일 뿐만 아니라 많은 라이브러리와 절충안 및 생태계의 조합입니다.

특히 ASP.NET Core 2.0에 차이가 있는 이유는 무엇입니까? ASP.NET Core에서 무엇을 선택하든 플랫폼에서 이러한 이점을 얻을 수 있습니다.

@markrendle 누군가 나에게 달력을 가져다 주었습니다. 왜냐하면 계절은 전체 분기에 걸쳐 있고(같은 분기의 다른 항목보다 3개월이 빠를 수 있음) 남반구 사람들에게 특히 혼란스럽기 때문입니다.

@enricosada 원격 측정 및 기타 데이터 소스(웹 분석, 검색 데이터, 직접적인 고객 피드백)에서 엄청나게 많은 유용한 정보를 얻을 수 있습니다. GitHub의 화난 몹으로부터 얻을 수 있는 것보다 훨씬 더 많습니다(하지만 각 개인의 분노가 정당화될 수 있음).

@yaakov-h 음, .NET Core 2.0(및 ASP.NET Core 2.0)에 대한 현재 예상 RTM은 7월/8월/9월인 Q3 달력이고 북반구의 여름은 대부분 7월/8월/9월입니다. , 그래서 그것은 기본적으로 같은 것입니다.

원격 측정 및 기타 데이터 소스(웹 분석, 검색 데이터, 직접적인 고객 피드백)에서 엄청나게 많은 유용한 정보를 얻을 수 있습니다.

하지만 이 원격 측정(적어도 자동화된 부분)이 엔터프라이즈 배포에 얼마나 안정적인지 궁금합니다. (대부분의 반발이 거기에서 나오는 것 같기 때문입니다.)

2.x(지원) 및 3.x(삭제)가 1.x(지원) 및 2.x(삭제)보다 나은 이유를 모르겠습니다. 저에게 설명해 주시겠습니까? 그게 무슨 차이가 있습니까?

@davidfowl 시간. 그리고 적절한 발표. 메시지가 더 명확했다면 사람들은 놀라지 않았을 것입니다.

@davidfowl 시간. 그리고 적절한 발표. 메시지가 더 명확했다면 사람들은 놀라지 않았을 것입니다.

이해는 하지만 실제로 이식하는 능력에 차이가 있을 것이라고 생각하지 않습니다. 동일한 EOL 정책이 여전히 존재합니다.

좋아, 이 문제를 이해하는 데 어려움을 겪은 후, 나는 나와 같이 어려움을 겪고 있고 또한 몇 가지 질문이 있는 사람들을 위해 몇 가지 통찰력을 제공하고 싶었습니다.

따라서 올바르게 이해한다면 결국 넷 프레임워크를 대체하는 넷표준을 갖게 될 것입니다.

따라서 netcore가 존재하지 않고 aspnet core가 netstandard를 기반으로 한다고 가정하겠습니다. 즉, 기능이 더 느려집니다.

예시:
2017 asp.net은 기능 A를 원합니다.
2018 netstandard는 기능 A를 구현합니다. ns에서 기능 A를 얻습니다.

팀이 말하는 것은 netcore가 netstandard를 기반으로 하지 않도록 하는 것입니다.
2017 asp.net은 기능 A를 원합니다
2017 aspnet 팀은 기능 A를 구현합니다. Asp.Net Core는 netcore에서 기능 A를 얻습니다.
2018 netstandard는 기능 A를 구현합니다. ns에서 기능 A를 얻습니다.

따라서 이 결정은 실제로 방정식에 더 많은 "유연성과 속도"를 가져옵니다. 누가 사용할 수 있는지, 피드백 등을 위한 더 빠른 릴리스. 네트 프레임워크의 느린 평화에 큰 도움이 된다고 생각합니다. 기능은 NS에 도달하면 정말 성숙해질 것입니다.

netstandard 2를 기반으로 하는 netcore가 있다는 것이 기능이 1년(또는 임의의 기간) 후에 출시된다는 것을 의미한다면 사람들은 여전히 ​​이것을 원한다고 주장할까요? 이것은 NET Framework 에 익숙한 시나리오입니다.

이것은 다른 사람에게 의존하지 않고 물건을 배송할 수 있는 aspnet 팀의 천국이며, 빠른 물건을 얻을 수 있는 고객에게도 좋은 소식입니다. 빠른 작업을 수행할 수 없는 경우 이전 버전을 고수하는 것이 합리적인 절충안입니다.

라이브러리 작성자는 여전히 netstandard를 목표로 삼아야 하며 그렇게 할 수 있다면 전혀 걱정할 필요가 없습니다.
netstandard(아마도 razor 페이지(?))에 없는 것이 필요한 경우 netcore를 대상으로 해야 합니다. 시나리오 1에서는 razor 페이지가 존재하지 않을 수도 있습니다. 이것이 어떻게 나쁠 수 있는지 나는 그것이 공정하다고 말할 수 있습니다.

따라서 문제는 현재 NET Framework에서 Net Core로 이동하는 것을 제한하는 종속성이 무엇입니까?
저만 여기 있을 수 있지만 aspnet 코어가 NET Framework에서 영원히 작동할 것이라고는 예상하지 못했습니다. 이것이 "전환" 단계라는 것이 분명했습니다. 현재 NET Framework가 필요한 모든 개발은 splited 입니다. (아니요, 이것은 마이크로 서비스가 아니며 그보다 훨씬 간단합니다).

2.x 지원 및 3.x 드롭은 1.x 지원 및 2.x 드롭과 다르지 않습니다. 나는 여기에서 추측하고 사람들이 시나리오를 명확하게 이해하지 못한다고 말할 것이므로 이것이 적어도 일부를 명확히 하기를 바랍니다.

@NickCraver 당신은 마이크로소프트가 이 결정을 되돌리기를 원한다고 말했습니다. 격리된 넷코어를 사용하지 않고 더 느린 기능 릴리스를 사용하려면 어떻게 하시겠습니까? (솔직한 질문)

@davidfowl 현재 제안에 개발자를 걱정시키는 미묘한 숨겨진 문제가 있을 수 있다고 생각합니다.
asp.net(netcore 포함)에 대한 기능 A가 있는 경우 마케팅 및 배송(그리고 management/pm 체크박스 선택)을 할 수 있으며 netstandard에서 구현하는 데 "게으름"이 될 수 있습니다. 불확실에 대해서는 여기를 참조하십시오.
따라서 이전 예에서 netstandard는 기능 A가 2019년 또는 2020년에 있을 수도 있고 2018년 대신에 없을 수도 있습니다. <-- 이것은 가능한 문제처럼 보입니다(?) 맞습니까? Microsoft는 여기에서 무언가를 약속할 수 있습니까?

발표가 마음에 드는지에 대해서는 의견이 갈릴 수 있지만 토론에 시간을 할애해 주신 @davidfowl @DamianEdwards 와 @shanselman 덕분입니다. 이는 참여도와 개방성이 증가했다는 또 다른 증거입니다.

나는 일부 사람들이 타이밍 등에 대해 논쟁할 것이라고 확신하지만, 그것은 진전입니다.

예시:
2017 asp.net은 기능 A를 원합니다.
2018 netstandard는 기능 A를 구현합니다. ns에서 기능 A를 얻습니다.

팀이 말하는 것은 netcore가 netstandard를 기반으로 하지 않도록 하는 것입니다.
2017 asp.net은 기능 A를 원합니다
2017 aspnet 팀은 기능 A를 구현합니다. Asp.Net Core는 netcore에서 기능 A를 얻습니다.
2018 netstandard는 기능 A를 구현합니다. ns에서 기능 A를 얻습니다.

그들이 했어야 할 일은 다음과 같습니다.
2017 aspnet 팀은 netstandard2.0을 지원하는 lib X에 필요한 기능을 빌드합니다. 이 방법으로 aspnet은 .netstandard가 실행되는 모든 것에서 작동하며 lib X는 .NET full에서도 사용할 수 있으므로 사용자는 .net full에서 실행할 수 있습니다(단지 너겟 설치만 가능).

대신, 그들은 이것을 하지 않고 lib X를 .NET 코어로만 강제합니다(그렇지 않으면 처음에 이 스레드/결정이 필요한 이유). lib X가 CoreCLR 기능을 필요로 하는 매우 고급인 경우 Microsoft는 이러한 고급 기능이 .NET 전체 CLR로 이식되지 않는 이유를 자문해야 합니다.

대체로 MS가 Azure 고객에게 AWS 또는 Google 클라우드의 JVM/NodeJS 기반 컨테이너와 경쟁할 수 있도록 Azure의 컨테이너에서 사용할 수 있는 스택을 제공하기 위해 빠르게 움직이는 .NET 코어/aspnet 코어가 필요한 정치처럼 느껴집니다. 그들의 비즈니스 관점에서 나는 그것을 이해할 수 있습니다. 그러나 그것이 보여 주는 것은 MS가 .NET 코어를 따라잡을 수 있을 만큼 충분한 리소스를 .NET 전체에 배치하지 않기 때문에 더 빠른 발전을 위해 .NET 전체에 관한 우선 순위가 없다는 것입니다. 지난 2년 동안 .NET 전체에 추가된 API의 양을 보십시오. 큰 팀이 그 일을 하고 있다는 뜻입니까?

아니요.

Microsoft는 대규모 데이터베이스 시스템인 SQL Server Enterprise를 판매합니다. 그것은 멋진 암호화 기능과 함께 제공됩니다. .NET Core에서는 지원되지 않습니다. 값비싼 데이터베이스 시스템의 잠재 고객인 기업에 .NET Core 2.0을 즐겁게 판매하십시오.

'빨리' 이동하고 싶을 수도 있지만 이동하려는 목적지를 완전히 이해하지 못한다면 먼저 결정하는 데 1-2분 정도 걸리는 것이 도움이 됩니다.

생각하면 할수록 대부분의 사람들이 가지고 있는 문제는 우리가 .net과 asp.net 사이의 줄을 끊고 있다고 느낀다는 것입니다.
현재 asp.net, asp.net 코어(.net) 및 asp.net 코어(core)가 있습니다. 따라서 코어가 없는지, 적은지 또는 완전한지 여부를 선택할 수 있습니다.

버전 관리가 제대로 전달되지 않았기 때문에 사람들은 asp.net 및 asp.net 코어(.net)가 고착된 동안 혁신과 진행이 마지막 부분일 뿐이라고 생각합니다.
시도하지 않고 lib가 netstandard2.0에서 작동하는지 확인할 방법이 없기 때문에 새 프로젝트에서 전체 코어를 사용하는 것은 매우 위험합니다. 따라서 asp.net(이전) 또는 asp.net 코어(이전)로 끝납니다.
그리고 둘 다 오래된 것이므로 system.web과 오래된 asp.net을 사용하는 것이 좋습니다. 그들은 그것을 알고 asp.net 코어가 어쨌든 EOL이기 때문에 귀찮게 할 이유가 없습니다.

따라서 우리는 용감한 선택 코어만 남기고 나머지는 오래되었지만 안정적인 system.web으로 이동합니다. 그리고 우리는 훨씬 더 분열된 생태계에 영원히 갇힐 것입니다.

추신: 나는 이것을 현재의 느낌과 같이 표현하고 있습니다. 해당 asp.net 코어 1.x는 2.x에 비해 "오래되고 구식"입니다. 사실이 아니라 사람들이 그렇게 생각하는 것입니다.

@davidfowl

각 .NET 플랫폼이 자체 속도로 이동하는 경우 최신 .NET Standard를 사용하면 느리게 이동하는 프레임워크가 작업을 덜 자주 수행하게 됩니다.

이것은 이미 발생하고 있으며 우리는 괜찮습니다. 버전 문서는 일반적으로 _vNext_로 채워집니다. 괜찮습니다. 표준을 증가시키기 전에 모든 플랫폼이 동등해질 때까지 기다리는 것보다 앞서 정의된 표준을 보고 플랫폼이 따라잡는 것을 지켜보고 싶습니다. 사람들은 정의와 구현을 위해 참여할 수도 있습니다. 그리고 ASP.NET Core가 릴리스의 표준을 대상으로 했다면 플랫폼과 아키텍처가 새 표준을 구현하는 순간 패키지를 사용할 수 있게 됩니다. 새로운 표준 버전은 VS 업데이트 또는 패키지를 통해 제공될 수 있습니다.

.NET Standard가 커뮤니티에서 계획한 노력처럼 들리지 않지만 그것이 제시되는 방식입니다. 검토를 통과한 구현된 계약의 스냅샷과 비슷합니다. 그리고 주요 프로젝트가 이를 목표로 하지 않는다면 출시에 대한 계획이 거의 없을 것입니다.

우리는 똑같은 일을 한다

오 좋네. 공유된 불행이 최고의 불행입니다. 플랫폼/구성 항목이 있는 Csproj 및 sln 파일은 빌드 조합이 항상 선언되지 않고 유추되기 때문에 정말 짜증납니다. 따라서 VS는 가능한 모든 조합이 중요하다고 가정하기 때문에 내가 실제로 존재하는 것보다 더 많은 빌드 조합을 가지고 있다고 생각할 수 있습니다. 그리고 파일에 플랫폼/구성 조합을 선언할 수만 있다면 필요하지 않은 추가 섹션이 있어야 합니다. csproj PropertyGroup 요소에서 Substring 와 같은 기능을 사용하여 사용자 정의 속성을 단순화하지만 이러한 조건은 빌드 구성을 결정하는 데 사용되므로 여기에 전체 문자열 값이 있어야 합니다. 이런 종류의 물건은 그렇게 번거롭지 않아야합니다.

솔직한 질문(Microsoft가 아닌 제 질문입니다)입니다. 새로운 기능보다 호환성을 선호하십니까? 그렇다면 왜 ASP.NET Core를 선택합니까?

개인적으로, 아닙니다. 내가 해야 할 일을 할 수 있는 방법이 있는 한, 테스트할 PITA나 이점이 거의 없는 큰 노력이 아닌 한 코드를 다시 작성하는 데 신경 쓰지 않습니다. 그래서 저는 가장 추진력과 잠재력이 있는 것을 선택하겠습니다. 그러나 Win32, COM, CORBA, ADO.NET, 여러 보고 엔진, 다양한 웹 API, CEF/Firefox/IE와 같은 내장 브라우저(물론 지원되지 않기 때문에 에지는 없음)와 같은 여러 기술에 걸쳐 프로젝트를 수행해야 합니다. 여러 공급업체별 사항은 제가 부끄러워하지 않도록 하겠습니다. 플러그인으로 할 수 있는 것을 구현하지만 대부분의 경우 호스트 실행 파일에서 최소 공통 분모와 결혼했습니다. 많은 기술을 다루는 것은 성가신 일이지만 정적입니다. 많은 데스크탑/서버 항목이 그렇습니다. 내가 상호 운용할 수 있는 도구만 주어지면 할 수 있습니다. 그러나 내가 기억하는 사용되지 않는 프레임워크는 적을수록 좋습니다.

하지만 ASP.NET은 웹 스택의 일부이며 웹 스택은 최신 상태를 유지해야 한다고 생각합니다. 다른 사용 사례가 있으며, 사용하지 않을 합당한 이유가 있거나 호환되지 않는 심각한 코드 기반이 없는 한 웹 작업에 최신 플랫폼을 사용할 것이라는 불행한 기대가 있습니다. 웹 표준이 빠르고 크게 변하기 때문에 최신 정보를 유지하려고 노력합니다. 웹과 보조를 맞추는 대부분의 사람들은 새로운 기술을 고수하고 있으며 오래된 스택에 새로운 것을 구현하는 것은 다소 고통스러울 수 있습니다. 특히 ASP.NET이 PHP 및 Node와 경쟁하는 상황에서 재능과 관심을 끌기 위해 보다 현대적인 스택을 유지해야 합니다. 웹 작업을 덜 하고 싶지만 불행히도 새로운 UI 기대입니다. 표준을 고수하면 두 세계의 장점을 모두 누릴 수 있기를 바랐지만 이는 제한된 시간 동안 제공되는 것 같습니다.

따라서 올바르게 이해한다면 결국 넷 프레임워크를 대체하는 넷표준을 갖게 될 것입니다.

정확하지 않습니다. 어떻게 그런 결론을 내리셨는지 모르겠습니다. .NET Standard는 항상 이를 지원하는 각 런타임의 하위 집합입니다.

그것은 몇 번 언급되었기 때문에 나는 여기에 미친 것들을 던지고 싶습니다. 내가 말하려는 것은 무슨 일이 일어날지 아무 ​​상관이 없으며, 이 시점에서 모두 추측입니다. 여러 사람들이 .NET Standard 대신 .NET Core를 대상으로 하려는 이유를 묻습니다.

• 우리는 .NET Core에서 해결하고자 하는 주요 사항 중 하나로 문자열을 식별했습니다. 수많은 아이디어가 있지만 그 중 하나는 기본적으로 문자열을 utf8로 설정하는 것입니다(수많은 호환성 문제가 있지만 여기에서 따라오세요).
• 우리가 수정하고 싶은 또 다른 것은 배열/문자열의 저렴한 조각, 인접 메모리 조각을 가져오는 기능입니다. Span<T> 를 추가했으며 이를 나타내기 위해 Buffer<T> 를 찾고 있습니다. String 및 Array가 0 할당이 필요한 슬라이스를 사용할 수 있도록 하는 새로운 인터페이스를 구현한다는 의미일 수 있습니다.
• 이것은 매번 배열을 할당하지 않는 분할을 허용하는 String에 대한 새로운 메소드로 이어집니다.
• 이로 인해 Span<char> 및 Span<byte> 를 사용하는 Int, UInt 등(TryParse)에 대한 오버로드가 발생합니다.
• 이것은 Span<byte> 를 사용하는 새로운 인코딩 루틴으로 이어집니다.
• Buffer<T> 및 Span<T> 를 사용하면 메모리를 균일한 방식으로 나타낼 수 있으며 Span<T> 또는 Buffer<T> 을 사용하는 미리 고정된 버퍼를 전달할 수 있도록 네트워킹 스택을 업그레이드하려고 합니다.
• Kestrel은 2.x 시간 프레임(현재 2.1을 목표로 함)에 HTTP2를 구현하며 ALPN을 수행하려면 SSL 스트림에 대한 새로운 API가 필요합니다(https://en.wikipedia.org/wiki/Application-Layer_Protocol_Negotiation).
• .NET Core의 Http 클라이언트는 이중 스트리밍을 지원하므로 웹 소켓이 아닌 단일 http 요청을 통해 시그널러에서 http를 통한 스트리밍 끝점을 구현할 수 있습니다.
• HttpClient 및 System.Net.Http에서 헤더 파서 구현을 분기하고 개선할 수 있도록 이름을 변경했습니다(https://github.com/aspnet/HttpAbstractions/tree/d1d9bceff56cb44a194ae36923ce687e5e353006/src/Microsoft.Net.Http.Headers). .NET Framework와 .NET Core를 모두 지원하도록 합니다. .NET Core에는 이러한 개선 사항의 복사본이 있습니다. 개선할 필요가 없기 때문입니다(사용할 수 없음).
• 사용할 수 있는 경우 새로운 시나리오를 밝힐 새로운 API가 필요한 새로운 스레딩 기본 요소가 많이 있습니다(https://github.com/dotnet/corefx/issues?q=is%3Aopen+is%3Aissue+ 저자%3Adavidfowl+label%3Aarea-System.Threading), 이것들은 제가 개인적으로 제출한 것 중 일부일 뿐입니다.

핵심 프리미티브를 수정할 수 있는 능력이 없다면, 우리는 그것들을 분기하여 비슷하게 보이지만 그렇지 않은 것을 만드는 것이 좋습니다. 이것이 우리가 ASP.NET Core https://github.com/aspnet/Common/tree/dev/src/Microsoft.Extensions.Primitives 내에 자체 BCL을 가지고 있는 이유입니다.

그것은 .NET의 매우 기본적인 부분에 영향을 미치는 가까운 시일 내에 우리가 수행하는 것을 볼 수 있는 무작위 덤프였습니다.

@FransBouma

.NET Core를 따라잡기 위해 .NET 전체에 충분한 리소스를 배치하지 않기 때문에 더 빠르게 진행합니다. 지난 2년 동안 .NET 전체에 추가된 API의 양을 보십시오. 큰 팀이 그 일을 하고 있다는 뜻입니까?

그것은 사실이 아닙니다. 모든 것이 .NET Framework로 지속적으로 포팅되지만 우리 모두가 알고 있듯이 .NET Core에서 동일한 변경을 수행하는 것보다 위험이 상당히 높습니다. .NET Framework 업데이트로 인해 애플리케이션이 중단되는 것을 모두 싫어하지 않습니까? 우리도 그것을 완화하기 위해 모든 종류의 프로세스를 발명하기 때문에 이를 유지하기 위해 엔지니어링에 가해지는 목 졸림을 믿지 않을 것입니다. 우리는 여전히 그 모든 기능에도 불구하고 기능을 수행할 수 있습니다. 즉, .NET Core만큼 빠르게 이동 하지 않으며 Windows 일정에 따라 제공되는 Windows 구성 요소입니다.

이해는 하지만 실제로 이식하는 능력에 차이가 있을 것이라고 생각하지 않습니다. 동일한 EOL 정책이 여전히 존재합니다.

@davidfowl 맞습니다. 그러나 그것을 어떻게 구성하느냐가 의미가 있습니다. 언제 전달 되는지는 말할 것도 없고요. 사람들이 실제 작업을 수행하는 데 더 많은 시간을 할애할 필요는 없지만 생각하고 올바른 결정을 내리는 데 더 많은 시간을 할애할 수 있습니다.

현재 .NET Framework에서 ASP.NET Core로의 이식/사용을 시작한 경우 다음 세 가지 선택 사항이 있는 것 같습니다.

1. 모든 코드와 종속성을 .NET Core로 이식하고 ASP.NET Core 2.x로 이동합니다.
   
   
   
   • 이것은 최적의 솔루션이 될 수 있지만 많은 작업이 필요할 수 있으며 일부의 경우 타사 라이브러리로 인해 제어할 수 없을 수도 있습니다.
   
   
2. ASP.NET Core 1.x 및 .NET Framework를 계속 사용하고 지원되지 않기 전에 1. 할 수 있기를 바랍니다.
   
   
   
   • 이것은 꽤 위험합니다. 1년(또는 2, 3? 누가 알겠습니까?) 이내에 지원되지 않는 플랫폼에서 실행할 위험이 있습니다.
   
   
3. ASP.NET 4.x로 다시 이동
   
   
   
   • 이 대안이 지원되는 동안 "되돌아가" 이미 시작한 작업을 취소하게 됩니다. 그리고 또한 직면합시다. 이 플랫폼은 앞으로 많은 사랑을 받지 못할 것입니다.
   
   

미리 알고 계획할 수 있었다면 1.과 2. 모두 괜찮은 대안이라고 생각합니다. 문제는 두 대안 모두 꽤 많은 미지수가 있다는 것입니다. A 도서관은 어떻습니까? 도서관 B는 어떻습니까? 라이브러리 A가 이식될 예정입니까?

현재 많은 사람들이 선택이 실제로 무엇을 수반하는지에 대한 명확한 그림 없이 선택을 강요받고 있다고 생각합니다.

@khellang (귀하의 가상 솔루션에서)

1. .NET Framework에서 ASP.NET Core 2.0으로 이동
   
   
   
   • 이것은 꽤 위험합니다. 1년 이내에 지원되지 않는 플랫폼에서 실행할 위험이 있습니다.
   
   

@davidfowl

솔직한 질문(Microsoft가 아닌 제 질문입니다)입니다. 새로운 기능보다 안정성과 호환성을 선호하십니까? 그렇다면 왜 ASP.NET Core를 선택합니까?

정직한 대답:
호의: 안정성과 호환성이 가장 중요합니다. 새로운 기능은 좋지만 출시될 때 기존 생태계 를 깨뜨리면 안 됩니다.
ASP.NET Core를 선택해야 하는 이유: 단순히 OS X 및 Linux에서 실행되기 때문입니다.

.NET(이전 및/또는 코어) 또는 Java와 같은 에코시스템은 기업에서 선택합니다. 그리고 결정을 내릴 때 해당 플랫폼/생태계를 위한 코드를 개발하는 데 많은 노력을 기울입니다.

예를 들어 우리 고객 중 한 명이 이미 ASP.NET Core에 많은 투자를 했습니다. .NET Core의 이전 발표 및 판매 아이디어를 기반으로 코드가 작성되었습니다. 이 새로운 (ASP.)NET Core 코드는 초기부터 (ASP).NET Core의 초기 개발 과정에서 팀과 함께 (고통스럽게) 작성한 서버 및 클라이언트 라이브러리 집합입니다. 비즈니스 논리의.
그리고 이 코드는 Linux 서버에서 실행되고 서비스를 제공하는 것 외에도 현재 이러한 서비스와 통신하는 매우 오래된 응용 프로그램 집합에서도 사용되고 있으며 WPF/Windows Forms/C++/CLI 및 일반 C++(DirectX 항목 포함).

이제 실제 애플리케이션에서 새로운 .NET Core 코드를 재사용하는 것이 불가능하기 때문에 기존 애플리케이션을 위한 .NET Core 코드에 대한 몇 년 간의 노력에 대한 고객의 투자를 단순히 차단하는 것입니다. (새로운 서버와 비즈니스 로직 라이브러리가 구축되었습니다).

질문으로 돌아가서: 기업은 지난 17년 동안 .NET이 제공한 것과 동일한 호환성과 안정성을 기대하면서 .NET Core를 ".NET, 이제 XPlat용"으로 선택할 것입니다. 그리고 솔직히 말해서 이것이 .NET Core의 유일한 이유입니다. 그것을 원하지 않는다면 Node.js 또는 Java를 사용할 것입니다. 둘 다 이제 .NET Core보다 훨씬 더 성숙하고 XPlat입니다.

그리고 조금 더 자세히 설명하자면 .NET Core는 project.json 등을 통해 초기 단계에서 멋지고 빠르게 진행되었습니다. 그런 다음 ".NET과의 호환성"을 이유로 Msbuild 및 .csproj를 위해 project.json을 다시 가져갔습니다. 그리고 이제 정확히 이 ".NET과의 호환성"의 이점도 사라지고 .. 정확히 무엇을 위해?

@생강

우선, 훌륭한 답변!

ASP.NET Core를 선택해야 하는 이유: 단순히 OS X 및 Linux에서 실행되기 때문입니다.

그러고 보니 MVC 5 on mono가 정말 원하셨던 것 같은데요?

질문으로 돌아가서: 기업은 지난 17년 동안 .NET이 제공한 것과 동일한 호환성과 안정성을 기대하면서 .NET Core를 ".NET, 이제 XPlat용"으로 선택할 것입니다. 그리고 솔직히 말해서 이것이 .NET Core의 유일한 이유입니다. 그것을 원하지 않는다면 Node.js 또는 Java를 사용할 것입니다. 둘 다 이제 .NET Core보다 훨씬 더 성숙하고 XPlat입니다.

그리고 조금 더 자세히 설명하자면 .NET Core는 project.json 등을 통해 초기 단계에서 멋지고 빠르게 진행되었습니다. 그런 다음 ".NET과의 호환성"을 이유로 Msbuild 및 .csproj를 위해 project.json을 다시 가져갔습니다. 그리고 이제 정확히 이 ".NET과의 호환성"의 이점도 사라지고 .. 정확히 무엇을 위해?

이것이 기본적으로 문제의 핵심입니다. 귀하의 평가를 기반으로:

이 새로운 (ASP.)NET Core 코드는 (ASP).NET Core의 초기 개발 과정에서 팀과 함께 (고통스럽게) 작성했습니다.

당신은 정말 오래된 ASP.NET 4.x 호환성이 있는 Linux의 기존 .NET Framework를 원했습니다. 정당한 요약입니까?

호의: 안정성과 호환성이 가장 중요합니다. 새로운 기능은 좋지만 출시될 때 기존 생태계를 깨뜨리면 안 됩니다.

.NET Core는 Desktop이 허용하지 않는 병렬 실행을 허용하므로 실제로 Desktop보다 더 안정적인 플랫폼입니다.

다음 버전의 Desktop에서 새로운 기능을 사용하려면 전체 시스템을 새 버전으로 업그레이드해야 하며, 이는 새로운 기능을 사용하려는 앱뿐만 아니라 해당 시스템의 모든 항목에 영향을 미칩니다. 단일 목적을 위한 전용 서버가 있는 경우에는 어느 것이 좋습니다. 그러나 동일한 서버에서 다른 속도로 업그레이드되는(또는 전혀 업그레이드하지 않는) 많은 앱이 실행 중인 경우에는 그렇지 않습니다.

@davidfowl 은 다음과 같이 썼습니다.

.NET Framework, UWP, .NET Core, 모노 등에서 실행할지 여부를 결정하는 것은 프레임워크에 달려 있습니다. 선택 사항입니다. Orleans는 .NET Core와 함께 제공되지 않습니다. ASP.NET Core는 그렇습니다. 그 제품들은 하나이며 동일합니다.

Orleans의 경우 "2.0 Technical Preview" 빌드에서 .NET Standard 1.5를 지원하지만 안정적인 릴리스를 만들기 위해 .NET Standard 2.0을 기다리고 있습니다. 현재로서는 우리를 위한 차단기가 보이지 않습니다. 제 관심사는 미래의 다이버전스에 관한 것뿐입니다. 그러나 그 차이는 어느 시점에서 발생해야 합니다.

👍 @davidfowl & co, 모두의 질문에 답해주셔서 감사합니다!

.NET Core를 따라잡기 위해 .NET 전체에 충분한 리소스를 배치하지 않기 때문에 더 빠르게 진행합니다. 지난 2년 동안 .NET 전체에 추가된 API의 양을 보십시오. 큰 팀이 그 일을 하고 있다는 뜻입니까?

그것은 사실이 아닙니다. 모든 것이 .NET Framework로 지속적으로 포팅되지만 우리 모두가 알고 있듯이 .NET Core에서 동일한 변경을 수행하는 것보다 위험이 상당히 높습니다. .NET Framework 업데이트로 인해 애플리케이션이 중단되는 것을 모두 싫어하지 않습니까? 우리도 그것을 완화하기 위해 모든 종류의 프로세스를 발명하기 때문에 이를 유지하기 위해 엔지니어링에 가해지는 목 졸림을 믿지 않을 것입니다. 우리는 여전히 그 모든 기능에도 불구하고 기능을 수행할 수 있습니다. 즉, .NET Core만큼 빠르게 이동하지 않으며 Windows 일정에 따라 제공되는 Windows 구성 요소입니다.

그것은 aspnet이 .net full에서도 실행될 수 있도록 netstandard2.0 패키지로 의존하는 라이브러리를 릴리스할 수 있다는 사실을 무시합니다. 또한 .NET 전체를 변경하는 것이 위험하지 않은 것은 아니지만 한 번의 변경으로 모든 것이 무너질 수 있는 끔찍하게 조직화된 코드 더미처럼 들리지 않도록 하십시오.

우리는 여전히 그 모든 기능에도 불구하고 기능을 수행할 수 있습니다.

예, 다른 모든 .NET 개발자도 마찬가지입니다. 그러나 당신은 지름길을 택하고(ASPNET 팀이 이전에 여러 번 해왔던 것처럼!) 그런 부담 없이 움직이기를 원합니다. 그러나 그것은 결국 날지 않을 것입니다.

즉, .NET Core만큼 빠르게 이동하지 않으며 Windows 일정에 따라 제공되는 Windows 구성 요소입니다.

여기에 문제의 핵심이 있다고 생각합니다. 맞죠? .NET 코어 팀은 거대 'WinDiv'와 통신하지 않고도 원하는 작업을 수행할 수 있습니다. Microsoft가 내부 정책 문제를 사내에서 해결하지 않고 Windows 정책 없이 .NET 전체 + .NET 코어 버전이 지정/이동하는지 확인하지 않는 이유는 무엇입니까?

Btw, .NET Core 2.0 사용자에게 SQL Server Enterprise의 암호화 API를 판매하는 방법에 여전히 관심이 있습니다.

또한 추가해야합니다. 나는 이 스레드가 얼마나 많은 사람들이 관련되어 있고 여전히 시민의식을 유지하고 있는지에 대해 꽤 감명을 받았습니다 ❤️ 그것은 당신이 인터넷에서 매일 보는 것이 아닙니다 👏 어쩌면 .NET OSS 생태계가 결국 성장하고 있는 것이 아닐까요? 😉

의존하는 라이브러리를 netstandard2.0 패키지로 릴리스하여 aspnet이 .net 전체에서도 실행될 수 있다는 사실을 무시합니다.

또한 .NET 전체를 변경하는 것이 위험하지 않은 것은 아니지만 한 번의 변경으로 모든 것이 무너질 수 있는 끔찍하게 조직화된 코드 더미처럼 들리지 않도록 하십시오.

그것은 크고 오랫동안 존재해 왔습니다. 모든 레거시 시스템과 마찬가지로 일부 부품은 다른 부품보다 우수합니다. 코드의 신뢰성이 떨어지는 것은 아니지만 일부 부분을 변경하는 것이 실질적으로 불가능하게 만듭니다. 베테랑들이 한 영역의 버그 수정이 다른 부분의 응용 프로그램에서 모호한 시나리오를 어떻게 깨뜨렸는지에 대해 이야기할 수 있는 재미있는 이야기가 많이 있습니다. 종속성 경계가 잘 정의되지 않은 경우에 발생합니다. 저를 믿을 필요도 없습니다. referencesource.microsoft.com을 찾아보세요. 현재 위치 업데이트는 .NET Framework에 대한 잠재적인 단 하나의 잠재적인 변경 사항에 대해 구성 스위치를 추가해야 하는 이유입니다. 그것은 물리학입니다, 그것은 단지 빨리 움직일 수 없습니다.

예, 다른 모든 .NET 개발자도 마찬가지입니다. 그러나 당신은 지름길을 택하고(ASPNET 팀이 이전에 여러 번 해왔던 것처럼!) 그런 부담 없이 움직이기를 원합니다. 그러나 그것은 결국 날지 않을 것입니다.

우리는 바로 가기를 좋아합니다! 개발자는 게으르다 😄 . 우리는 또한 .NET Framework가 나타내는 것을 방해하지 않고 .NET Core를 진정으로 개선하기를 원합니다. Sparkle 😄 과 같은 다른 이름으로 이름을 변경해야 했을 수도 있습니다.

여기에 문제의 핵심이 있다고 생각합니다. 맞죠? .NET 코어 팀은 거대 'WinDiv'와 통신하지 않고도 원하는 작업을 수행할 수 있습니다. Microsoft가 내부 정책 문제를 사내에서 해결하지 않고 Windows 정책 없이 .NET 전체 + .NET 코어 버전이 지정/이동하는지 확인하지 않는 이유는 무엇입니까?

물리학에 대한 다른 답변을 읽어보십시오.

Btw, .NET Core 2.0 사용자에게 SQL Server Enterprise의 암호화 API를 판매하는 방법에 여전히 관심이 있습니다.

그건 제 전문 분야가 아니므로 다른 사람이 답을 드리겠습니다.

@khellang lol 그건 GitHub 문제가 아직 트롤을 싫어하는 MS를 끌어들이지 않았기 때문입니다. 현재 Twitter는 아직 downvote가없는 매체입니다. :)

@davidfowl

당신은 정말 오래된 ASP.NET 4.x 호환성이 있는 Linux의 기존 .NET Framework를 원했습니다. 정당한 요약입니까?

아니 정말. 우리 클라이언트는 기존 .NET 4.x(시작할 당시에는 3.5였음) Windows 데스크톱 응용 프로그램을 보완하기 위해 완전한 새/빛나는(마이크로) 서비스가 필요했습니다.

우리는 당신이 모든 반짝이는 Core에 대해 베타 버전이 되었을 때 DTO, 비즈니스 로직, 클라이언트 라이브러리와 함께 ASP.NET Core 위에 완전히 새로운 MVC를 위한 새로운 서버 코드를 작성하기 시작했습니다. 기존 4.6 데스크탑 애플리케이션에서 병렬로 사용되어 완전히 새로운 서버와 통신합니다.

또한 완전히 새로운 ASP.NET Core 서버 중 일부는 Linux에서만 실행되지 않고 Topshelf(전체 4.6 프레임워크 위에 있음)가 있는 Windows 서비스로도 실행됩니다.

따라서 많은 투자가 이루어졌으며 이제 .NET Core 1에 갇힌 것 같습니다. 2로 이동하고 netstandard를 잃는 것도 의미하므로 어셈블리를 재사용할 수 없습니다. 기존 데스크톱 응용 프로그램(서비스 및 관련 라이브러리가 생성됨)을 더 이상 사용할 수 없습니다.

따라서 우리에게 가장 중요한 것은 .NET 4.6 데스크톱 애플리케이션에서 작성하는 새로운 (ASP) .NET Core 라이브러리를 계속 사용할 수 있다는 것입니다. 코드를 실행할 수 있는 데스크톱 .NET 버전이 지원되는 한 .NET Core 버전입니다.

따라서 .NET Core 1이 .NET 4.6처럼 지원되고 .NET 5가 나올 때 .NET Core x로의 선형 업그레이드 경로가 있고 .NET Core x 코드가 .NET Core에서 실행할 수 있는 한. NET 5라면 괜찮습니다.

@gingters asp.net 서비스에서 netstandard2.0에 없는 .net 기능을 사용하고 있습니까?

그렇지 않은 경우 libs가 작동해야 합니다. 그러나 나는 당신이 netstandard2.0에 없는 것에 대해 이야기하고 있다고 생각합니다.

@davidfowl c++/cli dll이 netcoreapp 2.0에서 작동합니까? 조만간 교체되지 않을 오래된 타사 C++/CLI 어셈블리가 있습니다.

@davidfowl 은 다음과 같이 썼습니다.

ASP.NET Core 2.0에는 솔직히 많은 새로운 기능이 없습니다.

어떤 경우에, 왜 이 매우 파괴적인 변화가 지금 발생합니까?

@qrli C++/CLI는 CoreCLR에서 작동하지 않습니다. 지원되지 않는 이유는 다음과 같습니다. https://github.com/dotnet/coreclr/issues/659#issuecomment -91341753

1x에 4년 지원을 제공하고(2x에서 최대한 포팅) 2x로 빠르게 진행하십시오. 느린 도시 교통을 위한 도시 자동차와 고속도로를 위한 페라리. 우리는 .net 세계 밖에서 많은 경쟁을 하고 있습니다.
ASP.Net Core가 성공하면 MS가 4년 동안 1x를 지원할 수 있는 리소스를 제공할 것이라고 확신합니다. 대부분 문화가 바뀔 것입니다.

@idg10 정말 아니에요. 2.x는 코어에서만 사용할 수 있는 성능이 포함된 거의 1.x입니다. 주요 기능은 Razor Pages뿐이라고 생각합니다.

따라서 버전 1.x에 있다고 해서 구식 버전에 있다는 의미는 아닙니다. 그러나 이것은 잘 전달되지 않았습니다.

어떤 경우에, 왜 이 매우 파괴적인 변화가 지금 발생합니까?

이것이 거의 요약되어 있다고 생각합니다.

@할라토레
나는 그것이 _지금_ 하는 것처럼 작동한다는 것을 알고 있습니다. 우리는 지금 1에 머물 수 있습니다. 문제는 앞으로 나아가고 있습니다. 우리가 (ASP) .NET Core 2 라이브러리로 업그레이드하기를 원할 때(또는 더 나쁘게: 필요로 할 때)(즉, 1이 서비스를 중단하고 중요한 보안 구멍이 수정된 경우) 업그레이드할 수 없는 문제에 직면합니다. .NET 데스크톱 앱에서 업그레이드된 패키지가 필요한 라이브러리를 사용할 수 없게 됩니다.

편집/추가: 기존 레거시 데스크톱 앱의 선형 업그레이드 경로에 있는 새로운 고정 .NET Core 라이브러리를 실행할 수 있는 새로운 전체 .NET 프레임워크가 없는 한.

@gingters 이해가 잘 안되네요.

데스크탑 라이브러리가 netstandard2.0에서 작동한다면 코어에서도 실행되어야 합니다. (만약 그들이 wpf 물건 등을 호출한다면 그들은 물론 그렇지 않을 것입니다)
이 경우 asp.net core 2.0을 사용할 수 있어야 합니다.

데스크탑 라이브러리가 netstandard2.0에 없는 것을 사용하기 때문에 코어에서 충돌하는 경우. 그러면 왜 1.x를 유지해야 하는지 알겠습니다. 그리고 짧은 EOL이 왜 문제인지 알 수 있습니다.

2.x가 대부분 핵심 성능 항목만 포함한다는 것을 알고 있다면 1.x가 더 쉽고 더 나은 선택이 될 것입니다(1.x는 2.x에 비해 구식이 아님을 의미합니다). 그리고 그 1.x는 패치를 받고 *년 동안 지원됩니까?

@hallatore 반대 입니다. 이전 애플리케이션: 4.6 전체 프레임워크에서 실행되는 Windows Forms, WPF, C++/CLI, 일반 C++, DirectX, 수백만 줄의 코드 등 pp의 혼합.

.NET Core에서: 새로운 비즈니스 논리 라이브러리(다른 라이브러리도 사용, 즉 .NET Core 버전의 Serilog 사용), 이러한 서비스에 대한 추상화 라이브러리 + 서비스 + 클라이언트 라이브러리. 서비스는 Linux 및 Windows 서비스로 실행되어야 합니다(현재는 전체 .NET 4.6 프레임워크의 Topshelf, 그러나 Windows 서비스 지원이 Core에 도입되는 즉시 변경될 수 있음).

이제 새로운 비즈니스 로직과 추상화 및 서비스 클라이언트 라이브러리도 .NET 4.6 애플리케이션에서 사용됩니다. 이것은 데스크톱 앱이 실행되는 한 전체 .net 프레임워크에서 실행해야 하기 때문에 업그레이드할 수 없음을 의미합니다(전체 프레임워크가 아닌 한 데스크톱이 작동할 수 있는 한 꽤 오래 지속될 것이라고 가정할 수 있습니다). 일반적으로 사라집니다).

@gingters 여전히 netstandard _min(usable)_을 대상으로 하는 솔루션에 공유 라이브러리 프로젝트가 있고 ASP.NET Core 2.0 코드에서 해당 라이브러리를 사용할 수 있을 뿐만 아니라 WPF, Xamarin, UWP 등에서 사용할 수 있도록 패키징할 수 있습니다.

MS 여러분이 여전히 요점을 이해하지 못한다는 것은 정말 슬픈 일입니다. 당신은 여전히 ​​그것이 단지 API 격차 문제라고 생각합니다. 당신은 여전히 ​​사람들이 자신의 코드를 수정할 수 있고 netcoreapp에서 작동할 것이라고 생각합니다... 나는 당신이 구글보다 기업을 훨씬 더 잘 이해한다고 생각했습니다.

그러고 보니 MVC 5 on mono가 정말 원하셨던 것 같은데요?

@davidfowl 내 말은, 어서. 그것은 무시하고 솔직히 모욕적인 대답입니다. MS의 누군가가 더 이상 단일 개발자가 Framework ASP에 할당되었는지 확인할 수 있습니까? 나는 여기서 바보가 되려고 하는 것이 아니지만, 때때로 커뮤니티에서 욕을 먹는 것 같습니다.

내가 .Net Core와 ASP.Net Core를 동일한 제품으로 간주해야 할 이유가 없습니다. 지원하라는 메시지가 전혀 없었습니다. 특히 Mono가 .Net Core 발표 이후에 Microsoft 윙에 들어왔다는 것을 고려할 때. 그것은 항상 .Net의 더 작고 민첩한 xplat 버전으로 메시지를 받았습니다. 그뿐만 아니라 우리 모두는 ASP.Net Core가 실제로 ASP.Net 5였고 모든 곳에서 작동할 예정이었던 시절을 기억합니다. 젠장, 그 변화는 불과 1년 반 전의 일이다.

netstandard20의 자체 호스팅 HTTP 스토리가 효과적으로 "Kestrel 1.x를 사용"합니까? 나는 Nancy 사람들이 그것에 대해 크게 관심을 가질지 확신하지 못합니다. ASP.Net 2.x는 기능 면에서 점진적일 수 있지만 Kestrel 2는 성능상의 이점이 있어 그날 사용할 수 있습니다. 나온다.

@davidfowl

그것은 크고 오랫동안 존재해 왔습니다. 모든 레거시 시스템과 마찬가지로 일부 부품은 다른 부품보다 우수합니다. 코드의 신뢰성이 떨어지는 것은 아니지만 일부 부분을 변경하는 것이 실질적으로 불가능하게 만듭니다. 베테랑들이 한 영역의 버그 수정이 다른 부분의 응용 프로그램에서 모호한 시나리오를 어떻게 깨뜨렸는지에 대해 이야기할 수 있는 재미있는 이야기가 많이 있습니다. 종속성 경계가 잘 정의되지 않은 경우에 발생합니다.

흥미로운 댓글이라고 생각합니다. @davidfowl 및 @DamianEdwards 와 함께 기록하고 있는 ASP.NET 4의 레거시 조각 중에서 당신이 정말로 남기고 싶었던 것을 골라내는 이전 NDC 회의 세션을 본 기억이 있습니다.

그러나 이 의견은 또한 우리 자신의 코드베이스에 대한 많은 사람들의 우려를 반영한다고 생각합니다. 우리는 종종 빈약한 종속성 경계로 잘 설계되지 않은 대규모 레거시 시스템을 유지 관리합니다. .NET Core용으로 이러한 시스템 중 일부를 다시 작성하는 것은 사실상 불가능합니다. 비즈니스는 그렇게 많은 변화의 위험을 허용하지 않습니다.

정답이 뭔지 모르겠습니다. 그러나 우리 자신의 응용 프로그램을 위해 우리는 가까운 장래에 전체 프레임워크와 ASP.NET4/MVC5를 사용할 것이라는 것을 알고 있습니다. MVC5가 _마침내_ GitHub로 옮겨 졌기 때문에 사랑을 받기를 바랍니다. 더 나은(예: 더 나은 비동기 지원, 성능 개선 등) 더 나은 것을 만들기 위해 제 시간과 노력을 기부할 의향도 있습니다.

@qrli Enterprises는 여전히 Windows Server 2008 R2 IIS 7.5 웹 팜에서 실행할 전체 .NET 4.5를 보유하고 있습니다. 아무도 그들에게서 그것을 빼앗지 않습니다.

@mattnischan

netstandard20의 자체 호스팅 HTTP 스토리가 효과적으로 "Kestrel 1.x를 사용"합니까? 나는 Nancy 사람들이 그것에 대해 크게 관심을 가질지 확신하지 못하며 나도 마찬가지입니다.

HttpListener 는 netstandard20의 일부이므로 netcore20도 netcore20으로 이동하여 그 전면에서 아무것도 제거되지 않습니다.

HttpListener 는 netstandard20의 일부이므로 netcore20도 포함됩니다.

그리고 HttpListener 에서 초당 동일한 요청을 기대할 수 있다고 가정합니다.

@markrendle 사실입니다. 지금은.

그러나 우리가 공유하는 라이브러리(예: serilog, newtonsoft, autofac 등)에서 사용하는 다른 라이브러리가 netstandard_min(usable)에 대한 지원을 중단할 때 제안하시겠습니까? 전체 프레임워크를 여전히 지원하는 최신 버전에서 감지된 심각한 보안 문제가 있습니까?

@mattnischan

HttpListener는 netstandard20의 일부이므로 netcore20도 포함됩니다.

그리고 HttpListener에서 초당 동일한 요청을 기대할 수 있다고 가정합니까?

네, Nancy는 .NETStandard 1.6이므로 Core 2.0에서 사용하고 Kestrel 2.0을 사용할 수 있습니다. 더 나은?

@gingters 당신이 그것에 올 때 나는 그 다리를 건너는 것이 좋습니다.

미래가 당신을 방해하게 두지 마십시오. 당신은 현재에 대항하여 오늘날 당신을 무장시키는 것과 같은 이성의 무기로 당신이 필요하다면 그것을 맞닥뜨릴 것입니다.
__~마르쿠스 아우렐리우스_

유지 관리 예산이 없고 앞으로 몇 년 동안 크게 변경되지 않고 사용해야 하는 소프트웨어를 제공할 때 이는 그다지 유용한 주문이 아닙니다.

앞으로 몇 년 동안 크게 변경되지 않아야 하는 경우 향후 몇 년 동안 의존하는 도서관에 무슨 일이 일어나는지가 왜 중요합니까?

@markrendle 이제 사람들의 생명이 위태로울 수 있는 환경에서 사용될 수 있으므로 애플리케이션 버전이 출시되기 전에 법에 따라(적어도 일부 국가에서는) 정확히 이러한 경우에 대한 비상 프로토콜을 제공해야 한다고 가정합니다. .

따라서 Kestrel만큼 빠른 웹 서버를 원하고 Kestrel이 아닌 유일한 특정 요구 사항이 있습니까?

네, Nancy는 .NETStandard 1.6이므로 Core 2.0에서 사용하고 Kestrel 2.0을 사용할 수 있습니다. 더 나은?

@markrendle @benaadams 아니요, 당신이 오해하고 있다고 생각합니다. 그리고 다시 한 번 바보가 되려는 것이 아니라 전체가 아닌 ASP.Net Core 조각의 다른 고객이 있다는 점을 지적한 것입니다. 나는 Kestrel 2.0이 나오면 그 위에 우리의 프로덕션 플랫폼을 호스팅하고 싶습니다. 그리고 우리의 프로덕션 플랫폼은 한동안 Framework에 있을 수 있습니다. netcoreapp20을 대상으로 지정할 수 없습니다.

Nancy는 netstandard16이지만 Core 2.0 외에는 Kestrel 2.0을 사용할 수 없기 때문에 문제가 되지 않습니다. 나는 이것이 구체적이라는 것을 알고 있으며 아마도 대답은 진정으로 "Kestrel 2만큼 빠른 프레임워크에서 작동하는 자신의 웹 서버를 작성하십시오. Kestrel은 ASP.Net 전용입니다."일 것입니다. 그러나 나는 그것이 메시지가 되기를 싫어합니다.

@gingters @gulbanana 나는 오픈 소스 프로젝트가 추정되는 미래 날짜에 기본 프레임워크의 임의 버전 지원을 중단하기 때문에 고정된 종속성 세트가 있는 배송된 애플리케이션이 어떻게 중단되는지 이해하지 못합니다.

@mattnischan 네, 무슨 말인지 이해하고 그 댓글을 삭제했습니다 :)

@스테파놀슨

서버와 데스크톱 응용 프로그램 간에 코드를 공유해야 하기 때문에 최신 버전의 ASP.Net을 사용할 수 없다는 의미입니까?

라이브러리로 .NET Standard를 대상으로 하는 경우 Desktop과 Core 모두에서 사용할 수 있습니다. .NET Standard를 대상으로 하는 라이브러리의 경우 Desktop, Core, Mono, Unity, UWP, Tizen 등의 범용 플랫폼 지원이 있습니다.

ASP.NET 응용 프로그램은 실행 파일입니다. 끝점은 도서관이 아닙니다. 최종 출력인 ASP.NET 응용 프로그램/실행 파일은 플랫폼에서 실행되어야 합니다. 결국 모든 플랫폼 라이브러리는 ASP.NET 응용 프로그램에서 사용되므로 플랫폼과 동일한 대상이 아닌 이점이 없습니다.

.NET Core는 플랫폼 간 적용 범위가 넓기 때문에 좋은 플랫폼입니다. 데스크탑과 나란히 설치할 수 있으며 앱별로 독립적으로 업그레이드할 수 있습니다. 전체 시스템과 모든 앱보다는

일부 품목은 외부에서 사용됩니다. 그래서 Wyam 은 정적 사이트 생성을 위해 Razor를 사용합니다. Razor는 현재 .NET Standard 1.3이므로 Core 외부에서 사용하는 것은 현재 문제가 되지 않습니다.

위에서 언급한 몇 가지 극단적인 경우가 있습니다.

.NET Standard 2.0 기능 세트를 지원하지 않는 라이브러리 사용. 그 중 많은 부분이 채워질 수 있는 공백이길 바라며 이 문제의 시작 부분에서 MS는 우선 순위를 정할 수 있도록 이러한 공백이 무엇인지 묻고 있었습니다.

예를 들어 UWP 앱에 포함된 웹 앱 실행 그러나 Desktop이 여전히 지원되었지만 버전 4.7.1로 변경된 경우 UWP가 현재 4.7.1을 지원하지 않고 ASP.NET이 지원했을 때 4.7.2, 4.7이 필요할 때와 동일한 상황에 있게 됩니다. 3 등. 다른 플랫폼에서는 절대 잡을 수 없는 Sisyphean 작업입니다. 그래서 별 의미 없이 그냥 바쁘게 하는 걸까요?

네, 무슨 말인지 이해하고 그 댓글을 삭제했습니다 :)

걱정마세요. 👍

@davidfowl

ASP.NET Core 회전 버전은 이에 어떤 영향을 줍니까? 우리가 3.0에서 .NET Framework 지원을 중단했다면(이 스레드에서 사람들이 회피하는 것처럼 보임) 상관없이 동일한 막다른 골목에 있지 않을까요? ASP.NET Core 2.0 응용 프로그램은 1년 동안 프레임워크에서 실행되도록 이식되었으며 3.0이 나오면 업그레이드할 수 없습니다. 어쨌든 .NET Framework에서 실행되고 ASP.NET Core 2.0이 종료된 경우에도 지원되는 ASP.NET Core 1.1.x를 사용하면 이 작업을 수행할 수 있습니다.

"언젠가 전체 .net을 중단해야 하는 이유가 지금 당장은 안 된다"고 말하는 것(내가 이해하는 대로)은 중요한 요점을 놓치고 있습니다. 많은 분들이 코어 2.0의 출시를 기다리셨을 거라 확신합니다. 정식 .net과의 호환성에서 많은 개선을 공개적으로 약속했기 때문입니다. 너무 많은 라이브러리 작성자가 코어로의 마이그레이션을 시작하기를 기다리고 있습니다. 따라서 Core 2.0이 출시된 후에 Core에서 훨씬 더 많은 libs를 마이그레이션할 것이라고 생각합니다. 따라서 asp.net 코어를 코어 3.0에 바인딩하는 것은 생태계에 훨씬 덜 실망스러울 것입니다. 3.0의 순간에 이것들은 코어로의 마이그레이션을 덜 차단해야 하기 때문입니다.
지금은 재앙입니다.

이전에 나는 두 단계로 우리 프레임워크( @benaadams가 설명한 것과 매우 유사한 이야기)를 core/asp.net 코어로 마이그레이션하기 시작하는 것을 평가하고 있었습니다. 웹 파트(현재 mvc/webapi에 있음)를 asp.net 코어로 마이그레이션하고 전체를 유지합니다. .net을 선택한 다음 모든 종속성이 코어에 해당하는 구현을 가질 때 코어의 다른 모든 항목을 마이그레이션합니다. 현재 우리를 가로막는 것은 Oracle ADO 공급자와 Postgres ADO 공급자입니다(corefx에는 아직 파고들지 않은 다른 비호환성이 있을 수 있습니다). 이제 이 계획은 죽었습니다. 따라서 우리는 앉아서 Core 세계의 모든 새로운 것을 버리고 종속성 마이그레이션을 기다려야 합니다. 그리고 이 모든 것은 MS의 누군가가 "빠르게 움직이는" 플랫폼이 필요하다고 결정했기 때문입니다.

@markrendle 그 때문에 애플리케이션이 중단되지 않습니다. 문제는 다른 문제입니다.
.NET Core 2는 전체 프레임워크에 대한 지원을 중단했기 때문에(버전 1에서는 제대로 실행되었으며 새 버전으로 업데이트할 때 이러한 기본 기본 기능이 중단될 것으로 예상하지 않는 Microsoft의 제품임), 종속성으로 인해 이 시나리오에 대한 지원이 조만간 중단될 수 있습니다.
누군가가 사용된 라이브러리 중 하나에서 심각한 보안 문제를 발견했으며 최신 버전이 더 이상 런타임을 지원하지 않기 때문에 중단된 버전에 대한 업데이트가 발행되지 않습니다. 이제 애플리케이션이 매우 규제된 환경에서 사용되기 때문에 중요한 보안 문제가 감지되었을 때 정확히 무엇을 할 것인지 설명하고 사람들이 다치거나 악화되는 것을 방지하기 위해 해당 수정 사항을 배포하는 방법을 설명하는 비상 계획을 제공해야 합니다. "글쎄요, 우리는 아무것도 할 수 없습니다"라고 대답하면 해당 응용 프로그램을 배송할 수 있는 허용이 취소됩니다.

@gingters 보세요, 요점은 현재 사용 가능한 정보와 회사가 운영되는 시장의 특성을 기반으로 기술 선택을 해야 한다는 것입니다. 세상의 최선의 의지로 모든 사태에 대해 설명할 수는 없지만, 세상의 관료와 규제 기관이 당신이 할 수 있는 척 하고 싶어 합니다. Microsoft가 Apple의 적대적 인수로 인수되고 .NET이 완전히 중단되어 Swift에 유리하다면? 판매 대상 국가 중 하나에서 강력한 암호화가 불법이 되고 SHA256을 포함하는 모든 소프트웨어 스택이 금지되면 어떻게 됩니까? Nicolas 또는 James 또는 _insert-name-of-Autofac-maintainer-here_가 화성으로 이동하여 수분 농부가 되기로 결정하면 어떻게 될까요? 자극이 역전되어 디지털로 기록된 데이터의 모든 비트가 지워지면 어떻게 될까요?

회사로서 JSON.NET에서 중요한 보안 문제가 발견되는 경우(예: 공식 업데이트가 없는 경우) 수행할 작업에 대한 실제 답변으로 가능한 대답은 "JSON.NET을 포크하여 패치할 것입니다"입니다. 이 질문은 James Newton-King이 어떤 이유로든 무기력해지면 무엇을 할 것인지에 대한 질문에 대한 답변입니다. 그런 종류의 시장에서 일한 나의 이전 경험에는 그러한 종류의 사태에 대비하여 소스 코드를 독점 패키지에 대한 에스크로 계약이 있었습니다. 그것에 비하면 오픈 소스 패키지에 대해 무엇을 해야 하는지는 사소합니다.

그리고 이 모든 것은 MS의 누군가가 "빠르게 움직이는" 플랫폼이 필요하다고 결정했기 때문입니다.

"빠르게 움직인다"는 표현이 과장된 것일 수 있습니다. Full Framework의 이전 릴리스 일정에 따라 배송에 "1~2년 추가 지연을 추가하지 않고"라고 표현하는 것이 더 나을 수 있습니다. 그것은 웹 세계에서 미친 시간입니다.

상황은 빠르게 변화하고 있으며 플랫폼은 관련성을 유지해야 합니다.

@davidfowl 및 @DamianEdwards 이 모든 혼란은 ASP.NET Core 1.x가 .NET Framework에서 실행될 수 있다는 사실에서 비롯된 것이라고 생각합니다. 이것은 ASP.NET Core가 ASP.NET 4/MVC5의 진화라는 가정을 만들었습니다. 사람들이 이전 버전과의 호환성을 유지하면서 모든 이점(속도 및 새로운 기능)을 얻을 것이라고 생각하여 마이그레이션하도록 만듭니다.

따라서 이 문제에 대한 장기적/영구적 답변은 장기적 지원과의 하위 호환성을 원하는 사람들을 위한 답변으로 ASP.NET 4/MVC5를 다시 홍보하는 것입니다 (그리고 약간의 개선도 제안할 수 있음).

그러면 ASP.NET Core는 도약할 수 있는 사람들에게 엄청난 이점을 제공하기 위해 과거에서 탈피하는 새로운 플랫폼이 되는 데 집중할 수 있습니다.

그런 점에서 (ASP).NET(Framework) 및 (ASP).NET Core는 고객이 선택할 수 있는 두 개의 평행하고 동등하게 유효한 도로가 될 것입니다. 그리고 나는 이것이 처음부터 일이 했어야 하는 방식이라고 생각합니다.

@markrendle 예, 이것은 가상이지만 슬프게도 관료제는 현실입니다. 그리고 예, 모든 상황에 대해 설명할 수는 없습니다. 예상할 수 있는 분들에게만.

그리고 이제 .NET Core 1에서 제대로 지원되었던 완전한 플랫폼(.NET 전체 프레임워크)의 삭제가 예상할 수 없었던 상황이 되었습니다. 그러나 이제 발생했기 때문에 b) 다른 종속성에서 v1에 대한 지원 중단을 예상할 수 있습니다. "예, 나중에 보다 빨리 발생하는 것으로 완전히 알 수 있습니다."

그리고 예, 수정 사항을 분기하고 백포팅하는 것이 가능한 솔루션 중 하나이지만 가능한 한 피하고 싶은 것입니다. .NET Core 팀이 "이봐. 봐, 우리는 전체 프레임워크에서 실행할 생각이 없으니 그것에 의존하지 마"와 같은 말을 하거나 처음부터 그것을 가능하게 하지 않았더라면 이 전체 토론 고객이 처음부터 .NET Core 위에 새로운 항목에 투자하기로 선택하지 않았기 때문에 필요하지 않습니다.

@gingters .NET Core 2.x 이상에서 ASP.NET Core 웹 비트를 실행하고 Core와 Full/UWP/무엇이든 간에 라이브러리를 공유하기 위해 .NET Standard 2.x를 사용하여 만족스러운 시점에 있다고 생각했습니다. . 이러한 라이브러리가 .NET Core 2.x만을 위해 .NET Standard 2.x에 대한 지원을 중단한다면 전체 .NET에 대한 지원도 중단할 것이며 어느 쪽이든 곤경에 처하게 됩니다.

@markrendle 1x 이후 공유 항목에서 사용해야 하는 ASP.NET Core 비트 중 하나에 중요한 문제가 있는 시점까지는 더 이상 지원되지 않습니다.

@gingters 운 좋게도 오픈 소스이며 필요한 경우 자신을 지원하거나 제3자에게 비용을 지불할 수 있습니다!

@마크렌들 번호 순수한 레거시 프로젝트는 죽은 프로젝트입니다. 엔터프라이즈 프로젝트는 일반적으로 수십 년 전의 최신 코드/라이브러리를 포함하는 대규모 혼합 코드베이스입니다. netcoreapp이라는 것은 혼합 기능을 제거했음을 의미합니다. 따라서 더 이상 멋진 새 버전으로 이동할 수 없지만 이전 버전으로 잠겨 있습니다. 안티 ms 직장 동료는 기꺼이 "내가 말했지..."라고 말한 다음 Google 솔루션으로 마이그레이션하도록 우리를 압박할 것입니다.

나는 netfx를 영원히 지원하는 것에 대해 논쟁하는 것이 아닙니다. 하지만 저는 netfx가 지금부터 최소 2년 동안 asp.net 코어에서 지원되어야 한다고 강력하게 생각합니다. 1.x뿐만 아니라 2.x도 마찬가지입니다.

@qrli "엔터프라이즈 프로젝트 ... 코드/lib가 포함된 대규모 혼합 코드베이스는 수십 년 전의 최신 버전입니다." 엔터프라이즈 프로젝트에서 잘못되어 중지해야 하는 모든 것입니다. 새로운 기술로 인해 심, 철사 및 거부로 묶인 절망의 큰 공에 더 많은 진흙 덩어리를 던지지 못한다고 불평하는 것은 새로운 산업용 레이저 절단기에 기대어 절단하지 못하게 하는 안전 기능이 포함되어 있다고 불평하는 것과 같습니다. 자신의 중요한 부분.

@benaadams

"빠르게 움직인다"는 표현이 과장된 것일 수 있습니다. Full Framework의 이전 릴리스 일정에 따라 배송에 "1~2년 추가 지연을 추가하지 않고"라고 표현하는 것이 더 나을 수 있습니다. 그것은 웹 세계에서 미친 시간입니다.

상황은 빠르게 변화하고 있으며 플랫폼은 관련성을 유지해야 합니다.

이것은 기술적/정치적 제한이 아니라 정치적/조직적 제한입니다. JVM/Java가 어떻게 움직이는지 보십시오. 그들이 전혀 움직이고 있다면. 여전히 관련성이 있지만 오늘날 .NET보다 훨씬 더 중요합니다. 따라서 사람들이 Java/JVM을 선택하는 이유는 '빠르게 움직이는 것'이 아닙니다. 반대로. 그들은 '빠른 이동'과 관련된 모든 단점이 없기 때문에 Java/JVM을 선택합니다. 1-2년 안에 투자가 낭비되지 않는 안정적이고 신뢰할 수 있는 플랫폼입니다.

MS가 .net을 완전히 빠르게 이동하려는 경우 빠르게 이동할 것입니다. 그들은 그것을 소유하고 무엇을 할 것인지 결정할 수 있습니다. 그러나 .net full은 현재 상태에 대해 '충분히' 충분합니다.

MS는 수년 동안 운전석에서 잠을 자다가 이제 갑자기 성능 및 메모리 압력과 같은 것이 중요합니다(의심할 여지가 없습니다). 반면 JVM 토지에서는 런타임의 특정 측면에 대한 투자가 많은 기간 동안 수행되었습니다. 몇 년이 지나면 보상을 받을 수 있습니다.

해결책이 무엇인지 단기적으로는 모르지만 장기적으로 .NET은 두 개의 주요 부서(.net은 Windows로 가득 차 있고 .net 코어는 devdiv로)에 걸쳐 분리된 상태로 남게 됩니다. 고용주는 우리 외부인에게 좋은 징조가 아닙니다.

여기에서 많은 요점이 만들어지고 모두가 다른 사람의 관점을 이해하려고 노력하고 있지만 "대기업은 그렇지 않아야 합니다"와 같은 솔루션은 도움이 되지 않습니다. 그렇게 설득한다 해도 대기업이기 때문에 20년은 걸릴 것입니다.

@kolectiv 그건 사실이지만, 기업이 갑자기 기업이 되지 않는다는 사실을 받아들인다고 해서 그러한 행동을 적극적으로 장려/활성화해야 한다는 의미는 아닙니다.

또한 _my_ 응용 프로그램이 더 느리게 실행되고 호스팅 비용이 더 많이 들어야 한다는 의미는 아닙니다.

ASP.NET Core 1.x(EF6, NHibernate, NServiceBus) 및 man에서 .NET 4.x를 여전히 대상으로 하는 많이 사용되는 라이브러리에서 이식성 분석을 실행하면 이러한 라이브러리는 netstandard20 을 대상으로 할 수조차 없습니다. netstandard20 .

리브 | 퍼센트
---------- | ----------
EF6 | 62.74
최대 절전 모드 | 67.39
N서비스버스 | 65.68

그리고 여전히 누락된 API에 큰 격차가 있습니다. EF Core는 여전히 EF6과 큰 격차가 있으며 EF6에 존재하지 않는 주요 기능이 있을 때 여전히 NHibernate를 사용합니다. NServiceBus는 메시징을 수행하는 모든 프로젝트에서 사용합니다.

아휴.

@마크렌들

"엔터프라이즈 프로젝트 ... 코드/lib가 포함된 대규모 혼합 코드베이스는 수십 년 전의 최신 버전입니다." 엔터프라이즈 프로젝트에서 잘못되어 중지해야 하는 모든 것입니다. 새로운 기술로 인해 심, 철사 및 거부로 묶인 절망의 큰 공에 더 많은 진흙 덩어리를 던지지 못한다고 불평하는 것은 새로운 산업용 레이저 절단기에 기대어 절단하지 못하게 하는 안전 기능이 포함되어 있다고 불평하는 것과 같습니다. 자신의 중요한 부분.

예, 그 성가신 기업과 대규모 조직에 다르게 일을 하라고 말합시다. 전선을 끊으십시오! 진흙 홍수를 막아라! 그렇게 하면 그들이 깨어나 듣게 될 것입니다. 오, 잠깐, 그건 도움이 되지 않을 겁니다. 그들은 이미 그것을 알고 있지만 당신이 신경 쓰지 않거나 당신 자신의 주장을 무시하기 위해 많은 일을 해야 하기 때문입니다.

보세요, 아무도 '새로운 기술: 나쁘다!'라고 말하지 않습니다. 새로운 기술이 가져올 결과를 깨닫지 못한 채 새로운 기술을 추구하는 것입니다. 우리 모두는 최신 비트로 작업하는 것을 좋아하고 오래된 cruft에 대해 걱정할 필요가 없습니다. 누가 그것을 원하겠습니까? 그러나 현실은 다른 이야기를 합니다. 최신 비트로만 작업해야 하고 오래된 것은 신경 쓰지 않아도 된다면 좋습니다! 슬프게도 참호에서 일하는 드론은 다른 현실과 함께 살아야 합니다. 많은 사람들이 현실을 바꿀 수 없고, 다른 미래를 만들 수도 없고, 함께 일해야 한다는 사실을 최소한 인정한다면 그것은 당신에게 적합할 것입니다.

@markrendle 무엇을 제안하고 있는지 잘 모르겠습니다. 1,500만 줄의 작동하는 C# 코드를 버리고 새로 작성하시겠습니까? 우리는 netstandard 2.0으로 (천천히) 전환하고 Span 등과 같은 것에 액세스할 수 있기를 바라지만 이와 같은 문제로 인해 그것이 현명한 것인지 의심스럽습니다.

우리는 Linux 지원을 원하지만 이것은 분기점처럼 느껴집니다. 나는 netstandard가 가장 진보된 구현으로 나아가고 그 다음 프레임워크와 같은 것들이 따라잡을 것이라고 가정했지만 적어도 우리는 그렇게 할 것이라는 것을 알고 있습니다.

@FransBouma 그럼 기업이 멍청한 짓을 하려고 해서 우리 모두가 고통을 받아야 합니까? 수백만 달러 규모의 공공 부문 프로젝트가 아직 준비되지 않았기 때문에 좋은 것을 얻을 수 없습니까? 어떻게 작동합니까?

@markrendle 계속 작동하는 코드를 원하는 것이 어리석은 이유는 무엇입니까?

그들은 '빠른 이동'과 관련된 모든 단점이 없기 때문에 Java/JVM을 선택합니다. 1-2년 안에 투자가 낭비되지 않는 안정적이고 신뢰할 수 있는 플랫폼입니다.

그리고 기본적으로 영원히 System.Web을 사용할 수 있습니다. Windows에 구워졌기 때문에 절대 사라지지 않을 것입니다. 당신은 그보다 훨씬 안정적이고 신뢰할 수 없습니다.

ASP.NET 코어 1.x -> ASP.NET 코어 2.x; 모든 API는 거의 동일합니다. 주요 변경 사항은 .NET Framework에 대한 지원을 중단한다는 것입니다. 쉬는날에도 샘버바꿔요 😱

ASP.NET Core 1.x는 .NET Core 2.x 및 .NET Framework에서 실행되며 .NET Standard 2.x(.NET Core 2.x를 통해)를 지원합니다. ASP.NET Core 2.x와 동일한 API를 사용하므로 디딤돌 릴리스입니다.

ASP.NET Core 2.x는 중단 릴리스입니다. 여전히 .NET Standard 2.x(.NET Core 2.x를 통해)를 지원하며 ASP.NET Core 1.x와 ASP.NET Core 2.x 간에 API 측면에서 크게 변경되지 않았습니다. 그러나 .NET Framework를 삭제합니다.

대안은 다음과 같습니다.

• ASP.NET Core는 계속해서 netstandard3.0 (2.x일 수 있음)와 같은 작업을 진행하고 netstandard 버전을 더 빠르게 만듭니다. 분기에 한 번처럼.
• NetFx 다음 릴리스는 다음 릴리스가 있을 때마다 netstandard3.x 를 지원하기 위해 다시 점프할 수 있습니다. 최신 표준이 아니어도 됩니다.

사용된 모든 항목이 netstandard의 일부일 필요는 없지만 최소한 ASP.NET Core 2.x는 다른 프레임워크가 결국 사용할 표준을 대상으로 하기 때문에 이것은 나쁜 생각일 수 있습니다.

그냥 스핏볼링. 나는 이것이 제기되었다고 확신합니다.

@bencyoung 저는 전 세계가 1,500만 줄의 작동하는 C# 코드(작업을 멈추지 않을 것입니다, btw)를 중심으로 회전해야 한다고 주장하는 것이 약간 이기적임을 제안하는 것입니다. 따라서 ASP.NET Core 2.0을 사용할 수 없습니다. 브라이튼이 락을 관통하는 것처럼 레거시 지원이 실행되는 전체 Windows 전용 프레임워크 ASP.NET이 여전히 있습니다. 따라서 코드를 이식하고 애플리케이션을 리팩터링/재설계하는 것이 경제적으로 실행 가능하지 않기 때문에 가지고 놀 수 없는 새로운 장난감이 있습니다. 짜증나지만 많은 일들도 마찬가지입니다. 그러나 Microsoft가 VB 6.0으로 작성된 COM 구성 요소를 여전히 포함하고 있는 기존의 20년 된 레거시 코드베이스에서 작동하지 않을 모든 것을 피한다면 앞으로 20년 후에는 Micro Focus가 될 것입니다.

@adamhathcock 그것이 내가 netstandard의 목적이라고 생각했던 것입니다. 최소 공통 분모가 아니라 통합 접근 방식입니다. 원하는 만큼 빠르게 움직일 수 있지만 .NET 프레임워크가 결국 따라잡을 것이라는 약속입니다. 결국에는 기본적으로 .NET 프레임워크에서 플랫폼별 항목을 뺀 네트표준이 생겨 통합될 것입니다.

NetFx 다음 릴리스는 다음 릴리스가 있을 때마다 netstandard3.x를 지원하기 위해 다시 점프할 수 있습니다.

.NET Framework 업데이트는 Windows(대부분)를 실행하는 지구상의 모든 컴퓨터 에 대한 강제 업데이트입니다.

.NET Core 업데이트는 개별 애플리케이션 이 선택 하는 업데이트입니다.

그들은 매우 다른 짐승입니다.

글쎄, 한 가지 쉬운 일은 ASP.NET Core 문서의 맨 첫 페이지 에서 이 페이지 에 대한 링크를 중지하는 것입니다.

(또는 단순히 "ASP.NET Core를 계속 사용하려면 .NET Framework를 선택하지 마십시오!"라는 줄을 추가하십시오.)

그들은 .NET 프레임워크가 결국 따라잡을 것이라는 약속이 될 것입니다.

https://github.com/aspnet/Home/issues/2022#issuecomment -299609207이 있습니다.

우리의 약속은 일반적으로 .NET Framework와 .NET Core 간에 유형이 공유되는 경우 새로 추가된 멤버를 .NET Framework로 이식하려는 것입니다. 매우 드문 경우에 이것이 가능하지 않을 수도 있지만, 문제는 자동으로 고려된다는 것입니다.

그러나 따라잡을 때쯤이면 ASP.NET은 차기 .NET Standard 버전으로 넘어갔을 것이며 ASP.NET용 .NET Framework의 올바른 버전은 결코 아닐 것입니다. 그것은 항상 뒤에있을 것입니다.

@markrendle 아니요, 그들은 큰 진흙 공이 아닙니다. 큰 믹스가 나쁜 아키텍처를 의미하지는 않습니다. 그들은 모듈식입니다. 많은 모듈이 오래 전에 정말 똑똑한 사람들에 의해 작성되었거나 타사에서 구입한 전투 테스트 코드입니다. 일부는 C로, 일부는 포트란으로, 일부는 C++/cli 등으로 마이그레이션하거나 다시 작성하려면 이를 이해하고, 논문을 읽고, 더 많은 실제 테스트 데이터를 수집하고, 새 버전을 다시 테스트해야 합니다. 노력이 필요하지만 그러한 작업은 예산이 책정되지 않고 우리 자신에게 달려 있습니다. 비즈니스 사람들은 우리가 .net 코어를 사용하든 말든 상관하지 않지만 기능이 완료되기를 원합니다. 그리고 제3자에게 우리는 그들을 촉구하거나 교체를 모색해야 합니다.
따라서 실제로 몇 년이 걸릴 수 있습니다.

@benaadams

그리고 기본적으로 영원히 System.Web을 사용할 수 있습니다. Windows에 구워졌기 때문에 절대 사라지지 않을 것입니다. 당신은 그보다 훨씬 안정적이고 신뢰할 수 없습니다.

ASP.NET 코어 1.x -> ASP.NET 코어 2.x; 모든 API는 거의 동일합니다. 주요 변경 사항은 .NET Framework에 대한 지원을 중단한다는 것입니다. 쉬는날에도 샘버바꿔요 😱
ASP.NET Core 1.x는 .NET Core 2.x 및 .NET Framework에서 실행되며 .NET Standard 2.x(.NET Core 2.x를 통해)를 지원합니다. ASP.NET Core 2.x와 동일한 API를 사용하므로 디딤돌 릴리스입니다.
ASP.NET Core 2.x는 중단 릴리스입니다. 여전히 .NET Standard 2.x(.NET Core 2.x를 통해)를 지원하며 ASP.NET Core 1.x와 ASP.NET Core 2.x 간에 API 측면에서 크게 변경되지 않았습니다. 그러나 .NET Framework를 삭제합니다.

예, 옵션이 실제로 무엇인지 봅시다. ASPNET Core 1.x는 막다른 골목입니다. 이식할 수 있지만 오늘날 .net이 꽉 찬 라이브러리에 의존하는 경우 코드를 .net core로 이동할 수 없습니다. 지원이 종료되면 .net core /standard로 이식되지 않을 수 있습니다. 이제 ASP.NET core 1.x를 선택하는 것은 종속성이 이미 netstandard2.0/.netcore에 있는 경우에만 현명합니다. 그러면 막다른 골목에 빠지지 않는다는 것을 알고 문제 없이 asp.net core 2.x로 이동할 수 있습니다.

안정성을 원한다면 nginx와 JVM 스택의 대안으로 system.web을 선택하라는 당신의 제안은 약간 약하다고 생각하지 않습니까? :) 플랫폼으로 선택해야 할 대규모 조직의 옵션에 관한 것입니다. 완전히 새롭고 외부 종속성(드물게)과 함께 작동할 필요가 없는 앱을 만들지 않는 한 안전한 내기를 할 가능성이 높으며 왜 그렇지 않습니까? 그런 다음 system.web 또는 JVM/nginx로 내려오면 선택은 매우 간단합니다.

작은 것들입니다. 나는 전에 그것에 대해 두드렸다: sql 서버 기업의 암호화 기능. .net 코어에는 없기 때문에 사용하지 않을 것입니다. 신탁? 아니요. 따라서 asp.net core와 이러한 기능을 사용하려면 .net full과 asp.net core 1.x를 사용해야 합니다. 그러나 asp.net core 1.x에 대한 지원이 종료될 때 이러한 기능이 이식/사용 가능하지 않으면 어떻게 됩니까? (그리고 누가 이미 'QFE 모드'인 플랫폼에 농장을 걸고 싶습니까?) system.web으로 돌아가시겠습니까?

문제의 일부는 ASP.NET이 .NET Core의 진화를 직접적으로 주도하고 있다는 것입니다. 나는 그것이 마이크로소프트의 내부적인 일이라고 생각하지만, 실제로 플랫폼과 특정 라이브러리는 그렇게 밀접하게 결합되어서는 안 됩니다.

새로운 것이 .NET 버전에 추가되어야 하는 경우 netstandard 범프(vNext 포함)를 통해 모든 사람이 사용할 수 있도록 만든 다음 릴리스될 때 이를 사용하도록 ASP.NET을 업데이트해야 합니다. 이 문제를 일으키는 것은 ASP.NET의 특권적 위치라고 생각합니다. Microsoft 내부의 개발자 그룹이 동일하기 때문에 불가피할 수 있습니다.

.NET을 많이 사용하는 HPC 소프트웨어 작성자로서 기본 플랫폼을 변경하지 않고 자체 제로 할당 구문 분석 등을 구현했습니다. Span 등의 이점을 얻을 수 있습니까? 전적으로! .NET Core로 전환할 수 있습니까? 오랫동안 아닙니다. .NET Framework에 Span 등이 추가된 것을 볼 수 있습니까? netstandard 약정 없이는 지금 말하기 어려운 것 같습니다 ...

@markrendle 물론이지만 전환 계획은 무엇입니까? 지원되지 않는 경로에 도달하지 않는 것을 볼 수 없습니다. 변경 사항이 netstandard에 있었고 ASP.NET Core가 변경 사항을 사용했다면 적어도 결국에는 경로가 있다는 것을 알았습니다....

@markrendle asp.net 코어의 의도된 사용자가 누구인지 잘 모르겠습니다. 하지만 내가 본 것은 대부분 .net과 큰 레거시(나쁘지 않은) 코드베이스에 큰 투자를 한 .net 사용자입니다. 우리가 의도한 사용자가 아니라면 우리가 .net이 아무리 좋다고 생각하더라도 node.js/python/go 녀석들이 .net에 sh*t를 주는 것을 볼 수 없습니다.
회사를 위한 것이 아니라 내 프로젝트를 위한 것이라면 asp를 사용하지 않고 대신 nancy를 사용합니다. 기업은 안정적인 보증과 지원이 필요합니다. 그리고 그들은/우리는 그것에 대해 큰 돈을 지불합니다.

이 문제에 대한 쉬운 해결책은 Microsoft가 .NET Framework 라이브러리의 전체 범위를 지원하는 Windows 전용 CoreCLR 배포판을 만드는 것입니다.

내 개인적인 측면은 우분투의 PI에서 .NET Core로 노는 것이 멋지지만 .NET Framework는 우리가 필요로 하는 모든 것을 수행하고 .NET Core는 비교할 때 문제일 뿐이기 때문에 비즈니스 측면은 .NET Core를 고려조차 하지 않았습니다. 이 문제의 대부분은 도구를 사용하고 모든 사람이 설정하도록 하는 것과 관련하여 이러한 고통이 마침내 사라지고 있지만 여전히 많은 기능이 부족합니다... EF Core는 EF6 또는 NHibernate를 대체할 만큼 충분히 부드럽지 못했으며 그들은 이겼습니다. .NET Core 2에서도 실행되지 않습니다. SOAP 서비스용 WCF(호스트)가 없다는 것은 우리가 비즈니스 커뮤니케이션에서 하루 종일 하는 일이기 때문에 상당한 부담이 되지만 여러 앱에서 .NET Core 및 .NET Framework를 사용하고 영리한 설계를 통해 완화할 수 있습니다. AppDomains도 내 문제의 가장 작은 부분이지만 쉽게 교체되지 않습니다. ASP.NET MVC 5에서 MVC Core로의 도약은 재작성에서 예기치 않게 쉬웠지만 .NET Core로 이동하면 VS가 협력을 중지하고 모든 오류를 표시합니다.

WPF 내에서 ASP.NET Core를 호스팅하는 것과 같은 재미있는 일도 불가능합니다.

오늘날 .NET Framework와 크게 다르지 않기 때문에 Windows CoreCLR 배포가 비공개 소스인지 여부는 중요하지 않습니다.

이제 조용히 울고 ASP.NET Core로 마이그레이션된 실험 분기를 삭제하는 동안 실례합니다.

안정성을 원한다면 nginx와 JVM 스택의 대안으로 system.web을 선택하라는 당신의 제안은 약간 약하다고 생각하지 않습니까?

그것의 극단적인 끝 ;)

그런 다음 system.web 또는 JVM/nginx로 내려오면 선택은 매우 간단합니다.

예, JVM을 사용할 수 있다면 차단기가 없고 좋은 interop 및 p/invoking이 있으므로 ASP.NET Core 2를 사용합니다. :)

API가 "거의 동일"하다면 하나의 버전 번호를 모두 2배로 유지하지만 "netstandard" 또는 "netcore"를 선택할 수 있는 옵션이 있는 것은 어떻습니까?

내부가 변하기 때문입니다. 런타임, jit 및 표준 라이브러리에 대한 변경 사항을 활용합니다. 사용자에게는 ASP.NET 1.x와 2.x 간의 호환성이 있는 것과 거의 동일하게 나타납니다. 내부가 아닌 노출된 API 표면에서 "여기서 완료되었습니다".

문제의 일부는 ASP.NET이 .NET Core의 진화를 직접적으로 주도하고 있다는 것입니다.

다른 사람들도 마찬가지입니다. 예를 들어 ValueTask 에서 했던 것처럼 dotnet/corefx 에서 API 요청을 할 수 있습니다. 그런 다음 Task-like로 발전했으며 현재 C#7의 일부입니다.

API가 .NET Core에 포함되자마자 사용을 시작할 수 있습니다(밤에 가서 API가 올바른지 확인하려는 경우). 또는 6개월 동안 중단하려는 경우 coreclr/corefx의 다음 릴리스에서.

그런 다음 ASP.NET이 릴리스될 때 이를 사용하도록 업데이트되었습니다.

이제 2년을 기다려야 합니다. 그것은 실제로 실용적이지 않습니다. API는 사용을 통해 개선이 필요하기 때문입니다. 사용을 통해 더 많은 발견이 일어날 것입니다. 이는 개발 주기에 2년 컴파일 단계를 추가하는 것과 같습니다.

.NET을 많이 사용하는 HPC 소프트웨어 작성자로서 기본 플랫폼을 변경하지 않고 자체 제로 할당 구문 분석 등을 구현했습니다. Span 등의 이점을 얻을 수 있습니까? 전적으로! .NET Core로 전환할 수 있습니까? 오랫동안 아닙니다.

HPC 소프트웨어가 웹 요청을 직접 중단합니까? 추측컨데 웹 요청에 의해 구동되는 대기열이 있을 수 있지만 별도의 프로세스에서 실행되므로 이 변경의 영향을 받지 않아야 합니까?

.NET Framework에 Span 등이 추가된 것을 볼 수 있습니까?

네

@benaadams

그러나 따라잡을 때쯤이면 ASP.NET은 차기 .NET Standard 버전으로 넘어갔을 것이며 ASP.NET용 .NET Framework의 올바른 버전은 결코 아닐 것입니다. 그것은 항상 뒤에있을 것입니다.

버전이 1개 이상 겹치는 경우(즉, 최신 전체 프레임워크를 계속 사용하는 경우 해당 프레임워크에서 실행되는 주변에 공식적으로 지원되는(ASP).NET Core 버전이 하나 이상 있음) 이는 완전히 괜찮고 수용 가능합니다.

Microsoft는 .NET Framework 라이브러리의 전체 범위를 지원하는 CoreCLR의 Windows 전용 배포를 만들 것입니다.

또는 .NET Standard 2.0 라이브러리 세트; API 격차를 커버하는 Windows에서만 실행되는 .NET Core에서 실행할 수 있습니까?

@benaadams 네, 그 아이디어입니다. 비록 PlatformNotSupportedException을 던지는 어떤 것에도 작동하지 않을 것이지만

@qrli 모듈식이라면 지금 업그레이드할 수 있는 모듈을 업그레이드하고 나머지는 나중으로 남겨둘 수 있습니다.

"모듈식"이 아닌 한 "PInvoke 및 COM을 통해 상호 운용되는 수십 개의 서로 다른 라이브러리로 구성된 대규모 모놀리식 System.Web ASP.NET IIS 응용 프로그램"을 의미하지 않는 한 큰 진흙 덩어리입니다.

어떤 어셈블리가 영향을 받고 어떤 어셈블리가 영향을 받지 않는지에 대한 최종 목록이 있습니까? Microsoft.Extensions.* 는 안전하고 Microsoft.AspNetCore.Razor.Runtime (가정)도 마찬가지이므로 Microsoft.AspNetCore.Html.Abstractions $도 netstandard 에 있어야 합니다. netstandard 에 머물고 있는 Microsoft.AspNetCore.* 에 다른 것이 있습니까?

@bencyoung 내가 권장하는 전환 계획은 시간이 지남에 따라 다양한 구성 요소를 .NET Core 2.x(또는 해당 특정 구성 요소에 대한 전체 개발 도구에서 가장 잘 작동하는 모든 것)를 대상으로 하는 독립 실행형 서비스로 마이그레이션하여 레거시 코드에서 해당 서비스를 사용하는 것입니다. 적절한 분산 시스템 아키텍처를 얻을 때까지 HTTP 또는 메시지 버스를 사용하는 표준 API 경계.

@markrendle 모든 것이 분산 시스템에 속하는 것은 아닙니다. 구체적인 예: 스택 오버플로가 페이지를 매우 빠르게 렌더링하는 이유 중 상당 부분은 배포 되지 않기 때문입니다. 네트워크 대기 시간이 0.017ms이지만 애플리케이션에 상당한 네트워크, 직렬화, 역직렬화 및 GC 비용이 추가됩니다. 시스템을 여러 서비스로 분할하는 것은 보편적인 해결책이 아닙니다. 복잡하고 비용이 많이 들며 많은 시나리오에서 부정적인 영향을 미칩니다. 좋은 것일 수도 있지만 지나치게 복잡한 나쁜 것일 수도 있습니다.

@markrendle 내 문제는 서비스로 마이그레이션하는 것이 아니라 기본 서비스 인프라 빌딩 블록 중 일부가 netstandard20 또는 netstandardbanana 로드맵에 없는 API를 사용한다는 것입니다. 우리에게 .NET Core는 그린필드 애플리케이션이 아니라 전체 그린필드 시스템에 관한 것입니다. System.DirectoryServices 가 한 가지 예이지만 다른 사람들에게는 WCF이고 더 많은 사람들에게는 System.Data 및 SqlClient 항목이고 우리에게는 System.Messaging 입니다.

가능하면 .NET Core를 사용하겠습니다. 지금까지 제로 클라이언트 프로젝트가 포함되어 있었는지 여부에 관계없이 모든 것이 차단되었습니다.

@NickCraver 내 말은 우스꽝스럽거나 그런 것이 아니라 SO 페이지가 그렇게 빨리 렌더링되는 진짜 이유는 당신과 그것을 구축하는 다른 사람들이 훌륭하기 때문이라는 것을 알고 있지만, 당신의 페이지에 대한 링크가 포함된 Google 검색 결과 페이지만큼 빠르게 렌더링되며 크고 복잡한 분산 시스템에서 가져온 것입니다. Amazon 페이지는 매우 빠르게 동일한 거래를 렌더링합니다. 저는 ASP.NET Core가 동일한 성능으로 구축된 것과 동일한 방식으로 시스템을 구축하는 데 사용할 수 있는 미래를 향해 나아가고 있다고 낙관합니다. 완전한 .NET의 작은 섬으로의 업데이트 주기.

@jbogard 비슷하지만 .NET Core 2.0이 나오면 매우 다를 것입니다.

한숨을 쉬다.

@jbogard

넷스탠다드바나나

스레드의 인용문

나와 내 팀의 주요 문제는 이 경로가 의도된 미래라는 표시가 없다는 것입니다. 미래를 아는 사람은 아무도 없지만 완전한 .net 프레임워크(구성 요소 공급업체 dll, 지불 서비스 SDK, HSM SDK)에 의존하는 모든 것을 자체 서비스로 분리하고 새로운 홉 STINGS를 도입해야 한다고 들었습니다. 이것은 이 사이트에서 필요로 하는 것이 아니며 이제 더 많은 개발 작업 복잡성을 도입하거나 MVC 5에 웹 앱 부분을 다시 수행해야 합니다.

우리는 kestrel의 속도와 멋진 새 API를 위해 asp.net 코어를 사용했습니다. 종속성을 감안할 때 손쉬운 업그레이드 경로가 없는 것과 비교하여 옵션을 더 정확하게 평가할 수 있다면 좋았을 것입니다.

@jabrown85에 추가
ASP.NET Core는 지금까지 감정의 롤러코스터였습니다.
csproj가 착륙한 후 마침내 "이제 준비되었습니다"로 이동하여 새로운 것을 시작하고 업그레이드할 수 있는 항목을 확인하는 것이 어렵지 않다고 생각했습니다. 이 발표 후에는 ".NET Core가 시나리오를 확실히 지원합니까, 아니면 안전하게 MVC5를 유지해야 합니까?"와 비슷합니다.

사상자는 지금까지 낮았고 기본 MVC 5 앱의 관리 작업을 관리하는 ASP.NET Core로 작성된 응용 프로그램은 하나뿐이지만 기본 앱이 NHibernate를 사용하기 때문에 1.x에서 영원히 멈춥니다.

@markrendle 컴퓨터는 아니오라고 말합니다

전체 .NET -> netstandard에 대한 로드맵이 있으면 좋을 것입니다. 기본 부분 중 일부는 ApiPort에서 "지원되지 않음"이라고 말합니다. ASP.NET Core 1.x에서 클라이언트 프로젝트에 대한 전체 분석을 실행하여 무엇이 누락되었는지 확인하겠습니다.

그러나 메인 앱이 NHibernate를 사용하기 때문에 영원히 1.x에 고정될 것입니다.

그렇지 않아야합니다. Hibernate가 죽지 않았습니까?

@benaadams 놀랍게도 아닙니다. EF6에는 실제로 동등한 기능이 없는 몇 가지 기능이 있습니다. 기본값은 EF6이지만 NH 루트로 가야 하는 경우가 있습니다.

@benaadams 공식적으로 아니오, 거의 죽은 것처럼 보이는 일시 중지가 있지만 일반적으로 며칠에 한 번 커밋합니다. ApiPort는 .NET Standard에 대해 72.26%의 적용 범위를 보고하지만 (적어도 가까운 장래에) 이식될 것이라고 확신하지 않습니다.

댓글을 읽으면서 이 프로젝트가 향하고 있는 일반적인 방향에 대해 우려하고 있습니다. 오랫동안 ASP.NET은 안정적이고 견고한 기술을 위한 좋은 선택이었습니다. 그러나 지금은 같은 느낌이 들지 않습니다. "빠르게 움직이고 깨는" 기술이 많이 있지만 이는 완전히 다른 범주입니다.
Microsoft가 이러한 문제를 해결하고 모든 사람의 기대치를 맞출 수 있기를 바랍니다.

기업용 소프트웨어와 비기업용 소프트웨어의 문제가 아닙니다. 오늘날 사용 중인 Python 2.x 응용 프로그램이 많이 있으며 모두 "엔터프라이즈"가 아닙니다. 게다가 모든 새 프로젝트가 Python 3을 사용하는 것은 아닙니다(Python 3.0 출시 후 거의 9년!).

블로그 게시물에 전체 스레드를 요약할 수 있는 사람이 있습니까?

출퇴근/점심 시간에 300개 이상의 댓글을 모두 읽었고 ... 여전히 완전히 "이해하지" 않는 것 같습니다.

내가 얻는 것은 다음과 같습니다.

• 전체 .NET Framework는 .NET Core 2에서 지원되지 않습니다.
• 모든 종속성은 netstandard2.0 netcoreapp2.0 에 의존합니다.
• DirectoryServices 또는 Drawing과 같은 것을 원하면 전체 프레임워크를 삭제하고 2.0으로 점프해야 합니다.

나는 나머지... 바쁜 일정과 모든 것을 놓쳤습니다.

@MaximRouiller

DirectoryServices 또는 Drawing과 같은 것을 원하면 전체 프레임워크를 삭제하고 2.0으로 점프해야 합니다.

아니요, .net Core를 지원하지 않는 라이브러리를 원하면 AspNet Core 2.0+를 전혀 사용할 수 없습니다.

@MaximRouiller , 그들이 방금 한 것은 Asp.Net 핵심 프로젝트가 전체 프레임워크 어셈블리를 참조할 수 없어 대부분은 아니지만 많은 사람들에게 쓸모가 없게 만드는 것입니다. 그들은 system.drawing 및 Directoryservices와 같은 어셈블리가 새로운 netstandar로 포팅될 것이라고 말합니다. 아니면 여전히 오래된 어셈블리는 누군가 이식하지 않는 한 작동하지 않습니다. 따라서 일부 어셈블리는 레거시이고 이식되지 않을 것이기 때문에 많은 사람들에게 거의 쓸모가 없습니다. 결론적으로, .NET 프레임워크의 정식 버전과 함께 .net 코어를 사용하던 사람은 망해서 MVC 5로 돌아가야 합니다.

@davidfowl 그런데 이 목록 에 감사드립니다. 그것은 매우 중요합니다. "그래서 우리가 여기서 무엇을 얻을 수 있습니까?" 사람들이 마음속으로 비용/편익의 균형을 맞추는 데 필요한 조각입니다.

아직 읽지 않았다면 목록 을 읽고 양쪽 모두에 대한 정보를 얻으십시오. 나는 여전히 2.x가 전환 릴리스가 되기를 원하고(실제로 이동을 보증하는 비즈니스에 정당한 이점이 있음) 3.x가 승리하기를 원합니다. 2일 뒤에 나왔어도. 모든 면에 대한 통찰력에 정말 감사드립니다.

@davidfowl 당신은 다음과 같이 말했습니다.

라이브러리는 표준 위에 작성할 수 있습니다. 표준 자체의 내용을 변경해야 하는 경우 .NET Framework를 포함한 모든 .NET 구현에서 채택하는 데 훨씬 더 오랜 시간이 걸립니다. 다음 두 가지를 의미할 수 있습니다.
.NET Standard는 가장 느린 구현 속도로 발전할 것입니다.
.NET Standard는 다른 속도로 발전할 것이며 .NET Framework는 마지막으로 따라잡을 것입니다.

그런데 왜 그럴까요? .NET Standard vNext를 출시하고 .NET이 나중에(몇 개월에서 1년 후) 따라잡도록 할 수 없습니까? 즉, 최첨단에 있고 최신 ASP.NET Core를 원하는 사람들은 .NET Core에서 호스팅할 수 있으며 레거시 코드에 .NET이 필요한 사람들은 .NET이 따라잡으면 결국 해당 버전의 ASP.NET Core를 사용할 수 있습니다. 사용하는 .NET Standard 버전으로 변경합니다. .NET Standard가 가장 낮은 구현만큼 빠르게 개선되어야 하는 이유를 이해할 수 없습니다.
또한 여기에서는 표준의 공식 구현에 대해 이야기하고 있지만 표준과 함께 업데이트되지 않는 다른 구현도 있을 것입니다.
그렇게 하면 사람들을 뒤에 남겨두지 않습니다. 물론 .NET에 있는 경우 최신 기능의 이점을 누리는 데 시간이 조금 더 걸리지만 영구적으로 고정되지는 않습니다.

@jdom 은 .NET Framework가 변경되는 속도와 속도가 느려야 하는 이유를 알고 있기 때문입니다. 그것은 다른 배포이며 아마도 그것에 대한 충분한 감사가 없을 것입니다. 모든 변경 사항은 수십억 대의 기계에 적용됩니다. 레이어링도 완전히 다르기 때문에 추론할 수 있는 사소한 일이 아닙니다.

.NET Standard가 가장 낮은 구현만큼 빠르게 개선되어야 하는 이유를 이해할 수 없습니다.

ASP.NET Core에서 .net 표준에 대한 로우 워터마크를 계속 높이면 목적이 무효화되고 동일한 상황에 처하게 됩니다. 언젠가 이러한 API가 .NET Framework에 제공될 것이라는 약속이 있기 때문에 뒤처져 있다고 느끼지 않으실 것입니다. .NET 4.7은 여전히 ​​.NET Standard 2.0과 기능 패리티를 완료하지 못합니다.

@davidfowl 하지만 이것은 PCL에서와 같은 문제를 다시 불러일으킬 것이고, 가장 낮은 공통 분모와 사용의 고통이 될 것입니다. ASP.NET이 사용을 포기한다는 사실은 이미 그것을 보여줍니다.

@davidfowl 그러나 이것은 PCL과 동일한 문제를 다시 불러일으킬 것이며, 가장 낮은 공통 분모가 되고 사용하기가 고통스러울 것입니다.

@Suchiman 그게 어떻게 문제입니까? PCL의 유일한 문제는 NuGet에서 동적으로 계산되고 표현되는 방식이었기 때문에 얻을 수 있는 결과를 예측하기 어려웠습니다. 다른 구현으로 구현할 수 있는 API 세트가 아니라면 netstandard가 어떻게 작동할까요?

PCL을 사용하기 귀찮게 만든 것은 매우 작은 API 표면적이었습니다. .NET Standard 1.3-1.4는 API 현명하게 가장 기본적인 라이브러리를 구현하기에 충분합니다.

.NET Standard는 항상 폭에 관한 것이었습니다.

ASP.NET Core 및 .NET Core는 경량 마이크로 서비스를 구축하기 위한 경쟁력 있는 크로스 플랫폼 서버 스택에 관한 것이었습니다. 이러한 의미의 숨결은 더 광범위한 플랫폼 지원(linux, osx, tizen, pi 등에서 실행)이었습니다.

@davidfowl

우리는 .NET Core에서 해결하고자 하는 주요 사항 중 하나로 문자열을 식별했습니다. 수많은 아이디어가 있지만 그 중 하나는 기본적으로 문자열을 utf8로 설정하는 것입니다(수많은 호환성 문제가 있지만 여기에서 따라오세요).

우리가 수정하고 싶은 또 다른 것은 배열/문자열의 저렴한 조각, 인접 메모리 조각을 가져오는 기능입니다. 스팬을 추가했습니다버퍼를 보고 있습니다.이것을 나타내기 위해. String 및 Array가 0 할당이 필요한 슬라이스를 사용할 수 있도록 하는 새로운 인터페이스를 구현한다는 의미일 수 있습니다.

라이브러리에서 이러한 새 비트를 사용하려면 라이브러리도 netstandard2.0 netcoreapp2.0 를 대상으로 해야 합니다. 그 맞습니까?

이전 4.x 프레임워크를 더 이상 지원하지 않는 것은 정말 나쁜 생각입니다. 많은 작업이 필요하면 사람들은 업그레이드하지 않습니다. 약 15년 ​​동안 2002년부터 더 이상 사용되지 않는 매우 오래된 클래식 ASP를 참조하세요. 그리고 우리는 여전히 고전적인 ASP에 존재하는 오래된 응용 프로그램을 가지고 있습니다! Microsoft는 비슷한 것을 다시 보고 싶어합니까? 오래된 4.x 지원을 중단하는 것은 의무적으로 수행되어야 하는 일이지만 장기적으로는! 지금은 아닙니다. 이것은 .NET 코어가 사실상의 표준이고 오래된 애플리케이션만 net 4.x를 사용하는 몇 년 안에 옵션이 될 수 있습니다.

(ASP).NET Core 이면의 아이디어는 정말 훌륭합니다. Microsoft가 .NET이 출시된 이후 가장 잘한 일입니다. 그러나 그러한 혼란은 이 멋진 개념을 무디게 만듭니다. 또한 Microsoft가 커뮤니티에서 논의조차하지 않고 스스로 이러한 대규모 변경을 결정한다는 것은 매우 슬픈 일입니다! 이 회사는 아직 오픈 소스 프로젝트를 처리하는 방법을 완전히 배우지 못한 것 같습니다.

@davidfowl

.NET Standard는 항상 폭에 관한 것이었습니다.

API 또는 플랫폼의 폭?

.netcoreapp .netstandard 를 진화시키는 데 문제가 있습니까?
다른 프레임워크에서는 구현되지 않을 것이기 때문에 BCL 조정 대상이 .netcoreapp 에만 해당합니까?

$# .netcoreapp2.1 와 동시에 .netstandard2.1 를 릴리스해도 .netcoreapp2.1 를 먼저 릴리스하고 $#와 동시에 .netstandard2.1 를 릴리스하는 것과 차이가 없습니다 .net50 , 단 .netstandard2.1 를 대상으로 하는 패키지는 .net50 에서 즉시 작동하기 시작하지만 .netcoreapp2.1 를 대상으로 하는 경우 차단됩니다.

ASP.NET Core는 .NET Core를 기반으로 구축된 상위 수준 웹 애플리케이션 프레임워크이며 향후 .NET Core를 대상으로 할 예정입니다. 그러나 대신 .NET Standard를 기반으로 구축된 상위 수준 웹 애플리케이션 프레임워크가 될 수도 있습니다. 특정 구현이 아닌 참조 API 인터페이스입니다.

.NET Standard의 공개 포지셔닝은 구현 세부 사항을 제쳐두고 구축하기 쉬운 대상이 됩니다. 대부분의 사용 사례를 다루는 Microsoft에서 직접 제공하는 2개의 공식 프레임워크를 사용합니다.

왜 지금 그 이야기를 변경합니까? .NET Framework가 따라잡지 못한다면 그것은 요점을 벗어난 것 같습니다. 적어도 그렇게 할 가능성이 있거나 다른 제3자 프레임워크가 그렇게 할 수 있습니다. 그렇다면 현실적으로 보조를 맞추는 단일 구현만 있다면 어떨까요? 이것이 바로 하나의 구체적인 구현이 있더라도 애플리케이션에 인터페이스가 있는 이유이므로 유연성과 이점이 있습니다.

ASP.NET Core 2.0의 범위를 .NET Standard 2.0과 인라인으로 축소한 다음 새로운 기능에 .NET Standard 2.1을 사용하시겠습니까? 적절한 지원 일정을 추가하면 이 모든 딜레마가 해결되지 않을까요? Microsoft는 .NET Standard와 두 프레임워크를 모두 소유하고 있으므로 버전 증가에 대한 이러한 두려움은 완전히 근거가 없는 것처럼 보입니다...

ASP.NET에서 ASP.NET Core로의 마이그레이션이 모든 사람을 위한 마이그레이션 경로가 아니라는 점을 고려해야 합니다.

전체 프레임워크의 ASP.NET은 그대로 유지되고 기능을 가져오지만 Core와는 다릅니다.

마이그레이션은 시간이 지남에 따라 쉬워지지만 100% 일치하지는 않습니다.

사람들은 여전히 ​​고전적인 ASP를 실행합니다. 그들에게도 좋습니다.

@davidfowl 저는 팀 전체와 여러분 모두의 발전에 큰 존경을 표합니다. 그러니 부디 이것이 일어나고 있는 일에 대해 얕잡아 보는 것으로 받아들이지 마십시오. 여러분은 개척자이며 우리는 모두 여러분을 올바른 일을 하는 방법에 대한 모범으로 보고 있습니다. 그러나 나는 이러한 요점 중 많은 부분을 즉각적인 목표 변경 문제로 보지 않습니다. 특히 전달되지 않은 경우에는 더욱 그렇습니다. 내가 틀렸을 수도 있습니다.

그것은 몇 번 언급되었기 때문에 나는 여기에 미친 것들을 던지고 싶습니다. 내가 말하려는 것은 무슨 일이 일어날지 아무 ​​상관이 없으며, 이 시점에서 모두 추측입니다. 여러 사람들이 .NET Standard 대신 .NET Core를 대상으로 하려는 이유를 묻습니다.

• 우리는 .NET Core에서 해결하고자 하는 주요 사항 중 하나로 문자열을 식별했습니다. 수많은 아이디어가 있지만 그 중 하나는 기본적으로 문자열을 utf8로 설정하는 것입니다(수많은 호환성 문제가 있지만 여기에서 따라오세요).

여기서 이 점은 확실히 게임 체인저가 될 것이지만 IMO는 프레임워크를 대상으로 지정하지 않아야 하는 유일한 항목이며 어쨌든 netcoreapp20용이 아닙니다.

• 우리가 수정하고 싶은 또 다른 것은 배열/문자열의 저렴한 조각, 인접 메모리 조각을 가져오는 기능입니다. 스팬을 추가했습니다버퍼를 보고 있습니다.이것을 나타내기 위해. String 및 Array가 0 할당이 필요한 슬라이스를 사용할 수 있도록 하는 새로운 인터페이스를 구현한다는 의미일 수 있습니다.
• 이것은 매번 배열을 할당하지 않는 분할을 허용하는 String에 대한 새로운 메소드로 이어집니다.
• 이로 인해 Span을 사용하는 Int, UInt 등(TryParse)에 대한 오버로드가 발생합니다.및 스팬.
• 이것은 Span을 사용하는 새로운 인코딩 루틴으로 이어집니다..
• 완충기및 스팬메모리를 균일한 방식으로 표현할 수 있도록 하고 Span을 사용하는 미리 고정된 버퍼를 전달할 수 있도록 네트워킹 스택을 업그레이드하려고 합니다.또는 버퍼.

이 모든 것은 여전히 ​​현재 netstandard 위에 패키지로 구현 가능합니다. 이를 위해 netstandard20도 필요하지 않습니다. 나는 이 짐을 가지고 다니고 싶지 않다는 것을 이해하지만 MS가 아닌 세계의 나머지 사람들은 사용 사례나 성능이 맞지 않을 때 항상 맞춤형 BCL과 유사한 impl을 만들어야 합니다. Span API가 2.0을 대상으로 하지 않는다는 것은 말할 것도 없고(다시 변경되지 않는 한).

Kestrel은 2.x 시간 프레임(현재 2.1을 목표로 함)에 HTTP2를 구현하며 ALPN을 수행하려면 SSL 스트림에 대한 새로운 API가 필요합니다(https://en.wikipedia.org/wiki/Application-Layer_Protocol_Negotiation).
.NET Core의 Http 클라이언트는 이중 스트리밍을 지원하므로 웹 소켓이 아닌 단일 http 요청을 통해 시그널러에서 http를 통한 스트리밍 끝점을 구현할 수 있습니다.

나는 이것이 조금 더 까다롭다고 생각하지만, Kestrel이 libuv를 가지고 다니는 것과 별반 다르지 않습니다. .Net Core의 CURL 구현은 모두가 따라잡을 때까지 netstandard 확장 패키지로 쉽게 가져올 수 있습니다.

• HttpClient 및 System.Net.Http에서 헤더 파서 구현을 분기하고 개선할 수 있도록 이름을 변경했습니다(https://github.com/aspnet/HttpAbstractions/tree/d1d9bceff56cb44a194ae36923ce687e5e353006/src/Microsoft.Net.Http.Headers). .NET Framework와 .NET Core를 모두 지원하도록 합니다. .NET Core에는 이러한 개선 사항의 복사본이 있습니다. 개선할 필요가 없기 때문입니다(사용할 수 없음).

맞습니다, 하지만 이것은 틀림없이 이 경우에 이것을 하는 올바른 방법입니다. 기다리며 구현에 매달리는 것이 답답하지만, 다른 사람이 프레임워크나 라이브러리를 작성할 때 하는 것과 이것이 어떻게 다른지 모르겠습니다.

• 핵심 프리미티브를 수정할 수 있는 능력이 없다면, 우리는 그것들을 분기하여 비슷하게 보이지만 그렇지 않은 것을 만드는 것이 좋습니다. 이것이 우리가 ASP.NET Core https://github.com/aspnet/Common/tree/dev/src/Microsoft.Extensions.Primitives 내에 자체 BCL을 가지고 있는 이유입니다.

다시 말하지만, 우리처럼.

ASP.NET Core와 .NET Core는 경량 마이크로 서비스를 구축하기 위한 경쟁적인 크로스 플랫폼 서버 스택에 관한 것이었습니다.

ASP.Net Core에는 그런 메시지가 있었습니다. .Net Core는 첫날부터 완전히 작동하는 xplat 서버 측 .Net 프레임워크 하위 집합으로 메시지를 받았습니다. .Net Core가 마이크로서비스만을 위한 것이라고 말하는 사람을 본 적이 없습니다. 원하는 경우 ASP.Net Core와 함께 사용할 수 있다고 들었습니다. 콘솔 앱, 데이터 분석, DB 서비스 등도 사용할 수 있습니다. .Net Core의 방향은 효과적으로 "ASP.Net Core 팀이 가장 원하는 것"입니까?

전체 프레임워크의 ASP.NET은 그대로 유지되고 기능을 가져오지만 Core와는 다릅니다.

그럴까요? 아직 MS에서 아직 작업 중이라고 확인하는 사람을 본 적이 없습니다. 제 직감은 그렇지 않다고 합니다. 알겠어. 팀이 자유로워지려면 "이동하지 않으면 지는" 유형의 순간이 필요합니다. 아직은 그런 순간이 아닌가 싶다.

Oracle.Net 드라이버, NHibernate 및 RabbitMQ(모두 4.6에 있음)를 사용하는 비즈니스 로직 4.6 어셈블리가 있다고 가정합니다. ASP.Net과의 인터페이스는 비즈니스 개체, 요청 및 응답을 통해서만 이루어집니다. 재컴파일 없이 ASP.Net Core 2에서 이 어셈블리를 참조할 수 있습니까?

내 빠른 요약

@stefan2410 짧은 대답, 아니요, 전체 프레임워크를 참조할 수 없습니다. netstandar 2.0용으로 생성된 경우에만 해당 어셈블리를 참조할 수 있습니다.

@mattnischan

이 모든 것은 여전히 ​​현재 netstandard 위에 패키지로 구현 가능합니다. 이를 위해 netstandard20도 필요하지 않습니다. 나는 이 짐을 가지고 다니고 싶지 않다는 것을 이해하지만 MS가 아닌 세계의 나머지 사람들은 사용 사례나 성능이 맞지 않을 때 항상 맞춤형 BCL과 유사한 impl을 만들어야 합니다.

죄송하지만 실제로는 그렇지 않습니다. 원숭이 패치 유형을 사용할 수 없습니다. 당신이 제안하지 않는 한 우리는 새로운 유형을 추가하고 기존 유형을 변경하지 않습니다.

Span API가 2.0을 대상으로 하지 않는다는 것은 말할 것도 없고(다시 변경되지 않는 한).

Span은 2.0에 구현으로 존재하지만 공개 API는 아닙니다. 우리는 부 버전에서 더 많은 기능을 수행할 수 있도록 새로운 메이저에서 주요 변경 사항을 만듭니다. ASP.NET Core 2.1이 .NET Standard 2.1을 대상으로 하는 경우 .NET Framework 지원이 다시 중단됩니다.

나는 이것이 조금 더 까다롭다고 생각하지만, Kestrel이 libuv를 가지고 다니는 것과 별반 다르지 않습니다. .Net Core의 CURL 구현은 모두가 따라잡을 때까지 netstandard 확장 패키지로 쉽게 가져올 수 있습니다.

따라서 말씀하신 내용은 BCL의 모든 클래스 이름을 .NET Standard 모두에서 사용할 수 있도록 이름을 바꿔야 한다는 것입니다.

.Net Core가 마이크로서비스만을 위한 것이라고 말하는 사람을 본 적이 없습니다. 원하는 경우 ASP.Net Core와 함께 사용할 수 있다고 들었습니다. 콘솔 앱, 데이터 분석, DB 서비스 등도 사용할 수 있습니다. .Net Core의 방향은 효과적으로 "ASP.Net Core 팀이 가장 원하는 것"입니까?

아니요, .NET Core는 원래 핵심에 카테고리가 없었던 범용 프레임워크입니다. ASP.NET Core는 .NET Core 위에 있는 라이브러리가 아니라 수직적이어야 했을 가능성이 있습니다. 이 혼란의 일부를 피할 수 있었을 것입니다.

그럴까요? 아직 MS에서 아직 작업 중이라고 확인하는 사람을 본 적이 없습니다. 제 직감은 그렇지 않다고 합니다. 알겠어. 팀이 자유로워지려면 "이동하지 않으면 지는" 유형의 순간이 필요합니다. 아직은 그런 순간이 아닌가 싶다.

예, HTTP/2 지원이 마지막 릴리스에 추가되었습니다. ASP.NET 및 IIS에서 작업하는 다른 팀 이 있으며 개선 작업을 수행합니다. 그러나 ASP.NET Core가 수행하는 것과 동일한 규모는 아닙니다.

나는 전염병과 같은 전체 프레임워크에서 ASP.NET Core 서비스를 실행하는 것을 피했기 때문에 이에 대해 그다지 강한 감정을 갖고 있지 않습니다. 즉, netstandard2.0 를 기다리고 있거나 단순히 원하지 않았기 때문에 .NET Standard를 지원하지 않았기 때문에 일부 훌륭하고 성숙한 라이브러리를 사용하는 것을 피해야 했습니다.

내 두려움은 전체 프레임워크에서 ASP.NET Core를 실행하는 기능을 제거하면 사용자가 현재 MVC 5/Web API 2 앱을 ASP.NET Core로 이식하지 못하게 하여 라이브러리 작성자가 .NET으로의 이식을 피해야 하는 또 다른 이유를 제공할 수 있다는 것입니다. 기준. 사용자 중 누구도 혜택을 받지 못한다면 왜 작업 업그레이드를 귀찮게 합니까? 그것은 닭과 달걀의 문제가 되며 이것이 약간의 관심을 끌기 시작한 것처럼 생태계 전체에 해를 끼칠까 두렵습니다. 먼저 ASP.NET Core 사용자가 필요하며 우리 모두가 원하는 만큼 많은 사용자가 있는지 확신할 수 없습니다. 내가 틀렸으면 좋겠어.

ASP.NET Core 2.1이 .NET Standard 2.1을 대상으로 하는 경우 .NET Framework 지원이 다시 중단됩니다.

아니요, Net Framework가 .NET Standard 2.1을 지원하는 즉시 자동으로 ASP.NET Core 2.1을 지원한다는 의미입니다. 1~2년이 걸리더라도 말입니다.

다른 모든 .NET Standard 호환 플랫폼(Xamarin/Unity/...)에 대해서도 동일합니다.

.NET Standard를 기반으로 구축한다는 것은 다른 플랫폼이 _심지어_ 밝혀질 것이라는 것을 의미하고, .NET Core를 기반으로 구축한다는 것은 그들이 __절대_ 켜지지 않을 것임을 의미합니다.

오랜 지연이 있더라도 full-fx가 netstandard를 따라잡을 계획이라고 가정합니다.
(그리고 NET Core를 제외한 다른 플랫폼이 .NET Standard 2.1을 구현할 것으로 예상되지 않는다면 왜 .NET Standard가 있습니까?)

죄송하지만 실제로는 그렇지 않습니다. 원숭이 패치 유형을 사용할 수 없습니다. 당신이 제안하지 않는 한 우리는 새로운 유형을 추가하고 기존 유형을 변경하지 않습니다.

후자는 대부분의 경우 1.x에서 이미 수행된 작업입니다. 맞습니까? 갑자기 더 이상 지속 가능하지 않습니까?

Span은 2.0에 구현으로 존재하지만 공개 API는 아닙니다. 우리는 부 버전에서 더 많은 기능을 수행할 수 있도록 새로운 메이저에서 주요 변경 사항을 만듭니다. ASP.NET Core 2.1이 .NET Standard 2.1을 대상으로 하는 경우 .NET Framework 지원이 다시 중단됩니다.

왜 떨어졌을까요? Span이 Framework에 _절대_ 존재하지 않는다는 말씀이신가요?

따라서 말씀하신 내용은 BCL의 모든 클래스 이름을 .NET Standard 모두에서 사용할 수 있도록 이름을 바꿔야 한다는 것입니다.

와, 아니. 다른 API가 포함된 사전이 필요한 경우 Microsoft.Net에서 이미 수행한 것처럼 System.Collections.Generic.Dictionary라고 부르지 말고 다른 것을 만들어야 합니다.*

예, HTTP/2 지원이 마지막 릴리스에 추가되었습니다. ASP.NET 및 IIS에서 작업하는 또 다른 팀이 있으며 개선 작업을 수행합니다. 그러나 ASP.NET Core가 수행하는 것과 동일한 규모는 아닙니다.

공정 해. 나는 그것을 모르고 있었다.

후자는 대부분의 경우 1.x에서 이미 수행된 작업입니다. 맞습니까? 갑자기 더 이상 지속 가능하지 않습니까?

그것은 혼란을 만듭니다. 그들은 가능한 한 적게 하려고 노력했습니다. API 설계 및 배포는 대부분의 사람들이 인식하는 것보다 훨씬 더 복잡합니다. 그리고 Microsoft가 그렇게 만드는 것이 아니라 많은 플랫폼과 일정을 지원하는 현실입니다. 나는 그 중간에 몇 번이고 모든 것을 말할 때까지 이것을 감사하지 않았습니다. 하지만 형식 전달이 메서드 수준에서 이루어졌으면 합니다. 지금까지 꽤 많은 경우를 해결했을 것입니다 :(

왜 떨어졌을까요? Span이 Framework에 절대 존재하지 않는다는 말씀이신가요?

전체 프레임워크에는 아직 없기 때문에 타임라인이 더 이상 정렬되지 않으므로 ASP.NET Core 2.0에서 삭제해야 합니다.

전체 프레임워크에는 아직 타임라인이 없기 때문에 타임라인이 더 이상 정렬되지 않으므로 ASP.NET Core 2.0에서 삭제해야 합니다.

AFAIK, Spans는 .NET Desktop에서 사용할 수 있는 netstandard1.x 패키지의 일부입니다(이것은 이식 가능한 구현이므로 CLR에 백업된 것과 같은 성능 향상이 없지만 가능성이 높습니다. 충분하다).

편집: System.Memory 패키지에는 netstandard1.0 TFM이 있으므로 .NET 4.5에서도 사용할 수 있습니다.

후자는 대부분의 경우 1.x에서 이미 수행된 작업입니다. 맞습니까? 갑자기 더 이상 지속 가능하지 않습니까?

그로 인해 오늘 특정 방향의 기능 작업을 중단합니다. 이는 의도적이며 .NET Framework가 작동할 수 있도록 .NET Standard 외부에 있는 항목을 복사하고 다시 구현하여 새로운 API 사용을 거부하고 있습니다. 이것이 전부는 아니지만 앞으로 다루려는 몇 가지 근본적인 부분이 있습니다. 결국 우리(Microsoft)가 양쪽을 제어합니다.

왜 떨어졌을까요? Span이 Framework에 절대 존재하지 않는다는 말씀이신가요?

Span 자체에는 어디에서나 실행되는 이식 가능한 버전이 있습니다. 빠른 구현이 .NET Framework에서 가능할지는 확실하지 않습니다. Span을 활용하는 .NET Framework에 추가될 API는 Span 자체보다 훨씬 더 오래 걸릴 수 있습니다. .NET Framework에서 문자열과 배열을 마지막으로 변경한 것이 언제입니까?

와, 아니. 다른 API가 포함된 사전이 필요한 경우 Microsoft.Net에서 이미 수행한 것처럼 System.Collections.Generic.Dictionary라고 부르지 말고 다른 것을 만들어야 합니다.*

그것이 바로 당신이 제안하는 것입니다. 우리는 Microsoft.Extensions.Collections.Generic을 원하지 않습니다. 우리는 그것을 피하기 위해 최선을 다하고 가능한 경우 이전 API 및 폴리필을 사용합니다(https://github.com/aspnet/DependencyInjection/blob/139d91e57dd31fcd5c6ddaf11ad1f771b5855807/src/Microsoft.Extensions.DependencyInjection/Internal/ConcurrentDiction). 이것은 지속 가능하지 않으며 .NET Core 사용을 적극적으로 피하기 때문에 .NET Core가 이점을 얻지 못한다는 것을 의미합니다.

범위가 있는 @PinpointTownes 는 충분하지 않으므로 기존 유형에 대한 메서드 호출에 사용해야 합니다. 그 때 클래스 수준의 형식 전달이 작동하여 많은 문제가 발생합니다.

@0x53A

공정 해. NuGet의 인기 있는 라이브러리가 분명히 지원되지 않는 이전 .NET Framework 버전에 대한 지원을 중단하지 않는 이유를 말씀해 주시겠습니까? 가장 인기 있는 라이브러리는 net20, net35, net40 등을 대상으로 합니다. ASP.NET Core를 계속 사용하기 위해 가장 높은 버전의 .NET Framework가 필요한 이유는 무엇입니까? 그것이 합리적이라고 생각하십니까?

이것은 쇼 스토퍼입니다. ASP.NET MVC 5/Web Api 2에서 Core로의 마이그레이션 취소를 고려해야 합니다. 많은 안정적인 프레임워크가 아직 코어용으로 제공되지 않습니다. EF Core가 기능 비교 가 충분히 성숙하지 않았기 때문에 우리는 여전히 EF6.x를 사용하고 있습니다.

범위가 있는 @PinpointTownes 는 충분하지 않으므로 기존 유형에 대한 메서드 호출에 사용해야 합니다.

"필요"는 아마도 약간 과도합니다. 스팬은 주로 성능을 위해 사용되므로 .NET Desktop이 스팬에 대한 기본 지원을 받을 때까지 ifdef를 사용하여 .NET Desktop에서 기존의 non-super-perfy 오버로드를 사용하는 것을 방해하는 것은 없습니다.

@davidfowl 저는 가장 큰 문제가 감정적이라고 생각합니다. netstandard를 목표로 하시면 결국 1.x에서 2.x로 업그레이드할 수 있다는 것을 알고 있습니다(지연이 있더라도). 대부분의 경우 netfx를 업데이트하는 것은 응용 프로그램(lib의 경우와 다름)에 그리 큰 문제가 아닙니다.

그러나 일부 앱은 netfx -> netcore를 절대 점프할 수 없으므로 netcore를 대상으로 하는 경우 1.x에서 막다른 골목에 있음을 알 수 있습니다.

그런 점에서 Asp.net 코어가 netfx에서 실행되지 않았더라면 더 좋았을 것입니다. 결국, 그들은 이미 이것에 많은 시간을 투자했을 수 있습니다.

나는 asp.net 사용자가 아니기 때문에 개인적으로 이것에 투자하지 않았습니다. 제 큰 질문은 사실 그냥

오랜 지연이 있더라도 full-fx가 netstandard를 따라잡을 계획이라고 가정합니다.
(그리고 NET Core를 제외한 다른 플랫폼이 .NET Standard 2.1을 구현할 것으로 예상되지 않는다면 왜 .NET Standard가 있습니까?)

net20, net35 등을 대상으로 하는 다른 라이브러리와 관련하여 내 경험에 따르면 대부분의 작성자는 가능한 가장 낮은 버전을 대상으로 하고 다른 선택의 여지가 없는 플랫폼만 잘라냅니다.

그리고 __예, 이전 버전의 .NET Framework__에 대한 지원을 중단하는 것이 합리적이라고 생각합니다. 아직 사용할 수 있는 명확한 마이그레이션 경로가 있기 때문입니다. 버전을 업데이트하면 됩니다. 대부분의 경우 "그냥" 재컴파일하고 테스트하여 변경할 필요가 없습니다.

저는 여러분이 넷코어를 대상으로 할 수 없는 앱의 수를 심각하게 과소평가하고 있다고 생각합니다. 단일 폐쇄 소스 타사 종속성만으로도 이를 차단하기에 충분합니다.

Span 자체에는 어디에서나 실행되는 이식 가능한 버전이 있습니다. 빠른 구현이 .NET Framework에서 가능할지는 확실하지 않습니다. Span을 활용하는 .NET Framework에 추가될 API는 Span 자체보다 훨씬 더 오래 걸릴 수 있습니다. .NET Framework에서 문자열과 배열을 마지막으로 변경한 것이 언제입니까?

@davidfowl 나는 이것이 아마도 문제의 일부라고 생각합니다. 저는 솔직히 여기에서 약간 악마의 옹호자 역할을 하고 있습니다. .Net Core 직전에 시작된 미개발 앱으로 중간에 갇혔기 때문에 우리는 경계를 넘나들고 있습니다.

가능하면 Kestrel과 같은 멋진 새 라이브러리를 사용하되 .Net Core가 안정화되기를 기다리거나(도구 변경만 가능하다면 다행입니다), _또는 _ 멋진 코어 비트를 사용하여 Framework로 돌아갑니다. 나는 대부분의 사람들이 corefx가 만들어낸 발전의 전부는 아니더라도 대부분이 Framework vNext 또는 vNext+1에 포함될 것이라고 가정하고 있다고 생각합니다. 그러나 (30,000피트 보기에서) 이 변경 사항과 다른 변경 사항에서 Framework가 미래의 플랫폼이 아닌 것처럼 보입니다.

그런 거라면 그런 것 같아요. 우리 프로젝트는 방대하기 때문에 BCL 유형이나 ifdef 스파게티에 가깝지만 완전히 그렇지는 않은 커스텀 impl을 많이 갖는 고통을 이해한다고 말할 때 저를 믿으십시오. 그래서, 나는 합병증의 무지에서 일을 제안하는 것이 아닙니다. 확실히 절충점이 있습니다.

참으로 좋은 질문입니다. .net 핵심 기능을 .NET 전체로 백포팅하면 무엇이 남습니까? 여기에서 읽은 것처럼 .NET 전체는 너무 부서지기 쉽고 코드를 옮기는 데 시간이 오래 걸리고(매우 느리게 이동) 언제든지 중단될 수 있습니다(얼마나 얽혀 있는지 모를 수 있음). 매우 자주.

둘 다일 수는 없습니다. .NET 전체로 백포팅하는 것은 괜찮습니다. 릴리스 빈도가 낮거나(예: 6개월에서 1년마다) 매우 복잡하고 오류가 발생하기 쉽습니다. 전자라면 속도를 높이고 사용자가 요금을 지불하게 하고 후자를 핑계로 사용하지 않도록 하십시오. 후자라면 미래 에 중요한 것은 어쨌든 .netcore의 API이므로 netstandard는 오류라는 올바른 결론이 아닙니까?

저는 .NET의 방향이 나아갈 미래에 대해 심각하게 우려하고 있습니다. 우리 회사는 .NET 전체 및 .NET 표준 1.6용 도구를 구축합니다. 마지막으로 우리가 원하는 것은 .NET 방향의 추진력(몇 달 전 .NET 핵심 발표에서 말했듯이 .NET 전체로 백포트될 새로운 기능)이 사물과 생태계를 효과적으로 분리하는 것입니다. 조각화가 죽이기 때문에 반으로 나뉩니다.

이 스레드의 어떤 것도 _all_ .NET의 미래와 생태계를 유지하는 데 필요한 생태계를 위해 괜찮다고 저를 안심시켰습니다. 두 그룹만 볼 수 있습니다.

• 옵션이 복잡해지고 앞으로 어려운 문제가 있다고 걱정하시는 분
• 한 가지 앞길을 내다보고 있는 Microsoft는 바로 .net 핵심 도로입니다.

이 둘은 현재 일치하지 않습니다. Microsoft의 누군가가 일관된 이야기를 제공하여 실제 거래가 무엇인지, 상황이 실제로 어떤지, 즉 .net 전체에 대한 기능 백포팅과 함께 .net 코어에서 누락된 무수히 많은 항목에 대해 수행된 작업을 모두 볼 수 있도록 해주실 수 있습니까? (sqlserver 항목, 트랜잭션 범위 등) 및 Microsoft가 이 새로운 방향을 미래를 위한 견고하고 안정적이며 신뢰할 수 있는 플랫폼으로 판매하여 기업과 대규모 팀이 걱정 없이 선택할 수 있다고 생각하는 방법.

이 모든 것이 장기적으로 좋은 일이라는 점에는 동의하지만 2.0에서 전체 프레임워크에 대한 지원을 중단하는 것은 너무 이르다고 생각합니다.

가능한 한 빨리 .NET Core로 이동하고 싶지만 불행히도 현재 가장 큰 방해 요소는 거의 독점적인 Microsoft 라이브러리 입니다(예: Entity Framework Core는 아직 충분하지 않으며 Azure Service Bus는 매우 초기 미리 보기만 있음).

Azure 라이브러리가 다음 주/달에 준비되기를 희망하지만 EF Core가 조만간 충분한 기능을 갖추게 될 것 같지 않습니다.

EF6의 내부에 대해 아무것도 모르지만 netstandard를 대상으로 하는 합리적인 노력으로 가능하지 않을까요? 이것은 거대한 차단기를 제거 할 것입니다 ...

"그냥 1.x에 머무르는 것"은 좋은 대안이 아닌 것 같습니다. 왜냐하면 상관하지 않는(또는 둘 다 지원하는 리소스/지식이 없는) 라이브러리가 많이 있을 것이기 때문입니다. 2.0

추신: 지난 몇 년 동안 .NET 생태계가 얼마나 복잡해졌는지 매우 실망스럽습니다. 나는 새로운 모든 것을 이해하는 데 많은 시간을 소비해야 했고 새로운 개발자가 이것을 이해하는 방법을 알지 못합니다. 이러한 극단적인 주요 변경 사항으로 인해 현재 인터넷에는 오래된 정보가 너무 많습니다.
또한 모든 다른 제품 버전(.net core, sdk, .net standard, ...)은 매우 혼란스럽습니다. 20분의 설명 없이 .NET 표준 테이블을 이해하는 사람을 아직 본 적이 없습니다. 😞

.NET 프레임워크의 정식 버전과 함께 .net 코어를 사용하던 사람은 모두 망해서 MVC 5로 돌아가야 합니다.

네. 나는 그 추론을 이해하고, 나는 이것이 오는 것을 보았어야 한다고 말할 수 있다고 생각하지만, 사전 경고 없이 이것이 우리에게 떨어졌다는 것은 매우 실망스럽습니다.

우리는 10년 이상 된 공유 라이브러리, 여러 MVC 3, 4, 5 앱, 콘솔 앱, Windows 서비스, 수십만 줄의 코드가 있는 다른 많은 앱 생태계와 마찬가지로 애플리케이션 생태계를 보유하고 있습니다. 우리는 일부에 비해 업그레이드할 정도로 나쁜 상황에 있지도 않습니다.

우리는 최근에 ASP.Net Core 1.1을 사용하는 몇 가지 새로운 웹 앱을 만들었습니다. 반드시 전체 4.6.2 프레임워크를 대상으로 해야 합니다. 이러한 앱은 기존 공유 라이브러리의 많은 부분을 사용합니다. 우리는 project.json을 처리하고 새로운 .csproj를 처리하는 데 당황스러운 양의 개발 시간을 소모했습니다. 동일한 솔루션에서 이전 .csproj와 새 .csproj를 혼합하려고 시도하고 VS15로 돌아가서 이전 .csproj 유형으로 작업을 완료했습니다. 체계. 종속성, 수많은 어셈블리 바인딩 문제, 빌드 및 게시 문제.. 목록은 계속됩니다.

그리고 지금 우리는 막다른 길에 높이 매달리고 말랐습니다. 몇 개월에 걸친 개발을 포기하거나 먼저 작동할 수 있는 것과 작동하지 않을 수 있는 것을 확인한 다음 업그레이드 방법을 찾은 다음 가능하다면 수행하는 데 많은 시간을 할애해야 합니다.

나는 그 방향과 필요성에 동의하지 않는다고 말할 수는 없지만 더 일찍 의사 소통을 했다면 감사했을 것입니다.

아, 물론 Azure Service Fabric 라이브러리는 .NET 코어에서도 실행되지 않습니다. 이는 우리에게 또 다른 차단 요소입니다.

Microsoft(특히 Azure) 내에서 적절한 .NET 핵심 스토리를 전달할 수 있을 때까지 전체 .NET 프레임워크를 지원해야 한다고 말하고 싶습니다.

@cwe1ss 이 변경은 .NET 생태계의 복잡성을 어느 정도 줄여줄 것입니다. 두 가지 다른 형식(ASP.NET Core + .NET Full 및 ASP.NET + .NET Core)이 없기 때문입니다. 나는 시대에 뒤떨어진 정보에 전적으로 동의하지만 지금 Microsoft처럼 공개적으로 개발할 때는 피할 수 없다고 생각합니다.

@davidfowl

다양한 .NET 런타임 간의 코드 공유 스토리는 .NET Standard입니다. 라이브러리는 .NET Core 및 .NET Framework에서 공유되는 코드를 대상으로 지정해야 합니다.<

그러나 내가 이해하는 전체 프레임워크는 .net 표준도 지원하지 않으므로 실제로 유용한 표준이 아닙니다.

마이크로소프트는 이전 버전과의 호환성의 중요성을 잊은 것 같습니다.<<

문제는 ASP.NET Core가 이전 버전과 호환되도록 의도된 적이 없다는 것입니다... 그래서 ASP.NET 4.x에서 그렇게 큰 패러다임 전환이 있었던 것입니다. 이전 버전과의 호환성이 상위 비트라면 .NET Framework에서 ASP.NET 4.x를 사용하는 것이 더 나을 것 같습니다. 이는 가까운 장래에 지원되며 Windows가 살아 있는 동안 보안 패치가 적용됩니다.<

보안 패치는 문제의 일부일 뿐입니다. 웹 표준은 너무 빨리 변하기 때문에 최신 표준을 사용할 수 있는 무언가가 필요합니다. 예를 들어 HTTPS v2에 대한 내용을 위에서 본 적이 있습니다. 그것이 실제로 무엇을 의미하는지 모르지만 요점은 내 프레임워크가 이러한 것들을 지원할 수 있기를 원한다는 것입니다. v4이든 v1이든 간에 프레임워크의 이전 버전을 계속 유지해야 하는 경우 필요한 것을 지원하지 않을 것입니다.

ASP .net Core는 항상 .net Core와 프레임워크 모두에서 실행되는 것으로 마케팅되었습니다. 다른 사람들이 말했듯이 프레임워크가 따라잡을 때까지 6개월 또는 1년을 기다려야 하는 것은 저를 괴롭히지 않습니다. 어쨌든 나는 보통 6개월 이상 뒤처진다. 그러나 우리 중 많은 사람들이 시간을 투자한 다른 많은 Microsoft 기술과 마찬가지로 기존 투자가 완전히 포기되고 있는 것 같습니다.

스테판

"공개 개발"을 위한 @Rutix 이 주요 변경 사항은 발표나 설문 조사 없이 놀랍게도 조용하게 이루어졌습니다(결국 이 문제는 풀 리퀘스트를 보고 있는 커뮤니티 회원에 의해 생성되었습니다).

조용히 일을 하는 것은 과거에 마이크로소프트를 물렸고 그들은 배우지 않는 것 같습니다. 그리고 그들이 완전한 프레임워크 지원을 중단하는 것이 커뮤니티를 혼란스럽게 하고 플랫폼에 대한 믿음과 투자를 해칠 것이라는 것을 알 수 없다고 말하지 마십시오.

마지막 사건은 https://github.com/dotnet/roslyn/issues/17054 였지만 신속하게 수정했습니다. 어떻게 진행될지 궁금합니다.

그러나 내가 이해하는 전체 프레임워크는 .net 표준도 지원하지 않으므로 실제로 유용한 표준이 아닙니다.

@stefanolson 정확하지 않습니다. .Net Standard 1.x를 대상으로 하는 라이브러리는 오늘날 다양한 전체 프레임워크 버전에서 실행할 수 있습니다. .Net Standard 2.0을 대상으로 하는 라이브러리는 내가 마지막으로 본 4.6.1에서 실행할 수 있을 예정입니다.

@Suchiman 거기에 전적으로 동의합니다. 나는 그들이 의사 소통하는 방법과 커뮤니티에 폭탄을 떨어 뜨리는 방법을 배우지 않는 것 같아 약간 실망했습니다. 그들이 먼저 그것을 발표하고 커뮤니티 토론을 했다면 이 방법을 더 잘 처리할 수 있었을 것입니다.

그러나 내가 이해하는 전체 프레임워크는 .net 표준도 지원하지 않으므로 실제로 유용한 표준이 아닙니다.

@stefanolson 그렇습니다 . 다른(기존) 버전의 .NET Framework는 다른 버전의 .NET 표준을 구현합니다. https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/ 참조

이 스레드에 약간 늦었다는 것을 알고 있지만 Windows의 NetFX에서 ASP.NET Core를 사용하는 두 가지 사용 사례는 다음과 같습니다.

ASP.NET을 사용하여 애플리케이션용 REST API 호스팅

우리의 응용 프로그램은 ".NET API에서 REST API로 변환된" 종류의 응용 프로그램입니다. 처음에는 .NET API로 제공되었으며 모든 종류의 Windows 항목에 종속됩니다.

REST API를 추가할 때 ASP.NET Web API를 선택하여 호스팅합니다. Web API가 ASP.NET vNext/5/Core, __and__에서 통합되고 있다는 것이 분명해지면 __ASP.NET Core가 NetFX__에서 실행될 것이라는 것을 알아냈습니다. ASP.NET vNext/5/Core를 사용하는 것이 합리적이었습니다.

.NET Core를 활용하여 애플리케이션(일부)을 Linux 및 macOS에 이식하지만 여전히 .NET Core에서 실행되지 않는 Windows 종속성이 있습니다(포팅한 종속성 목록을 보려면 CoreCompat.* NuGet 패키지).

간단히 말해서, 우리는 이제 ASP.NET Core 1.x에 고정되어 있음을 알게 되었습니다. 이는 제한된 기간 동안 계속 지원될 것입니다. 그 다음엔? ASP.NET 4로 돌아가시겠습니까?

.NET Core의 다른 영역에서 수행하고 있는 모든 성능 작업을 이해하고 있지만 제 사용 사례에서는 인터넷에 노출된 대용량 웹 사이트를 호스팅하지 않고 REST API를 호스팅하고 있습니다. 최대 10-20RPS?

비주얼 스튜디오 지원

사실, NET 4.x에서의 Visual Studio 2017 경험은 여전히 ​​.NET Core보다 훨씬 낫습니다. 테스트 프로젝트를 다시 컴파일하고 테스트 창에 새 테스트를 표시하는 데 걸리는 시간이 좋은 예입니다. . NetFX에서는 훨씬 빠릅니다.

오늘날 우리는 본질적으로 동일한 코드베이스를 컴파일하는 NetFX 및 .NET Core 프로젝트를 가지고 있는 상황으로 끝납니다. 이 이중 유지 관리를 유지하는 유일한 이유는 .NET Core 프로젝트(_특히_ 단위 테스트 및 디버거)에 대한 Visual Studio의 성능 때문입니다.

나중에 생각해보면, 이 변경 사항이 미리 보기 출시 며칠 전에 이루어졌다는 것입니다. 아직 기술적인 이유가 없음을 나타내는 것 같습니다. 따라서 ASP.NET Core v3에서 변경하지 않는 이유는 무엇입니까?

@mattnischan

@stefanolson 정확하지 않습니다. .Net Standard 1.x를 대상으로 하는 라이브러리는 오늘날 다양한 전체 프레임워크 버전에서 실행할 수 있습니다. .Net Standard 2.0을 대상으로 하는 라이브러리는 내가 마지막으로 본 4.6.1에서 실행할 수 있을 예정입니다.<

asp.net 코어가 .net 표준이 아닌 .net 코어를 실행하는 것처럼 보입니까? 그래서 나는 .net 표준의 요점이 무엇인지 아직 확신하지 못합니다. – 그것이 만들어지자마자 사실상 폐기된다면 말입니다.

asp.net 코어에 .net 표준 2.1이 필요했다면 현재 프레임워크에는 없지만 필요한 것들이 있기 때문에 완전히 의미가 있습니다. 따라서 최신 버전의 Asp.net 코어를 사용하려면 전체 .net 프레임워크가 이러한 추가 기능을 지원할 때까지 기다려야 했습니다. 그것은 효과가 있고 의미가 있을 것입니다.

그러나 대신 그들은 표준을 쓸모 없게 만드는 표준을 포기하고 있습니다 (이 혼란스러운 상황을 올바르게 이해하고 있다면)

그래서... 빌드 2017이 내일부터 시작됩니다. 팀이 준비하느라 무척 바빴던 것 같아요. 일부 발표일 수도 있고 아닐 수도 있습니다. 그들에게 약간의 숨을 쉴 여유를 주고 일주일 후에 다시 소집할 수 있을까요?

https://build.microsoft.com/ (수요일 8:00 PST, 15:00 GMT 및 목 유사?)

우리는 더 많이 알 수 있습니다. 않을 수 있습니다. 상황이 더 명확할 수도 있고 그렇지 않을 수도 있습니다. 그러나 ASP.NET 팀은 조금 더 잘 대응하고 모두의 관심사에 더 집중할 수 있을 것입니다. @davidfowl 은 용감하게 해냈지만!

@stefanolson 그러나 대신 그들은 표준을 쓸모 없게 만드는 표준을 포기하고 있습니다 (이 혼란스러운 상황을 올바르게 이해하고 있다면)

.NET Standard의 핵심은 호환성이라고 생각합니다. 라이브러리 작성자는 .NET Standard를 대상으로 할 수 있으며 .NET Framework, .NET Core 또는 .NET Standard를 지원하는 다른 것에 관계없이 누구나 사용할 수 있습니다.

.NET Core의 요점은 .NET Framework를 다시 상상하는 것입니다. .NET Core는 플랫폼 간, 고성능, 오픈 소스이며 빠르게 발전하고 있습니다.

기본적으로 문자열 구현을 utf8로 변경하는 것은 대규모이며 .NET Framework에서 볼 수 있을 것으로 예상되는 것이 아닙니다.

이 스레드를 읽고 나면 다음과 같은 느낌이 듭니다.
.NET Core -> .NET Framework는 ASP.NET MVC -> WebForms와 같습니다.

도구 측면도 두 번째로 하고 싶습니다. 현재 복원/빌드/테스트 등의 성능은 매우 나쁩니다. "1.0을 유지"해야 하는 경우 더 나은 성능을 가진 최신 SDK를 계속 사용할 수 있습니까? 아니면 1.x SDK를 사용하게 될까요?

.NET Core 스토리는 기복이 가득한 멋진 둘러보기입니다. 우리는 최근에 ASP.NET Core 작업을 시작했는데 이전의 모든 "성공"(버전 관리, 이름 지정, project.json - .csproj 전환) 때문에 .netstandard 2.0을 고대하고 있었습니다. 이것은 첫 번째 "실제" 릴리스가 될 것입니다.

ASP.NET Core 1.1이 여전히 지원되고 향후 10년 동안 운영될 것이라는 점을 이해하지만 여러분은 매우 용감하게 ____그것을__ 빠르게 이동하고 ASP.NET Core의 초기 판매 포인트 중 하나를 잘라냅니다.

우리 측에서 차단기(디렉토리 서비스 제외)가 무엇인지 알고 싶다면: 우리는 여전히 EF6을 사용하고 있으며 netstandardwhatever를 대상으로 하는 공식 Open XML SDK NuGet 패키지를 기다리고 있습니다.
코드를 마이그레이션하는 데 시간이 매우 오래 걸릴 수 있습니다...

Asp.Net Core 라이브러리 릴리스의 유지 관리 단계의 일부로 대상을 지정하는 것과 관련된 Core에서 발생하는 변경 사항을 기반으로 netstandardXX 을 추진하기 위한 일종의 프로세스를 공식화할 수 있습니까?

그대로, ANC 웹 API를 SPA(그리고 궁극적으로 WebForms 레거시 앱에서)에 노출하고 호출할 때 트리거를 가져오려고 했던 WebForms/MVC 앱이 있지만 다음으로 인해 CoreCLR에서 개발할 수 없습니다. Sybase(현재 SAP) Ase ADO.NET 드라이버에 대한 종속성 이제 9년).

이 문제를 읽고 더 이상 내 경로가 무엇인지 확신이 서지 않습니다. 내가 계획할 수 있는 유일한 확신은 버그가 있는 드라이버가 데스크톱 프레임워크에 계속 존재한다는 것입니다. 지난 몇 년 동안 ASP.NET에 대한 변경 사항은 시간 낭비가 될 것이고 WebApi2를 대상으로 해야 하기 때문에 무시해야 합니까? 나는 앞으로 10-15년 동안 여기에서 지원될 것이라고 믿는 응용 프로그램에서 마이그레이션하지 않고 2.x의 이점을 볼 수 있다는 것을 알고 ANC 1.x를 계속 진행해야 한다고 말해야 합니까? (WebForms 앱은 1.1 프레임워크가 릴리스된 이후 마이그레이션 및 유지 관리됨)?

@davidfowl

Span 자체에는 어디서나 실행되는 이식 가능한 버전이 있습니다. 빠른 구현이 가능할지 확신하지 못합니다.
.NET 프레임워크에서. Span을 활용하는 .NET Framework에 추가될 API는 Span 자체보다 훨씬 더 오래 걸릴 수 있습니다. .NET에서 문자열과 배열을 마지막으로 변경한 것이 언제입니까?
뼈대?

무엇을 기다립니다?

우리 모두가 웹 개발자는 아닙니다. 우리는 수년 동안 더 나은 문자열 처리 지원을 간절히 기다리고 있었는데 갑자기 우리가 SOL이라고 말하는 것입니까? .NET Framework 및 이를 기반으로 구축된 수많은 비 웹 응용 프로그램이 Span을 기반으로 하는 문자열 처리 라이브러리에 액세스할 수 없다는 사실은 무엇입니까?

이것은 더 이상 ASP.NET만의 문제가 아닙니다. 이는 .NET Framework 및 기본 클래스 라이브러리에 대한 Microsoft의 장기적인 노력의 핵심입니다.

알다시피, @davidfowl 과 같은 사람들에게 계속해서 모든 사람과 이 토론에 기여한 모든 사람에게 답장을 보내야 합니다. 오늘 일찍부터 따라잡을 것이 많지만 모든 사람이 .NET을 사용하고/사용하기를 희망하는 측면에서 각 댓글을 통해 많은 것을 배우고 있는 것 같습니다.

나는 우리가 결국 모든 사람의 도움으로 어떤 길을 곧게 만들 것이라고 생각하고 모든 면이 고려되기를 바랍니다.

공식 발표를 간절히 기다리고 있습니다

내가 올바르게 이해했다면 net coreapp 2.0은 ASP.NET Core 2.0 프로젝트가 레거시 NetFx 클래스 라이브러리(예: net461)에 종속되도록 하는 호환성 shim을 제공합니다.
현재 계획된 이러한 compat shim의 기능/제한에 대한 자세한 정보는 어디에서 찾을 수 있습니까?

@dgaspar 그것은 정확하지 않습니다. 작동 방식은 다음과 같습니다. netcoreapp2.0 는 net461 에서 대부분 의 API를 지원합니다. 라이브러리가 net461 용으로 빌드되고 netcoreapp2.0 가 지원하는 하위 집합 내에 존재하는 API만 호출하는 경우 어쨌든 라이브러리를 가져올 수 있습니다. 호출하는 모든 클래스와 메서드가 있어야 하므로 실행합니다.

이제 단점도 있습니다. 메소드 가 없거나 어떤 식으로든 완전히 지원되지 않으면 누락된 메소드 등에 대한 런타임 오류가 발생합니다. 따라서 컴파일 시간 검사는 좋은 보장이 아닙니다. 알고 있어야 할 양날의 검이지만 아직 업데이트되지 않은 일부 라이브러리는 호출하는 API 세트로 ​​문제가 없습니다.

@NickCraver 기억하시는 분...

"imports": [ "dnxcore50", "portable-net45+win8" ]

12월에 작성한 관련 댓글입니다. 11개의 엄지손가락을 위로 이월:

여기에서 문제가 발생했습니다. 저는 15년 동안 C# 앱을 출시해 왔습니다. 아이러니하게도 Microsoft에서 더 높은 수준의 추상화를 제공함에 따라 이전에는 걱정할 필요가 없었던 내부를 깊이 파고드는 데 점점 더 많은 시간을 할애하고 있습니다. 당신은 잘못하고있어.

컴파일러가 포착하지 못한 임의의 라이브러리 및 패키지 관리 유발 오류로 런타임에 놀라고 싶다면 Ruby로 앱을 작성하겠습니다.

node.js를 사용하면 모든 netfx 라이브러리를 쉽게 호출할 수 있습니다.

mvc 코드는 정말 쉬운 부분입니다. node.js 또는 nancy에서 다시 작성하는 데 몇 주가 걸릴 수 있지만 비즈니스 및 알고리즘 코드를 이식하고 이전 코드만큼 견고하게 작동하는지 증명하는 데 훨씬 더 오래 걸릴 것입니다. 소스가 없는 경우는 말할 것도 없습니다.

RyuJit을 예로 들자면 프로덕션으로 출시된 후에도 주요 버그를 차단하는 것이 발견되었으며 완전히 해결하는 데 1년이 더 걸렸습니다. 애완동물 가게가 아니라 하루에 수백만 달러를 버는 데 도움이 되는 산업용 도구인 소프트웨어도 마찬가지입니다.

UI 프레임워크는 winform에서 web으로 빠르게 변경됩니다. 그러나 핵심 비즈니스 논리/알고리즘은 훨씬 더 안정적이고 오래 지속됩니다. 그래서 새로운 빛나는 UI 프레임워크를 사용하려면 비즈니스/알고리즘 코드를 다시 작성/재테스트하거나 포기해야 합니까? 아니요, 우리는 새로운 반짝이는 것이 5년 안에 더 유행하는 것으로 대체될 것이라는 것을 알고 있었지만 우리의 비즈니스/알고리즘 코드는 계속 사용될 것입니다.

@qmfrederik

나중에 생각해보면, 이 변경 사항이 미리 보기 출시 며칠 전에 이루어졌다는 것입니다. 아직 기술적인 이유가 없음을 나타내는 것 같습니다. 따라서 ASP.NET Core v3에서 변경하지 않는 이유는 무엇입니까?

우리는 다음에 HTTP2 지원을 하고 있으며 새로운 API가 필요합니다.

도구 측면도 두 번째로 하고 싶습니다. 현재 복원/빌드/테스트 등의 성능은 매우 나쁩니다. "1.0을 유지"해야 하는 경우 더 나은 성능을 가진 최신 SDK를 계속 사용할 수 있습니까? 아니면 1.x SDK를 사용하게 될까요?

네, 작동합니다.

@davidfowl

다음으로 HTTP2 지원을 하고 있으며 새로운 API가 필요합니다.<

그렇다면 asp.net core 2.0에서 사용할 수 있는 HTTP2 지원은 1.x에서 사용할 수 없습니까? 이것은 우리가 어떤 이유로든 완전한 .net 프레임워크에 묶여 있기 때문에 최신 기술에 액세스할 수 없는 위치에 대해 걱정하는 종류의 문제입니다. 위에서 말했듯이 필터가 내가 사용하는 모든 항목에 도달하는 데 6개월에서 1년이 걸리더라도 궁극적으로 너무 뒤쳐지는 것을 원하지는 않습니다. 이 단계에서 코드 공유 및 타사 라이브러리 사용으로 인해 전체 .net 프레임워크가 필요합니다.

마지막으로 몇 가지 사항을 명확히 합니다.

• 레거시 모듈이라고 하면 netfx 또는 C++/cli dll에 따라 달라지는 dll이며, 이 dll은 일부 기본 dll을 호출할 수 있습니다. 비즈니스/알고리즘용, COM용, asp.net용이 없습니다. 그들은 나쁘지 않습니다. 주로 .net 코어에서 실행하지 않기 때문에 레거시가 됩니다.
• 장기적으로 넷 코어로 마이그레이션하는 것이 가능하며 우리는 그것을 정말로 원합니다. 하지만 그렇게 하도록 추진하는 것은 정말 어렵습니다. 우리와 제3자가 모두 거기에 도달하려면 몇 년이 걸릴 것입니다.
• 도메인 특정 라이브러리는 기술 스택 변경을 위한 주류 라이브러리보다 훨씬 느립니다. 우리 모두는 파이썬 3 예제를 알고 있습니다. 해당 도메인 특정 라이브러리는 실제 비즈니스입니다.

@danielcrabtree

.NET Core의 요점은 .NET Framework를 다시 상상하는 것입니다. .NET Core는 플랫폼 간, 고성능, 오픈 소스이며 빠르게 발전하고 있습니다.<

정말 환상적입니다. 문제는 기존 코드 기반을 어떻게 처리하고 .net 코어와 함께 사용할 수 있도록 하는 것입니다. .net 코어에 구축된 WPF를 사용할 수 있다면 어디에서나 .net 코어를 사용할 수 있습니다. 그러나 그렇지 않고 내 코드가 WPF와 ASP.net 간에 공유되므로 공유 방법이 필요합니다. 그러나 최신 웹 기술과 보안 기술에 너무 뒤처지고 싶지 않습니다. 그 중 대부분(모두?)은 2.x 이상에만 있을 것 같습니다.

이 스레드와 .NET Core의 다른 문서에서 여러 번 플랫폼 간으로 설명됩니다. 이것은 플랫폼으로 이동하는 주요 판매 포인트 중 하나로 광고되었습니다.

그러나 트위터의 이 대화에서 명확히 알 수 있듯이 그렇지 않은 것 같습니다.

https://twitter.com/James_M_South/status/861595907782987776

그리고 위의 댓글; 강조 내.

.NET Core 2에서 누락된 나머지 큰 격차는 System.DirectoryServices 및 System.Drawing입니다. 우리는 이번 여름 에 Windows의 .NET Core에서 두 가지를 모두 사용할 수 있는 Windows 호환 팩 을 만들기 위해 노력하고 있습니다.

저는 ImageSharp 를 사용하여 System.Drawing 에 의해 남겨진 격차를 채우기 위해 아주 초기부터 .NET Core로 매우 열심히 일해 왔으며 이제 매우 혼란스럽고 약간 불만을 품고 질문하게 되었습니다.

이제 .NET Core는 무엇입니까?

다음은 MS Docs 의 설명입니다.

.NET Core는 Microsoft 및 GitHub의 .NET 커뮤니티에서 유지 관리하는 범용 개발 플랫폼입니다. Windows, macOS 및 Linux를 지원하는 크로스 플랫폼이며 장치, 클라우드 및 임베디드/IoT 시나리오에서 사용할 수 있습니다.

그 크로스 플랫폼 성명이 또 있습니다. 인가 아닌가? 이 문제를 해결하려는 시도는 개발 커뮤니티 전반에 걸쳐 많은 혼란을 야기한다고 생각합니다.

내가 읽은 모든 설명은 다른 것 같습니다.

우리는:

1. 우리가 실제로 목표로 삼고 전반적인 이해를 높일 수 있도록 적절하고 일관된 메시지를 어딘가에 적어 두십시오.
2. System.DirectoryServices 및 System.Drawing 에 대한 실제 로드맵에 대해 명확하게 전달

특히 System.Drawing 는 혼란스럽고 우려스럽습니다. 모든 플랫폼에서 해당 API를 .NET Core로 이식하려는 이유를 이해할 수 없습니다. 작업하기 어렵고 서버에서 지원되지 않으며 최신 개발에 필요한 많은 중요한 기능(멀티 스레딩, 픽셀 형식, ICC, EXIF, 양자화, 색인화된 Png 등)이 부족합니다.

여기에는 알아볼 수 있는 이름과 얼굴이 많이 있으며 여기에 약간의 노이즈를 추가하는 것으로 알고 있습니다. 하지만 다음과 같습니다.

• 디렉토리 서비스
• 그림 그리기(필요하지 않음)
• EF

이 세 가지는 큰 휴식을 취하기 전에 속도를 내야 하는 가장 중요한 세 가지인 것 같습니다. 개인적으로, 내가 작업하는 대부분의 모든 것은 오로지 EF6 때문에 net4x에서 이루어집니다. EFCore... 음... :trollface:

@stefanolson
공유 코드를 .NET Standard 라이브러리로 분리해야 한다고 생각합니다. 그런 다음 .NET Framework의 WPF 및 ASP.NET과 .NET Core 및 기타 .NET Core 애플리케이션의 ASP.NET에서 사용할 수 있습니다.

@JimBobSquarePants
Windows 호환 팩이 .NET Core의 일부라고 생각하지 않습니다. .NET Core 위에 있는 Windows 전용 라이브러리입니다. Linux 전용 기능을 노출하는 Linux 전용 라이브러리가 있다고 상상할 수 있습니다.

Windows 호환 팩은 기존 .NET Framework 코드 기반을 더 쉽게 마이그레이션할 수 있도록 해준다고 생각합니다. 분명히 누군가 .NET Core로 전환한 후에는 ImageSharp와 같은 더 나은 솔루션으로 마이그레이션하는 방법을 살펴봐야 합니다.

@stefanolson
.NET Core에서 WPF 응용 프로그램을 만들 수 있지만 Windows에서만 실행되는 Windows 전용 WPF 팩을 만들 수도 있습니다.

이 GitHub 문제는 독일 IT 뉴스 사이트에서 언급되었습니다.
https://www.golem.de/news/asp-net-core-2-0-microsoft-veraergert-net-entwickler-mit-support-entscheidung-1705-127712.html

@danielcrabtree 에게 감사합니다. 호환성 팩에 대해 처음 들은 것입니다.

@MJomaa 링크 번역: https://translate.google.com/translate?u=https%3A%2F%2Fwww.golem.de%2Fnews%2Fasp-net-core-2-0-microsoft-veraergert- net-entwickler-mit-support-entscheidung-1705-127712.htm

System.Xaml이 이식되기를 기다리고 있습니다.

@alexwiese 숨 참지 마세요.

System.Xaml이 이식되기를 기다리고 있습니다.

계속해; 내가 물거야. 웹사이트에서 Xaml을 어떻게 사용하고 있습니까?

계속해; 내가 물거야. 웹사이트에서 Xmal을 어떻게 사용하고 있습니까?

비즈니스 규칙 엔진에도 사용되는 플랫폼 간 UI("그린 스크린" 콘솔 애플리케이션, Xamarin 앱 및 Angular SPA 간에 공유되는 화면 템플릿)입니다.

와우, 좋습니다. 어떤 식으로든 XAML의 XML을 HTML 및 Javascript로 변환하고 있습니까? 충분히 공평하다 😄

당신이 단지 트롤링하는 것인지 확신할 수 없었습니다.

저도 똑같이 하고 있지만 실제로는 XAML을 포팅하는 것을 볼 수 없습니다. 이 시점에서 실행되지 않고는 구문 분석할 수 없다는 점을 고려할 때입니다.

와우, 좋습니다. 어떤 식으로든 XAML의 XML을 HTML 및 Javascript로 변환하고 있습니까? 충분히 공평하다 😄

당연히 아니지; 먼저 JSON으로 변환 중입니다 😉

우리 중 많은 사람들이 인용하고 있는 이 주제에 대한 또 다른 뉴스 기사: https://www.infoq.com/news/2017/05/ASPNET-Core-2

@cwe1ss 작성자는 @Grauenwolf입니다.

@alexwiese @yaakov-h 이에 대한 블로그 게시물을 읽고 싶습니다. 꽤 흥미롭게 들리고 내가 익숙한 것과는 다른 일련의 도전 과제가 있어야 합니다.

이것은 정말 나쁘다. ASP.NET Core는 필요할 때 레거시 라이브러리를 활용할 수 있을 때 합리적인 판매였습니다. 새 항목으로 수행할 수 있는 경우 몇 가지를 조정하고 .NET Core를 대상으로 합니다. 그렇지 않으면 전체 프레임워크를 대상으로 합니다.

이 변경으로 모든 것이 아니면 전혀 점프가 되지 않습니다. 그리고 항상 모든 종속성을 미리 이해하지 못한다는 점을 감안할 때 위험이 커집니다.

나는 빠르게 움직이고 어떻게 해서든 가야 할 방향으로 진화하려는 욕구를 이해하지만 사용자를 뒤에 남겨 둘 것입니다. 사람들은 점프가 아니라 이동하는 경향이 있습니다. 많은 수는 현재를 벗어나지 않을 것입니다. 그리고 나서 완전히 다른 플랫폼으로 이동할 수도 있습니다. 진지하게, 당신은 그 위험을 과소 평가하고 있습니다.

이것은 결국 이루어져야 하는 움직임이지만 빠르면 2019년 말이나 2020년에 더 가깝습니다. 그럼에도 불구하고, 당신은 여전히 ​​혼합을 선택한 사람들을 지원하기 위한 장기적인 모델을 원합니다.

그리고 아니오, ASP.NET Core 1.x는 거기에 대한 답이 아닙니다. 미성숙한 상태는 앞으로의 마이그레이션 경로가 용이한 과도기 단계로 괜찮지만 장기적으로 살기에는 적합하지 않습니다. 이런 플랫폼을 개발하는 사람과 사용하는 사람의 마음가짐에는 큰 차이가 있습니다. 이 방향을 재고해 주십시오.

@davidfowl netcore용 edge.js와 같은 것은 어떻습니까? API 소비자가 플랫폼 검사를 담당하게 하고 netfx와 netcore 간의 강력한 형식의 인터페이스는 대부분의 시나리오에 충분합니다.

그러면 이 템플릿이 제거됩니까?

현재 VS2017에 구워졌습니다.

완전히 용납할 수 없는 헛소리, 이것은 다시 이것이 전성기와 널리 채택될 준비가 되지 않은 장난감 기술임을 증명합니다.

멋진 라이드와 코딩 경험을 갖고 계신 여러분께 진심으로 감사드립니다. 블로그 항목과 트위터에서 빛날 수 있고(만세!), 링크드인 프로필과 이력서를 개선할 수 있고(만세^2), 여러분 앞에 있는 모든 릴리스 파티, 소녀, 음료 및 물건은 유망해 보이지만 .. 누가 그것을 사용할 것입니까? 기업을 대상으로 하고 대규모 채택과 견고한 사용자 기반을 원하십니까? 또는 일부 스타트업 히피들만?!?

"full Span"에 대한 의견은 잠재적으로 .NET Framework에 포함되지 않을 수 있다는 점에 대해 심각하게 우려하고 있습니다. 전체 Span이 .NET Framework에 없는 경우 이를 사용하는 API는 이를 미래의 넷표준으로 만들 수 없다고 가정합니다. 따라서 고성능 구문 분석을 사용하거나 노출하는 플랫폼 간 라이브러리를 작성할 수 없습니까? 이는 우리가 안전하지 않은 사용자 정의 구현을 영구적으로 효과적으로 고수하고 있음을 의미합니다...

크로스 플랫폼이 되는 라이브러리를 원하면 netstandard를 대상으로 해야 하지만 널리 사용되는 라이브러리가 아닌 경우 ASP.NET Core는 무엇이라고 언급합니까? 다른 라이브러리가 netstandard에 대한 지원을 중단하고 .NET Core로 전환하도록 권장하시겠습니까? 다음 주요 버전의 JSON.NET 또는 무엇이든 netstandard를 삭제해야 합니까? 그것은 확실히 빠른 구문 분석과 함께 할 수 있습니다!

참고 Java는 Netty(https://netty.io/)와 역호환되는 방식으로 복사 없이 빠른 IO를 추가할 수 있었습니다.

마지막으로 이 질문에 기꺼이 응답해 주신 분들께 감사하다는 말을 전하고 싶습니다. 답변에 감사드립니다...

@shanselman 빠른 이동은 특히 ASP.Net 팀과 같이 호환성에 많은 노력을 기울이고 호환되는 방식으로 사물을 디자인하는 팀의 경우 고귀한 목표입니다. 나는 그들이 문제 영역을 얼마나 단순화하기를 원하는지 알고 있으며 그것을 지원하지만 ...

빠르게 이동하는 동시에 고객과 "떨어지는 것"도 좋지 않습니다. 당신의 고객(저 포함)은 기존 앱과 라이브러리에 상당한 레거시 소프트웨어와 시간 투자를 하고 있습니다. 당신은 우리를 그냥 놔두고 우리가 따르지 않거나 따라갈 수 없는 곳으로 갈 수 없습니다.

.Net core로 이동할 수 없고 지금부터 적어도 일정 기간 동안 Full Framework를 사용해야 하는 고객을 고려해야 합니다. Full Framework에서 벗어나면 많은 사람들이 이전 버전에 좌초되고 .Net 세계에서 큰 분열을 일으키게 됩니다.

@JimBobSquarePants System.Drawing 부분에서 두 번째입니다. System.Drawing 를 다시 가져오는 것에 대해 다른 리포지토리에 몇 가지 논의가 있습니다. 이 스레드의 일부 의견을 기반으로 Windows에 먼저 "호환 팩"이 있고 그 다음 System.Drawing 에 대한 모든 OS-es가 있다는 것을 이해합니다.

그것이 어떻게 생겼는지, Mono의 libgdiplus를 기반으로 하는지 여부가 궁금합니다.

제가 보기에는 몇 가지 문제가 있습니다.

1. 이것은 오히려 제대로 전달되지 않았습니다.
2. 사람들은 결정에 관여하지 않았습니다. Microsoft는 물론 원하는 방향을 자유롭게 선택할 수 있지만 커뮤니티와 이러한 유형의 큰 변화에 대해 논의하지 않는 것은 오픈 소스 개발 정신이 아닙니다.
3. 커뮤니티에서 이러한 유형의 결정을 검토하는 데 사용할 수 있는 "거대한 계획"은 없습니다. 처음에 .NET Core는 전체 프레임워크의 일부 플랫폼 간 버전이었습니다. 그런 다음 .NET Standard 2.0을 사용하면 .NET Core 2가 물론 합리적인 제한(UWP, WinForms 등 없음) 내에서 전체 프레임워크의 드롭인 교체와 같은 것으로 나타났습니다.
4. .NET Core 2는 System.DirectoryServices와 같은 전체 프레임워크에 있는 몇 가지 중요한 기능을 놓치게 됩니다. 내가 말할 수 있는 한, 이것은 인정되었지만 .NET Core에 이러한 기능을 추가하는 방법은 더 명확해질 수 있습니다.
5. ASP.NET Core 2는 전체 프레임워크에 최신 기능이 없기 때문에 전체 프레임워크에서 실행되지 않습니다. 나는 사실 이것에 대해 완전히 괜찮습니다. 누락된 기능을 전체 프레임워크에 추가하는 것이 지나치게 어렵다면 그렇게 하지 마십시오. ASP.NET Core 2가 .NET Core 2에서만 실행되도록 하는 것은 실제로 꽤 의미가 있습니다. 하지만 그것들을 하나의 제품으로 언급하는 것이 이들의 관계를 설명하는 가장 좋은 방법은 아닐 수도 있습니다.

사람들이 정말로 보고 싶어하는 것은 .NET 플랫폼의 비전 에 대한 설명입니다. 어떤 방향으로 일이 진행될까요? 전체 프레임워크가 버그 수정 등만 수신하지만 새로운 기능은 수신하지 않습니까? .NET Core에 누락된 기능을 추가하기 위해 어떤 작업이 수행되고 있으며 언제 예상할 수 있습니까? 이것을 설명하면 사람들이 지금 느끼고 있는 불안을 완화하는 데 큰 도움이 될 것입니다.

@davidfowl HTTP 2.0에 관한 것만은 아닌 것 같습니다. 정말 HTTP 2.0에 관한 것이라면 HTTP 2.0 지원을 제외하고 ASP.NET Core 2.0 대상 NetFX를 가질 수 없습니까? 커뮤니티가 정말로 원할 경우 NetFX에서 HTTP 2.0을 수행할 수 있도록 플러그형 모델을 사용할 수도 있습니까?

@cokkiy @popcatalin81 @xprzemekw 건설적인 말이 아니라면 댓글을 삼가해 주세요. 이런 댓글은 누구에게도 도움이 되지 않습니다.

@davidfowl https://github.com/aspnet/Home/issues/2022#issuecomment -300141134에서 설명한 대로 이동해야 하는 정당한 이유가 있습니다.

연기하는 이유는 다음과 같습니다(예: asp.net core 3.0).

• EF Core는 많은 기능이 없기 때문에 아직 EF 6.0을 대체할 준비가 되지 않았습니다.
• 생산 준비 없음 System.Drawing 교체
• 아니요 System.DirectoryServices
• office xml sdk 에 대한 언급이 있었지만 2017-05-01 https://www.nuget.org/packages/DocumentFormat.OpenXml/ 현재 netstandard에서 이미 사용 가능한 것으로 보입니다.
• .net 코어에서 사용할 수 없는 MS 범위 밖의 다른 패키지(nhibernate, 다양한 db 제공자, ikvm)

하지 않는 이유는 다음과 같습니다.

• 사람들은 .net 코어로 이동할 의도 없이 레거시 종속성이 있는 asp.net 코어로 앱을 이식했습니다.
• netstandard를 뒤로하고 그것에 대해 별로 신경 쓰지 않는 것에 대해 걱정하십시오.
• 일부 타사 패키지는 .net 코어로 이식될 가능성이 낮습니다(이로 인해 사용되지 않을 수 있지만 내 의견일 수 있음)

건설적인 의견의 예는 이 세 가지 시나리오 중 하나를 보고 싶은 이유를 추가하거나 대안 솔루션을 제안하는 것입니다. 동의/비동의를 표현하고 싶다면 "반응" 버튼을 사용하세요.

@쿠키몬스타

사람들은 .net 코어로 이동할 의도 없이 레거시 종속성이 있는 asp.net 코어로 앱을 이식했습니다.

완전히 동의합니다. Microsoft가 ASP.NET Core가 .net Core와 .net 프레임워크 모두에서 작동할 것이라고 발표했기 때문입니다. 이제 AspNet Core 1.x에 그대로 두는 것은 공정하지 않습니다.

마지막 요약은 꽤 좋습니다. 한두 가지를 추가하고 싶습니다.

1.) .NET Core로 Windows 서비스를 작성할 수 있어야 합니다(*NIX 플랫폼의 데몬은 다르게 작동한다는 것을 알고 있습니다). 따라서 ServiceBase는 여전히 필요하며 이는 EF와 함께 높은 우선 순위입니다.

2.) .NET Core를 사용하여 독립 실행형 서비스를 작성 하고 기존의 전체 프레임워크 기반 .NET 응용 프로그램(즉, Windows Forms/WPF 앱의 무료 서비스) 내에서 추가 로 호스팅하여 확장할 수 있어야 합니다.

후자는 하드 컷을 만들고 신규 개발을 시작할 수 없는 느린 마이그레이션 시나리오에 실제로 필요합니다.

완전히 동의합니다. Microsoft가 ASP.NET Core가 .net Core와 .net 프레임워크 모두에서 작동할 것이라고 발표했기 때문입니다. 이제 AspNet Core 1.x에 그대로 두는 것은 공정하지 않습니다.

또한 기존(전체 프레임워크) .NET 프로젝트에서 (ASP) .NET Core 프로젝트를 참조할 수 없다는 사실로 인해 .csproj 및 msbuild로의 대규모 변경이 주로 변명되었음을 다시 한 번 강조하고 싶습니다.

이 변경으로 인해 후자는 불가능합니다(적어도 가장 큰 ASP.NET 부분의 경우). 그렇다면 당시에는 호환성이 가장 중요했지만(많은 고통을 일으켰지만) 지금은 그렇지 않은 이유(그리고 다시 많은 고통을 야기함)는 무엇입니까?

미안 나도 스트레스 받아야해. 그러나 거의 500개의 댓글이 있습니다. 이 문제에 대해 Microsoft 직원으로 참여하면 두 가지 옵션이 있습니다.
1: 문제 음소거
2: 내 결정에 대해 다시 생각해보기

@gingters xamarin, asp.net, uwp 및 기타 모든 것이 코드를 공유하고 네이티브 코드와 같은 다른 프로젝트 유형도 참조할 수 있도록 csproj 변경은 주로 _.net_ 코어용이었습니다.

또한 asp.net core 2 프로젝트가 다시 compat shim을 통해 전체 프레임워크 프로젝트를 참조할 수 있도록 합니다.

@qmfrederik

커뮤니티가 정말로 원할 경우 NetFX에서 HTTP 2.0을 수행할 수 있도록 플러그형 모델을 사용할 수도 있습니까?

그들은 기술적으로 가능했습니다. 하지만 그들은 원하지 않는 것 같습니다. 제 생각에는 그들이 기업/대기업의 실제 요구 사항이나 이전 버전과의 호환성 또는 미개발 분야 이외의 다른 문제에 대처해야 할 필요성에 대해 생각하고 싶지 않다고 생각합니다.

솔직히 말해서 과거의 기대 관리는 플랫폼 간 콘텐츠를 천천히 확장/마이그레이션하는 동시에 기존 앱을 천천히 확장/마이그레이션하려는 비즈니스를 완전히 대상으로 했습니다. 따라서 이 움직임은 이전의 기대 관리와 완전히 일치하지 않습니다.

@aL3891

xamarin, asp.net, uwp 및 기타 모든 코드를 공유하려면

네. 정확히. 그리고 여기에는 .NET Core 라이브러리를 사용하는 WPF/Windows Forms 앱도 포함됩니다. 이제 .NET Core 2로 이동하려는 경우에는 불가능합니다.

이 라이브러리가 netstandard2.0 를 대상으로 할 수 없는 이유를 정확히 설명할 수 있습니까?