Aspnetcore: 토론 : ASP.NET Core 3.0은 .NET Core에서만 실행됩니다.

지금 전체적인 그림에서 이것이 의미가 있다고 생각합니다. .NET Core와 ASP.NET Core는 모두 사람들이 이미 큰 문제를 일으키지 않고 이미 전환 할 수있는 기회를 가졌거나 여전히 가지고있을 정도로 충분히 오랫동안 사용되어 왔습니다 (과거 2.0에서 지원이 처음 중단되었을 때와 비교). .

그러나 현재 별도의 종속성으로 존재할 수있는 ASP.NET Core의 특정 구성 요소에 대한 영향에 대해 슬프다. 이는 개별 구성 요소가 netstandard 지원을 중단하고 대신 netcoreapp3.0이 필요함을 의미하기 때문입니다. 특히 # 3756을 사용하면 이러한 구성 요소는 ASP.NET Core 컨텍스트 외부에서 사용할 수 없습니다.

예를 들어 RazorLight 와 같은 프로젝트는 .NET Framework와 더 중요한 것은 일반적으로 .NET Standard 지원을 효과적으로 중단해야합니다.

이로 인해 판매 한 많은 사람들이 조직의 새로운 ASP.NET Core 프로그래밍 모델로 이동하여 지원되지 않는 플랫폼에서 지원되고 적극적으로 개발 된 플랫폼을 3 년 이내에 (. NET Core 2.1 LTS).

이 움직임을 정당화하기 위해 어떤 분석을 사용했는지 잘 모르겠지만 .NET Framework에서 ServiceStack ASP.NET Core 앱 을 실행하는 경우 ASP.NET Core 프로젝트를 실행하는 데 가장 많이 사용되는 web-corefx 템플릿이 .NET Framework는 1/3 (33.8 %) 공유를 넘어 .NET Core에서 실행하기위한 가장 인기있는 프로젝트 템플릿 인 동일한 빈 웹 템플릿입니다.

IMO 3 년은 새로운 ASP.NET 프로그래밍 모델 (정체 된 ASP.NET Framework 플랫폼에서 벗어나기 위해)을 시작했거나 이전 한 고객을 버리기에 충분한 시간이 아닙니다. 이동하려는 조직이 버려졌습니다.

어떤 이유로 든 .NET Framework 전용 종속성에 의존하기 때문에 .NET Core로 이동할 수없는 고객이 있습니다. MS가 향후 IMO에서 ASP.NET Core 3.0에서 .NET Framework에 대한 지원을 유지하지 않으려면 지원을 확장해야합니다. .NET Framework의 ASP.NET Core 2.1에 대해 7 년과 같은 연장 된 기간으로. 기존 프로덕션 시스템의 마이그레이션에는 몇 년이 걸릴 수 있습니다. .NET Core를 시작하면 ASP.NET Framework가 ASP.NET Core가 .NET의 미래 프로그래밍 모델이라는 공식 입장으로 정체 된 것이 분명합니다. 이제 동일한 고객이 곧 그들이 이동 / 이동 한 새로운 프로그래밍 모델이 몇 년 안에 지원되지 않을 것이라는 사실을 알아 내기 시작합니다. 이러한 기존 .NET 고객을 수용하는 가장 좋은 방법은 보안 패치에 대해 추가 LTS 기간 동안 .NET 2.1을 지원하는 것입니다 (이상적으로는 버그 해결에도 적합).

"killing .NET Framework", 에피소드 2 : 같은 이야기, 같은 캐릭터 : rofl :

안타깝게도 이것은 한 가지를 강조합니다. .NET Standard를 .NET 에코 시스템의 앞차로 만드는 데 완전히 실패했습니다 . 모든 플랫폼이 새로운 API를 포함하거나 포함하려고하는 마지막 순간에 항상 업데이트되는 가장 낮은 공통 분모 일뿐입니다.

아마도 그것은 나일 수도 있지만, netcoreapp 만큼 빠르게 움직이지 않는 이유를 이해하지 못했습니다 (정의에 따라 새 API를 가장 먼저 얻음).

NuGet 패키지 작성자이며 최신 항목을 사용하기를 원하십니까? 가장 최근의 netstandard 버전을 대상으로합니다. 처음에는 netcoreapp 기반 응용 프로그램 만 사용할 수 있지만 결국에는 Xamarin, Mono 또는 .NET Framework와 같은 다른 플랫폼이 따라 잡을 것입니다. 그리고 사람들은 아무것도 변경하지 않고도 패키지를 사용할 수 있습니다. 그것이 일이 작동하는 방식입니다.

물론 .NET Framework와 같은 비 .NET Core 플랫폼이 릴리스가 드물고 안정성 막대가 훨씬 더 높기 때문에 따라 잡는 데 시간이 걸릴 수 있지만 6 개월, 12 개월 또는 18 개월이 걸린다고해도 저는 그렇지 않습니다. .NET Framework를 사용할 때 사람들이 원하는 것이기 때문입니다. 빠르게 움직이는 대상이 아니라 안정적인 프레임 워크입니다.

IMHO, ASP.NET Core 3.0이 필요한 모든 .NET Core API를 노출하는 새로운 netstandard TFM을 대상으로하는 것이 훨씬 더 나은 접근 방식입니다. 새 API가 충분히 안정적이라고 확신하면 최신 표준과 호환되도록 .NET Framework로 백 포트합니다.

나는 사람들이 .NET Framework 앱을 최신 ASP.NET Core 버전으로 옮길 수 있기 전에 매우 짧은 3 년 지원으로 이전 버전에서 영원히 차단되는 것보다 몇 달을 기다려야 할 것이라고 확신합니다.

약속 한대로 수행 : .NET Framework를 ASP.NET Core로 마이그레이션 할 때 사용자를 신뢰하는 사람들을 위해 막 다른 골목 대신 느리게 발전하는 안정적인 프레임 워크로 만듭니다.

나는 이것을 좋아하지 않는다. .net core의 시작 부분에서 Microsoft는 크로스 플랫폼으로 mono 또는 .net framework 를 선택하지 않았으며 여기에 여러 .net 런타임이 있으므로 .netstandard 설계했습니다 .net standard 는 이름으로 만 존재합니다 (적어도 asp.net 코어의 경우 사람들은 netcoreapp 패키지 만 빌드하기 시작합니다).
언젠가는 .net 코어가 창에서 .net 프레임 워크를 대체 할 수 있지만 mono 및 다른 플랫폼은 mono (xamarin, unity3d)에 의존합니다.
.net 프레임 워크를 선호하는 또 다른 이유는 .net 코어 공유 프레임 워크가 정말 크다는 것입니다. .net 코어 2.0에서 최신 .net 코어 2.1로 앱을 업그레이드하면 C:/program file/dotnet 폴더가 얼마나 큽니까? 내 폴더에 GBs 파일이 있으며 .net 코어 런타임을 업데이트하면 커집니다. 그러나 .net 프레임 워크는 이전 버전을 대체합니다.

약속 한대로 수행 : .NET Framework를 ASP.NET Core로 마이그레이션 할 때 사용자를 신뢰하는 사람들을 위해 막 다른 골목 대신 느리게 발전하는 안정적인 프레임 워크로 만듭니다.

FWIW 이것이 최적의 전략이 될 것입니다. LTS 확장에 대한 저의 제안은 ASP.NET Core로 마이그레이션하도록 적극적으로 마케팅 한 기존 고객에게 더 많은 시간을 제공하기위한 최소 기준입니다. 발표.

그래서 .net 표준은 농담입니까? 희망 모노 팀은 aspnetcore repos를 포크하고 aspnetmono로 이름을 바꾸고, 그렇지 않으면 .net 스택을 떠날 수 있습니다 .😔

이것은 내 작업에서 ASP.NET Core를 사용하지 않을 것임을 의미합니다. 이제 더 많은 변경 사항이 포함되므로 앱을 Core로 포팅하는 것을 염두에 두지 않고 ASP.NET에 머물 것입니다.

물론, 목표가 변화가없는 것이라면 똑같은 일을 영원히 계속할 수 있습니다. 제가 일하는 곳에서는 몇 년 전에 ASP.NET Core를 사용하기 시작했으며 처음에는 .NET Framework에서 실행되었습니다. 시간이 지남에 따라 .NET Core 플랫폼이 성숙 해지고 기능이 확보되면서 프로젝트를 netcoreapp으로 전환했습니다. 하나 또는 두 개의 이전 프로젝트가 여전히 ASP.NET을 사용하고 있으며이를 다시 작성할 계획이 없습니다. 작동 코드입니다. 그러나 새로운 기능에 대해서는 Span과 같은 기능을 기대하고 있습니다.

변화는 미룰 수 있지만 영원히 피할 수 있거나 피해야하는 것은 아닙니다. 기술은 변화이며 개발자의 직업은 항상 새로운 것을 배워야합니다. 현재 .NET Framework에서 ASP.NET Core를 사용하는 경우 .NET Core로 이동하는 데 3 년이 걸리지 않을 것입니다.

.NET Core로 오세요. 물이 따뜻합니다 ...

어떤 이유로 든 .NET Framework에만 의존하여 .NET Core로 이동할 수없는 고객이 있습니다.

더 심각하게는 .NET Standard 2.0 이후 .NET Core 2.0에서 .NET 4.x 라이브러리를 사용할 수 있습니다 . .NET Core에없는 일부 기능을 사용할 가능성이 있습니다. 이러한 많은 구멍을 막는 .NET Core 용 Windows 호환성 팩 이 있지만 COM interop 및 WinForms 및 WPF 등과 같은 기타 앱 모델을 포함하여 .NET Core 3.0에서 더 많은 기능이 지원되고 있습니다.

ASP.NET Core 애플리케이션 이 .NET Framework에서 .NET Core로 이동하는 것을 방해하는 모든 차단기는 dotnet / corefx 에서 발생해야합니다.

Xamarin의 경우; 내가 틀렸을 수도 있지만 iOS 또는 Android에서 웹 서버를 실행하는 데 사용하지 않을 것 같습니다.

Mono 클라이언트 앱의 경우 UI가 Mono에서 실행되는 동안 웹 서버가 프로세스 부족 및 .NET Core에서 실행될 수 있습니다. Kestrel은 BSD 버전이 현재 .NET Core 격차이지만 Mono의 다른 플랫폼 중 일부를 제거 하는 Big Endian 플랫폼에서 실행할 수 없었습니다 .

Unity의 경우 게임은 모든 종류의 이상한 일을합니다. 그래서 아마도 그것은 다루지 않은 시나리오 일 것입니다. 게임이 클라이언트에서 웹 서버를 사용하고 있었다면; 서버 나 proc 외부가 아니라; .NET Core가 해당 부분을 실행할 수있을 때.

ASP.NET Core 앱 모델 외부 예를 들어 라이브러리의 경우 .NET Standard는 ASP.NET Core에 모든 종류의 유용한 기능이 있으므로 Razor가 특정 예이므로 더 중요합니다.

모든 라이브러리가 .NET Core로만 이동하는 것은 아니며 (예 : Microsoft.Extensions.* 이 .NET Standard로 유지됨) @daveaglick 이 https : //에서 수행 한 것처럼 영향을받는 특정 시나리오 를 제공하는 것이 도움이 될 수 있습니다. 고려할 수 있도록 github.com/aspnet/AspNetCore/issues/3757#issuecomment-434140416 모호한 "모든 것"이 아닌 .NET Standard에서 사용할 수있는 특정 라이브러리 및 / 또는 기능에 대해 설명합니다.

ASP.NET Core는 .NET Core에서 많은 변경 사항과 새로운 API를 주도하고 있으며 이러한 기능을 사용하려는 욕구를 이해할 수 있습니다 (사용 사례 중 하나이기 때문에). 그렇지 않으면 약간의 자기 패배입니다.

반면에 .NET Standard 버전에 있으면 다른 런타임이 ASP.NET Core 3.0을 구현할 때 지원할 수 있다면 좋을 것입니다. 현실적으로 그것은 곧되지 않을 것입니다 (.NET Standard 2.1은 아직 완성되지 않았고 그 이상의 버전이 필요하기 때문입니다).

아마도 ASP.NET Core 앱 모델이 나중에 상황이 잡히면 .NET Standard로 돌아 갈까요? 현재 작동하는 것처럼 .NET Standard 프로세스에서는 항상 너무 빠르게 이동하고있을 수 있지만?

@gulbanana com을 사용하는 .net 프레임 워크의 asp.net 코어는 어떻습니까? 또는 .net 프레임 워크 만 지원하는 너겟 패키지가 있습니까?

이사를해야하는지 말아야하는지에 대한 질문이 아니라 언제 야하는지에 대한 질문이 아니라고 생각합니다.
지난번에 이로 인해 ~ 토론 ~ 대 폭풍이 발생했을 때 생태계는 기존 앱을 이식 할 준비가되지 않았습니다.
이제 Windows 호환성 패키지가 있으며 WinForms 및 WPF가 .NET Core에 제공됩니다.

.NET Framework 용 2.1 패키지가 좋은 마이그레이션 경로를 제공한다고 생각합니다. netfx에서 2.1로 마이그레이션 한 다음 .NET Core로 마이그레이션합니다.

이것은 AngularJS 대 Angular와 유사합니다. 기존 코드를 최신 1. *의 구성 요소 (하드)로 마이그레이션 한 다음 최신 Angular 버전으로 이동합니다. 매우 어렵지만 실행 가능합니다.

CoreCLR 및 모노 모두에 흥미로운 새 기능이 추가됨 (예 : 기본 인터페이스 방법 또는 빠른 Spans) .NET Framework에 도달하지 못할 경우, 어느 시점에서 .NET Framework를 남겨 두는 것이 합리적입니다.
이는 반드시 .NET Framework를 "지원하지 않음"을 의미하는 것이 아니라 그대로 두는 것입니다.

여전히 고전적인 ASP (ASP.NET이 아니라 정말 오래된 것)를 사용하는 사이트가 있습니다. 여전히 작동하고 Windows에서 제공되며 새로운 앱을 만들지 않을 것입니다.
나는 <10 년 안에 .NET Framework의 상황이 될 것이라고 믿습니다.

2.1에 대해 요청 된 확장 지원에 동의하지만 팀이 2.1 패키지 다운로드를 모니터링하여 2 ~ 3 년 내에 결정을 내릴 수 있기를 바랍니다 (= 중요한 보안 문제 수정). 조금 더.

@ John0King COM은 .NET Core 3.0에서 지원됩니다.

또한 : .NET Remoting과 같은 것을 사용하는 레거시 애플리케이션이 있습니다.
그러나 그것들은 이미 유산입니다.

세상은 기본적으로 레거시 코드로 실행되며 계속해서 그렇게 될 것입니다. 무언가를 "지원"또는 "새로운"것으로 이식할지 여부에 대한 비즈니스 결정이지만 그때까지는 @dylanbeattie 가 말했듯이 :

예, 어떤 것이 "지원"되는지 여부가 그다지 관련성이없는 것은 아니라는 점을 언급 할 가치가 있습니다. 기존 앱은 실제로 사용할 수 있다고해서 새로운 프레임 워크로 이식 할 필요가 없습니다. 웹 서버는 보안 위협으로 인해 약간의 특별한 경우입니다. LTS에 대한 장기간의 보안 패치 지원은 사람들을 도울 것입니다.

@gulbanana 웹 프레임 워크, 기본 애플리케이션 프레임 워크를 변경 한 다음 호환되지 않는 종속성을 업그레이드하거나 교체해야하기 때문에 System.Web에서 ASP.NET Core로 애플리케이션을 포팅하는 데 더 높은 기준을 추가 할뿐입니다 (새로 구매해야 할 수 있음). 라이센스).

비용 / 편익 분석을 수행한다면 ASP.NET Core의 이점에 있을지 확신 할 수 없습니다.

이것은 특히 프로젝트 기반으로 소프트웨어를 개발할 때 적용 할 수 있으며, 물론 각 프로젝트는 예산이 충분히 부족하므로 정기적 인 유지 관리가 가능하지만 명백한 실질적인 이점없이 전체 프레임 워크를 교체하는 것을 정당화하기는 어렵습니다. .

비용 / 편익 분석을 수행한다면 ASP.NET Core의 이점에 있을지 확신 할 수 없습니다.

그래서 .. 음 .. 놔둬? ASP.NET Core로 마이그레이션 할 필요 가 없으면 수행하지 마십시오.
냉소적으로 들리려고하지 않지만 "최신 항목"에 응용 프로그램을 유지해야하는 업무가 없다면 이식하지 마십시오. 장점은 .NET Framework / ASP.NET 클래식이 계속 지원되고 응용 프로그램이 그대로 실행된다는 것입니다.

이식은 자주 필요하지 않습니다. 동의합니다. ASP.NET에서 ASP.NET Core 로의 전환은 큰 변화이며, 그 중 일부는 Core가 더 빠르게 이동한다는 것입니다 (2.0에서와 마찬가지로 3.0에도 API 변경 사항이 있음). 이 토론 문제는 netfx에서 corefx 로의 변경에 관한 것이며 더 이상 큰 변경이 아닌 대부분의 ASP.NET Core 앱의 경우

이것은 마이그레이션을 훨씬 더 점진적이고 쉽게 만들 수있는 ".NET Framework의 ASP.NET Core"중간 지점을 제거하는 것 같습니다. 그런 다음 ASP.NET MVC / WebAPI 등을 마이그레이션합니다. ASP.NET Core에 대한 응용 프로그램은 웹 프레임 워크와 기본 런타임을 한 번에 모두 변경하는 매우 큰 변화가 될 것입니다.

대기업 앱의 경우 이것이 상당히 고통 스러울 것으로 예상합니다. 저희 팀은 1 ~ 2 년 동안이를 면밀히 주시하고 있지만 :

• EntityFrameworkCore는 우리가 필요로하는 모든 작업을 수행하지 않으며 .NET Core 3.0에서는 EntityFramework 자체가 .NET Core에 제공됩니다. 그 중 어느 정도와 어떤 플랫폼에서 실행 될지 명확하게 전달되지 않았다고 생각하며 실제로 미리보기 빌드를 테스트해야 할 것입니다.

• OData 이야기는 대규모 애플리케이션 측면에서 여전히 공중에 떠있는 것 같습니다. OData 3 / System.Data.Services에서 OData 4 / WebAPI 및 그 이상으로 이동하려면 _ 실질적인 _ (재) 작업이 필요합니다. 이것은 현재 몇 년 동안 해결되지 않은 문제이며 솔직히 그럴 것이라고 확신하지 않습니다.

또한 이제는 지원되지 않는 다른 모든 기술 (AppDomains, Remoting 등) _first_를 병렬로 또는 이후 단계에서 수행 할 수있는 대신 제거해야합니다.

또한 이제는 지원되지 않는 다른 모든 기술 (AppDomains, Remoting 등)을 먼저 제거해야합니다. 그 작업을 병렬로 수행하거나 이후 단계에서 수행 할 수있는 것이 아닙니다.

2.1로 먼저 마이그레이션 할 수없는 이유는 무엇입니까?

@davidfowl 3.0 / 3.1 / etc에서 새로운 기능을 발견하지 않는 한 중개자로 사용할 수 있습니다. 마이그레이션하는 데 필요합니다. 아직 전체 분석을 수행하지 않았으며 지금까지 대부분 EF 및 OData에서 차단되었습니다.

마이그레이션하는 데 필요한 ASP.NET Core 2.1의 새로운 기능? .NET Framework의 ASP.NET Core 2.1을 의미했습니다.

몇 년 전이 문제가 발생했을 때 모든 것을 포팅하기가 너무 어려웠다 고 불평했던 기억이납니다. 다음은 내가 그때 작성한 오래된 github 주석의 인용문입니다.

Active Directory 또는 Office COM 자동화를 사용하거나 일부 System.Drawing 기반 라이브러리를 사용하여 축소판 그림을 작성하거나 WPF 앱과 코드를 공유하는 웹앱을 상상해보십시오.

멋진 점은 .NET Core 3.0부터 이러한 모든 시나리오가 지원된다는 것입니다. 더 쉽게 만들기 위해 엄청난 양의 작업이 수행되었습니다.

@davidfowl 나도 그렇게 했어.

가설 적으로 우리가 ASP.NET/MVC/WebAPI에서 사용하고있는 기능 중 2.1에서는 구현되지 않았지만 이후 버전으로 제공되는 기능이있을 수 있습니다. 이 경우 2.1은 실행 가능한 디딤돌이 아닙니다.

2.1에없는 중요한 것이 실제로 필요한지 확인하려면 더 철저한 분석을해야합니다.

안녕하세요.

안타깝게도 이것은 한 가지를 강조합니다. .NET Standard를 .NET 에코 시스템의 앞차로 만드는 데 완전히 실패했습니다 . 모든 플랫폼이 새로운 API를 포함하거나 포함하려고하는 마지막 순간에 항상 업데이트되는 가장 낮은 공통 분모 일뿐입니다.

당신은 틀린 것은 아니지만 .NET Standard의 목표에 대해 다소 무지합니다. 표준의 목표는 혁신을 주도하는 것이 아니라 융합을 주도하는 것입니다. 그런 각도에서 접근한다면 어떤 개념이 보편적이거나 보편적이어야하는지 생각해야하므로 설계 상 뒤쳐 져야합니다. 이것이 어떤 모습인지 궁금하다면 모든 .NET 구현 소유자가 검토 한 후 지난 3 주 동안 병합 한 35 개 이상의 PR을 살펴 보도록 권합니다.

.NET Core는 혁신이 일어나는 최첨단 플랫폼으로 간주됩니다. 우리는 .NET Framework가 가지고있는 것보다 훨씬 더 나은 이탈과 그로 인한 위험을 처리 할 수있는 몇 가지 기능을 구축했습니다. 그러나 .NET 에코 시스템에 중요한 모든 기능이 .NET Core 환경의 일부는 아닙니다. 예를 들어 사전 컴파일은 Xamarin 및 Unity에서 훨씬 더 두드러집니다. 그리고 .NET Core 기능을 표준에 추가 할 때 런타임 환경, 운영 체제 및 하드웨어 제약 조건을 고려해야합니다.

아마도 그것은 나일 수도 있지만, netcoreapp 만큼 빠르게 움직이지 않는 이유를 이해하지 못했습니다 (정의에 따라 새 API를 가장 먼저 얻음).

현실은 "빠르게 움직이고 깨뜨리는 것"이 ​​우리 청중 전체가 높이 평가하는 것이 아니라는 것입니다. .NET Core의 주요 버전에서 API를 제거해야하는 경우에는 충분히 나쁘지만 .NET Standard로는 사실상 불가능합니다. 따라서 우리는 다소 느리게 움직이고 추가 할만큼 충분히 성숙하다고 생각하는 개념 만 포함해야합니다.

약속 한대로 수행 : .NET Framework를 ASP.NET Core로 마이그레이션 할 때 사용자를 신뢰하는 사람들을 위해 막 다른 골목 대신 느리게 발전하는 안정적인 프레임 워크로 만듭니다.

이는 .NET Framework가 결국 .NET Core가 가진 모든 기능을 갖지만 시간이 지연된다는 가정을 계속합니다. 우리는 그것이 단순히 현실적이지 않다는 것을 배웠습니다. .NET Core에서 과감하게 혁신하지 않기로 결정하거나 새로운 기능의 좋은 덩어리가 .NET Framework로 다시 돌아 가지 않는다는 엔지니어링 현실을 받아 들일 수 있습니다. 우리는 고객이 .NET Core에서 새로운 기능을 활용할 수 있도록하면서 .NET Framework의 핵심 가치 제안 (성숙하고 풍부한 개발 플랫폼)을 보존하기 위해 최선을 다하고 있다고 믿습니다. 앞으로는 Span<T> 했던 것처럼 런타임, 라이브러리 및 언어 변경이 필요한 영역에서 더 기꺼이 혁신 할 것으로 기대합니다. 이러한 것들은 비용이 많이 들지만 사람들이 코드를 작성하는 방식을 바꿀 수 있습니다. 이에 대한 좋은 예는 인터페이스의 기본 구현, 산술과 관련된 일반 코드 작성 기능, 하드웨어 내장 함수 등을 사용할 수있는 기능입니다. 이러한 기능은 위험으로 인해 .NET Framework로 백 포트하지 않을 것입니다. .

우리의 웹 스택이 이러한 기능을 활용할 수 있다는 것이 합리적이라고 생각합니다. 이를 수행하는 유일한 방법은 ASP.NET Core가 .NET Framework에서도 실행되는 제한을 제거하는 것입니다. ASP.NET Core를 .NET Framework에서 실행 한 원래 이유는 .NET Core에 API가 충분하지 않았기 때문입니다. .NET Core 3.0 에서는 기존 API 가

@ yaakov-h 그게 사실이라면 나는 놀랄 것입니다. 분석을 할 때 알려주세요.

당신은 틀린 것은 아니지만 .NET Standard의 목표에 대해 다소 무지합니다. 표준의 목표는 혁신을 주도하는 것이 아니라 융합을 주도하는 것입니다.

그리고 정확히 반대 방향으로 가고 있습니다. ASP.NET Core 용 .NET Standard는 충분히 빠르게 이동하지 않기 때문에 포기하고, ASP.NET Core를 대상으로하는 NuGet 패키지도 포기해야합니다. 수렴이라고 생각하지 마십시오. 저는 그렇게 무지하지 않습니다 . : rofl :

그런 각도에서 접근한다면 어떤 개념이 보편적이거나 보편적이어야하는지 생각해야하므로 설계 상 뒤쳐 져야합니다.

이는 기술적 인 문제가 아니라 선택입니다. corefx / coreclr에 포함되는지 검토 할 때 특정 API가 새 버전의 .NET Standard에 포함되어야하는지 여부를 결정하는 데 방해가되는 것은 없습니다.

이것이 어떤 모습인지 궁금하다면 모든 .NET 구현 소유자가 검토 한 후 지난 3 주 동안 병합 한 35 개 이상의 PR을 살펴 보도록 권합니다.

나는 그것이 쉬운 일이라고 말하는 것이 아니라 내 요점을 증명한다. 당신은 새로운 netstandard 버전을 만들기 위해 너무 많은 것을 기다리고 있고 드물게 그렇게하는 경우, 그것은 많은 수의와 함께 제공되기 때문에 고통스러운 과정이다. 동시에 새로운 API.

현실은 "빠르게 움직이고 깨뜨리는 것"이 ​​우리 청중 전체가 높이 평가하는 것이 아니라는 것입니다.

그러나 이것이 모든 ASP.NET Core 반복이 작동하는 방식입니다. 다음 버전과 호환되지 않는 버전 용으로 작성된 패키지를 만드는 (때로는 대규모) 주요 변경 사항이 함께 제공됩니다. 그러나 우리에게 이전 버전과는 아무런 관련이없는 지원 정책을 사용하여 레거시 버전을 영원히 업데이트하거나 유지하는 등 많은 옵션을 제공하지 않습니다 (ASP.NET/.NET뿐만 아니라 Windows의 수명 주기도 많음). 요즘은 짧아집니다).

앞으로는 Span과 마찬가지로 런타임, 라이브러리 및 언어 변경이 필요한 영역에서 더 기꺼이 혁신 할 수있을 것으로 기대합니다.. 이러한 것들은 비용이 많이 들지만 사람들이 코드를 작성하는 방식을 바꿀 수 있습니다. 이에 대한 좋은 예는 인터페이스의 기본 구현, 산술과 관련된 일반 코드 작성 기능, 하드웨어 내장 함수 등을 사용할 수있는 기능입니다. 이러한 기능은 위험으로 인해 .NET Framework로 백 포트하지 않을 것입니다. .

이러한 "위험한"변경 사항이 포함 된 새로운 병렬 .NET Framework 버전 (.NET Framework 5)을 도입하지 못하게하는 이유는 무엇입니까? 다시 말하지만 기술적 인 문제가 아닙니다.

모든 기회는 홍보 Microsoft.AspNetCore.Razor.Language 및 Microsoft.AspNetCore.Razor 외부 aspnet 나에 보관 netstandard 웨이브를? razor는 HTML 전용이지만 메일 템플릿에 사용하는 라이브러리가 여러 개 있으며 그대로 계속 사용할 수 있다면 좋을 것입니다.

이 움직임은 이전에 말한 것과 달리 .NET 로드맵에서 netstandard에 대한 지원이 부족함을 보여줍니다. 새로운 주요 라이브러리 중 하나가 netstandard를 포기하면 채택에 대한 좋은 징조가 아닙니다.

이것은 이제 .NET 개발자가 Microsoft가 공개적으로 개발 한 다른 모든 새로운 라이브러리에 대해 예상해야하는 움직임입니까? 커뮤니티가 netstandard의 미래와 채택에 대한 공식적인 성명을 얻을 수 있습니까?

@terrajobst 모든 플랫폼을 포괄 할 준비가되어 있지 않은 것 같은 API를 .netstandard에 추가하지 않는 것에 대해 당신이

그리고 당신은 정확히 반대 방향으로 가고 있습니다 : ASP.NET Core 용 .NET Standard는 충분히 빠르게 움직이지 않기 때문에 포기하는 것입니다.

ASP.NET Core는 .NET Framework 및 .NET Core에서만 의미가 있지만 .NET Standard는 모든 사람이 구현해야합니다. 예를 들어 Xamarin / Unity가 서버 웹 스택에서 주로 사용하는 API를 제공하도록 만드는 것은 의미가 없습니다.

이는 기술적 인 문제가 아니라 선택입니다. corefx / coreclr에 포함되는지 검토 할 때 특정 API가 새 버전의 .NET Standard에 포함되어야하는지 여부를 결정하는 데 방해가되는 것은 없습니다.

이것이 우리가 .NET Core v1 일에서 한 일입니다. 표준을 .NET Core에서 v2로 분리했습니다. 그렇습니다. 이것은 선택이지만 임의의 것이 아닙니다. 목표는 .NET Core를 사용하여 더 빠르게 이동할 수있는 것입니다. 단일 런타임보다 N 개의 다른 런타임 컨텍스트에서 기능이 작동하는 방식을 고려하는 데 더 많은 시간이 걸립니다.

동시에 수많은 새로운 API가 제공되기 때문에 고통스러운 프로세스입니다.

여러 구현 자와 여러 런타임으로 설계를 검토해야하므로 고통스러운 프로세스입니다. 그러나 사후에 집계 및 번들로 처리하는 것이 우리가 진행하면서 조정하는 것보다 훨씬 저렴합니다. CoreFx 저장소는 대용량 저장소입니다. Xamarin과 Unity가 함께 번들로 제공되는 기능을 검토하는 것이 Firehose에서 술을 마시고 CoreFx에 대한 모든 API 토론을 구독하는 것보다 훨씬 쉽습니다.

그러나 이것이 모든 ASP.NET Core 반복이 작동하는 방식입니다. 다음 버전과 호환되지 않는 버전 용으로 작성된 패키지를 만드는 (때로는 대규모) 주요 변경 사항이 함께 제공됩니다.

그리고 이것을 좋아하지 않기 때문에 .NET Standard를 .NET Core와 일치시켜 모든 사람에게 적용하고 싶습니까? 미안하지만이 주장은 이해가되지 않습니다.

이러한 "위험한"변경 사항이 포함 된 새로운 병렬 .NET Framework 버전 (.NET Framework 5)을 도입하지 못하게하는 이유는 무엇입니까? 다시 말하지만 기술적 인 문제가 아닙니다.

기술적 인 문제가 아니라고 생각하는 이유는 무엇입니까? .NET Framework의 병렬 버전을 제공하는 것은 실행 가능한 솔루션이 아닙니다. 우선 OS 구성 요소이므로 서비스가 필요하기 때문에 상당히 비쌉니다. .NET Framework 3.5 및 4.x에 대한 분기 / 서비스 / 패칭 전략이 얼마나 복잡한 지 알 수 없습니다. 세 번째 것을 추가하는 것은 비실용적입니다. 둘째, COM 활성화 관리 구성 요소와 같은 항목에 대해 올바른 런타임을 선택하려면 활성화를 변경해야하므로 그렇게하는 것만으로도 위험이 따릅니다. 그리고 그것은 우리가 in-proc을 나란히 지원하는지 여부와 얼마나 많은 조합을 지원하는지에 대한 질문을 제기합니다. 단순한 작업이 아니며 위험도 없습니다.

수렴이라고 생각하게 하지마

@PinpointTownes 그것은 수렴입니다 ... .NET Core 😉

예를 들어 Xamarin / Unity가 서버 웹 스택에서 주로 사용하는 API를 제공하도록 만드는 것은 의미가 없습니다.

.NET Core뿐만 아니라 UWP에서도 ASP.NET Core를 사용하려는 사람들이 있는데 Xamarin에서도 사용하지 않는 이유는 무엇입니까? https://aspnet.uservoice.com/forums/41199-general-asp-net/suggestions/32626766-support-for-asp-net-core-running-on-uwp-as-windows

말이 안되는 것-당신에게-당신이 지원하고 싶지 않은 것 사이에는 차이가 있습니다.

CoreFx 저장소는 대용량 저장소입니다. Xamarin과 Unity가 함께 번들로 제공되는 기능을 검토하는 것이 Firehose에서 술을 마시고 CoreFx에 대한 모든 API 토론을 구독하는 것보다 훨씬 쉽습니다.

그런 극단적 인 접근을 제안 했습니까? 새로운 표준 API가 .NET Core에 도입 된 직후 (예 : 몇 주), 일단 먼지가 해결되면 곧바로 (즉, 몇 주) 논의하는 것과 같이 타협 할 수있는 타협이있을 것입니다.

그리고 이것을 좋아하지 않기 때문에 .NET Standard를 .NET Core와 일치시켜 모든 사람에게 적용하고 싶습니까? 미안하지만이 주장은 이해가되지 않습니다.

당신은 내가 그것을 좋아하지 않는다고 생각하지만 당신은 틀렸다. 나는 빠르게 움직이는 것을 좋아한다. 60 개의 NuGet 패키지의 유지 자로서 때때로 꽤 고통 스럽더라도. 내가 싫어하는 것은 모든 사람들이 같은 속도로 움직 이도록 강요하고, 따라 잡을 수 없기 때문에 길 한가운데에있는 사람들을 버리는 것입니다.

.NET Standard를 .NET Core만큼 빠르게 이동시키는 것이 처벌로 보일 수 있는지 잘 모르겠습니다. 최신 netstandard TFM을 목표로 삼도록 강요하는 것은 없습니다. 최신 API 세트가 필요한 경우에만 수행합니다. 필요하지 않은 경우 이전 버전을 대상으로 지정하여 더 광범위한 플랫폼에서 패키지를 사용할 수 있도록합니다.

평균적인 개발자의 관점에서 볼 때 이는 완전한 승리입니다. 최신 .NET Core 런타임에서 사용할 수있는 최신의 반짝이는 API를 사용하여 패키지를 작성할 수 있습니다. 다른 플랫폼이 따라 잡으면 여기에서도 패키지를 사용할 수 있습니다. 다중 타겟팅을 사용하거나 패키지를 다시 게시 할 필요가 없습니다.

우선 OS 구성 요소이므로 서비스가 필요하기 때문에 상당히 비쌉니다. .NET Framework 3.5 및 4.x에 대한 분기 / 서비스 / 패칭 전략이 얼마나 복잡한 지 알 수 없습니다. 세 번째 것을 추가하는 것은 비실용적입니다.

ASP.NET Core 3.0에 대한 .NET Framework 지원을 제거하는 것이 .NET Core로 이동할 수없는 사람들에게는 이상적이지 않은 것처럼 이것이 여러분에게 이상적이지 않다는 것을 확실히 상상할 수 있습니다. 하지만 당신이 마이크로 소프트라는 평범한 회사가 .NET Core로 옮겨야하는 것보다 훨씬 더 많은 자원을 가지고 있다고 생각하는 것이 완전히 틀렸습니까? (나는 당신이 소유하고 통제하지 않는 외부 의존성에 대해서도 이야기하지 않습니다).

둘째, COM 활성화 관리 구성 요소와 같은 항목에 대해 올바른 런타임을 선택하려면 활성화를 변경해야하므로 그렇게하는 것만으로도 위험이 따릅니다. 그리고 그것은 우리가 in-proc을 나란히 지원하는지 여부와 얼마나 많은 조합을 지원하는지에 대한 질문을 제기합니다. 단순한 작업이 아니며 위험도 없습니다.

물론 쉽지 않습니다. 그리고 그것은 위험합니다. 그러나 이것이 주요 버전이 나타내는 것입니다. 일이 깨질 수있는 위험이 있습니다. 이제 ASP.NET Core 2.2에 영원히 머물러야하는 것과 ASP.NET Core 3.0을 사용하기 위해 .NET Framework 5로 이동하는 위험을 감수하는 것 사이에 사람들이 무엇을 선택할 것이라고 생각하십니까?

하지만 당신이 마이크로 소프트라는 평범한 회사가 .NET Core로 옮겨야하는 것보다 훨씬 더 많은 자원을 가지고 있다고 생각하는 것이 완전히 틀렸습니까?

제 경험상 사람들은 우리가 가진 자원의 수와 현상 유지만을 지원하기 위해 우리가해야하는 자원의 양을 지속적으로 과대 평가합니다.

하지만이 경우에는 자원 문제도 아닙니다. 오픈 소스 .NET Framework 만 있으면 모든 PR이 .NET Framework로 직접 이동할 수 있습니다. 그것은 기계의 복잡성 및 경쟁 위험과 관련이 있습니다. 중앙 집중식 프레임 워크이며 병렬 릴리스도 활성화와 같은 공통 리소스 집합을 공유합니다. 우리는 똑똑한 사람들이 올바르게 나오면 할당 할 수 있다는 잘못된 시간을 거듭 증명했습니다.

이제 ASP.NET Core 2.2에 영원히 머물러야하는 것과 ASP.NET Core 3.0을 사용하기 위해 .NET Framework 5로 이동하는 위험을 감수하는 것 사이에 사람들이 무엇을 선택할 것이라고 생각하십니까?

제 생각에는 .NET Core 기능을 .NET Framework로 백 포트하는 것보다 더 많은 사람들이 .NET Core로 원활하게 마이그레이션 할 수 있도록 .NET Core에서 지원되는 API의 범위를 밀어 붙이는 것이 훨씬 더 실용적입니다. 우리가 할 수있는 일은 슬픔을 유발하는 것뿐입니다. 병렬 릴리스에는 IT를 설치하여 설치 프로그램에 연결하거나 호스팅 업체가 시스템을 제공 할 때까지 기다리는 등의 다른 문제가 수반된다는 점을 기억하십시오.

이것은 ASP.NET Core의 모든 부분에 적용됩니까, 아니면 유용하고 일반적으로 재사용 가능한 부분 (예 Microsoft.AspNetCore.Http.Extensions )이 .NET Standard에 남아 있습니까?

헉헉

@terrajobst 모든 플랫폼을 포괄 할 준비가되어 있지 않은 것 같은 API를 .netstandard에 추가하지 않는 것에 대해 당신이

예. .NET Standard 2.0에는 완전히 새로운 API가 없습니다. .NET Framework와 Xamarin의 교차점으로 정의되었습니다. 델타가 무엇이든간에 기존 코드와 합리적으로 호환되는 기준에 도달하려면 델타가 필요합니다. 유일한 작업은 UWP 및 .NET Core였습니다. 그리고 이러한 코드베이스는 원래 .NET의 현대적인 재설정으로 설계되었으며, 우리는 실행 불가능하다는 것을 알게되었습니다. 추가 될 API / 기술이 대체로 성숙하고 제한된 환경 (Xamarin iOS)에서 지원 되었기 때문에 복잡성이 낮았습니다.

그러나 이제 우리는 완전히 새로운 기능과 개념을 추가하는 것에 대해 이야기하고 있으며 그것은 다른 짐승입니다.

제 경험상 사람들은 우리가 가진 자원의 수와 현상 유지만을 지원하기 위해 우리가해야하는 자원의 양을 지속적으로 과대 평가합니다.

내 경험상 Microsofties는 현재 상태만을 지원하기 위해 보유한 리소스의 수와해야 할 일의 양을 지속적으로 과대 평가하고 있습니다. 당신의 주장은 실제로 양방향으로 작동합니다 : sweat_smile :

제 생각에는 .NET Core 기능을 .NET Framework로 백 포트하는 것보다 더 많은 사람들이 .NET Core로 원활하게 마이그레이션 할 수 있도록 .NET Core에서 지원되는 API의 범위를 밀어 붙이는 것이 훨씬 더 실용적입니다.

명확하게하자 : 나는 그게 전부 이지만 .NET Core가 .NET Framework가 가진 대부분 / 모든 기능을 따라 잡고 구현할 때까지 작동하지 않을 것입니다. 그렇게되기 전까지는 누락 된 기능이나 누락 된 API로 인해 사람들이 차단되는 것을 볼 수 있습니다. 누락 된 항목이 너무 많아서 큰 레거시 모 놀리 식 앱이 문제없이 .NET Core로 이동할 수 있다고 생각하는 것은 합리적이지 않습니다.

나는 당신의 우려를 확실히 이해합니다. 그러나 궁극적으로 당신의 삶을 더 편하게 만드는 것은 우리를 더 고통스럽게 만들 가능성이 있습니다. .NET Framework를 지원하지 않는 것은 우리에게 PITA가 될 것입니다.

나는 당신의 우려를 확실히 이해합니다. 그러나 궁극적으로 당신의 삶을 더 편하게 만드는 것은 우리를 더 고통스럽게 만들 가능성이 있습니다. .NET Framework를 지원하지 않는 것은 우리에게 PITA가 될 것입니다.

그 부분을 이해합니다. 그러나 대안은 .NET Framework의 더 많은 기능이 아니라 단순히 덜 강력한 ASP.NET Core입니다.

우리는 지난 몇 년 동안 .NET Framework와 .NET Core를 함께 발전 시키려고 노력했습니다. 일을 피 하려던 것과는 다릅니다. 예를 들어 바인딩 리디렉션의 악몽과 같은 문제를 해결하기 위해 런타임 엔지니어와 이야기하면서 개인적으로 엄청난 시간을 보냈습니다. 또는 4.6.1에서 .NET Standard 2.0 지원이 중단되었습니다. 우리는 시도했습니다. 의지력의 문제가 아니라 실용성의 문제입니다.

.NET Core가 .NET Framework가 가진 대부분의 / 모든 기능을 따라 잡고 구현할 때까지 작동하지 않습니다.

내 경험에 의하면, 일부의 API의 가용성 심지어는 관련이 없습니다. 기업 환경에서 가장 중요한 것은 지원 및 배포 복잡성입니다. 그리고 "운영 체제에서 지원, 제공 및 자동 업데이트" 는 .NET Core LTS 릴리스에서받는 3 년 지원 및 현재 여전히 포함 된 까다로운 배포보다 훨씬 더 매력적입니다. 솔직히 말해서 .NET Core 및 ASP.NET Core를위한 안정적인 도구는 아직 없습니다. 1 년 후에도 여전히 현상 유지가 될 것이라고 확신 할 수 있습니다. 우리는 매 릴리즈마다 변경이 있었고 3.0의 새로운 프레임 워크 참조가 올바른 솔루션이 될지 누가 알 수 있습니다. 따라서 업데이트 만 수행 할 수 없거나 수행해야하는 방식으로 수행 할 수없는 기업을 다룰 때 이는 확실히 큰 고통입니다. 일반적으로 그들은 지난 5 년 이상 동안 해왔 던 방식대로하기를 원합니다. 그들은 프레임 워크에 의해 망가졌고 그들에게 편안하지 않은 것은 거의 돋보입니다.

그러나 대안은 .NET Framework의 더 많은 기능이 아니라 단순히 덜 강력한 ASP.NET Core입니다.

작년에 제가 제안한 것과 거의 같습니다. .NET Framework에서 계속 작동하지만 (예 : netstandard20 및 netcoreapp30 ) 훨씬 더 적은 기능 세트를 제공하는 ASP.NET Core 패키지 흥미로운 성능. 때때로 사람들이 원하는 것은 작동하는 것입니다. 새롭고 빛나는 것들이 아닙니다. 초고속이 아닙니다.

우리는 지난 몇 년 동안 .NET Framework와 .NET Core를 함께 발전 시키려고 노력했습니다. 일을 피 하려던 것과는 다릅니다. 예를 들어 바인딩 리디렉션의 악몽과 같은 문제를 해결하기 위해 런타임 엔지니어와 이야기하면서 개인적으로 엄청난 시간을 보냈습니다. 또는 4.6.1에서 .NET Standard 2.0 지원이 중단되었습니다. 우리는 시도했습니다. 의지력의 문제가 아니라 실용성의 문제입니다.

우리는 분명히 모든 것에 동의하지는 않지만 말할 필요도없이 여러분이 한 일에 매우 감명을 받았습니다 (예, HttpClient 딸꾹질과 같은 일이 처리하기가 상당히 고통 스러웠더라도).

그 남자가되어서 정말 미안 해요 : sweat_smile :

지금까지 ASP.NET Core 전면에서 Razor는 사람들이 일반적으로 ASP.NET Core 외부에서 사용할 수 있기를 원하는 구체적인 것으로 나타났습니다. 나는 그것이 합리적이라고 생각하며 우리는 더 많은 영역을 식별해야합니다 (더 유용한 토론이 될 것입니다). ASP.NET Core 2.1 및 2.2는 여전히 .NET Framework를 지원하지만 .NET Framework를 영원히 지원하는 것은 합리적이지 않다고 생각합니다.

뿡뿡

이에 대한 좋은 예는 인터페이스의 기본 구현입니다. 이러한 기능은 위험으로 인해 .NET Framework로 백 포트하지 않을 것입니다.

그리고 그 진술로 DIM이 죽었습니다. 요점은 유산의 진화입니다. 레거시에 적용되지 않고 레거시와 새로운 것을 연결하려는 라이브러리에도 적용 할 수 없다면 누구에게도 도움이되지 않습니다.

지금까지 ASP.NET Core 전면에서 Razor는 사람들이 일반적으로 ASP.NET Core 외부에서 사용할 수 있기를 원하는 구체적인 것으로 나타났습니다.

Microsoft.Owin.Security.Interop backcompat '패키지, ASP.NET Core 데이터 보호 및 기본 종속성 을 목록에 추가 할 수 있습니다.

작년에 제가 제안한 것과 거의 같습니다. .NET Framework에서 계속 작동하지만 (예 : netstandard20 및 netcoreapp30 ) 훨씬 더 적은 기능 세트를 제공하는 ASP.NET Core 패키지 흥미로운 성능. 때때로 사람들이 원하는 것은 작동하는 것입니다. 새롭고 빛나는 것들이 아닙니다. 초고속이 아닙니다.

우리는 이것에 대해서도 논의했습니다. 문제는 일부 기본 플랫폼 API 및 기능이 공개 API로 흘러 들어가야하기 때문에이를 완전히 캡슐화 할 수 없다는 것입니다. 즉, ASP.NET Core의 미들웨어에 통합되는 라이브러리도 여러 구현을 제공해야합니다. 그러나 더 이상 호환되지 않는 두 가지 버전의 ASP.NET Core를 생성하는 공용 교환 유형이 코어 전용 일 수 있으므로 분열을 생성하지 않고는 불가능할 수도 있습니다.

헉헉

그리고 그 진술로 DIM이 죽었습니다. 유산의 전체 진화 지점. 레거시에 적용되지 않고 레거시와 새로운 것을 연결하려는 라이브러리에도 적용 할 수 없다면 누구에게도 도움이되지 않습니다.

레거시 코드 를 기존 설치 와 통합하고 있다고 생각

@terrajobst 당신은 Unity를 계속 언급합니다. 자체 CLR 구현이 있습니까? 나는 그들이 Mono를 사용하고 있다는 인상을 받았습니다.

Unity에는 자체 비 모노 AOT 버전 인 IL2CPP를 포함하여 여러 .NET 구현이 있습니다. 클래스 라이브러리 및 지원되는 API도 표준 Mono와 다릅니다.

뿡뿡

레거시 코드를 기존 설치와 통합하고 있다고 생각합니다.

"레거시"응용 프로그램이 여전히 활발하게 유지 관리되고 개발되고있는 경우에는 큰 차이가 없습니다. 프레임 워크를 업그레이드하는 것과 .NET Core로 마이그레이션해야하는 것에는 엄청난 차이가 있습니다.

.NET Core 전용 기능 일 가능성이 높지만 .NET Framework에 대해 컴파일 된 코드를 계속 사용할 수있는 동시에 .NET Core를 발전시킬 수 있습니다.

무엇을 위해? .NET Core의 이러한 "진화 된"API는 .NET Standard에 적용되지 않습니다. 그리고 라이브러리 작성자는 자체 API에서 호환되지 않는 분기를 생성하는 방법을 고려할 때이를 만질 수 없습니다.

@HaloFour에 동의합니다. DIM을 사용할 수있는 유일한 사람은 .NET Core만을 대상으로하는 라이브러리 작성자입니다. 기본적으로 corefx 및 aspnetcore 만 있습니다. 다른 사람이 그 근처에 갈 것이라고 상상할 수 없습니다.

DIM을 사용할 수있는 유일한 사람은 .NET Core만을 대상으로하는 라이브러리 작성자입니다. 기본적으로 corefx 및 aspnetcore 만 있습니다.

음, 또 다른 표현 방식은 .NET Core, Xamarin, Mono 및 Unity에서 사용할 수있는 동안 사용할 수없는 유일한 플랫폼은 .NET Framework라는 것입니다.

다른 사람이 그 근처에 갈 것이라고 상상할 수 없습니다.

나는 이와 같은 기능이 도서관에서 하키 스틱 채택 패턴을 가질 것이라고 상상할 것입니다. 결국 라이브러리 작성자는 항상 도달 범위 대 기능 집합을 고려합니다. 앱의 경우 대상 환경을 알고 있기 때문에 결정하기가 더 쉽습니다.

@ yaakov-h

ASP.NET Core의 모든 부분에 적용됩니까?

어떤 패키지에 무슨 일이 일어나고 있는지에 대한 임시 목록은 다음과 같습니다. https://github.com/aspnet/AspNetCore/issues/3756

@terrajobst 기본 인터페이스 구현이 C #의 언어 기능이 될 것이라고 생각했습니다. .NET Framework가이를 지원하지 않는다고 말하면 .Net Framework가 C # 버전 7.3 또는 기껏해야 다음 버전에서 영원히 멈출 것입니다. 그 차이는 생태계에서 누구도 일어나고 싶지 않은 일이 아닙니다.

몇 가지 .NET Core 워크로드를 실행하지만 다년 간의 .NET FX 프로젝트도 실행합니다.

.NET Core로 안전하게 업그레이드 (시작하는 .NET Framework에서도)는 매우 큰 작업입니다.

Microsoft가 .NET FX의 ASP.NET 이상에서 ASP.NET Core에서 .NET FX로 프로젝트를 "업그레이드"하는 데 도움이되는 일부 도구를 출시 할 계획이 있습니까?

새 VS 프로젝트를 만들고 뷰를 가져오고 프로젝트를 다시 지깅하는 방법에 대한 MSDN 기사가 있지만 레거시 항목 (Global asax, 라우팅, ....)이 너무 많아서 이전과 새 방법을 문서화 한 중앙 위치가 있었으면합니다. 모든 것을 포팅.

이러한 "위험한"변경 사항이 포함 된 새로운 병렬 .NET Framework 버전 (.NET Framework 5)을 도입하지 못하게하는 이유는 무엇입니까?

그 시점에서 .NET Core 3.0이 아니라면 어떤 이점이 있습니까? 이미 나란히 있고 "위험한"변경 사항이 있습니다. .NET Core의 다음 기능 세트에 .NET Framework 6 등이 필요합니까?

.NET Core 2.0에 이미 포함 된 API와 .NET Core 3.0에 제공되는 새로운 기능 세트로 인해 .NET Core는 매우 긴 LTS 버전 인 Framework 4.x와 함께 ".NET Framework 5"를 충족하지 못합니까?

추측에; 이 시점에서 .NET Core로 작동하도록 .NET Framework를 변경하는 것보다 .NET Core 3.0이 .NET Framework 4.x에서 확인한 특정 격차를 해결하는 것이 더 작은 엔지니어링 과제가 될 것입니다.

실용적인 제안 : ASP.NET Core 2.2가 일반적인 3 년 이상의 _extended_ 지원 기간으로 LTS가 될 가능성이 있습니까?

지금은 전체 프레임 워크를 고수해야하는 사람들을 만족시키면서 (1) 실제로 .NET Core로 마이그레이션 할 충분한 시간과 (2) ASP.NET MVC에서 ASP로 마이그레이션 할 충분한 동기를 부여합니다. .NET Core (.NET Core _yet_로 이동할 수없는 경우).

여전히 이것이 명확하지 않다고 생각합니다. .NET Framework의 ASP.NET Core가 .NET Core 2.1 LTS를 따르거나 .NET Framework v4.6.1 + 지원주기를 따르나요 (즉, .NET FX에서 실행되기 때문에). 가까운 미래에 지원됩니까?

@mythz ASP.NET Core는 실행하는 플랫폼에 관계없이 .NET Core 지원 수명주기 의 적용을받습니다.

여기서 가장 좋은 방법은 .net 표준을 3.0, 4.0 및 5.0 이상에 대해 실제로 업데이트하고 실제로 어떤 시점에서 .net 프레임 워크가 .net 코어로 완전히 마이그레이션 될 것이라는 사실을 전달하는 것입니다.
나머지는 모두 반만 구운 것입니다.

오늘 이미 LTS 지원 비용을 지불하는 고객이 있습니까? (그냥 조사 질문). 충분한 시간은 얼마입니까?

@terrajobst 진짜 문제는 netstandard가 모 놀리 식이라는 것입니다. netstandard 대신 버전이 지정된 API 세트가 필요하지 않은 것 같습니다. 예를 들어 base2.0 + span은 두 개의 API 세트가됩니다.

그런 다음 API 세트를 기반으로 표준을 발전시키고 전체 프레임 워크에서 일부 API 세트 만 구현할 수 있습니다. (일부 API 세트를 생략 할 수 있으므로 다른 플랫폼에서 netstandard를 구현하기가 더 쉽습니다.)

API 세트를 사용하면 전체 프레임 워크와 같이 지원이 덜한 대상에 대해 별도의 ASP.NET Core 빌드가 생성됩니다.

@Sebazzz 는 매우 이상한 주제입니다. netstandard를 재 설계하려는 시도로이 스레드를 탈선시킬 수 없습니까? 이에 대해 dotnet / standard에 문제를 제기 할 수 있지만이 아이디어는 이미 제안되어 중단되었다고 말씀 드리겠습니다.

@davidfowl 나는 그것이 전혀 "이상하다"또는 "탈선"이라고 생각하지 않는다. 그가 제안한 방식보다 조금 덜 세분화되어 있다면 정확히 우리가 필요로하는 것처럼 들립니다. 이 모든 문제가 우리가 웹 서버를 신경 쓰지 않는 Xamarin 및 Unity와 같은 구현에이 모든 웹 서버 항목을 통합해야한다는 것이라면 IMO는 별도의 ".NET Web Server Standard"API 그룹을 만듭니다. 이상적인 솔루션이 될 것입니다.

트윗 담아 가기

@terrajobst 진짜 문제는 netstandard가 모 놀리 식이라는 것입니다. netstandard 대신 버전이 지정된 API 세트가 필요하지 않은 것 같습니다. 예를 들어 base2.0 + span은 두 개의 API 세트가됩니다.

우리는 다양한 방식 (프로파일, PCL, 느슨한 계약 및 .NET Standard 1.x가 된 버전 화 된 계약 세트)에서 이것을 시도했습니다. 시간이 지남에 따라 (플랫폼 버전과 API 세트가 진화 할 때) 호환성 규칙을 도구화하고 이해하는 것은 너무 어렵습니다. 오늘날의 .NET Standard는 실행 가능한 모델에 가장 근접한 것입니다. 완벽하지는 않지만 최소한 몇 분 안에 설명 할 수 있고 사람들의 머리가 터지지는 않습니다.

.NET Standard에 대해 더 자세히 논의하게되어 기쁘지만 @davidfowl 이 여기에 속하지 않는다는 데 동의합니다. 원하는 경우 https://github.com/dotnet/standard에 문제를 제출

편집 .NET Standard 주석을 주제에서 벗어난 것으로 표시했습니다.

@ Shayan-To

@terrajobst 기본 인터페이스 구현이 C #의 언어 기능이 될 것이라고 생각했습니다. .NET Framework가이를 지원하지 않는다고 말하면 .Net Framework가 C # 버전 7.3 또는 기껏해야 다음 버전에서 영원히 멈출 것입니다. 그 차이는 생태계에서 누구도 일어나고 싶지 않은 일이 아닙니다.

언어 변경과 런타임 변경이 필요한 기능입니다. 유형 시스템의 규칙을 변경하므로 제네릭과 유사합니다. 일반적으로 C #은 컴파일하는 프레임 워크를 알지 못합니다 (프레임 워크가 제공하는 API를 설명하는 참조 어셈블리 집합을 전달하기 만합니다). API 변경이 필요하지 않은 모든 C # 기능 (예 : null 통합 연산자 ?. 또는 식 삭제를위한 _ )이 지원됩니다. 최신 컴파일러 및 언어 버전을 사용하고 해당 API가없는 이전 버전의 .NET Framework를 대상으로 할 때 컴파일러가 항상 작동하는 방식과 동일합니다. 예를 들어 .NET Framework 3.5 또는 4.0을 대상으로하는 경우 async / await가 작동하지 않습니다. Task 를 사용하려면 4.5 이상이어야합니다.

Man 나는 너희들에게 느낀다 .. .net 코어로 완전히 옮겨가는 것은, imo, 장기적으로 할 올바른 일이고 나는 제공 할 더 높은 속도의 혁신을 선호한다.

그러나 사람들은 이것에 대해 화를 낼 것입니다 .. 그것의 상당 부분은 의사 소통입니다. 2.1 3 년 LTS가 발표되었을 때 fullfx의 사람들은 3.0으로 이동할 수 있고 여전히 fullfx를 실행할 수있을 것으로 예상했으며 asp.net 코어를 고용주와 고객에게 판매하여 자신의 평판을 높이고 있습니다. 이제 그들은 깔개가 아래로 당겨진 것처럼 느껴질 것입니다. 장기 솔루션으로 판매 한 제품, asp.net의 미래는 이제 (지각 적으로) 지원 기간이 3 년으로 제한됩니다.

지금 마이그레이션하기가 더 쉽다는 것은 중요하지 않습니다. 플랫폼 전환은 항상 위험이 될 것이며, 이는 이러한 사람들이 예상하거나 계획하거나 예산을 책정하지 않은 위험 및 개발 노력이 될 것입니다.

대부분의 개발자는 .net core 3으로 이동하고 싶어하지만, 잠재적으로 종속성을 가질 수있는 것 외에도 (또는 위험 변경을 수반 할 수 있음) 이제 마이그레이션을 _ 다시 시도하고 _ _ 이번에는 _ 장기 투자가 될 것이라고 약속해야합니다. . 판매가 어려울 수 있지만 3 년의 지원 주기로 인해 강제적으로 판매 할 수 있습니다.

다시 말하지만, 저는 fullfx를 삭제하려고했지만,이를 지원하는 마지막 버전의 LTS를 상당량 확장하는 것을 고려해야한다고 생각합니다. 또한 블로그, 회의 / 세션 등에서처럼 어떤 부분이 여전히 네트워크 표준이 될지, 2.1 / 전체 프레임 워크를 사용하는 사람들이 여전히이를 활용할 수있는 방법을 매우 명확하게 전달합니다.

그렇지 않으면 내러티브가 "Microsoft가 전담 개발자를 다시 떠나고 있습니다"가 될 위험이 큽니다. 공정하다고 말하지 않고 일어날 수있는 일에 대해 경고하려고합니다.

LTS에 대한 합리적인 시간은 무엇입니까?

6 년 정도? 나는 메시지가 리셉션에서 큰 역할을 할 것이라고 생각합니다 .. 결국 어떤 사람들은 어떤 일이 있어도 화를 낼 것입니다 : /

트윗 담아 가기

참고로 Java LTS "Premier Support"는 5 년이며 "Extended Support"(유료)는 추가 3 년입니다. LTS 릴리스이며 지난달 릴리스 된 Java 11은 각각 2023 년 9 월과 2026 년 9 월까지 지원됩니다.

"확장 지원"LTS 제공을 조사하고 있으며 제공되는대로 자세한 내용을 제공 할 것입니다. 이는 .NET Framework 버전 (2.1.x)에서 지원되는 ASP.NET Core가 필요한 고객에게 현재 LTS 지원 기간보다 더 긴 옵션을 제공 할 수 있습니다.

또한 참고로 오늘 ASP.NET 커뮤니티 스탠드 업 ( https://www.youtube.com/watch?v=-b59KvkWBUo&list=PL1rZQsJPBU2StolNg0aqvQswETPcYnNKL&index=0

.net 표준을 타겟팅하십시오. asp.net 코어는 .netstandard2.1 또는 3.0 하고 나중에 mono 및 .netframework 캐치 업을 허용 할 수 있지만 asp.net 코어가 netcoreapp 대상이면 모든 라이브러리가 형식에 액세스하려고합니다. 해당 aspnetcore 라이브러리 중 .netcoreapp 라이브러리 여야합니다.

.net 코어는 항상 .net framework 및 mono 보다 빠르게 릴리스됩니다.
mono 및 .netframework는 microsoft start가 netcoreapp 더 많은 프레임 워크 / 라이브러리를 대상으로 지정하면 결국 .netcoreapp 어셈블리를 소비합니다 (그러면 nuget 대상 .netcoreapp 에도 더 많은 라이브러리가 발생 함).

그렇다면 .netstandard 는 .netcoreapp 😂

@ John0King 은 ASP.NET Core 외부에서 필요한 유형의 예를 제공하십시오.

1. @poke가 언급 한 면도기
2. MVC 필터 인터페이스 / (좀 ActionFilters 및 TagHelpers 일반적인 정적 / 문자열 확장자 방법, INT, 긴 요법. 내가 사용을 포함하는 헬퍼 클래스 라이브러리가 속성 PrivateAssert="All" 내가 이것을 사용 사용할 때 너무 MVC 패키지를 참조하십시오 다른 곳에서 라이브러리 일부, 해당 프로젝트는 MVC 어셈블리를 참조 할 필요가 없습니다. 라이브러리를 두 개로 분리해야한다고 생각합니다. 하나는 .netstandard 이고 다른 하나는 .netcoreapp 입니다.

또 다른 질문은 다음과 같습니다. 어떤 유형의 클래스 라이브러리를 만들어야하는지 문제가 될까요? ( .netstandard 대 .netcoreapp ). 오늘은 asp.net core 2.1에서 매우 간단합니다. 클래스 라이브러리에 대해 .netstandard 를 선택하고 웹 프로젝트에 대해 .netcoreapp 또는 net461 를 선택합니다.

mono 및 .netframework는 microsoft start가 netcoreapp에 더 많은 프레임 워크 / 라이브러리를 대상으로하는 경우 결국 .netcoreapp 어셈블리를 사용합니다 (너겟 대상 .netcoreapp에도 더 많은 라이브러리가 발생 함).

이것은 사람들이 .netstandard 라이브러리에 오게되는 것과 .netcoreapp 라이브러리에 오게되는 것을 분리하려고 더 열심히 노력하지 않는 경우에 발생합니다.

MVC 필터 인터페이스 / 속성 (일부 ActionFilters 및 TagHelpers 및 string, int, long ect에 대한 일반적인 정적 / 확장 메서드가 포함 된 도우미 클래스 라이브러리가 있습니다. PrivateAssert = "All"을 사용하여 MVC 패키지를 참조하므로이 라이브러리를 사용할 때 다른 곳에서는 해당 프로젝트가 MVC 어셈블리를 참조 할 필요가 없습니다. 라이브러리를 두 개로 분리해야한다고 생각합니다. 하나는 .netstandard이고 다른 하나는 .netcoreapp입니다)

자세히 설명해 주시겠습니까? 이건 말이 안 돼. MVC는 ASP.NET Core 프레임 워크이며 독립 실행 형으로 사용할 수 없습니다.

@davidfowl 이 라이브러리는 도우미 클래스 라이브러리입니다. asp.net 코어 MVC 프로젝트에서 작업 할 때 해당 필터를 사용할 수 있으며 콘솔 앱에서만 확장 메서드를 사용할 수 있습니다.

@davidfowl 이 라이브러리는 도우미 클래스 라이브러리입니다. asp.net 코어 MVC 프로젝트에서 작업 할 때 해당 필터를 사용할 수 있으며 콘솔 앱에서만 확장 메서드를 사용할 수 있습니다.

아직도 이해가 안 돼요. MVC와 다른 임의의 것들을 가지고있는 라이브러리에 대해 이야기하고 있습니까?

안타깝게도 기업용 소프트웨어에서는 이런 종류의 것이 일반적입니다. MVC 용 회사 유틸리티 + WPF 용 회사 유틸리티 + telerik 용 회사 유틸리티 등을 포함하는 '도우미 라이브러리'...
'.NET'이 단일 통합 플랫폼이었을 때 더 합리적이었습니다.

@davidfowl 예. 헬퍼 라이브러리에는 모든 곳에서 이러한 유형을 사용할 수있는 클래스 / 메서드가 있습니다. mvc 프로젝트에서이 라이브러리를 참조하면 mvc 관련 클래스 / 메서드를 사용할 수 있습니다.

오, 이것은 당신의 라이브러리가 더 잘 계층화되도록 강제합니다 😉

불행히도 이는 온 프레미스 배포를 수행하는 사람은 3 년 이상 자신의 소프트웨어를 지원할 수 없음을 의미합니다. 예를 들어 .netcore 3.0을 대상으로하는 앱을 출시하자마자 고객은 3 년을 확보 한 후 강제로 업그레이드해야합니다. 어떤 산업은 괜찮을 것이고 어떤 산업은 그렇지 않을 것입니다.

이것이 가장 큰 문제이며 많은 사람들이 .net 코어를 완전히 사용하지 않는 것으로 만듭니다. 나는 실제로 이것이 올바른 방향이라는 데 동의하지만 이것이 .net 코어로가는 많은 곳을 막을 것이라고 확신합니다.

이것에 대한 .net 팀의 응답을 정말로 원합니다.

문제는 ASP.NET Core가 웹 프레임 워크라는 것입니다. 어떤 산업에서 웹 사이트 를 완전히 수정하지 않고 3 년 이상 운영하는 것이 안전한가요? 보안 취약점이 아니라면, 당신이 의존했던 것을 더 이상 사용하지 않는 브라우저 나 TLS 1.4 또는 사이트가 새로운 watchlet에서 작동하도록 요구하는 사용자 일 것입니다.

그 시간 범위 동안 당신은 무모 끝에 년 동안 모두에서 웹 응용 프로그램을 업데이트하지 않도록 단지 작은 비틀기와 마이너 의존성 업데이트,하지만 계획을 멀리 얻을 수 있어야합니다.

ASP.NET Core 2.1의 LTS 기간을 5 ~ 7 년으로 늘리면 커뮤니티에서 더 좋아질 것이라고 생각합니다.

우리의 경험에 따르면 기업의 기업형 개발은 "현대적인"웹 개발에 비해 빠른 속도로 진행되지만 여전히 상당히 오래된 플랫폼에 새로운 투자를하지 않도록하고 싶어합니다. 이러한 응용 프로그램은 3 년 이내에 주요 업그레이드를 수행 할 수있을뿐 아니라 _ ​​출시까지 1 년 이상 걸리는 경우가 많습니다. 이러한 엔터프라이즈 (일반적으로 내부 용) 웹 애플리케이션은 종종 7-10 년 동안 지원되지만 ASP.NET Core 2.1 용 LTS가 10 년이되는 것은 부당하다고 생각합니다. 5 년은 3 년보다 더 나은 해결책으로 느껴지며, 7 년은 거의 모든 사람을 편안하게 해줄 것입니다.

그리고 이것은 ASP.NET Core 3.0에 .NET Framework 지원을 제거하는 주요 변경 사항이 필요하기 때문에 필요합니다. 향후 LTS 릴리스는 주요 변경 사항이 그렇게 크지 않다는 가정하에이 표준을 따르지 않아야합니다.

.NET Standard를 .NET Core만큼 빠르게 이동시키는 것이 처벌로 보일 수 있는지 잘 모르겠습니다. 최신 netstandard TFM을 목표로 삼도록 강요하는 것은 없습니다. 최신 API 세트가 필요한 경우에만 수행합니다. 필요하지 않은 경우 이전 버전을 대상으로 지정하여 더 광범위한 플랫폼에서 패키지를 사용할 수 있도록합니다.

플랫폼이 따라 잡지 않으면 어떻게됩니까? 그러면 .NET Core 및 Xamarin에서만 사용할 수 있지만 .NET Framework에서는 불가능한 기능 A가 필요한 netstandard2.3 를 대상으로하는 라이브러리가 있습니다.

그런 다음 netstandard2.4 가 나오면 몇 가지 새로운 Apis가 있으며 이러한 API 중 일부는 .NET Framework로 이식 할 수 있습니다. 이제 뭐야?

.NET Framework에서 실행되는 netstandad2.4의 기능이 필요한 라이브러리를 대상으로하는 방법은 무엇입니까?하지만 netstandard2.4 는 netstandard2.2 구현할 수 없기 때문에 .NET Framework를 대상으로 할 수 없습니다.

그런 다음 세 가지 플랫폼으로 크로스 컴파일해야합니다.
netstandard2.2 기존의 플랫폼과 net4x 순 표준은 단지에서 추가 된 기능을 지원하기 위해 netstandad2.4 및 net4x can also implement but not support because of APIs that went into netstandard2.3`합니다.

패키지 작성자가 너깃 패키지를 작성하고 배송하는 것을 어떻게 더 쉽게 만들 수 있습니까?

모든 플랫폼이 지원할 최소 공통 분모가 netstandard로 유입 될 때만 작동 할 수 있습니다. 더 많은 API가 PlatformNotSupported 예외를 던지는 것을 원하지 않는 한, 그렇지 않으면 netstandard 내에서 조각화가 발생합니다.

ASP.NET Core 3.0에 대한 .NET Framework 지원을 제거하는 것이 .NET Core로 이동할 수없는 사람들에게는 이상적이지 않은 것처럼 이것이 여러분에게 이상적이지 않다는 것을 확실히 상상할 수 있습니다. 하지만 당신이 마이크로 소프트라는 평범한 회사가 .NET Core로 옮겨야하는 것보다 훨씬 더 많은 자원을 가지고 있다고 생각하는 것이 완전히 틀렸습니까? (나는 당신이 소유하고 통제하지 않는 외부 의존성에 대해서도 이야기하지 않습니다).

여기서 실제 문제는 무엇입니까? ASP.NET 레거시에서 ASP.NET Core로 이동할 수없는 사람들은 ASP.NET Core가 .NET Framework를 대상으로하는지 여부에 관계없이 이동할 수 없습니다. .NET Framework의 ASP.NET Core에서는 작동하지 않는 System.Web 특정 라이브러리 일 가능성이 가장 높습니다. 지금 자신의 응용 프로그램을 가지고있는 사람들은 분명히 이미 작업 세트를 가지고 있습니다.

그리고 이미 .NET Framework의 ASP.NET Core 2.1을 사용하고있는 사람들이 작동한다면 왜 이동하고 싶습니까? 분명히 필요한 모든 것이 이미 있고 ASP.NET Core 3.0에 새로 추가 된 다른 모든 것이 있으면 좋습니다.

그 외 :
애플리케이션을 .NET Core로 마이그레이션하는 방법에는 여러 가지가 있습니다. 즉, 이전 모 놀리 식 애플리케이션에서 일부를 분리하고이를 마이크로 서비스로 다시 구현하면 위험을 낮추고 시간에 따라 분산시킬 수 있습니다.

플랫폼이 따라 잡지 않으면 어떻게됩니까? 그런 다음 .NET Core 및 Xamarin에서만 사용할 수 있지만 .NET Framework에서는 불가능한 기능 A가 필요한 netstandard2.3을 대상으로하는 라이브러리가 있습니다.

.NET Standard를 지원하는 대부분의 플랫폼에서 API를 구현할 수 없다면 표준의 일부가 아니어야 할 가능성이 높습니다. (실제로는 Xamarin이 실행되는 플랫폼이 일반적으로 훨씬 더 제한적이므로 그 반대 일 가능성이 매우 높습니다). .NET Standard에 포함 된 API를 검토 할 때 이러한 종류의 문제가 감지 될 것으로 예상하지만 잘못되었을 수 있습니다.

그리고 이미 .NET Framework의 ASP.NET Core 2.1을 사용하고있는 사람들이 작동한다면 왜 이동하고 싶습니까?

• 지원하다? (3 년 지원은 엄청나게 짧습니다)
• 3.0에만 존재하는 버그 수정? (LTS 버전은 중요한 버그 및 취약점에 대한 수정 만받습니다)
• 최신 ASP.NET Core 버전과 만 호환되는 라이브러리를 참조해야합니까?

애플리케이션을 .NET Core로 마이그레이션하는 방법에는 여러 가지가 있습니다. 즉, 이전 모 놀리 식 애플리케이션에서 일부를 분리하고이를 마이크로 서비스로 다시 구현하면 위험을 낮추고 시간에 따라 분산시킬 수 있습니다.

네, 물론 이론적으로는 그 문제를 다루는 이상적인 방법입니다. 그러나:

• 일부 앱은 제어 할 수없는 외부 라이브러리에 의존합니다. 라이브러리가 .NET Core에서 작동하지 않고 공급 업체가 이식을 원하지 않거나 이식 할 수없는 경우 운이 좋지 않습니다.
• .NET Core로 마이그레이션하는 것은 많은 비용과 시간이 소요될 수 있습니다. 마이크로 소프트 최고의 팀조차도 그 문제로 어려움을 겪고 있다면, 어떤 일반 팀이라도 그렇게 쉬울 것이라고 생각하십니까? Entity Framework 6이 마침내 .NET Standard와 호환되는 것을 확인하려면 3.0을 기다려야합니다.

내가 말하는 것을 잘못 해석하지 마십시오. 저는 새로운 앱에 .NET Core를 사용하는 것입니다. 그러나 ASP.NET Core가 .NET Framework와 호환된다는 사실은 많은 회사가 합리적인 비용으로 ASP.NET Core로 전환하는 데 도움이되었습니다. 나는 "너무 어렵지 않은"마이그레이션 경로가 없었다면 결코 그렇게 인기가 없었을 것이라고 확신합니다.

Microsoft, 2.1 지원 연장을 요청하는 것이 너무 많습니까? 2021 년은 우리에게 충분하지 않으며 전환을위한 충분한 자원 / 시간도 없습니다. 적어도 2022 년까지는? 추가 1 년은 우리에게 고통 스럽지만 변화를 만들 수있는 기회를 제공 할 것입니다.

많은 타사 공급 업체가 아직 라이브러리를 .Net Core 호환성으로 마이그레이션하지 않았으며 이것이 중단의 가장 큰 이유입니다.

참고로 https://github.com/aspnet/AspNetCore/issues/3753#issuecomment -434521855

필자는 필요에 따라 LTS를 확장한다고 생각하지만 .NET FX에서 ASP.NET Core를 .NET FX 지원 주기로 롤링하는 IMO도 고려해야합니다. 우선 .NET Framework의 서로 다른 부분을 서로 다른 지원주기에두고 함께 롤링하는 것이 더 합리적 일 경우 혼란 스럽습니다. 두 번째로 2.1 용 코드는 이미 작성, 릴리스 및 의존하므로 .NET Core 3.0과 연계하여 적극적으로 개발하는 것보다 2.1을 지원하는 데 훨씬 적은 리소스가 필요합니다. 같은 팀이 두 가지를 모두 유지하고 있다면, 최근에 더 친숙한 모듈 식 ASP.NET Core 활성 코드 기반이 완전히 다른 기존 ASP.NET 코드 기반보다 더 쉽게 지원할 수 있다고 가정합니다.

MS는 2012 년 Silverlight 5의 EOL을 발표했을 때 2021 년 10 월까지 계속 지원하고 있습니다 (2015 년 Chrome과 2017 년 Firefox에서 삭제 되었음에도 불구하고). 이것은 완전히 포기 된 기술을위한 것입니다. 여기에서는 그렇지 않습니다. 대체로 동일한 코드 기반, 프로그래밍 모델, 활성 개발 팀이 여전히 작업 중이며, 폐기 된 .NET Framework에서 기존 소프트웨어 만 실행하고 있습니다.

이 발표 이전에 MS는 Windows 전용 워크로드 (교차 플랫폼 / 고성능 워크로드의 .NET Core와 달리)에 적합하고 ASP.NET Core가 미래라는 강력한 메시징이 .NET Framework를 포기하지 않았습니다. 여러 플랫폼을 대상으로하는 라이브러리를 개발하기위한 솔루션으로 .NET Standard를 사용하여 향후 .NET Framework 및 .NET Core를 모두 지원하는 프로그래밍 모델.

이제 .NET Core가 모든 새로운 프로젝트의 미래라는 것이 분명해졌지만 지금까지이 지침을 기반으로 결정을 내린 기존 투자 및 기존 고객을 처리하는 방법에 관한 것입니다. 기존 .NET 개발 팀은 기존 시스템을 지원해야 할 때 어떻게 진행하고 있습니까? 새로운 앱을 개발하기 위해 컨텍스트를 전환하는 동안 클래식 ASP.NET (기존 기술 / 지식이 하루가 지남)에 머물러야합니다. .NET Core에서.

.NET Framework에서 시스템을 유지 관리해야했다면 활성 지식 기반 / 생태계에 대한 액세스 권한이있는 새로운 ASP.NET 프로그래밍 모델에서 개발 한 다음 이전 ASP.NET을 사용하도록 강제로 되 돌리는 것을 선호합니다. 무기한이지만 FX의 ASP.NET Core가 WebForms와 동일한 수준의 지원을 제공하지 않는 한 불가능합니다.

MS는 또한 FX에서 ASP.NET Core를 "안정적인"개발 환경 (즉, ASP.NET Core 2.1에서 고정)으로 포지셔닝 할 수 있습니다. .NET Core가 시작된 이후 지난 몇 년 동안 .NET 개발자가되는 것은 쉽지 않았습니다. .NET Core <1.x로 이식하려는 모든 노력을 사실상 포기해야했습니다. 끊임없는 변화의 흐름을 따라 잡기가 어려웠습니다. .NET Core 2.x가 가능할 때까지만 가능했습니다. 이를 지원하고 기존 앱을 마이그레이션합니다. 반면에 기존 ASP.NET Framework 개발자는 선택한 플랫폼이 정체 된 다음 새로운 ASP.NET Core 프로그래밍 모델로 대체되고 확장으로 인해 기존 기술 / 지식이 약화되는 것을 목격했습니다. FX에서 ASP.NET Core에 대한 지원을 종료하면 전체 시스템을 .NET Core로 업그레이드 할 수없는 경우 (위험 대비) 버려진 플랫폼에서 실행될 위험이있는 .NET Core에 대한 인기있는 단계적 마이그레이션 전략이 종료됩니다 (위험 마이그레이션 시도를 고려하지 못하게 할 수 있음) 또한 매일 작업하는 기존 시스템을 마이그레이션 할 수없는 경우 향후 ASP.NET Core 개발 모델에 참여할 수있는 기회도 없어집니다. WebForms와 동일한 지원을받는 경우에만 가능합니다. 아직 고려 중입니다.

아무도 언급하지 않았습니다. asp.net 핵심 애플리케이션에서 WCF 서비스를 호스팅해야하며 이것이 .net 프레임 워크에서 마이그레이션하는 유일한 문제점입니다. 슬프게도 .net core 3에서 서버 측 wcf 지원에 대한 소식이 없습니다.

@DamianEdwards @davidfowl @natemcmaster 우리는 같은 배에 있습니다. 우리 회사는 .Net Full 프레임 워크의 ASP.Net Core에서 실행되는 여러 제품을 보유하고 있으며, 우리가 판매하는 산업이 얼마나 느리게 움직이고 있기 때문에 3 년보다 훨씬 더 오랜 시간 동안 이러한 제품을 지원합니다. .net 코어 2.2 용 LTS를 확장하는 것은 ASP.net 코어 응용 프로그램을 다시 ASP.Net으로 이식해야하기 때문에 현재 상황에서 의미가 없습니다. 확실히 이것은 포인트 녀석을 물리 치고 있습니다! 더 짧은 기간 동안 지원 신청을 제안 하시겠습니까? 불행히도 이것은 우리가 통제 할 수없는 것입니다. 우리가 일하는 산업은 새로운 소프트웨어를 출시하는 데 1 년이 걸릴 수 있습니다.

불행히도 이는 온 프레미스 배포를 수행하는 사람은 3 년 이상 자신의 소프트웨어를 지원할 수 없음을 의미합니다. 예를 들어 .netcore 3.0을 대상으로하는 앱을 출시하자마자 고객은 3 년을 확보 한 후 강제로 업그레이드해야합니다. 어떤 산업은 괜찮을 것이고 어떤 산업은 그렇지 않을 것입니다.

이것이 가장 큰 문제이며 많은 사람들이 .net 코어를 완전히 사용하지 않는 것으로 만듭니다. 나는 실제로 이것이 올바른 방향이라는 데 동의하지만 이것이 .net 코어로가는 많은 곳을 막을 것이라고 확신합니다.

이것에 대한 .net 팀의 응답을 정말로 원합니다.

@davidfowl https://github.com/aspnet/AspNetCore/issues/3753#issuecomment -434594997

오, 이것은 당신의 라이브러리가 더 잘 계층화되도록 강제합니다 😉

이 주장은 반대 방향으로 작동하지 않습니까?

내가 이해할 수없는 것은 실제로 ASP.NET Core의 적절한 계층화 아키텍처를 방해하는 것입니까?
예, Span<T> 와 같은 일부 런타임 기능은 .Net Framework에서 사용할 수 없지만 전혀 사용할 수 없다는 의미는 아닙니다. 사용할 수 있지만 .Net 코어만큼 성능이 떨어집니다. 우리는 그것을 다룰 수 있습니다.

일부 저수준 구현은 특히 .net 코어 및 .net 표준에 대한 변형으로 구현 될 수 있습니다. API는 일반적으로 NuGet 패키지로 사용할 수 있기 때문에 그럴 여지가 많지 않을 것입니다.
많은 라이브러리 작성자가 서로 다른 플랫폼에 대해 서로 다른 구현을 지원합니다. 이것이 항상 그래 왔던 것입니다.

.Net Framework / .Net Standard를 지원하지 못하게하는 것이 정확히 무엇인지 자세히 설명해 주시겠습니까? 플랫폼 별 구현을 위해 추상화 할 수없는 몇 가지 간단한 예는 무엇입니까?

.Net Framework / .Net Standard를 지원하지 못하게합니다. 플랫폼 별 구현을 위해 추상화 할 수없는 몇 가지 간단한 예는 무엇입니까?

머릿속에서 런타임 또는 프레임 워크 변경이 필요한 항목

• 내부 GC 포인터; 따라서 객체없이 참조에서만 안전한 Span 생성 : MemoryMarshal.CreateSpan<T>(ref T reference, int length)
• Utf8String 초
• 기본 인터페이스 구현
• 스레드 풀 사용자 정의 작업 항목
• 기본 유형에 대한 스팬 오버로드 : Stream, Sockets, TextReader / TextWriter, WebSockets
• 기본 유형에 대한 IAsyncDisposable 오버로드 : Stream, Sockets, TextReader / TextWriter, WebSockets 등
• IAsyncEnumerator기본 유형에 대한 오버로드 : Stream, Sockets, TextReader / TextWriter, WebSockets 등

보너스 아이템

• 하드웨어 내장 함수 (x86, x64, ARM)
• 이스케이프 분석 (스택 할 새 할당)
• 병렬 런타임 버전
• 바인딩 리디렉션 및 버전 관리 수정

더 이상 넷 프레임 워크를 지원하지 않는 넷 스탠다드 버전을 가질 수없는 이유를 이해할 수 없습니다. Windows Phone이 1.2 이상의 netstandard 지원이없는 것처럼. 표준을 앞으로 나아가고 netcore, mono, xamarin 등과 같은 구현이 결국 일치하거나 결코 일치하도록 허용 할 수없는 이유는 무엇입니까? 그런 다음 적용 범위를 최대화하기 위해 구현할 netstandard 버전을 결정하는 것은 라이브러리 제작자에게 달려 있습니다.

이 변경으로 인해 xamarin 및 mono는 더 이상 aspnetcore를 사용할 수 없습니다. 따라서 라이브러리 제조업체가 netcore와 netstandard를 모두 대상으로하거나 더 나쁘게는 netstandard를 모두 포기하고 netcore 만 대상으로 지정해야합니다.

이것은 궁극적으로 netstandard의 죽음으로 이어질 것입니다.

.Net Framework / .Net Standard를 지원하지 못하게합니다. 플랫폼 별 구현을 위해 추상화 할 수없는 몇 가지 간단한 예는 무엇입니까?

머릿속에서 런타임 또는 프레임 워크 변경이 필요한 항목

• 내부 GC 포인터; 따라서 객체없이 참조에서만 안전한 Span 생성 : MemoryMarshal.CreateSpan<T>(ref T reference, int length)
• Utf8String 초
• 기본 인터페이스 구현
• 스레드 풀 사용자 정의 작업 항목
• 기본 유형에 대한 스팬 오버로드 : Stream, Sockets, TextReader / TextWriter, WebSockets
• 기본 유형에 대한 IAsyncDisposable 오버로드 : Stream, Sockets, TextReader / TextWriter, WebSockets 등
• 기본 유형에 대한 IAsyncEnumerator 오버로드 : Stream, Sockets, TextReader / TextWriter, WebSockets 등

보너스 아이템

• 하드웨어 내장 함수 (x86, x64, ARM)
• 이스케이프 분석 (스택 할 새 할당)
• 병렬 런타임 버전
• 바인딩 리디렉션 및 버전 관리 수정

첫 번째 목록의 항목은 netstandard 변경 후보가 될 것 같습니까?

대부분은 다른 런타임으로 가져 오는 것이 불가능한 것 같지 않지만, 아무도 기본 인터페이스 구현을 .NET Framework로 가져 오기 위해 새 버전으로 CLR을 개정하는 것을 원하지 않는 것 같습니다.

동시에 Microsoft는 .NET Framework와 영원히 호환되지 않는 .NET Standard 버전을 추진하고 싶지 않은 것 같습니다. 그렇지 않으면 이것은 실제로 문제가되지 않을 것입니다. netstandard30 또는 netstandard40 하고 Framework 지원을 중단하십시오. .NET Core가 이러한 새로운 표준 중 하나를 대상으로합니다.

이 스레드 등은 Microsoft가 효과적으로 구석에 그리는 결과라고 생각합니다.

동시에 Microsoft는 .NET Framework와 영원히 호환되지 않는 .NET Standard 버전을 추진하고 싶지 않은 것 같습니다.

이 솔직하지 않은; .NET Standard 2.1이 마무리되고 있으며 기본 프레임 워크 유형에 대한 Span 오버로드를 포함하여 .NET Standard 2.0에 대한 3104 개의 새로운 API 가 있습니다. .NET Framework와 호환되지 않을 수 있습니다.

.NET Standard는 계속 발전하고 있습니다.

그렇지 않으면 이것은 실제로 문제가되지 않을 것입니다. netstandard30 또는 netstandard40으로 진행하고 프레임 워크 지원을 중단하십시오. .NET Core가 이러한 새로운 표준 중 하나를 대상으로합니다.

문제는 프레임 워크뿐만 아니라 모든 런타임을 새로운 표준 중 하나와 호환되지 않게 만드는 것입니다. 그 후 모든 표준과 호환되지 않습니다. .NET Standard에 들어가는 것은 구현할 수있는 것으로 다양한 런타임에서 동의해야합니다.

Mono와 Unity의 다양한 GC가 곧 내부 포인터를 지원합니까? .NET Standard에 추가하지 않으면 GC가이를 처리하도록 변경 될 때까지 향후 .NET Standard에서 해당 .NET Standard에서 차단됩니다. 하나; 지금 구현할 수있는 api를 추가하고 향후 표준으로 사용할 수없는 API를 저장하는 것이 좋습니다.

Core에 추가되는 API가 영구적으로 고정되고 모든 런타임을 강제하는 올바른 API입니까? 다음 표준과 호환되기를 원하는 것입니까?

일부 Core 2.1 API는 사용 피드백으로 인해 미리보기 1과 미리보기 2 사이에 변경되었습니다. 따라서 Core X의 새로운 API가 무엇인지 알기조차 어렵습니다. 그런 다음 구현할 모든 런타임에 대해 표준에 추가 할 올바른 집합이 무엇인지 (또는 뒤에 남게됩니다).

.NET Standard에 대한 접근 방식은 표준이 채택되기 전에 2 개의 브라우저가 기능을 구현해야하는 경우 브라우저 표준보다 훨씬 더 공격적입니다.

새로운 .NET Standard가 .NET Core와 동시에 제공 될 수 있고 모든 런타임이이를 즉시 구현할 수 있고 ASP.NET Core가 .NET Standard를 통해 모든 새로운 API를 사용할 수 있다면 좋을 것입니다. 이상적으로는 좋지만 실용 적이지도 않습니다. .NET Core에서 구현되지 않은 승인 된 API 도

기본적인 질문은 ASP.NET Core가 요청한 API를 사용하고 함께 제공되는 .NET Core 버전으로 제공 될 수 있다는 것입니다 (동시에 제공됨). 또는 이전 버전의 .NET Core에 제공된 API 만 사용할 수 있습니까? 따라서 해당 .NET Core의 .NET Standard 버전에있을 가능성이 있습니까? (.NET Standard 버전처럼 보이므로 현재 .NET Core보다 apis 1 버전이 뒤처 질 것입니다. 샘플 크기 1 사용)

ASP.NET Core에서 api를 사용할 수있는 경우 그런 다음 api는 사용 테스트를 받고 좋은 api인지 평가합니다. 그렇지 않은 경우 더 나은 API를 제안 할 수 있습니다. ASP.NET Core에서 사용할 수없는 경우 .NET Standard 후보가 될 때 좋은 api인지 여부는 아직 알 수 없습니다.

아무도 기본 인터페이스 구현을 .NET Framework로 가져 오기 위해 새 버전으로 CLR을 개정하고 싶어하지 않습니다.

기존 .NET Framework 워크로드 (WinForms 및 WPF 포함)를 지원하는 .NET Core는 본질적으로 CLR의 개정입니다. 하지만 더 지속 가능하고 미래를 보장하는 방식으로 수행 되었습니까?

이 솔직하지 않은; .NET Standard 2.1이 마무리되고 있으며 기본 프레임 워크 유형에 대한 Span 오버로드를 포함하여 .NET Standard 2.0에 대한 3104 개의 새로운 API가 있습니다. .NET Framework와 호환되지 않을 수 있습니다.

.NET Framework 4.8 및 .NET Framework 4.9 포함?

향후 프레임 워크 업데이트가 이러한 새로운 API를 얻을 가능성은 항상 있습니다. 현재로서는 .NET Framework가 DIM을 얻지 못하므로 DIM 메서드를 사용하는 모든 인터페이스를 .NET Framework로 포팅 할 수 없습니다.

기존 .NET Framework 워크로드 (WinForms 및 WPF 포함)를 지원하는 .NET Core는 본질적으로 CLR의 개정입니다. 하지만 더 지속 가능하고 미래를 보장하는 방식으로 수행 되었습니까?

그리고 역방향 증명이 아닙니다. Microsoft가 .NET Core에서 실행되는 Paint.Net과 같은 것을 보여준 것처럼 .NET Core에서 기존 서버 측 프로젝트를 실행할 수 없으며 대부분의 사람들도 실행할 수 없습니다.

새로운 .NET Standard가 .NET Core와 동시에 제공 될 수 있고 모든 런타임이이를 즉시 구현할 수 있고 ASP.NET Core가 .NET Standard를 통해 모든 새로운 API를 사용할 수 있다면 좋을 것입니다. 이상적으로는 좋지만 실용 적이지도 않습니다.

이것은 실용적이지 않을 수도 있지만 ASP.NET Core의 두 가지 버전이있을 수 있다면 사람들이 전반적으로 조금 더 행복 할 것이라고 생각합니다.

• .NET _Core_에 연결되어 있고 원하는 새로운 API를 사용할 수있는 빠르게 움직이는 최신 버전입니다.
• .NET _Standard_에 연결되고 더 많은 곳에서 실행되는 느리게 움직이는 LTS 버전 결국 오래된 최신 빌드를 따라 잡지 만 항상 뒤처집니다.

.NET Core에 연결하면 모든 사람이 만족하지 않는 트레이드 오프가 발생합니다. 빠른 접근 방식에 대한 추론을 얻었지만 전반적인 .NET 생태계에 대한 합법적 인 우려도 있습니다.

• .NET Core에 연결되어 있고 원하는 새 API를 사용할 수있는 빠르게 움직이는 최신 버전입니다.
• .NET Standard에 연결되고 더 많은 곳에서 실행되는 느리게 움직이는 LTS 버전 결국 오래된 최신 빌드를 따라 잡지 만 항상 뒤처집니다.

따라서 ASP.NET Core 3.0이 .NET Core 3.0으로 만 나온다면; 그러나 나중에 api가있는 .NET Standard가되었을 때; .NET Standard 인 ASP.NET Core 3.x 용 패키지도 출시되었습니다 (ASP.NET Core가 4.0으로 이동 한 경우에도 마찬가지입니다). 그것이 귀하의 요구 사항을 충족합니까?

@ yaakov-h

.NET Standard에 연결되고 더 많은 곳에서 실행되는 느리게 움직이는 LTS 버전 결국 오래된 최신 빌드를 따라 잡지 만 항상 뒤처집니다.

이것은 무엇을 의미 하는가? @DamianEdwards가 언급 한 확장 지원과 함께 항상 ASP.NET Core 2.1을 사용할 수 있습니다. 내 생각 엔 그 지원이 10 년이더라도 불평하는 사람들을 만족시키지 못할 것 같다. 직감은 새로운 기능이 개발되고있는 한 사람들이 그 기능에 접근하기를 원할 것이라고 말하지만 (현재 느린 열차에있는 기능조차도), 아마도이 응답을 너무 많이 읽고있을 것입니다 ...

다음과 같은 확장 지원과 함께 ASP.NET Core 2.1을 항상 사용할 수 있습니다.

커뮤니티를 나누지 마세요 !!
(투표 기준) 개발자 1/3이 asp.net 코어 2.1에 머물 것으로 예상합니까? 또는 라이브러리의 2 버전을 유지해야하는 너겟 패키지를 만드는 2/3 개발자를 기대하십니까?

뿡 빵뀨

따라서 ASP.NET Core 3.0이 .NET Core 3.0으로 만 나온다면; 그러나 나중에 api가있는 .NET Standard가되었을 때; .NET Standard 인 ASP.NET Core 3.x 용 패키지도 출시되었습니다 (ASP.NET Core가 4.0으로 이동 한 경우에도 마찬가지입니다). 그것이 귀하의 요구 사항을 충족합니까?

정확합니다.

뿡뿡

@DamianEdwards가 언급 한 확장 지원과 함께 항상 ASP.NET Core 2.1을 사용할 수 있습니다. 내 생각 엔 그 지원이 10 년이더라도 불평하는 사람들을 만족시키지 못할 것 같다.

여기에 충돌하는 메시지가있는 것 같습니다.

1. 이전 LTS 버전 인 2.1을 유지하는 것이 좋습니다.
2. ASP.NET Core는 너무 빠르게 이동하여 .NET Core와 후속 .NET Standard 사이의 릴리스주기를 한 번도 기다릴 수 없습니다.

(2)가 뒤처 질 까봐 많은 혼란과 두려움을 불러 일으키고 있다고 생각합니다.

헉헉

(투표 기준) 개발자 1/3이 asp.net 코어 2.1에 머물 것으로 예상합니까? 또는 라이브러리의 2 버전을 유지해야하는 너겟 패키지를 만드는 2/3 개발자를 기대하십니까?

라이브러리 작성자는 지원하려는 ASP.NET Core의 최소 버전이 무엇인지 결정하고이를 대상으로 할 것으로 예상합니다. 그것은 그들이 오늘 이미하고있는 일입니다. 일부 라이브러리는 ASP.NET Core 1.x를 지원하고 2.x는 2.x 만 지원합니다. 이것은 다르지 않습니다.

@ yaakov-h

나는 충돌하는 메시지가 무엇인지 잘 이해하지 못합니다. 현재 2.1은 LTS이며 .NET Core 및 .NET Framework에서 실행되며 3 년 동안 지원됩니다. 이것은 새로운 메시지가 아닙니다. 처음부터 우리가 받았던 것과 같은 메시지입니다.

ASP.NET Core는 너무 빠르게 이동하여 .NET Core와 후속 .NET Standard 사이의 릴리스주기를 한 번도 기다릴 수 없습니다.

그것은 여기에 작성된 의견에 근거한 추측입니다. 공식적으로 우리는 .NET Core의 배송주기에 연결되어 있으며 이미 모든 릴리스에서 새로운 API를 추가하고 사용하고 있습니다. .NET Framework에서 실행되는 ASP.NET Core는 영구적 인 것이 아니며 (ASP.NET Core라고도 함) 항상 디딤돌로 사용되었습니다. 고객이 완벽하게 작동하는 애플리케이션을 합리적으로 작성할 수 있도록 충분한 핵심 API를 다시 추가해야했습니다.

MS 팀의 답변이 있습니까?

불행히도 이는 온 프레미스 배포를 수행하는 사람은 3 년 이상 자신의 소프트웨어를 지원할 수 없음을 의미합니다. 예를 들어 .netcore 3.0을 대상으로하는 앱을 출시하자마자 고객은 3 년을 확보 한 후 강제로 업그레이드해야합니다. 어떤 산업은 괜찮을 것이고 어떤 산업은 그렇지 않을 것입니다.

이것이 가장 큰 문제이며 많은 사람들이 .net 코어를 완전히 사용하지 않는 것으로 만듭니다. 나는 실제로 이것이 올바른 방향이라는 데 동의하지만 이것이 .net 코어로가는 많은 곳을 막을 것이라고 확신합니다.

이것에 대한 .net 팀의 응답을 정말로 원합니다.

안타깝게도 온 프레미스 배포를 수행하는 사람은 3 년 이상 소프트웨어를 지원할 수 없습니다.

그건 그냥 헛소리입니다. 실제로 업그레이드를 할 수 있습니다. 작동하지 않는 유일한 시간은 임베디드 환경이지만 임베디드 소프트웨어는 3 년의 지원 기간보다 훨씬 더 많은 문제가 있습니다.

@schmitch 무슨 말인지 잘 모르겠어요? 당연히 업그레이드 만 할 수 있지만 일부 산업의 경우 새 버전의 소프트웨어로 업그레이드하는 것은 릴리스주기와 해당 산업이 기술적으로 얼마나 진보적인지 (아니면 그렇지 않은지)에 따라 수년이 걸릴 수있는 대규모 프로젝트가됩니다.

뿡뿡

내 생각 엔 그 지원이 10 년이더라도 불평하는 사람들을 만족시키지 못할 것 같다.

사람들이 그것을 어떻게 받아들이기를 기대하고 있었는지 확신하지 못합니다.이 결정 효과는 그들이 팔린 플랫폼에 직면하여 미래가있을뿐만 아니라 최신 프로그래밍 모델에 구축 된 기존 투자가 실행되는 방향으로 향합니다. 3 년 이내에 지원되지 않는 플랫폼 (이 발표 당시). 먼저 .NET Framework 로의 마이그레이션을 통해 .NET Core 로의 신중한 단계적 마이그레이션에 대해 생각한 다른 사람들은 이제 대체 할 우발적 인 상황이 없을 위험에 직면 해 있습니다. 새로운 .NET Core 런타임 또는 버스트에서 실행됩니다.

개발자 플랫폼 자체가 목표가되어서는 안됩니다. 플랫폼에서 생성되는 가치가 기하 급수적으로 증가하고 플랫폼 자체의 가치가 있기 때문입니다. 이와 같은 맹목적인 움직임은 플랫폼의 속도를 높이기위한 리소스의 최대 효율성이 생성되는 생태계의 투자보다 더 중요하다는 것을 보여줍니다. .NET Core 2.1 비트의 잉크는 아직 건조하지 않았지만 기존 시스템 (FX의)은 생태계에 추가하는 자산과 가치 대신 최소한의 지원을 제공한다는 관점에서 이미 책임으로 취급되고 있습니다.

앞서 언급했듯이 엔터프라이즈 시스템은 빙하 속도로 이동할 수 있으며, 종종 동시에 많은 수의 직원과 고객이 지속적인 ROI를 도출하기 위해 사용해야하는 지속적인 개선을 제공하는 개발 팀의 균형을 맞출 수 있습니다. 많은 마이그레이션은 세심한 계획과 엄격한 테스트를 거쳐 "실행 중"에서 이루어져야합니다. 수년이 걸릴 수 있습니다.이 시간은 가치 창출을 선호하고 그 아래에서 지원을 받고있는 플랫폼에서 벗어나기 위해 스크램블링하는 것을 선호합니다. 대형 브라운 필드 시스템은 쉽게 폐기하고 몇 년마다 원활하게 업그레이드 할 수있는 iPhone과 같은 상품이 아닙니다. 오래되고 더 긴 시스템이 개발 중이며 더 많은 가치를 투자할수록 마이그레이션이 더 어려워집니다. 마이그레이션에서 창출되는 가치가 없다는 점을 감안할 때 흡수하기 어렵고, 리소스가 필요하고, 기회 비용을 흡수하고, 위험이 증가하며, 그들이 기대할 수있는 최선의 방법은 이전과 똑같이 실행되는 기존 시스템을 사용하여 완벽하게 마이그레이션하는 것입니다.

FX 지원에 만료 날짜가 지정 되더라도 기존 시스템이 과거에 실행되어 장애물에 부딪 히거나 마이그레이션이 불가능한 기존 시스템이있을 것입니다. 그러면 안내는 무엇입니까?

ASP.NET Core 2.1은 이미 개발되었으며, FX / .NET Core에서 ASP.NET Core를 실행하려는 노력은 이미 투자 된 막대한 비용입니다. 따라서 결정은 이미 개발 된 플랫폼 (LTS 이후)을 유지하기위한 MS 리소스와 인기있는 플랫폼을 포기하기 위해 생성 된 누적 비용, 악의 및 관성에 대한 문제로 구성되어야합니다.

나는 그때 요구되는 것을 이해하지 못한다. LTS의 라이프 사이클은 2.1이 나온 이후로 변경되지 않았습니다. .NET Core 또는 .NET Framework에 관계없이 LTS 버전으로 앱을 작성한 경우 "지원되지 않을"때까지 3 년이 걸립니다. 나는 변하지 않은 지원 측면에서 깔개가 어떻게 당신 밑에서 당겨 지는지 이해하지 못합니다. 플랫폼 업데이트를 받으려면 업그레이드해야합니다.

지금은 2.1 마지막 LTS 버전은 .NET 프레임 워크에서 지원되고 있음으로 업그레이드 할 장소가 없습니다 의미 이해하지만, LTS 지원을 확대하는의는 제공됩니다. API를하기 때문에 응용 프로그램도 이러한 육년 후 .NET 코어로 이동할 수 없다 경우 누락 된 경우 문제를 신고하여 차이를 이해할 수 있도록합니다.

나는 그때 요구되는 것을 이해하지 못한다.

이 스레드는 MS로부터 다양한 수준의 약정을 요청합니다. .NET Core와 함께 계속 개발하고, ASP.NET Core 2.1을 포기하지 않고 "느린 기차"에서 개발하고, WebForms와 동일한 수준의 지원을 유지하고, LTS를 확장합니다. . 내 선호는 기존 .NET에 대한 많은 유틸리티를 제공하면서 .NET Core 만 v3 + 만 억제하지 않는 ASP.NET Core (편집 : 더 바람직 할 것)의 호스팅 옵션으로 포기하지 않는 것입니다. FX 투자.

이제 2.1이 .NET Framework에서 지원되는 마지막 LTS 버전이라는 것은 업그레이드 할 곳이 없다는 것을 의미합니다.

즉, 지원되지 않는 플랫폼이되었다는 의미이며, 지원되지 않는 EOL 끝에 도달하기 전에 누구든지이를 용암처럼 취급하고 출격해야합니다.

• .NET Core로 이동하기위한 스테이징 플랫폼으로 사용하려고 생각한 사람은 마이그레이션이 예상보다 오래 걸리거나 종속성 중 하나라도 장애가 발생하는 경우 지원되지 않는 플랫폼에서 좌초 될 위험에 직면하기 때문에 실행 가능성이 낮은 옵션이되었습니다. 그들은 .NET Core에서 실행할 수 없습니다.
• 기업의 기존 관리 형 인프라의 .NET Framework 서버를 사용해야하는 사람은 누구나 새로운 개발 모델 및 에코 시스템 사용에 참여할 수 없으며 기존의 기존 ASP.NET 지식 / 기술의 가치가 매일 낮아지는 것을 확인해야합니다.
• 팀은 기존 .NET Framework 필수 시스템을 마이그레이션 할 수 없으며 .NET Core의 새 ASP.NET Core 프로젝트로 컨텍스트 전환이 필요합니다.
• 예산, 계획 및 투자 결정의 기준이되는 지침이 변경 되었기 때문에 어떤 조직도 계획되지 않은 마이그레이션을 강요 당하고 싶지 않습니다.

다시 한 번 그린 필드 프로젝트, .NET Core로 마이그레이션 할 수 있거나 계획 한 사람 또는 레거시 시스템을 유지 관리 할 필요가없는 사람에게는 문제가되지 않지만 기존 .NET FX 에코 시스템 및 ASP.NET Core에 영향을 미칩니다. .NET FX에서 널리 사용되는 호스팅 옵션을 더 이상 사용할 수 없기 때문에 가난 해졌습니다.

완벽한 세상에서는 모든 사람이 .NET Core에있을 것이지만이 결정으로 평가 절하되는 .NET FX에 대한 상당한 투자가 존재합니다.

API가 없어서이 6 년 후에도 애플리케이션이 .NET Core로 이동할 수없는 경우

.NET Core로 전환 할 수 없거나 전환하기를 원하지 않는 많은 사람들이 있으며, 클래식 ASP.NET과 동일한 수준의 지원을 공유하기를 원합니다 (현재 메시징이 무기한으로 제안 함).

누락 된 API는 마이그레이션을 막는 유일한 이유가 아닙니다. 예를 들어 개발자 팀이 더 이상 존재하지 않는 종속성에 의존 할 수 있고, 변경할 수없는 중요한 구성 요소이며, 안전하게 리팩토링 할 수 없습니다 (예 : 테스트 없음), 다른 .NET FX 전용 시스템과 공유되며 예산, 변경 용량이 없거나 기업의 관리 인프라와 같은 외부 요인으로 인해 .NET Framework 서버에서 실행 만 지원하는 다른 부서에서 유지 관리합니다.

이런 종류의 결정으로 .NET Standard를 종료 해 주셔서 감사합니다.

아직 Core를 대상으로하지 않는 타사 어셈블리가 많이 있기 때문에 지금까지 .NET Core를 무시했습니다.

Core를 지원할 의사가있는 많은 공급 업체는 .NET Framework에서만 사용할 수있는 네이티브 API가없는 Managed ODP.NET과 같이 핵심적인 방식으로 지원합니다.

그런 다음 이러한 종류의 결정을 내립니다.

아니요. Microsoft가 .NET Framework를 지원하기에는 너무 많은 작업이 필요하고 여러분이 시작하도록 밀어 붙인 .NET Standard를 제공 할 수 없기 때문에 .NET Core를 더 빨리 채택하지 않을 것입니다.

@davidfowl .NET Core로 마이그레이션하기 어렵게 만드는 두 가지 예를 제공 할 수 있습니다

헉

이 스레드는 MS로부터 다양한 수준의 약정을 요청합니다. .NET Core와 함께 계속 개발하고, ASP.NET Core 2.1을 포기하지 않고 "느린 기차"에서 개발하고, WebForms와 동일한 수준의 지원을 유지하고, LTS를 확장합니다. . 내 선호는 기존 .NET FX 투자에 많은 유틸리티를 제공하면서 .NET Core v3 + 만 억제하지 않는 ASP.NET Core의 호스팅 옵션으로 포기하지 않는 것입니다.

우리는 현재 LTS 지원 확장을 모색하고 있지만 ASP.NET Core에 대한 일급 .NET Framework 지원을 영원히 고려하지 않습니다 (당신이 요구하는 것입니다). WebForms와 동일한 수준의 지원을 원하는이 버전의 ASP.NET Core는 보안 수정 및 안정성 수정 만받을 수 있습니다. 최신 버전의 ASP.NET Core에 기능이 표시되면 ASP.NET Core 2.1을 사용하는 사용자의 만족도 수준은 낮아질 것입니다 (적어도 내 직감이 말해 주듯이). 범위.

누락 된 API는 마이그레이션을 막는 유일한 이유가 아닙니다. 예를 들어 개발자 팀이 더 이상 존재하지 않는 종속성에 의존 할 수 있고, 변경할 수없는 중요한 구성 요소이며, 안전하게 리팩토링 할 수 없습니다 (예 : 테스트 없음), 다른 .NET FX 전용 시스템과 공유되며 예산, 변경 용량이 없거나 기업의 관리 인프라와 같은 외부 요인으로 인해 .NET Framework 서버에서 실행 만 지원하는 다른 부서에서 유지 관리합니다.

이는 매우 일반적이며 (Microsoft 내에서도) .NET Core 2.0에서 .NET Framework dll을 참조하는 기능을 추가 한 이유는 대부분의 어셈블리가 .NET Core 용으로 컴파일되지 않은 경우에도 호환되는 것으로 밝혀 졌기 때문입니다. 이제는 작동하지 않는 것 (예 : AppDomains ...)이 있지만 API 표면을 더 추가하면 작동하지 않는 라이브러리 세트가 무의미한 숫자로 줄어들 것으로 예상합니다.

헉

이것이 .NET Standard를 어떻게 죽이는 지 모르겠습니다. .NET Standard는 ASP.NET Core보다 훨씬 큽니다. 모든 지원 .NET 플랫폼에서 작동하는 재사용 가능한 공유 라이브러리 (예 : Microsoft.Extensions *)를 만드는 것입니다.

아직 Core를 대상으로하지 않는 타사 어셈블리가 많이 있기 때문에 지금까지 .NET Core를 무시했습니다.

어느 것? 진행중인 사용자를 지원합니까 아니면 해당 어셈블리가 .NET Core를 지원하지 않습니까?

Core를 지원할 의사가있는 많은 공급 업체는 .NET Framework에서만 사용할 수있는 네이티브 API가없는 Managed ODP.NET과 같이 핵심적인 방식으로 지원합니다.

나는 이것에 동의하고 .NET Core에서 (마이크로 소프트가 제공하는 일부 라이브러리에도 불구하고) 많은 무능한 버전의 라이브러리를 보았지만 조수가 그것을 켜고 있다고 말하고 싶습니다. 그 이유 중 일부는 .NET Core 1.0에 존재하는 초기 누락 된 API 세트 때문이었습니다. 2.0 및 2.1에서는 많은 라이브러리 세트가 기능 손실없이 코어 / 표준으로 더 쉽게 포팅되는 것을 보았습니다.

@voltcode 구체적인 피드백에 감사드립니다! 이러한 유형의 호환성 문제 중 일부는 현재 (3 년 정도) .NET Core 프로젝트를 지원하는 기간 동안 사라지거나 최소화 될 것으로 예상합니다.

뿡뿡

....

아직 Core를 대상으로하지 않는 타사 어셈블리가 많이 있기 때문에 지금까지 .NET Core를 무시했습니다.

어느 것? 진행중인 사용자를 지원합니까 아니면 해당 어셈블리가 .NET Core를 지원하지 않습니까?

Oracle이 드라이버 기능의 100 %를 Core로 포팅하지 않기 때문에 우리의 경우 ODP.NET이 분명합니다.

Core를 지원할 의사가있는 많은 공급 업체는 .NET Framework에서만 사용할 수있는 네이티브 API가없는 Managed ODP.NET과 같이 핵심적인 방식으로 지원합니다.

나는 이것에 동의하고 .NET Core에서 (마이크로 소프트가 제공하는 일부 라이브러리에도 불구하고) 많은 무능한 버전의 라이브러리를 보았지만 조수가 그것을 켜고 있다고 말하고 싶습니다. 그 이유 중 일부는 .NET Core 1.0에 존재하는 초기 누락 된 API 세트 때문이었습니다. 2.0 및 2.1에서는 많은 라이브러리 세트가 기능 손실없이 코어 / 표준으로 더 쉽게 포팅되는 것을 보았습니다.

하지만 많은 고객이 그것을 보는 것은 아닙니다.

이러한 종류의 결정이 .NET의 미래에 어떤 영향을 미치는지 알기 위해 고객은 .NET Framework에서 UNIX 배포 용 Java로 응용 프로그램을 이동하기 위해 개발 노력을 지불했습니다. .NET Core 및 장애가있는 ODP.NET 구현에 베팅하는 반면 JDBC 드라이버는 .NET Framework ODP.NET 드라이버와 1 : 1 기능 패리티를 제공합니다.

다른 사람들은 다른 대체 스택을 선택할 수도 있습니다.

일반적인 엔터프라이즈 앱에 이식되지 않거나 이식 할 수없는 수많은 종속성이 있습니다.

이 문제는 HN 상단에 나타났습니다. 너희들 (@MSFT)도 거기 확인하고 싶을 것입니다. 단 1 시간 및 이미 50 개 이상의 댓글.

뿡뿡

이것이 .NET Standard를 어떻게 죽이는 지 모르겠습니다. .NET Standard는 ASP.NET Core보다 훨씬 큽니다. 모든 지원 .NET 플랫폼에서 작동하는 재사용 가능한 공유 라이브러리 (예 : Microsoft.Extensions *)를 만드는 것입니다.

재사용 가능한 공유 라이브러리가 아닌 경우 ASP.NET Core가 무엇인지 이해할 수 없습니까? 라이브러리가 현대적이고 빠르다는 추세가 .NET Standard 지원을 중단하는 것이라면 까다로운 메시지입니다. Newtonsoft.Json이 훨씬 더 빠르게 실행할 수 있다면 .NET Core 3으로 만 전환해야합니까? Autofac이 필요합니까?

나는 이것의 이유를 이해하지만, 이것이 지난번 나온 이후로 논쟁과 평가가 많이 바뀌 었는지 확신하지 못합니다! 기다릴 것 같아서 ...

저는 저의 사용 사례를 버리고 이것과 관련하여 지금 우리 가게가 어떻게 보이는지에 대한 관점을 제공 할 것입니다.

AspNetCore는 자체 호스팅 (http.sys), 웹 API 및 다양한 서비스에 대한 정적 웹 콘텐츠 측면에서 우리 스택에 놀랍 습니다. 우리는 견고했지만 우리 관점에서 많은 결함이있는 Nancy에서 왔기 때문에 약 1 년 전에 AspNetCore로 전환했습니다. 오늘날 우리는 2.x에서 모든 코드베이스를 실행하고 있습니다. 대부분의 경우 순수한 .NET Core 대상으로 완전히 이동하는 것이 좋습니다. 그러나 System.DirectoryServices 및 System.Drawing 와 같은 것에 의존하는 AspNetCore를 활용하기 위해 구축 한 많은 서비스도 있습니다. 이러한 서비스의 관점에서 .Net Framework에서 벗어나기 전에 웹 호스팅 기술을 변경할 것입니다. 안타깝게도 2 개의 서로 다른 웹 호스팅 기술을 동시에 관리하는 복잡성과 팀 규모로 인해 나머지 서비스에서 AspNetCore를 모두 공격하여 두 대상에서 더 호환되는 것을 선호합니다.

간단히 말해서-이 결정은 내가 지금 알지 못하는 것에 대해 미래의 어느 시점 (LTS가 2.x에 대해 만료 될 가능성이 있음)에 AspNetCore를 완전히 종료하도록 할 것입니다. 실제로 사용되는 AspNetCore 기능 수에 대한 사용 사례가 매우 좁기 때문에 AspNetCore를 대체 할 자체 솔루션을 작성할 가능성이 높습니다 (즉, 우리가 활용하는 기능은 오늘날 우리에게 막대한 부가가치).

다른 사람들은 다른 대체 스택을 선택할 수도 있습니다.

공평하지만 대체 스택에는 동일한 지원 정책이 있습니다. Java는 유사한 LTS 모델 (https://www.oracle.com/technetwork/java/javase/eol-135779.html)로 이동했습니다.

일반적인 엔터프라이즈 앱에 이식되지 않거나 이식 할 수없는 수많은 종속성이 있습니다.

뿡뿡

라이브러리가 아니라 프레임 워크입니다. 함께 제공되는 매우 큰 라이브러리 세트로 구성됩니다.

재사용 가능한 공유 라이브러리가 아닌 경우 ASP.NET Core가 무엇인지 이해할 수 없습니까? 라이브러리가 현대적이고 빠르다는 추세가 .NET Standard 지원을 중단하는 것이라면 까다로운 메시지입니다. Newtonsoft.Json이 훨씬 더 빠르게 실행할 수 있다면 .NET Core 3으로 만 전환해야합니까? Autofac이 필요합니까?

얼마나 까다로운 지 모르겠습니다. 97 %는 고객이 불평 할 것이기 때문에 이러한 라이브러리가 프레임 워크를 제거하지 않을 것이라고 확신합니다. 프레임 워크 제거에 대한 기준은 매우 높으며 .NET Standard 2.0에서 Microsoft.Extensions. *를 유지 한 것과 동일한 이유입니다. 나는 우리가 모든 것을 거기로 옮겼다면 그것이 모호 할 것이라는 데 동의하지만 여기서 일어나는 일은 아닙니다.

어떤면에서 이것은 .NET Core에 이미 존재하는 현실을 공식화하는 것입니다. .NET Core와 함께 ASP.NET Core를 제공합니다. .NET Core에서 ASP.NET Core는 공유 프레임 워크이며 단순한 패키지 집합이 아닙니다. 이러한 패키지는 전체 제품과 별도로 배송되지 않으므로 이러한 개별 패키지를 참조 할 때 얻을 수있는 이점은 적습니다 (패키지 목록도 작음).

뿡 빵뀨

그러나 System.DirectoryServices 및 System.Drawing과 같은 것에 의존하는 AspNetCore를 활용하기 위해 구축 한 많은 서비스도 있습니다.

NET Core https://docs.microsoft.com/en-us/dotnet/core/porting/windows-compat-pack 의 Windows 압축 팩에

간단히 말해서-이 결정은 내가 지금 알지 못하는 것에 대해 미래의 어느 시점 (LTS가 2.x에 대해 만료 될 가능성이 있음)에 AspNetCore를 완전히 종료하도록 할 것입니다. 실제로 사용되는 AspNetCore 기능 수에 대한 사용 사례가 매우 좁기 때문에 AspNetCore를 대체 할 자체 솔루션을 작성할 가능성이 높습니다 (즉, 우리가 활용하는 기능은 오늘날 우리에게 막대한 부가가치).

지원이 연장 된 경우에도 마찬가지입니까?

또한 이제는 지원되지 않는 다른 모든 기술 (AppDomains, Remoting 등)을 먼저 제거해야합니다. 그 작업을 병렬로 수행하거나 이후 단계에서 수행 할 수있는 것이 아닙니다.

2.1로 먼저 마이그레이션 할 수없는 이유는 무엇입니까?

제가 망설이는 가장 큰 이유는 3 년 지원 제한이 유지 될 수 없다는 의미입니다. 안정적인 장기 플랫폼을 가질 수있는 지점이 아니라 단기 마이그레이션 디딤돌입니다. 즉, 중간으로 진행할 위험이 없으므로 마이그레이션을 일시 중지하여 우선 순위가 높은 여러 새 기능을 구축 한 다음 마이그레이션을 완료하여 하드 블록을 찾고 모든 새로운 기능을 이전 코드베이스로 백 포트해야합니다.

제가 망설이는 가장 큰 이유는 3 년 지원 제한이 유지 될 수 없다는 의미입니다.

그렇기 때문에 @DamianEdwards가 언급 한대로 확장 지원을 제공합니다.

이 결정이 얼마나 많은 결과를 낳는 지 보여주기 위해 Blazor는 어떻습니까? netstandard를 기반으로하지 않습니까? 우리도 그것을 기대해야합니까? Blazor는 차세대 제품으로 광고되고 있습니다. 현재 netstandard에 의존하고있는 github.com/aspnet의 또 다른 것은 다음 메이저 릴리스에서이를 버리고 넷 코어로 이동할 것입니까? MSFT 제어에서 aspnetcore의 운명을 공유 할 aspnet repo 외부의 다른 계획은 무엇입니까?

뿡뿡

다른 사람들은 다른 대체 스택을 선택할 수도 있습니다.

공평하지만 대체 스택에는 동일한 지원 정책이 있습니다. Java는 유사한 LTS 모델 (https://www.oracle.com/technetwork/java/javase/eol-135779.html)로 이동했습니다.

간과하고있는 작은 세부 사항은 Java 및 기타 스택이 런타임 구현에서 부분적으로 만 구현되는 표준이 필요없이 .NET Framework 및 .NET Core와 달리 버전간에 여전히 호환된다는 것입니다.

그만한 가치가 있기 때문에 저는 현재 회사의 첫 번째 ASP.Net 코어 앱을 배포하는 작업을하고 있습니다. 우리는 .NET Framework에 정말 많은 투자를하고 있으므로 .NET Core가 아닌 .NET Framework에서 ASP.Net Core를 사용하는 것이 확실한 접근 방식이었습니다.

이제 나는 나중에 많은 고통을 겪게 될지 궁금합니다.

여기에는 상호 연결된 많은 문제가 있습니다. ASP.Net 코어는 .NET Framework에서만 실행되는 것이 아닙니다. 과거에 ASP.Net Core에 대한 Microsoft의 메시지는이를 명확하게 나타내지 못했습니다.

마찬가지로 많은 .NET 개발자는 .NET Framework가 주요 구현이며, 물론 환경 별 API를 제외하고는 일반적으로 나머지는 하위 집합이라는 생각에 익숙합니다. 이것은 .NET Core에서 변경되었지만, 많은 사람들은 일반적으로 "완전한".NET Framework가 거의 .NET Core가 수행하는 모든 작업을 지원할 것이라는 인상을 받았습니다 (분명히 도구 및 플랫폼 간 호환성 제외). 더 느린 시간 척도에서 꼬임이 해결되기를 기다렸다가 포함합니다.

최근 몇 가지 중요한 기능이 .NET Framework에 적용되지 않을 수 있다는 많은 제안이있었습니다. (예 : Span의 호환성 위험.NET Framework 4.8에서 구현하기에는 너무 심각하다고 간주되는 유형은 이러한 위험이 4.9에서 더 낮아지는 이유가 무엇입니까? 유사한 우려가 기본 인터페이스 방법을 둘러싼 것으로 보입니다.) 이것은 많은 개발자가 만족하지 않는 주요 패러다임 전환입니다!

바로이 스레드의 메시지는 Microsoft가 .NET Framework를 레거시 기능으로 간주하기 시작했음을 시사합니다. 실제로 보안 수정 만받을 때까지 시간이 지남에 따라 개발 관심이 줄어들 것입니다.

Microsoft는 역사적으로 그들이 적극적으로 개발하고있는 것이 무엇인지, 산발적 인 새로운 기능만으로 유지하고있는 것이 무엇인지, 그리고 실제로 보안 및 안정성 픽스 만 제공 할 계획이 무엇인지에 대해 분명히하는 것에 대해 끔찍했습니다. .NET Framework가 현재 두 번째 범주에 속할뿐만 아니라 세 번째 범주에 속하는 것과 거의 비슷하다고 생각합니다.

정말 짜증납니다. .NET Core에는 일부 엔터프라이즈 애플리케이션에 적합하지 않은 몇 가지 문제가 있습니다. 지속적으로 개발되는 애플리케이션에서 사용하는 것이 좋습니다. 그러나 예를 들어 대부분의 기업에는 배포되는 일부 애플리케이션이 있으며 몇 년에 한 번만 터치됩니다. .NET Core에서는 제대로 작동하지 않습니다. 여기서 기업은 대부분의 릴리스에 대해 짧은 지원 주기로 어려움을 겪어야합니다. 그리고 Windows에는 보안 업데이트 등을 받기 위해 새 패치 릴리스를 자동으로 설치하는 메커니즘이 현재 존재하지 않습니다.

따라서 새로운 프로젝트를 시작하는 기업은 무엇을해야할지 고민하게됩니다. 보다 엔터프라이즈 친화적 인 .NET Framework는 더 이상 사용되지 않을 것이라는 분명한 징후를 보이고 있으므로 새로운 개발에서는 피하는 것이 더 좋습니다. 반면에 .NET Core는 존재하지만 엔터프라이즈 친화적이지 않습니다.

그래서 이것은 기본적으로 폭언이되었지만, 이것이 많은 개발자들이 갖고있는 우려를 더 잘 보여주기를 바랍니다.

뿡뿡

그러나 System.DirectoryServices 및 System.Drawing과 같은 것에 의존하는 AspNetCore를 활용하기 위해 구축 한 많은 서비스도 있습니다.

NET Core https://docs.microsoft.com/en-us/dotnet/core/porting/windows-compat-pack 의 Windows 압축 팩에

호환성 팩이이 사용 사례를 지원하는지 몰랐습니다. 이상적으로는 모든 것을 .NET Core로 옮기고 싶습니다. 이것은 정말 좋은 대답 인 것 같습니다 (처음에는 간과했을 수도 있음). 우리는 서비스 호스팅을 Linux / OSX로 옮길 계획이 없으므로 이러한 부분이 우리에게 잘 맞을 수 있습니다.

지원이 연장 된 경우에도 마찬가지입니까?

지원 측면에서-이처럼 광범위한 문제와 관련된 다른 모든 제약을 고려할 때 2021 년까지 2.x의 LTS가 합리적이라고 생각합니다.

내가 지금 이해하고있는 바에 따르면 .NET Framework 프로젝트를 검토하고 .NET Core 프로젝트로 변환 할 기회가 생기면 AspNetCore 3.x로 업그레이드하는 것이 편할 것입니다 (필요에 따라 호환성 팩 사용).

후속 조치에 감사드립니다.

저는 고압 프로젝트에서 15 년 동안 .NET (대부분 C #)으로 작성했습니다. 저는 수년을 낭비했고 고객은 오버 엔지니어링 된 프레임 워크를 사용하여 시간을 낭비했습니다. .NET Core의 개념이 마음에 들었습니다. 나에게 그것은 NodeJS 프로젝트를 작성하는 속도 였지만 놀라운 .NET 생태계 (모든 지방 포함)에서였습니다. 불행히도 그것은 그 약속에 실패했지만 여전히 (이 새로운 발표에도 불구하고) 피비린내 나는 사용하기에는 너무 복잡합니다. 지난 3 년 동안 저는 NodeJS에서 빌드했습니다. 미안합니다. 비교가 안됩니다. 더 간단하고 사용하기 쉽게 만들면 다시 광범위한 개발자 커뮤니티를 끌어들일 수 있습니다.

Windows에 배포 된 .NET Framework를 대상으로하는 ASP.NET Core 2.1 앱에서 실행할 수있는 하드 컴파일 된 바이너리 .NET Framework 종속성 (소스 코드가없는 공급 업체 항목)이있는 프로젝트의 경우 프로젝트에 Windows 호환 기능 팩을 추가하여 계속 작동합니다. 하드 종속성이 팩에서 제공하는 유형을 참조하는 경우 코어 3.0?

안타깝게도 System.Drawing, GDI 및 때때로 레지스트리 (!)에 의존하는 매우 성숙한 상용 라이브러리의 거대한 생태계가 있습니다. 이제 2.1에서만 작동하고 3 년 동안 만 지원된다면 이는 일부 기업에서 Core 채택을 중단 할 수있는 문제입니다.

.NET Core는 시작점에 도달하기 위해 완전한 원을 만들고 있습니다.

다른 접근 방식을 제안합니다. .NET Framework에 .NET Core의 유용한 기능을 통합 한 다음 .NET Core를 실험적인 막 다른 분기로 완전히 제거합니다. 따라서 세분화를 중지하고 기술을 절약하여 고객의 더 큰 이익을 얻습니다. 다소 논란의 여지가 있지만 제품 측면에서 훨씬 더 건전한 접근 방식입니다.

뿡뿡

.NET Framework에서 실행되는 ASP.NET Core는 영구적 인 것이 아니라 항상 디딤돌로 사용되었습니다.

그것은 전혀 사실이 아닙니다. ASP.NET Core의 메시징은 항상 .NET Core 와 .NET Framework 모두에서 지원된다는 것입니다. .NET Core의 가장 초기 발표 에도 ASP.NET Core 용 두 플랫폼 (이전 ASP.NET 5)이 언급되어 있습니다.

.NET Standard를 보여주는 잘 알려진 에는 "ASP.NET Core에서 .NET Framework를 대상으로하는 지원을 제거 할 계획이 없습니다 . .

그렇습니다.이 결정이 지금 까지 바뀌 었다는 것은 분명합니다. 그러나 그것이 항상 그저 거짓말이거나 Microsoft가 수년에 걸쳐 수행 한 매우 나쁜 의사 소통 이라고 말하는 것은 분명합니다.

ASP.NET Core라고도합니다.

오 어서. 이 모든 시간이 지나면 나와 같은 사람들은 .NET Core와 ASP.NET Core가 동일 하지 않기 때문에 사람들과 싸워야했습니다. 여기서 이점을 위해 비슷한 이름을 사용하지 마십시오. 그것은 공정하지 않습니다. "Core"로 이름이 변경된 것은 확실히 .NET Core에 명시 적으로 연결하기위한 것이 아닙니다. 또한 EF Core에는 "Core"도 있지만 netstandard에서 계속 실행되므로 인수가 작동하지 않습니다.

확장 된 LTS 지원이 필요한 곳입니다. 애플리케이션이 6 년 후에도 .NET Core로 이동할 수없는 경우 […]

이게 지금부터 어디에서 왔습니까? 지난번에 메시지는 여전히 " '확장 지원'LTS 제공을 조사하고 있습니다.

헉

간과하고있는 작은 세부 사항은 Java 및 기타 스택이 런타임 구현에서 부분적으로 만 구현되는 표준이 필요없이 .NET Framework 및 .NET Core와 달리 버전간에 여전히 호환된다는 것입니다.

공평하지만 그게 더 나은 지원과 무슨 관련이 있는지 이해가 안 돼요. 라이브러리 (특정 시점 문제)와 엔터프라이즈 지원 (지원주기가 길어짐)이 적기 때문에 Java로 전환하는 것이 더 좋을 것이라고 주장했습니다.

안녕하세요.

바로이 스레드의 메시지는 Microsoft가 .NET Framework를 레거시 기능으로 간주하기 시작했음을 시사합니다. 실제로 보안 수정 만받을 때까지 시간이 지남에 따라 개발 관심이 줄어들 것입니다.

Microsoft는 역사적으로 그들이 적극적으로 개발하고있는 것이 무엇인지, 산발적 인 새로운 기능만으로 유지하고있는 것이 무엇인지, 그리고 실제로 보안 및 안정성 픽스 만 제공 할 계획이 무엇인지에 대해 분명히하는 것에 대해 끔찍했습니다. .NET Framework가 현재 두 번째 범주에 속할뿐만 아니라 세 번째 범주에 속하는 것과 거의 비슷하다고 생각합니다.

https://blogs.msdn.microsoft.com/dotnet/2018/10/04/update-on-net-core-3-0-and-net-framework-4-8/ 참조

Windows에 배포 된 .NET Framework를 대상으로하는 ASP.NET Core 2.1 앱에서 실행할 수있는 하드 컴파일 된 바이너리 .NET Framework 종속성 (소스 코드가없는 공급 업체 항목)이있는 프로젝트의 경우 프로젝트에 Windows 호환 기능 팩을 추가하여 계속 작동합니다. 하드 종속성이 팩에서 제공하는 유형을 참조하는 경우 코어 3.0?

예, 바이너리와 호환됩니다.

안타깝게도 System.Drawing, GDI 및 때때로 레지스트리 (!)에 의존하는 매우 성숙한 상용 라이브러리의 거대한 생태계가 있습니다. 이제 2.1에서만 작동하고 3 년 동안 만 지원된다면 이는 일부 기업에서 Core 채택을 중단시킬 수있는 문제입니다.

이 스레드에서 여러 번 언급했듯이. .NET Core 프로젝트에서 .NET Framework에 대해 컴파일 된 종속성을 직접 참조하는 기능을 추가했습니다.

@poke 메시지에 대한 말이 맞습니다. 전혀 명확하지 않았습니다. 제 실수입니다.

이게 지금부터 어디에서 왔습니까? 지난 번에 메시지는 여전히 " '확장 지원'LTS 제공을 조사하고 있습니다"였습니다. 지금이게 진짜이고 우리는 6 년을 받나요?

나는 6 개를 구성했는데 우리가 제공 할 때 지원이 얼마나 연장 될지 모르겠습니다.

.NET Core는 항상 .NET Framework 를 대체 할 것이었지만 (원래 .NET Framework 5가 될 예정 이었음) 재 작성이 너무 야심적이어서 이제 데스크톱 앱을 지원하는 데 유용하게 사용되었습니다.

와우, 여기에 재미있는 댓글이 많이 있습니까? 기사를 읽지 못하는 사람들이 산재 해있는 잘못된 괴상한 분노가 많이있는 것 같습니다.

대기하다

@edandersen 이 외부 dll에서 ApiPort 를 실행
Windows 호환성 팩은 이미 system.drawing 및 레지스트리에 대한 기능을 제공합니다. 이미 .NET Core에서 이러한 것들을 실행하려고 했습니까? System.Drawing은 mono의 libgdiplus를 사용하여 * nix에서도 작동합니다. 이를 통해 Windows가 아닌 시스템에서 ClosedXML을 사용하여 Excel 파일로 작업 할 수 있습니다.

우리 회사의 "최근"응용 프로그램에 대한 가장 큰 .NET Framework 종속성은 WCF 기능입니다.
.NET Core WCF 클라이언트 라이브러리가 개선되고 있습니다. 우리가 사용하는 일부 서비스에서 얼마나 잘 작동하는지 현재 상태를 확인하지 않았지만 과거에는 일부 서비스와 대화 할 수 없었습니다. 그러나 누락 된 기능은 이미 문제 목록에있었습니다. 반면 간단한 서비스는 잘 작동합니다!
반면에 .NET Core에서 SOAP 서비스를 호스팅하기위한 "드롭 인"대체품은 없습니다. 이는 일부 애플리케이션을 .NET Core로 마이그레이션하는 것을 차단합니다 (하지만 언급했듯이 필요 없음).
최근 ASP.NET Core 애플리케이션의 경우 WCF 서비스 만 호스팅 한 다음 HTTP / JSON을 통해 ASP.NET Core 애플리케이션으로 전달하는 추가 ASP.NET 프록시 웹앱을 만들었습니다. 그다지 예쁘지 않고 배포 복잡성을 추가하지만 일부 통합 지점을 허용합니다.

.NET Core에서 WCF 호스팅 기능을 구성하는 데 어려움이 있다는 점을 감안할 때 실제로 .NET Core에서 WCF 호스팅 기능을 원한다고 말하는 것이 아닙니다. SOAP 서비스를 호스팅하고 WSDL을 생성하는 몇 가지 옵션은 멋질 것입니다. 나는 이미 그것을 시도하고있는 몇몇 OSS 라이브러리를 보았다. 아마도 이것으로 충분할 것입니다.

@ davidfowl

공평하지만 그게 더 나은 지원과 무슨 관련이 있는지 이해가 안 돼요. 라이브러리 (특정 시점 문제)와 엔터프라이즈 지원 (지원주기가 길어짐)이 적기 때문에 Java로 전환하는 것이 더 좋을 것이라고 주장했습니다.

요점은 Java LTS 버전도 3 년이지만 모든 주요 구현 간의 호환성은 금이며, 이는 여러분이 여기에서 기꺼이 버릴 수있는 것입니다.

이 전체 .NET Framework, .NET Core, Xamarin, .NET Standard 실수는 WinDev 대 DevTools의 좋은 예전처럼 보이기 시작했습니다. .NET 팀 내부에서 변경 사항이 있습니다.

따라서 당연히 고객은 내부 팀이 로드맵 기능을 위해 싸우고있는 것처럼 보이지 않는 플랫폼으로 이동할 의향이 있습니다.

이러한 결정은 자신감을 불러 일으키지 않습니다.

이것은 특히 현재 기후의 맥락에서 .NET 팀의 실수처럼 느껴집니다!

Java를 언급하는 사람들을 위해 최근에 무슨 일이 일어나고 있는지 실제로 보셨습니까? 안드로이드에서 구글을 사용하는 것에 대한 절대적으로 미친 소송과 그들의 최신 라이선싱 헛소리 사이에서 오라클의 행동은 지속적으로 그것이 번창하기를 바라는 것이 아니라 원치 않는 제품을 죽이려는 회사의 행동으로 보입니다!

지금은 마이크로 소프트가 정반대의 행동을하고 있다는 강력한 마케팅을 통해이를 활용할 수있는 완벽한시기이며 .NET은 건전하고 안정적이며 안전한 개발 옵션을위한 곳입니다. 대신, 우리는 이것을 얻습니다

안녕하세요.

두 환경에서 작업하는 우리는 실제로 Oracle 작업에 감사합니다.
Java로 해왔습니다.

프로덕션에서 Java를 거의 사용하지 않고 Oracle을 경멸하는 사람들은
그들에 대한 증오 논쟁에서 길을 잃었습니다.

Android와 관련하여 저는 Google로서 소송을 전적으로지지합니다.
Java 플랫폼을 포크하여 Microsoft가 실패한 곳에서 성공했습니다.
J ++로. Maven Central의 임의의 JAR이 실제로 Android에서 작동하도록 보장되는 날을 기대합니다.

.NET의 경우 지속적인 재부팅에 질리기 시작했습니다.
Microsoft 플랫폼을 대상으로하는 방법.

전체 WinRT, UAP, UWP, .NET 네이티브 드롭 F #, XNA, Core 1.0이 남았습니다.
신 포도가 많고 최근의 결정이 상황을 더 좋게 만들지는 않습니다
사무용 겉옷.

.NET은 제가 가장 좋아하는 플랫폼이므로 더 이상 망치지 마십시오.

헉

이제 2.1이 .NET Framework에서 지원되는 마지막 LTS 버전이라는 것은 업그레이드 할 곳이 없다는 것을 의미합니다.

즉, 지원되지 않는 플랫폼이되었다는 의미이며, 지원되지 않는 EOL 끝에 도달하기 전에 누구든지이를 용암처럼 취급하고 출격해야합니다.

이것이 제가 전체 토론에서 정말로 이해하지 못하는 점 중 하나입니다. 보안 수정 (확장 된 LTS 지원으로 다룰 수 있음) 외에 LTS 지원에서 실제로 무엇을 얻습니까?

주류 LTS 지원에는 다음 두 가지가 있습니다.

• 보안 수정
• 중요한 버그 수정

이전 버전 (보안 픽스)의 대부분은 Windows Update를 통해 패치됩니다 (.NET Framework를 대상으로하기 때문에). 따라서 남은 보안 및 중요한 버그 수정 만 ASP.NET Core 자체에 있습니다.

지원이 2018 년에 종료된다는 것을 이미 알고 있다고 가정 해 보겠습니다. 2020 년에 새로운 프로젝트를 시작하는 사람은 아무도 없을 것이므로 (imho) 2021 년 (또는 2026 년 또는 연장 지원이 의미하는 기간) 이후에 중요한 버그를 발견 할 가능성은 거의 없습니다. 되려고).

그것은 단지 보안 버그를 열어두고 LTS로 덮는 것이 합리적입니다.

이전 답변에서 TLS 1.4 등을 언급하는 것을 보았습니다. 어쨌든 새로운 기능이므로 Java에서도 동일하므로 LTS에서 다루지 않을 것입니다 (Java 6에만 TLS 1.0 지원-TLS 1.1 만 포함) 비공개 업데이트는 Oracle의 확장 지원 가입자에게만 제공됩니다.

• .NET Core로 이동하기위한 스테이징 플랫폼으로 사용하려고 생각한 사람은 마이그레이션이 예상보다 오래 걸리거나 종속성 중 하나라도 장애가 발생하는 경우 지원되지 않는 플랫폼에서 좌초 될 위험에 직면하기 때문에 실행 가능성이 낮은 옵션이되었습니다. 그들은 .NET Core에서 실행할 수 없습니다.
  하지만 이제 .NET Framework에서 ASP.NET Core와 함께 사용할 수 있지만 .NET Framework + 호환성 패키지의 ASP.NET Core에서는 사용할 수없는 API는 무엇입니까?

이 점을 확인하고 누락 된 API를 향후 호환성 패키지와 함께 제공하거나 .NET Core에 추가하여 .NET Core를 대상으로하는 경우에도 .NET Framework 라이브러리를 참조 할 수 있도록하는 것이 더 중요한 점이라고 생각합니다.

.NET Core 이후 .NET Standard 또는 .NET Core에서 사용 가능한 API 만 사용 하는 한 .NET Core 프로젝트의 모든 .NET Framework 라이브러리를 참조 (및 사용할)

따라서 라이브러리 작성자가 netstandard / netcoreapp을 대상으로 라이브러리를 업데이트 할 필요가 없습니다.

이 라이브러리가 특정 버전의 .NET Core에서 사용할 수없는 호환되지 않는 API를 사용하는 경우 보고서를 표시하는 nuget.org의 각 nuget 패키지 옆에있는 기능 / 링크를 통해 Microsoft가 NuGet 웹 페이지 / 라이브러리를 확장하면 도움이 될까요?

예를 들면

'Company.Example.MyLib'는

• .NET Core 2.1 : 부분 지원 (상세 보고서)-세부 보고서에 작동하는 Apis와 작동하지 않는 Apis가 표시되는 위치
• .NET Core 3.0 :; 완전 지원

.NET 이식성 분석기를 실행하여 가능해야합니까? (IL 코드를 분석하고 안전한지 확인하기 위해 호출하는 다른 API를 확인하여) 호출하기에 안전한 공용 API 목록을 추가하면 보너스가 될 것입니다.

이렇게하면 개발자가 프로젝트에 필요한 특정 라이브러리가 .NET Core에서 실행될 수 있는지 여부를 명시 적으로 호출하지 않더라도 쉽게 결정할 수 있습니까?

지금은 API가 지원되는지 여부를 파악하는 것이 다소 고통 스럽습니다. 라이브러리가 필요하고 분석기를 로컬에서 실행합니다. 많은 개발자는 공식적으로 netstandard를 지원하지 않는 일부 라이브러리를 사용할 수 있다는 것을 모를 수 있습니다.

@davidfowl @terrajobst 그것이 NuGet에 가능한 추가일까요? -NET Core 호환 .NET Framework 라이브러리의 검색 가능성을 더 쉽고 빠르게 만들려면?

• 기업의 기존 관리 형 인프라의 .NET Framework 서버를 사용해야하는 사람은 누구나 새로운 개발 모델 및 에코 시스템 사용에 참여할 수 없으며 기존의 기존 ASP.NET 지식 / 기술의 가치가 매일 낮아지는 것을 확인해야합니다.

이는 .NET Framework 지원 여부에 대한 논쟁이 아닙니다. 레거시 종속성에 갇혀 있고 .NET Core (호환성 팩 또는 .NET Framework 라이브러리 포함)로 마이그레이션 할 수없는 사람들은 이후에도 수행 할 수 없습니다. 그게 어떤 변화를 가져올까요?

그러나 모 놀리 식 애플리케이션의 일부는 분할되어 점차 레거시 애플리케이션의 일부를 새 애플리케이션으로 이동할 수 있지만 이는 다른 이야기입니다.

• 예산, 계획 및 투자 결정의 기준이되는 지침이 변경 되었기 때문에 어떤 조직도 계획되지 않은 마이그레이션을 강요 당하고 싶지 않습니다.

이익이 투자보다 비중이 크다면 왜 안됩니까? 즉, 대가로 큰 가치를 제공하거나 성능을 크게 향상시키는 고유 한 기능이있는 경우.

그렇지 않은 경우 이전 시스템을 유지하십시오. 소프트웨어 개발은 ​​영원히 이랬습니다. Fortune과 Cobol에서 개발 된 소프트웨어를 실행하는 회사는 여전히 있습니다.

.NET Core로 전환 할 수 없거나 전환하기를 원하지 않는 많은 사람들이 있으며, 클래식 ASP.NET과 동일한 수준의 지원을 공유하기를 원합니다 (현재 메시징이 무기한으로 제안 함).

누락 된 API는 마이그레이션을 막는 유일한 이유가 아닙니다. 예를 들어 개발자 팀이 더 이상 존재하지 않는 종속성에 의존 할 수 있고, 변경할 수없는 중요한 구성 요소이며, 안전하게 리팩토링 할 수 없습니다 (예 : 테스트 없음), 다른 .NET FX 전용 시스템과 공유되며 예산, 변경 용량이 없거나 기업의 관리 인프라와 같은 외부 요인으로 인해 .NET Framework 서버에서 실행 만 지원하는 다른 부서에서 유지 관리합니다.

하지만 어떤 의존성? 이러한 외부 종속성이 사용하는 API를 식별하려면 구체적인 예제가 필요합니다. 이 API는 .NET Core 3.0 또는 .NET Core의 향후 버전에 추가 될 수 있습니다.

이를 통해 .NET Core 프로젝트에서이 .NET Framework 라이브러리를 사용할 수 있습니다. 유일한 문제는 .NET Framework 라이브러리가 .NET Standard 또는 .NET Core에서 사용할 수없는 API를 사용하는 경우입니다. 그러나 해당 피드백을 수정하려면 라이브러리를 식별해야합니다.

헉

뿡뿡

다른 사람들은 다른 대체 스택을 선택할 수도 있습니다.

공평하지만 대체 스택에는 동일한 지원 정책이 있습니다. Java는 유사한 LTS 모델 (https://www.oracle.com/technetwork/java/javase/eol-135779.html)로 이동했습니다.

간과하고있는 작은 세부 사항은 Java 및 기타 스택이 런타임 구현에서 부분적으로 만 구현되는 표준이 필요없이 .NET Framework 및 .NET Core와 달리 버전간에 여전히 호환된다는 것입니다.

이는 이후의 Java 에디션에서도 마찬가지입니다. Java 9는 런타임을 모듈화하기위한 첫 번째 단계를 추가했으며 이는 주요 변경 사항 입니다. 버전 9에서는이 기능이 기본적으로 비활성화되어 있지만 향후 버전에서는 플래그가 기본적으로 활성화 (또는 끌 수 없음)되며 이로 인해 레거시 응용 프로그램이 크게 변경됩니다.

예를 들어 일부 리플렉션 마법을 통해 내부 API를 사용하는 많은 라이브러리의 경우 이러한 변경으로 인해 중단

@ TsengSR

Java 9에 도입 된 주요 변경 사항에도 불구하고 모든 관련 Java 프레임 워크의 100 %가 Java 9, 10 및 11에서 작동하며, .NET Framework, UWP 및 Core에서는 확실히 그렇지 않습니다.

공식적인 크로스 플랫폼 GUI 프레임 워크가 두 개 있지만 Core에 대한 공식 로드맵은 아직 얻지 못했다고 상상해보십시오!

헉

@ TsengSR

Java 9에 도입 된 주요 변경 사항에도 불구하고 모든 관련 Java 프레임 워크의 100 %가 Java 9, 10 및 11에서 작동하며, .NET Framework, UWP 및 Core에서는 확실히 그렇지 않습니다.

공식적인 크로스 플랫폼 GUI 프레임 워크가 두 개 있지만 Core에 대한 공식 로드맵은 아직 얻지 못했다고 상상해보십시오!

죄송합니다. 그건 말도 안됩니다.

--add-opens 가 호출되지 않는 한 이러한 모듈에 반영되는 것을 방지하는 Java 9의 내부 모듈입니다 (그리고 iirc는 사람들이 레거시 애플리케이션을 계속 실행하고 나중에 몇 가지 버전을 제거 할 수 있도록 항상 임시 솔루션이어야 함).

Java 9가 곧 실현 될 때 드라마와 똥을 놓친 경우에 대한 응답은 다음과 같습니다.
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012673.html

전체 에코 시스템이 한 번에 모듈 식 Java 플랫폼으로 마이그레이션 할 수 있도록
보다 편안한 속도로 저는 불법적 인 반사 접근을 허용 할 것을 제안합니다.
JDK 9에서 기본적으로 클래스 경로의 코드에서 허용하지 않으려면향후 릴리스.

다른 것, Java EE 9 deprecated JAX-WS는 deprecated되었고 Java EE 11에서 제거 될 예정입니다. 이는 대략 WCF와 동일한 것으로 볼 수 있습니다. 이를 사용하는 적용 가능한 모든 것은 마이그레이션 프로세스 인 다른 것으로 대체하지 않고는 최신 버전으로 이식 할 수 없습니다. .NET Framework의 ASP.NET Core에서 .NET Core의 ASP.NET Core로 (또는 ASP.NET에서 ASP.NET Core @ .NET core로) 마이그레이션하는 것과 거의 다르지 않습니다.

https://www.oracle.com/corporate/features/understanding-java-9-modules.html

향상된 플랫폼 무결성 —Java 9 이전에는 앱의 클래스에서 사용하기위한 것이 아닌 플랫폼의 많은 클래스를 사용할 수있었습니다. 강력한 캡슐화를 통해 이러한 내부 API는 플랫폼을 사용하는 앱에서 실제로 캡슐화되고 숨겨집니다. 이로 인해 코드가 내부 API에 의존하는 경우 레거시 코드를 모듈화 된 Java 9로 마이그레이션하는 데 문제가 발생할 수 있습니다.

이러한 내부 API를 사용하거나 (오래된 라이브러리 중 일부가 사용했거나 Java 9가 출시 될 때 다시 사용했던 sun.* 네임 스페이스의 모든 것을 포함하여) 또는 종속 된 타사 라이브러리를 사용하는 모든 애플리케이션 이 API 또는 다른 라이브러리에서이 주요 변경 사항이 적용될 수 있습니다. 문제는 .NET Framework 및 .NET Core에서와 같이 API가 호출되는지 여부를 라이브러리에서만 볼 수 없다는 것입니다.

쫑끼리

--add-opens가 호출되지 않는 한 이러한 모듈에 반영되는 것을 방지하는 Java 9의 내부 모듈입니다 (그리고 iirc는 사람들이 레거시 애플리케이션을 계속 실행하고 나중에 몇 가지 버전을 제거 할 수 있도록 항상 임시 솔루션이어야 함).

또는 클래스 경로 모드를 사용하고 모듈이라는 혼란을 건너 뛸 수 있습니다. 해당 모드는 가까운 미래에 유지됩니다. 그리고 모듈에 들어가면 다른 모듈의 패키지에 대한 종속성을 명시 적으로 선언 할 수 있습니다.

다른 것, Java EE 9 deprecated JAX-WS는 deprecated되었고 Java EE 11에서 제거 될 예정입니다. 이는 대략 WCF와 동일한 것으로 볼 수 있습니다.

모든 J2EE는 더 이상 사용되지 않으며 Java 11에서 제거되었습니다. 그러나 J2EE는 구현이 아닌 인터페이스 만 정의합니다. J2EE를 계속 사용하려면 종속성을 전환하기 만하면됩니다. 어쨌든 모든 구현은 분리되었으며 Java 11에서 잘 작동합니다.

이러한 내부 API (일부 이전 라이브러리에서 사용했거나 Java 9가 출시 될 때 다시 사용했던 sun. * 네임 스페이스의 모든 것 포함)를 사용하거나이 API에 의존하는 타사 라이브러리를 사용하는 모든 애플리케이션 또는 다른 라이브러리에이 주요 변경 사항이 적용될 수 있습니다.

항상 그렇습니다. 문서화되지 않은 API였습니다. 아무도 그것들을 사용해서는 안되며 언제라도 변경되거나 제거 될 수 있습니다. 일반적으로 (ab) 사용되는 많은 내부 API는 기존 프로그램을 중단하지 않도록 남겨져 향후 적절한 API로 마이그레이션 할 수 있습니다.

일부 API는 더 이상 사용되지 않지만 JRE 또는 Java 에코 시스템 전체가 아닌 특정 API에 대해 이야기하고 있습니다. 이러한 API에서 새로운 공식 및 문서화 된 API로 이동하는 데 필요한 작업은 일반적으로 최소화됩니다.

그리고 Java는 항상 .NET보다 이전 버전과의 호환성을 끊는 데 더 많은 의지를 가지고 있습니다. 예를 들어 Java에서 var 라는 유형을 선언하는 것은 이제 로컬 추론을 위해 예약되어 있기 때문에 불법입니다. Java에서 _ 변수의 이름은 폐기 / 와일드 카드로 예약되어 있기 때문에 불법입니다. C #은 이전 버전과의 호환성을 유지하기 위해 두 경우 모두 정반대의 결정을 내 렸습니다.

오해하지 마십시오. Java는 자체 엉망입니다. 모듈 사이에서 Java 8에 대한 지원이 거의 끝 나가고 Oracle이 JRE 라이선스에 탐욕스러워지는 Microsoft는 사람들을 전환 할 수있는 엄청난 기회가 있습니다. 그러나 마이크로 소프트가 향후 플랫폼의 지원과 발전에 대해 혼합 된 메시지를 내놓는다면 그것은 일어나지 않을 것입니다.

쫑끼리

이것이 제가 전체 토론에서 정말로 이해하지 못하는 점 중 하나입니다. 보안 수정 (확장 된 LTS 지원으로 다룰 수 있음) 외에 LTS 지원에서 실제로 무엇을 얻습니까?

업그레이드 할 곳 이없이 끝나게 될 LTS에 대한 똑딱 거리는 시계가 있는데, 이는 Java LTS가 비교를 통해 던져 질 때 요점을 드러내고 있습니다. Java 및 .NET Framework를 사용하면 이전 버전과의 호환성에 중점을 둔 기존 시스템을 최소한의 노력으로 업그레이드 할 수 있다는 확신이 항상있었습니다. 더 이상 업그레이드 경로가 없었기 때문에 기존 시스템은 새 런타임으로 마이그레이션하거나 지원되지 않는 플랫폼에서 계속 실행해야하는 문제에 직면 해 있습니다. 여러 가지 이유로 .NET Core로 마이그레이션하는 것이 실행 불가능한 시스템이있을 것이며 지원되지 않는 플랫폼에서 중요한 비즈니스 기능을 계속 실행할 수 있습니다.

이 결정의 가장 가까운 비유가 Java 영역에서 무엇인지 확실하지 않아 기존 시스템이 GraalVM에서 실행되도록 강제로 마이그레이션 할 수 있습니다. 많은 일이 작동하고 일부는 작동하지 않으며 시스템이 클수록 호환성을 예측할 수 있다는 확신이 떨어집니다. 마이그레이션이 물리적으로 시도 될 때까지 문제가 발생합니다.

.NET Core 로의 마이그레이션을 가능하게하기 위해 많은 작업이 수행되었다는 데 동의하지만 마이그레이션을 방지 할 외부 요인 (MS 제어 외부 포함)이 여전히 남아 있으며이 결정은 내려 질 것입니다. ASP.Core / FX는이 발표 이전에 비해 마이그레이션 가능성이 낮았습니다. ASP.Core / FX는 인기있는 마이그레이션 경로 였지만, 많은 마이그레이션을 방지 할 미래의 지원되지 않는 플랫폼으로의 마이그레이션을 포함하는 전체 마이그레이션 전략을 권장하는 것은 더 이상 현명하지 않을 것입니다. 더 많은 기존 시스템 / 개발자가 정체 된 클래식 ASP.NET에 남아있게됩니다.

이전 버전 (보안 픽스)의 대부분은 Windows Update를 통해 패치됩니다 (.NET Framework를 대상으로하기 때문에). 따라서 남은 보안 및 중요한 버그 수정 만 ASP.NET Core 자체에 있습니다.

조직은 향후 버그 또는 보안 문제가 지원을 위해 지정된 라이브러리에서만 발생하기를 바라며 부분적으로 지원되는 플랫폼에 기업을 기반으로하는 것을 원하지 않습니다. ASP.Core / FX가 향후 보안 취약성이 해결 될 나머지 .NET Framework와 동일한 수준의 지원을 받으면 먼 길을 갈 것입니다.

현재 MS만이 업데이트 된 ASP.Core NuGet 패키지를 패치하고 릴리스 할 수 있으며, 상호 연결되는 종속성 트리가 OSS 인 것은 그들이받는 2.1 PR (LTS 이후)이 검토, 승인 및 승인되지 않는 한 여기에서 많은 도움이되지 않을 것입니다. 출시되었습니다.

결국 모든 세부 사항을 논의한 후에도 여전히 중요한 궁극적 인 질문은 다음과 같습니다.

ASP.Core / FX에서 기존 시스템을 계속 실행할 수 있습니까?

기술적으로는 가능할 것이지만 미래의 중요한 버그 / 보안 취약성이 해결 될 것이라는 보장 없이는 권장 사항이 NO가되어 외부 생태계가이 결정의 고통을 흡수하게됩니다.

ASP.NET Core가 .NET Core 전용 일 경우 전체 .NET Standard에 대해 어떻게 생각해야합니까?

마이크로 소프트 자체가 (의심 할 바없이 타당한) 이유 때문에 그것에 베팅하지 않는다면, 왜 우리가해야할까요?

최상급의 최첨단 .NET Core 전용 라이브러리와 "더 단순하고"덜 고급 인 .NET Standard 라이브러리가 있습니까?

이것은 비 .NET-Core 플랫폼을 개선하기 위해 드라이브를 죽이는 것 같습니다.

누군가가 내가 틀렸다는 것을 보여주고 내 걱정을 덜어주기를 바랍니다.

안녕하세요,
나는 앞으로 나아가는 가치를보고 그것을 좋아하지만이 결정에 대한 3 가지 주요 문제를 봅니다.
1) netstandard는 마이크로 소프트 내부의 아무도 그것으로 어려운 것을 만들지 않는다면 2 등 시민이 될 것입니다. 만약 여러분이 dogfood를하지 않는다면 어떻게 다른 개발자에게 그것을하도록 요청할 수 있습니까? 오늘날 도서관 작성자는 정말 열심히 일해야합니다. 내부 ppl이 표준을 사용하지 않으면 지원이 개선되지 않습니다.
2) 다른 런타임에서 aspnet 코어를 실행하는 데 가치가 있습니다.
3) 오래된 런타임에서 실행되는 소프트웨어에는 가볍게 버려서는 안되는 가치가 있습니다.

그리고 커뮤니케이션이 있습니다. 모든 사람들이 어디에서나 실행되는 하나의 .net 런타임을 좋아할 것이라고 생각합니다. 그러나 그것은 가까운 미래에 대한 유토피아이며 netstandard는 대리자로 만들어졌습니다. 내 관점에서 보면 넷 스탠다드가 아닌 플랫폼을 목표로하는 모든 프로젝트는 그 비전의 방향으로 가지 않는 단계입니다.
.net 프레임 워크가 유지 관리 모드에 있고 .netcore가 대신 할 것이며 (일부 시체를 남겨두고) 모노가 장치에서 실행되고 CoreRT가 발전하지 않을 것임이 분명합니다.

netcore 3.0을 사용하면 한 번에 두 가지 작업을 수행 할 수 있습니다. 데스크톱 워크로드 지원과 "관련성 유지를 위해 즉시 ppl에게 지시"라는 것입니다. 나는 이것이 개발자의 믿음의 도약이 필요할 것이라고 생각하며 많은 프로젝트가 일부 누락 된 종속성으로 인해 마이그레이션되지 않을 것이라는 것을 모두가 알고 있기 때문에 너무 낙관적이며, 이는 아마도 향후 3.1 / 3.2 릴리스에서 1-2 년 내에 추가 될 것입니다 ( 2.1의 3 LTS에 매우 가깝습니다.) 그 동안 관련성을 원하는 개발자는 제어 할 수없는 종속성으로 인해 3.0 비트를 사용하지 못하도록 차단됩니다.

ppl이 테스트하고 실제 의미를 확인한 후에이 결정을 연기 할 수 있습니까?
도서관 작성자에게 지시하는 것처럼 aspnet 코어를 netstandard 및 netcoreapp으로 컴파일하는 것이 가능합니까? .net 프레임 워크에서 성능이 저하 되어도 괜찮습니다 😄

Roslyn은 이제 .NETStandard 2.0-> https://github.com/dotnet/roslyn/pull/30914 에서 실행됩니다.

그것은 확실히 어려운 일로 간주됩니다!

뿡뿡

커뮤니티가 ASP.Net Core로 노력을 옮기고 있기 때문에 다양한 이유로 마이그레이션 할 수없는 .Net Framework 시스템의 향후 개발을위한 옵션을 심각하게 제한하기 시작할 것이라고 생각합니다.

예를 들어 Identity Server 는 이미 ASP.Net Core로 이동했으며 SignalR 의

ASP.NET Core에 대한 LTS 지원은 이미 3 년으로 설정되어 있지만 온-프레미스 배포의 경우 이러한 라인 (4 년)을 고객에게 지원해야하므로 더 긴 수명주기가 필요합니다.
이 기간 동안 주요 애플리케이션 변경없이 보안 픽스가 포함 된 패치를 릴리스 할 수 있어야합니다. 이는 더 중요한 변경 사항에 대해 광범위한 사용자 승인 테스트를 필요로하는 고객 변경 제어 프로세스를 유지하고 유지 관리 모드에있는 릴리스에서 최신 버전으로 마이그레이션하는 것과 같은 주요 변경 사항을 수행 할 필요가 없도록하기위한 것입니다. .

LTS 정책이 변경 될 가능성이 있습니까? 우분투의 LTS 릴리스 전략과 같은 것입니다. 5 년 지원과 함께 2 년마다 LTS 릴리스를 제공합니다. 새 버전으로 마이그레이션하는 작업이 수행되는 동안 현재 릴리스가 3 년 이상 지원되도록 6을 요청합니다.

연장 된 지원이 언급되었다는 것을 이해 합니다만, 이것이 각 고객이 구매해야하는 것으로 가정합니다. 초기 설치 (개발 후, 판매 프로세스, UAT 등)가 기껏해야 만족스럽지 않을 것이라고 생각합니다. 2 년 지원.

또한 .netcore에서 .netstandard 라이브러리를 3.0 번 처리하는 방법이 궁금합니다.
.netstandard의 슬로건은 "모두를 지배하는 하나의 라이브러리"입니다.
이 전에는 모든 것을 의미합니다.
이 후에는 약간의 의미가 있습니다.

이 결정이 얼마나 많은 결과를 낳는 지 보여주기 위해 Blazor는 어떻습니까? netstandard를 기반으로하지 않습니까? 우리도 그것을 기대해야합니까?

누구든지 이것을 명확히 할 수 있습니까?

그렇다면 Newtonsoft.Json과 같은 라이브러리 (고성능의 이점을 누릴 수 있음)에 대한 권장 사항은 .NET Standard가 아닌 .NET Core로 전환하는 것입니까? 나는 그런 종류의 라이브러리와 ASP.NET Core 사이에 많은 차이가 보이지 않습니다. 더 큰 애플리케이션에 REST 서비스를 포함합니다. 일부는 .NET Core로 쉽게 이동할 수 있고 일부는 불가능합니다.

내 이해에서 라이브러리에 대한 권장 사항은 새 API의 이점을 얻고 싶지만 대상을 잃고 싶지 않은 경우 .NET Core 3 및 .NET Standard 2.x를 모두 대상으로하는 것입니다.

내 이해에서 라이브러리에 대한 권장 사항은 새 API의 이점을 얻고 싶지만 대상을 잃고 싶지 않은 경우 .NET Core 3 및 .NET Standard 2.x를 모두 대상으로하는 것입니다.

앞으로의 길은 어디에서나 netstandard 라고 생각했고 현재 우리는 전환 단계에 있습니다. 그러나 이와 같은 움직임으로 다른 사람들이 따라야 할 (또는 필요) 우리는 다중 타겟팅으로 돌아갑니다.

.NET Framework와 .NET Core는 동일한 역할을 수행하므로 ASP.NET Core가 언젠가는 .NET Framework에서 실행되지 않을 것으로 예상됩니다.

그러나 .NET Standard X 에서 실행되지 않는 데 큰 문제가 있습니다. 솔직히 말해서 xamarin 또는 unity에서 실행하기 위해 asp.net 코어가 필요하지는 않지만 가능하다고 말할 수있는 것은 좋습니다. .NET 플랫폼에서 실행되는 또 다른 라이브러리 집합입니다. 중단함으로써 우리는 .NET Core와 ASP.NET Core 간의 긴밀한 통합을 얻고 있으며 .NET Core 4.5로 인해 DNX 2.0부터 Microsoft.AspNetCore 및 @davidfowl을 비난하고 있습니다.

반면에 .NET Standard는 확실히 실험 할 곳이 아니며 제대로 적용하기가 어렵습니다. 그렇다면 타협을 할 수 있을까요? ASP.NET Core는 현재 .NET Core 만 대상으로하지만 LTS 버전은 .NET Standard를 대상으로하는 것이 가능할까요? API가 .NET Standard로가는 길을 찾지 못하면 실제로 사용할 가치가 있습니까?

우리는 또한 당신이 의도 한대로 이것을 볼 수 있습니다 :

• .NET Core는 콘솔 / 웹 / 3rdparty 데스크톱 용입니다 (표준 + 웹 특정 API).
• Unity는 게임용입니다 (표준 + 게임 별 API)
• Xamarin은 장치 / 데스크톱 용입니다 (표준 + 장치 / 데스크톱 특정 API).

하지만 누가 .NET Standard를 발전시킬까요? 리소스가 제한되기 전에 말했듯이 실제로 푸시 할 필요가 없습니다 (제 제안에서 LTS를 릴리스하기 위해 변경이 필요하여 .net core / asp.net 코어 팀에 속하게됩니다). NET Standard는 빠르게 부실화됩니다.

주의를 기울이지 않는 사람들에게는 .NET Standard 2.1이 .NET Framework에 대한 지원을 중단 한 것으로 보입니다.

.NET Standard 2.1에 추가 된 많은 API에 의미가 있으려면 런타임 변경이 필요하므로 .NET Framework 4.8은 .NET Standard 2.1을 구현하는 대신 .NET Standard 2.0에 유지됩니다. .NET Core 3.0과 향후 Xamarin, Mono 및 Unity 버전은 .NET Standard 2.1을 구현하도록 업데이트됩니다.

https://blogs.msdn.microsoft.com/dotnet/2018/11/05/announcing-net-standard-2-1/

.Net Framework 가 Silverlight를 사용하는 것을 보는 것이 고통 스럽지만 ASP.NET Core 와 관련하여 중요한 것은 .NET Standard를 대상으로해야한다는 것입니다.

Core / Standard 에코 시스템에서 가장 큰 참조 응용 프로그램 중 하나 일 가능성이 높은 ASP.NET Core는 .Net Standard와이 표준이 나타내는 모든 좋은 기능의 챔피언이 될 책임이 있다고 생각합니다.

ASP.NET Core가 .NET Core에서 구현되는 표준 변경을 요청하는 것이 합리적이라고 생각합니다.

Nuget 패키지를 통해 .Net Framework에서 Span 등 _is_를 사용할 수있는 것과 같은 방식으로 ASP.NET Core가 아직 .Net Standard에없는 무언가에 의존해야하거나 의존해야하는 경우 해당 종속성을 포함해야한다고 생각합니다. 너겟 패키지를 통해.

마지막으로 (반대되는 모든 증거와는 대조적으로) .Net Standard 3.0+를 대상으로하고 4.x와 나란히 설치되는 .Net Framework 5.0이 있기를 바랍니다.

마지막으로 (반대되는 모든 증거와는 대조적으로) .Net Standard 3.0+를 대상으로하고 4.x와 나란히 설치되는 .Net Framework 5.0이 있기를 바랍니다.

네, 맞습니다. 이것이 제가 수년 동안 말하고있는 것입니다. CLR 2.0 아키텍처는 오랫동안 우리에게 좋은 서비스를 제공해 왔지만 이제는 오래 걸리기 시작했고 Generics와 동일한 종류의 근본적인 업그레이드가 필요합니다. 필요한 변경을 다소 고통 스러울 수 있지만이 필요하다; Generics가 필요했던 것과 동일한 방식으로 새롭고 더 강력한 기능으로 업데이트하는 것이 필요하며,이를 미루면 결국 고통이 줄어들지 않고 악화 될뿐입니다.

이것이 바로 .NET Core이며,이 스레드는 일시적인 고통입니다.

@terrajobst 는 그것이 일어나지 않을 것이라고 말했습니다 : 스레드 참조 : https://twitter.com/terrajobst/status/1059525279431815168?s=19

뿡 빵뀨
네, 두 가지를 제외 하고요.

1. Core는 Framework의 업그레이드가 아닙니다 . 그것은 평행 한 개념입니다. 할 수없는 정말 근본적인 일이 너무 많으며, AppDomains와 같은 많은 것들이 일어날 가능성이 거의 없다고 들었습니다. 제발, 우리는 여전히 작동하는 Reflection.Emit ! 이것이 컴파일러와 코드 생성 도구에서 얼마나 흔한 지 고려할 때 말 그대로 첫 번째 우선 순위 중 하나 였을 것이라고 생각할 것입니다. 그러나 여기서 우리는 4 년 후 작동하지 않습니다! 이것은 "Core as a replacement / upgrade for .Net Framework"라는 개념을 진지하게 받아들이는 것을 매우 어렵게 만듭니다.
2. Core는 런타임, CLR 2.0 스타일을 근본적으로 업그레이드하지 않습니다. "CLR 변경으로 어떤 언어 제안이 도움이됩니까?" 우리는 일반적으로 누락 된 기능으로 인해 사람들이 중요하다고 생각하는 누락 된 기능, CLR이 지원할 수없는 (또는 적어도 CLR의 제한 사항을 해결하기위한 대규모의 추악한 클러 지 없이는 지원할 수없는)의 훌륭한 목록을 가지고 있습니다. 유형 시스템에서. 핵심 팀이이 주제의 제안 중 몇 개를 심각하게 받아들이고 있습니까? 그리고 프로젝트를 실행하는 사람들이 런타임을 업그레이드 할 필요가 없기 때문에 나머지 중 몇 명이 손을 뗄 수 있습니까? 우리는 DIM을 받고 있고 ... 다른 건 없나요? 전혀 요?

따라서 .NET Core는 업그레이드 된 .NET Framework가 아니고 프로젝트 팀이 가능한 한 CLR을 업데이트하지 않기 위해 최선을 다하고 있기 때문에 절실히 필요한 CLR 업데이트를 만드는 업그레이드 된 .NET Framework가 아닙니다. 말 그대로 그것의 정반대입니다.

제발, 우리는 여전히 작동하는 Reflection이 없습니다. 이것이 컴파일러와 코드 생성 도구에서 얼마나 흔한 지 고려할 때 말 그대로 첫 번째 우선 순위 중 하나 였을 것이라고 생각할 것입니다. 그러나 여기서 우리는 4 년 후 작동하지 않습니다! 이것은 "Core as a replacement / upgrade for .Net Framework"라는 개념을 진지하게 받아들이는 것을 매우 어렵게 만듭니다.

작동하지 않는 것을 이해하면 좋을 것입니다. ASP.NET Core와 EF는 몇 군데에서 리플렉션 방출을 사용하므로 큰 격차를 알지 못합니다. 여기서 자세히 설명해 주시겠습니까?

그것은 적어도 2.0 .. 이후 거기에 있었다. iirc 1.0조차도 DefineDynamicAssembly를 가지고 있었지만, 아마도 전체 emit 제품군은 아닐 것이다.

나는 또한 그들이 CLR 업데이트를 피하고 있다는 생각을 진지하게 받아들이 기가 어렵다는 것을 알게되었습니다. 수행되는 작업의 양을 보셨습니까? https://github.com/dotnet/coreclr/commits/master
CLR 변경으로 인해 .NET Core에서만 작동하는 C # 8 용 언어 기능도 있습니다. 이러한 반대 의견 중 상당수는 오래된 정보 인 것 같습니다 (Microsoft의 계획이 때때로 빠르게 변경 되었기 때문에 충분히 공평합니다 ...)

뿡뿡

작동하지 않는 것을 이해하면 좋을 것입니다. ASP.NET Core와 EF는 몇 군데에서 리플렉션 방출을 사용하므로 큰 격차를 알지 못합니다. 여기서 자세히 설명해 주시겠습니까?

확인한 지 몇 달이 지났으므로 최근에 변경되었을 수 있지만 메모리에 새 어셈블리를 만들 수는 있지만 생성과 관련된 신비한 이유로 디스크에 저장하지 않는 한 PDB 파일은 Core를 저와 같은 컴파일러 유지 관리자에게 쓸모 없게 만듭니다.

이 문제가 해결 되었습니까? 나는 그것을 듣고 기뻐할 것입니다 ...

뿡뿡

또한 CLR 업데이트를 피하고 있다는 생각을 진지하게 받아들이 기가 어렵습니다.

내가 말한 것은 2.0 업데이트 (제네릭)와 동일한 방식으로 CLR을 근본적으로 업그레이드하는 것을 피하고 있다는 것입니다.

특히 유형 시스템에 새로운 기본 유형 (모양, 메타 클래스, DU 등)을 추가하거나 명령 세트에 새로운 IL 명령을 추가하는 변경을 적극적으로 피하는 것 같습니다.

안녕하세요.

확인한 지 몇 달이 지났으므로 최근에 변경되었을 수 있지만 메모리에 새 어셈블리를 만들 수는 있지만 디스크에 저장할 수는 없습니다.

https://github.com/dotnet/corefx/issues/4491 (과거에 언급 한 곳)을 살펴보면 상황은 여전히 ​​동일하다고 생각합니다. 특정 기능 (중요한 기능이라하더라도) 하나를 놓치는 것은 "아직 작동하는 Reflection.Emit 도 없습니다"와는 상당히 다릅니다.

저와 같은 컴파일러 관리자에게는 Core를 쓸모 없게 만듭니다.

Reflection.Emit은 컴파일러 작성자에게 어떻게 유용합니까? 나는 그것이 현재 프레임 워크에 대한 어셈블리를 생성하는 것으로 제한되어 있다고 생각했기 때문에 예를 들어 .Net Standard 어셈블리를 만드는 데 전혀 사용할 수 없었습니다. 이것은 어떤 컴파일러에도 상당한 제한이 될 것이라고 생각합니다.

내가 말한 것은 2.0 업데이트 (제네릭)와 동일한 방식으로 CLR을 근본적으로 업그레이드하는 것을 피하고 있다는 것입니다.

CLR을 변경하지 않는 데는 관성이 있다고 생각하지만, 그에 대한 몇 가지 좋은 이유도 있습니다. 특히 플랫폼이 젊을 때 그러한 변경이 가장 유용하고 덜 고통 스럽다고 생각한다면 더욱 그렇습니다.

DIM은 이것이 변경 될 수 있다는 신호라고 생각하지만 JIT 내장 함수가 종종 잘 작동 할 때 새로운 IL 명령어를 기대하지 않으며 기존 유형 시스템에서 합리적으로 인코딩 할 수있는 새로운 유형의 유형을 기대하지 않습니다.

@svick

특정 기능 (중요한 기능이라 할지라도)이 누락 된 것은 "아직 작동하는 Reflection.Emit도 없습니다"와는 상당히 다릅니다.

텍스트 파일을 입력 할 수 있지만 저장할 수없는 텍스트 편집기가 있다면 작동하지 않는다고하지 않겠습니까?

Reflection.Emit은 컴파일러 작성자에게 어떻게 유용합니까?

지금까지는 잘 작동했습니다. 그리고 내가 아는 한 새 어셈블리를 생성하고 저장하거나 메모리에서 새 어셈블리를 생성하고 실행할 수있는 유일한 컴파일러 백엔드입니다.

JIT 내장 함수가 자주 잘 작동 할 때 여전히 새로운 IL 명령을 기대하지 않습니다.

하지만 그렇지 않은 경우는 어떻습니까?

또는 기존 유형 시스템에서 합리적으로 인코딩 될 수있는 새로운 유형의 유형입니다.

기존 유형의 시스템 내에서 모양을 구현하기위한 제안을 본 적이 있나요? 그것에 대해 합리적인 것은 없습니다. 처음부터 끝까지 크고 못생긴 클러 지입니다. (이를 생각 해낸 사람들에 대한 어떤 것도 반대하지 않습니다. 작업하는 한계를 감안할 때 그럴 필요가 있습니다.) 그리고 CLR 수준의 지원없이 메타 클래스를 구현하는 데 행운을 빕니다!

어떤 종류의 효율적인 방식 으로든 더 높은 수준의 기능을 개발하려면 업데이트 된 CLR이 필요하며 실제로 Core에서이를 구현하기 위해 작업하는 사람은 없습니다.

.net 팀의 누군가가 온-프레미스 배포에 대한 권장 사항을 설명해 주시겠습니까? 그냥 "asp.net 일반 사용"입니까? 나는 @ Edward84 의 의견에 구체적으로 말하고 있습니다.

Microsoft.Extensions.* 지원 라이브러리에 영향을 줍니까? 특히 Microsoft.Extensions.Logging 및 Microsoft.Extensions.Configuration .

공통 핵심 API를 공유하는 대규모 코드 기반이 있습니다. 일부는 WinForms이고 일부는 클래식 ASP.NET, 일부는 WCF 등입니다. 최신 애플리케이션은 .NET Core입니다 (현재는 아니지만 결국 핵심 라이브러리를 .NET 표준으로 포팅했을 때).

위에서 언급 한 라이브러리의 추상화를 기반으로 핵심 로깅 및 구성 API를 사용하기로 선택했습니다.

따라서 .NET Core 및 .NET Framework (4.7.2+)에서 참조하는 .NET Standard API에서 이러한 기능을 사용하는 것이 안전한지 또는 .NET Core 전용 기능을 사용할 수도 있는지 궁금합니다.

@mvestergaard 발표 자체 에서 언급했듯이 :

Microsoft.Extensions 패키지 (예 : 로깅, 종속성 주입 및 구성)는 .NET Standard를 계속 지원합니다.

그리고이 스레드 의 @benaadams 의 의견 에서 :

모든 라이브러리가 .NET Core로만 이동하는 것은 아닙니다 (예 : Microsoft.Extensions.* 는 .NET Standard로 유지됨).

@mvestergaard 는 이미 언급했듯이 LTS 정책을 검토하여 연장 된 지원, 더 긴 기간, "유지 관리 모드"기간 등과 같은 것이 유용한 지, 어떤 모습 일지 결정합니다. 또한 새로운 LTS 열차의 타이밍을 더 예측 가능하게 만들 수 있는지 확인하기 위해 노력하고 있습니다 (LTS 모델이있는 다른 스택에서보고 정말 존경하는 모델).

내가 가진 가장 큰 문제는 .NET Framework를 대상으로 할 때만 사용할 수있는 성숙한 패키지 또는 System.Drawing 및 GDI +가 필요한 것과 같이 .NET Framework 외부에서 사용할 수없는 패키지를 사용할 수 없다는 것입니다.

후자의 시나리오는 .NET Core 3.0에서 지원 될 것으로 보이지만 AFAICT는 .NET Framework에서만 사용할 수있는 안정적이고 성숙한 라이브러리를 사용하지 못할 것입니다.

그 예는 Entity Framework 입니다. 성능을 유발하는 문제를 숨기기 위해 전체 EF가 할 수있는 모든 복잡한 시나리오를 처리하는 데는 멀고 미성숙 EF Core 로 전환해야합니다. 문제 .

그 예는 Entity Framework입니다. 우리는 완전한 EF가 할 수있는 모든 복잡한 시나리오를 처리하기에는 먼 것처럼 보이는 미성숙 한 EF Core로 전환해야합니다.

EF6는 이번 주에 @DamianEdwards가 설명한대로 .NET Core 3.0에서 지원 될 예정입니다. ASP.NET Community Standup-2018 년 11 월 6 일 -ASP.NET Core 3.0 기능 (19:06)

@benaadams 좋은 소식입니다! 그렇게 큰 거래에 대해 꽤 모호합니다! :) 그것을 찾는 좋은 직업. 여기 에서 또 다른 언급을 찾았

@SaebAmini : 시스템을 사용할 수 있습니다. .NET Core에서 그리기. System.Drawing.Common 및 Scott Hanselmans Blogpost : https://www.hanselman.com/blog/HowDoYouUseSystemDrawingInNETCore.aspx를 참조하십시오 .

그리고 CoreCompat.System.Drawing이 존재하기 전에 Mono의 System.Drawing 포트로 존재했습니다.

.NET Core에서 실행할 때 사용 사례에 누락 된 기능이 있습니까?

@TsengSR 우리가 .NET Framework를 대상으로 한 구체적인 시나리오는 다음과 같습니다.

1. .NET Framework에서만 사용할 수있는 Microsoft Solver Foundation 패키지를 사용해야합니다.
2. System.Drawing을 사용한 바코드 이미지 생성 패키지 입니다.
3. EF6를 사용해야합니다.

약 1 년 전 일입니다.

@SaebAmini : 앞서 언급했듯이 EF6 지원은 .NET Core 3.0에서 제공되며 System.Drawing은 이미 존재하며 (이전에는 CoreCompat 패키지가 존재했으며 귀하의 경우에 작동했을 수 있음) Microsoft Solver Foundation Package의 경우 이식성 API 분석기 실행 :

이식성 분석기 사용 방법 보기

https://gist.github.com/TsengSR/f61c03c5f2d63dbe78d6b8c1eed08831 (다운로드하고 HTML을 열면 넣을 다른 위치를 찾지 못했습니다).

.NET Core 2.0 + Platform Extensions (약 1 년 전에 출시됨)와 97.93 %의 호환성을 보여 주며 대부분 사용되지 않는 System.Web 및 System.ServiceModel /와 관련된 호환되지 않는 API를 나열합니다. System.Data.Linq

지금은 이전에이 패키지를 사용하지 않았고, 솔버가 System.Web 및 HttpContext 또는 System.ServiceModel 액세스해야하는 이유를 잘 모르겠습니다. 이 중 어떤 것도 필요하지 않으며 (사용 사례가이 API를 호출하지 않는다는 것을 알고 있음) .NET Core 2.0 / 2.1 + Platform Extensions 또는 .NET Core 3.0에서 사용할 수있을 가능성이 매우 높습니다. netstandard 또는 netcoreapp20 타겟 모니 커를 구체적으로 타겟팅하지 않는 경우

따라서 기술적으로는 EF Core 2.0이 애플리케이션 요구 사항을 충족 할 수 있다면 1 년 전에 애플리케이션을 .NET Core 2.0 + Platform Extensions로 마이그레이션 할 수 있었을 가능성이 높습니다 (물론 일부 마이그레이션 작업과 업데이트가 작동해야합니다. EF Core 2.0 포함).

예, 문제의 라이브러리 또는 대체 프레임 워크의 기능 (EF6-> EF Core 2.0 / 2.1)을 분석하는 데 약간의 작업이 필요하지만 불가능하지는 않습니다. 나는 사람들이 (ASP.NET Core 자체 외부에서) 전혀 변경하지 않고 모든 코드를 ASP.NET Core에 1 : 1로 이식 할 수 있거나 기대해야한다고 생각하지 않습니다.

"배지"(.NET Core 3.0 호환) 및 / 또는 패키지를 다운로드하는 것보다 더 명확하게하기 위해 너겟 페이지의 어딘가에있는 자세한 API 호환성 보고서와 같이 API 호환성을 표시하는 것이 더 분명하기를 바랐습니다. 그런 다음 패키지 분석기를 통해 실행합니다.

이 발표는 .NET Core가 얼마나 더 호환되는지를 강조했다면 더 잘 받아 들였을 것입니다. .NET Framework에서 ASP.NET Core를 이동하는 데는 두 가지 요소가 있습니다.
1) .NET Framework에 대한 필요성 감소, 레거시 dep 사용 가능 및 interop 개선 등
2) .NET Core, 기능 및 성능의 이점 증가 및 유지 관리 부담 감소

팩터 2는 실제로 ASP.NET을 구축해야하는 사람들의 마음 속에 크게 떠 오릅니다! 그러나 사용자의 관점에서 볼 때 장점은 거의 없습니다. 사람들은 일하는 것이 있고 그들의 최우선 순위는 그것이 계속 일해야한다는

@gulbanana에 동의합니다. .NET Core는 이제 .NET Framework와 훨씬 더 호환됩니다. 실제로 .exe의 이름을 .dll로 바꾸고 누락 된 .DLL을 검색 경로에 추가하는 것만으로도 꽤 큰 .NET Framework 앱을 시작할 수있었습니다.

dotnet 명령 줄 도구의 진행 상황은 인상적입니다. 특히 .NET Core 글로벌 도구 추가. 그들은 개발을 쉽게 만듭니다.

crossgen 사용한 AOT 컴파일은 훌륭합니다. 나는 계속할 수 있습니다.

tl / dr .NET Core는 요즘 매우 인상적입니다.

없어진 물건 있어요:

• 현재 고객 커뮤니케이션 전략이 부족합니다. 고객은 좋아하는 .NET 플랫폼이 Microsoft에 의해 조각화된다는 소식을 듣고 큰 실망을합니다. 여기서 더 명확해야합니다. 예를 들어, 단일하고 호환성이 높고 빠르고 미래 지향적 인 .NET 구현을 사람들에게 직접 광고하는 것이 훨씬 더 나은 접근 방식입니다. .NET Core와 마찬가지로 .NET의 미래는 대부분의 문제, 급등 생산성, 창의성, 새로운 시장 틈새 개방 등을 해결할 것입니다.
• 즉시 사용 가능한 더 많은 호환성 전략
• 그래픽 사용자 인터페이스. dotnet 명령 줄 도구는 훌륭하지만 현재 거의 모든 프로젝트에서 .NET SDK 형식으로 작업하려면 추가 텍스트 편집기와 콘솔을 사용해야합니다. 이 점에서 Visual Studio UI는 부족합니다. 이로 인해 포인트 앤 클릭 만하는 습관을 가진 많은 사람들에게 큰 장벽이 생깁니다. 이것도 개선되어야합니다
• LTS 지원

@TsengSR 자세한 응답 친구, 훌륭한 정보에 감사드립니다! 프로젝트가 단순히 다른 대상에 대한 불평을 컴파일하지 않기 때문에 바코드 패키지를 사용하면 작동하지 않을 것입니다. 한 번 더 시도해야 할 것 같습니다. (당신이 그것을 스스로 다시 컴파일하고 상속받는 것을 의미하지 않는 한)

그것이 합리적이라면 실제로 노력에 대해 걱정하지 않습니다. 내 주요 관심사는 EF가 주요 차단제 인 옵션없이 높고 건조한 상태로 남아 있었고 겉보기에는 일어나지 않을 것 같습니다. 잘 생각해 보니 반갑습니다. @gulbanana에 동의하지만 이것이 더 잘 광고 될 수 있습니다.

여기에는 많은 합쳐진 문제가 있습니다. 내 개인적인 2 센트는 .NET Framework를 남겨 두는 것이 그렇게 큰 문제가 아니라는 것입니다. 그러나 문제는 표준화 노력 (.NET Standard)에 대한 명백한 지원이 전혀 없다는 것입니다. 물론, 당신은 아마에 ASP.NET 코어를 실행 오늘 유니티를 말하고 싶지 않지만, 오늘날에 관한 없습니다. 약 1 ~ 2 년 후 다른 .NET 런타임 이 나올

ASP.NET Core 3 용 .NET Core 3에 필요한 모든 변경 사항을 최소한 "수집"하여 제안 사항으로 .NET Standard 작업 그룹에 전달할 기회가 있습니까?

안녕하세요. .NetStandard 2.0 또는 .NetCore 2.0 용으로 게시 된 패키지는 .NetCore 3.0에서 계속 작동합니다. 예 : Oracle.ManagedDataAccess.Core 대상 .NetCore 2.0

이전 버전과의 호환성이 있으면 .NetCore 3.0으로 이동하는 것이 적합하지만 이전 버전에 대한 지원이 없으면 모든 플레이가 따라 잡지 않는 한 실제로 쓸모가 없습니다.

.NetFramework는 최신 버전에서 .NetFramework 2.0을 사용할 수 있어도 호환성의 역사를 가지고 있으므로 .NetCore에 대해 유지 관리해야 할 사항은 최소 2.0 ~ 3.0 등입니다.

감사

안녕하세요. .NetStandard 2.0 또는 .NetCore 2.0 용으로 게시 된 패키지는 .NetCore 3.0에서 계속 작동합니다. 예 : Oracle.ManagedDataAccess.Core 대상 .NetCore 2.0

예, .NET Core 3.0은 이전 버전과의 호환성을 유지하므로 .NetStandard 1.0-> .NetStandard 2.1 및 .NetCore 1.0-> .NetCore 2.2 라이브러리를 사용할 수 있습니다.

@benaadams 그럼 좋습니다. 또한 누락 된 API를 사용하지 않으면 .net 프레임 워크 dll이 작동합니까?

감사

또한 누락 된 API를 사용하지 않으면 .net 프레임 워크 dll이 작동합니까?

예, .NET Core (및 Mono, Xamarin, Unity, UWP)에서 작동하는 .NET Standard 라이브러리를 사용하는 것이 더 안전합니다.

또한 Windows 호환 기능 팩을 사용하면 .NET Standard 2.0 위에 또 다른 20,000 개의 API가 추가되어 .NET Core를 .NET Framework에 더 가깝게 만듭니다 (.NET Core 2.1로 수행 할 수 있음). .NET Core 3.0은 EF6 (cross-plat) 및 Windows : WinForms, WPF, COM Interop 등과 가장 호환됩니다.

안녕 여러분,
고객에게 .NET Core의 ASP.NET Core로 애플리케이션을 마이그레이션하는 과정에서 합리적인 디딤돌을 제공하기 위해 현재 지원과 일치하도록 .NET Framework에서 ASP.NET Core 2.1.x에 대한 지원 및 서비스를 확장 할 것입니다. 다른 패키지 기반 ASP.NET 프레임 워크에 대한 정책 (예 : MVC 5.x, Web API 2.x, SignalR 2.x). 이는 사실상 ASP.NET Core 2.1.x 관련 패키지 (최종 세부 목록 미정)가 .NET Core 2.1 교육 전반에 대한 3 년 LTS 기간을 넘어서 무기한 지원된다는 것을 의미합니다.

좋은 소식입니다. 고객의 의견을 들어 주셔서 감사합니다.

우리가 CTP3 이후 MVC에 있었고 거의 모든 확장 포인트를 사용했기 때문에 이전 MVC 앱을 이식하는 데는 매우 오랜 시간이 걸릴 것입니다. 이것은 우리의 우려를 다룹니다.

@DamianEdwards 좋은 소식입니다! 하지만 이것이 2.1.x로 고정되어 있습니까? 아니면 LTS 릴리스가되면 2.2.x로 업데이트됩니까? 2.2로 들어가는 많은 노력이 있었고 아직 출시되지도 않았습니다. 그리고 netstandard 호환성을 계속 유지하고 전체 프레임 워크에서 잘 실행되기 때문에 확장 된 지원을 위해 이것을 완전히 건너 뛰는 것은 일종의 낭비입니다.

@poke 귀하의 우려를 이해하는 동안 어딘가에 선을 그려야합니다.이 경우 버전을 선행하는 LTS와 정렬하는 것이 더 낫다고 생각합니다. 이것은 LTS 또는 Current 열차 중에서 선택할 때 고객이 스스로 결정해야하는 절충안입니다. 새로운 기능은 안정성에 관한 것이므로 LTS에 오지 않습니다. 피드백은 장기적인 지원을위한 것이었고 우리는 이미 그것에 대한 기차를 가지고 있으므로 이것은 기차의 연장입니다. 2.2는 LTS가되지 않습니다.

@DamianEdwards 네, 답장 해 주셔서 감사합니다. 이의 마지막 코멘트 이었기 때문에 나는 그냥 물어되었다 아직 결정되지 않았 음을 그냥 2.2 LTS되었다 IFF에이 확장 된 지원이 이월 것인지 알고 싶어, 그래서.

그리고 사람들이이 확장 된 지원에 의존해야하는 경우 프레임 워크 앱을 2.2로 업그레이드하지 않도록이를 강조하는 것이 충분히 중요하다고 생각합니다. 그렇지 않으면 다시 다운 그레이드해야합니다.

새로운 기능은 안정성에 관한 것이므로 LTS에 오지 않습니다.

하지만 이전 LTS 결정과 실제로 일치하지 않습니다.

@찌름

하지만 이전 LTS 결정과 실제로 일치하지 않습니다.

이것은 나를 혼란스럽게했다. 어떤 방식으로? 1.x LTS 트레인에 1.1이 추가되었다는 사실을 말씀하시는 건가요? 그렇다면 그것은 반복되지 않을 첫 번째 릴리스 트레인의 이상입니다. 앞으로 우리의 의도는 어떤 릴리스가 LTS 대 최신 버전이되는지 (즉, 안정성 대 기능을 어디에서 얻을 수 있는가) 일관성을 유지하는 것입니다.

@DamianEdwards 나는 지금까지 모든 릴리스가 대규모 기능 릴리스였으며 각 LTS 결정은 일반적으로 (적어도 공개적으로) 회고하여 이루어 졌다는 사실을 주로 언급했습니다.

@poke 좋아요. 지금까지 4 개의 릴리스 (1.0, 1.1, 2.0, 2.1)가 있었고 5 번째 릴리스 (2.2)가 곧 출시 될 예정입니다. 그 중에서 1.0과 2.0 만 처음에는 LTS로 의도되었지만 여러 요인 (대부분 우리가 이런 방식으로 엔지니어링을 수행하는 데 정말 새로운 것과 관련이 있음)으로 인해 1.0, 1.1 및 2.1이 LTS 열차가되었습니다. 2.0 및 2.2는 현재 릴리스입니다. 이 단계에서 3.0은 3.1이 3.x 트레인 LTS가되기 전에 거의 확실하게 Current가 될 것입니다 (2.2가 3 개월의 현재 "유예"기간에 진입하게 함). 우리의 희망은 그 이후에 패턴과 케이던스가 더 일관 될 것입니다 (우리는 그것을 좋아합니다).하지만 지금까지 우리의 수정 구슬은 우리를 실패했습니다.

@DamianEdwards 통찰력에 감사드립니다! 😄 (Btw. 나는 이것에 대해 논쟁하려는 것이 아니라 궁금했습니다.))

우리에게 더 큰 문제는 곧 .NET Framework에서 벗어날 가능성이 거의없는 레거시 응용 프로그램에서 프로세스 내에서 호스팅되는 새로운 REST API입니다. 적어도 우리는 지금 .NET Standard 2 지원 라이브러리와 ASP.NET Core 2.1 이상으로 발전하지 못한다는 것을 알고 있습니다! LTS 기간이 연장됩니다.

빠른 질문입니다. C ++ / CLI 형태로 네이티브 패키지를 사용하는 사람들은 어떻습니까? 조만간 .Net Core에서 지원 될 예정입니까, 아니면 P / Invoke를 사용하기 위해 대규모 재 작업을 수행하지 않는 한 고아입니까?

@lokitoth-ASP.NET Core보다 더 일반적이기 때문에 https://github.com/dotnet/core 사람들에게 좋은 질문입니다.

@lokitoth 예, 지원됩니다. https://github.com/dotnet/coreclr/issues/18013 참조

oO 어떻게 놓쳤습니까?

좋아요, 그럼 문제가 없습니다.

@ danroth27 이 문제가 Client-Side-Blazor에 미치는 영향에 대해 말씀해 주시겠습니까?

@Slkebe 나는 어떤 영향도 기대하지 않습니다. 클라이언트 측 Blazor 앱은 서버에서 실행하기로 결정한 런타임 또는 플랫폼과는 독립적입니다.

@ danroth27 내 이해에 따르면 클라이언트 측 Blazor는 종속 Microsoft.AspNetCore.* 패키지가 netstandard를 대상으로하기 때문에 모노에서 실행할 수 있습니다.
내가 뭔가를 놓치고 있습니까? Blazor는 계속해서 Microsoft.AspNetCore.* 2.1.X를 타겟팅해야합니까?

@Slkebe 클라이언트 측 Blazor 라이브러리는 .NET Standard를 계속 대상으로하는 구성 요소 (예 : Microsoft.Extensions. * 및 친구)에만 의존합니다. ASP.NET Core에 의존하는 Blazor의 서버 쪽 부분은이 문제에 설명 된대로 .NET Core를 대상으로합니다.

https://blogs.msdn.microsoft.com/dotnet/2018/11/05/announcing-net-standard-2-1/

이제 결정은 무엇입니까? .net 표준 2.1의 대상?

@ John0King 새로운 결정이 없습니다.

이것은 바나나입니다! 바나나

나는 당신의 관점에 공감합니다.

이것이 이미 제기 되었다면 사과드립니다.하지만 ASP.NET이 아닌 응용 프로그램의 일부로 Kestrel + some 미들웨어를 사용하려는 사용 사례는 어떻습니까? 전체 3.0 트리를 가져와야합니까 (내 사용 사례에 소비자 용 사용자 지정 SDK 정의가 포함되어 있기 때문에 이상적이지 않음), 아니면이 사용 사례가 3.x에서 지원되지 않습니까?

현재 포함 된 라이브러리로 인해 .NET Framework에서 실행되는 ASP.NET Core 애플리케이션을 개발 중입니다. 다중 인증 기능 때문에 ASP.NET Core를 사용하고 있습니다. 나는 어리 석고 갇힌 느낌이 듭니다.

다중 인증 기능 때문에 ASP.NET Core를 사용하고 있습니다.

@FlorianGrimm 구체적으로 무엇입니까? Microsoft.Owin은 ASP.NET 4에 대해 유사한 인증 기능을 제공했습니다.

현재 Windows 인증, aad, 기본 인증 및 익명을 사용하는 온-프레미스 및 Azure에서 실행되는 하이브리드 앱 하나의 소스 코드 (.exe)입니다.

@FlorianGrimm .NET Core 사용을 방해하는 라이브러리 종속성은 무엇입니까?

Microsoft.Office.Project.Schema, Microsoft.SqlServer.TransactSql.ScriptDom 및 Microsoft.SharePointOnline.CSOM.

SharePoint 팀이 완료되기를 바랍니다.
https://sharepoint.uservoice.com/forums/329220-sharepoint-dev-platform/suggestions/16585795-support-net-core-with-csom
ilspy 이외의 다른 옵션을 찾습니다.

어쨌든 나는 ASP.NET Core를 좋아하고 다른 Microsoft Teams가 더 많은 .NET Core 어셈블리를 제공하기를 바랍니다.

장기간 업데이트되지 않은 '토론'이슈는 주기적으로 마감합니다.

불편을 드려 죄송합니다. 여전히 문제가 발생하는 경우 업데이트 된 정보로 새 문제를 기록해 주시면 조사하겠습니다.