괴롭힘.
실제 답변 제공.

.Net Core와 Mono의 차이점은 무엇입니까?

.NET Core는 이제 공식적으로 .NET의 미래입니다. 서버 응용 프로그램을 포함 하는 ASP.NET MVC 프레임 워크 및 콘솔 응용 프로그램을 다시 작성하여 시작했습니다 . (Turing-complete이며 C dll과의 interop을 지원하므로 절대적으로 원한다면 Avalonia 와 같은 타사 라이브러리를 통해 자체 데스크톱 응용 프로그램을 작성할 수도 있습니다., 나는 이것을 처음 쓸 때 약간 기본적 이었으므로 웹이나 서버에 거의 제한을 두지 않았다.) 시간이 지남에 따라 많은 API가 .NET Core에 추가되어 버전 3.1 이후에, .NET Core는 “Core”가없는 .NET 5.0으로 알려진 버전 5.0으로 이동하여 .NET Framework의 미래가 될 것입니다. 정식 .NET Framework였던 것은 수십 년 동안 유지 관리 모드에서 정식 .NET Framework 4.8.x로 유지 될 것입니다. 아직까지는 일부 업그레이드가 있을지 모르지만 의심의 여지가 있습니다. 다시 말해 .NET Core는 .NET의 미래이며 Full .NET Framework는 Dodo / Silverlight / WindowsPhone의 길을 갈 것입니다 .

.NET Core의 주요 요점은 다중 플랫폼 지원 외에 성능을 향상시키고 “기본 컴파일”/ 자체 포함 배포를 가능하게하는 것입니다 (따라서 대상 컴퓨터에 .NET 프레임 워크 / VM을 설치할 필요가 없음) .
한편,이 수단 리눅스에서 지원을 docker.io 다음 방금 당신이 좋아하는 DOTNET-CORE 프레임 워크의 어떤 버전을 사용할 수 있기 때문에 다른, 독립적 인 배치에, “클라우드 컴퓨팅”에 유용합니다, 그리고 sysadmin이 실제로 설치 한 .NET 프레임 워크의 버전에 대해 걱정할 필요가 없습니다.

.NET Core 런타임은 여러 운영 체제 및 프로세서를 지원하지만 SDK는 다른 이야기입니다. SDK는 여러 OS를 지원하지만 SDK에 대한 ARM 지원은 여전히 ​​진행 중입니다. .NET Core는 Microsoft에서 지원합니다. Dotnet-Core는 WinForms 또는 WPF 또는 이와 유사한 것을 제공하지 않았습니다.

• 버전 3.0부터 WinForms 및 WPF는 .NET Core에서도 지원되지만 Windows에서만, C #에서만 지원됩니다. VB.NET이 아님 (2020 년 v5 용 VB.NET 지원 계획) .NET Core에는 Forms Designer가 없습니다. 나중에 지정되지 않은 시간에 Visual Studio 업데이트와 함께 제공됩니다.
• WebForms는 여전히 .NET Core에서 지원되지 않으며이를 지원할 계획이 없습니다 ( Blazor 는이를위한 새로운 도시입니다).
• .NET Core에는 mscorelib를 대체하는 System.Runtime도 포함되어 있습니다.
• 종종 .NET Core는 System.Runtime / mscorelib (및 기타)를 둘러싼 약간의 래퍼 인 NetStandard 와 혼합되어 .NET Core, Full .NET Framework 및 Xamarin (iOS)을 대상으로하는 라이브러리를 작성할 수 있습니다. / Android)와 동시에
• .NET Core SDK는 적어도 마지막으로 확인하지 않은 ARM에서 작동하지 않습니다.

” 모노 프로젝트” 는 .NET Core보다 훨씬 오래되었습니다.
모노는 스페인어이며 원숭이를 의미하며 부수적으로 이름은 단핵구증과 관련이 없습니다 (힌트 : http://primates.ximian.com / 에서 직원 목록을 얻을 수 있음 ).
Mono는 2005 년에 Linux 용 .NET Framework (Ximian / SuSe / Novell)의 구현 으로 Miguel de Icaza ( 그놈 을 시작한 사람 및 기타 몇 사람)에 의해 시작되었습니다 . Mono에는 Web-Forms, Winforms, MVC, Olive 및 MonoDevelop 라는 IDE가 포함됩니다.(Xamarin Studio 또는 Visual Studio Mac이라고도 함). 기본적으로 (OpenJDK) JVM 및 (OpenJDK) JDK / JRE와 동일합니다 (SUN / Oracle JDK와 반대). 이를 사용하여 ASP.NET-WebForms + WinForms + ASP.NET-MVC 응용 프로그램을 Linux에서 작동시킬 수 있습니다.

Mono는 Microsoft가 아닌 Xamarin (Ximian이었던 새로운 회사 이름, Linux 시장 대신 모바일 시장에 집중했을 때)으로 지원됩니다.
(Xamarin은 Microsoft가 구입했기 때문에 기술적으로는 문화적으로는 아닙니다.)
일반적으로 C #은 모노로 컴파일하지만 VB.NET은 컴파일하지 않습니다.
Mono는 WSE / WCF 및 WebParts와 같은 일부 고급 기능이 누락되었습니다.
많은 Mono 구현이 불완전하고 (예 : ECDSA 암호화에서 NotImplementedException 발생), 버그가있는 (예 : Firebird를 사용하는 ODBC / ADO.NET) .NET (예 : XML- 직렬화) 또는 다르게 불안정한 경우 (ASP.NET MVC) 허용 할 수 없을 정도로 느리다 (Regex). 거꾸로 Mono 툴체인은 ARM에서도 작동합니다.

.NET Core와 관련하여 크로스 플랫폼이라고 할 때 크로스 플랫폼은 ElasticSearch와 마찬가지로 ARM-Linux에 .NET Core를 실제로 설치할 수 있음을 기대하지 않습니다. 소스에서 전체 프레임 워크를 컴파일해야합니다.
즉, 해당 공간이있는 경우 (예 : 총 16 ~ 32GB의 HD가있는 크롬 북)
OpenSSL 1.1 및 libcurl과의 비 호환성 문제도있었습니다.
최신 버전의 .NET Core 버전 2.2에서 수정되었습니다.
크로스 플랫폼의 경우 너무 많습니다.

“공식 사이트에서 작성된 코드는 Mono와 같은 응용 프로그램 스택에서도 이식 가능합니다.”라는 문구를 발견했습니다.

해당 코드가 WinAPI 호출에 의존하지 않는 한 Windows-dll-pinvokes, COM-Components, 대소 문자를 구분하지 않는 파일 시스템, 기본 시스템 인코딩 (코드 페이지) 및 디렉토리 구분 기호 문제가 없습니다. 옳은. 그러나 .NET Core 코드는 Mono가 아닌 .NET Core에서 실행됩니다. 따라서 두 가지를 혼합하는 것은 어려울 것입니다. 모노는 상당히 불안정하고 느리기 때문에 (웹 애플리케이션의 경우) 어쨌든 권장하지 않습니다. .NET 코어에서 이미지 처리 (예 : WebP 또는 GIF 이동 또는 여러 페이지 강점 또는 이미지에 텍스트 쓰기)를 시도하면 놀라 울 것입니다.

참고 :
.NET Core 2.0부터 System.Drawing의 기능이 대부분 포함 된 System.Drawing.Common (NuGet)이 있습니다. .NET-Core 2.1에서는 거의 기능이 완전해야합니다. 그러나 System.Drawing.Common 따라서 GDI +를 사용하고, 의지 푸른에없는 작업 (System.Drawing 라이브러리 애저 클라우드 서비스 [기본적으로 단지 VM]에서 사용할 수 있지만 푸른 Web App에서 [기본적으로 공유 호스팅?]되지 않음)
그래서 지금까지 System.Drawing.Common은 Linux / Mac에서는 잘 작동하지만 iOS / Android에는 문제가 있습니다.
.NET Core 2.0 이전에는 2017 년 2 월 중순 쯤 이미징 (예)에서 SkiaSharp 를 사용할 수있었습니다 (아직 가능). .net-core 2.0을 게시하면 SixLabors ImageSharp가 나타납니다.
System.Drawing은 필연적으로 안전하지 않으며 많은 잠재적 또는 실제 메모리 누수가 있기 때문에 웹 응용 프로그램에서 GDI를 사용해서는 안되기 때문에 갈 길입니다. SkiaSharp는 네이티브 라이브러리를 사용하기 때문에 ImageSharp보다 훨씬 빠릅니다. 또한 GDI +는 Linux 및 Mac에서 작동하지만 iOS / Android에서 작동한다는 의미는 아닙니다.

.NET (비 핵심) 용으로 작성되지 않은 코드는 .NET Core로 이식 할 수 없습니다.
즉, PDFSharp와 같은 GPL이 아닌 C # 라이브러리에서 PDF 문서를 작성하려면 (매우 흔한 경우) 운이 나쁘다(현재)( 더 이상은 아닙니다 ). Windows-pInvoke를 사용하는 ReportViewer 컨트롤을 사용하지 마십시오 (COM을 통해 mcdf 문서를 암호화하고 작성하며 글꼴, 문자, 커닝, 글꼴 포함 정보, 문자열을 측정하고 줄 바꿈을 수행하고 실제로 허용 가능한 품질의 강점을 그리기 위해) Linux의 Mono에서는 실행되지 않습니다
( 저는 작업 중입니다 ).

또한 Mono에는 .NET Core 런타임 라이브러리가 없기 때문에 .NET Core로 작성된 코드는 Mono로 이식 할 수 없습니다.

내 목표는 C #, LINQ, EF7, Visual Studio를 사용하여 Linux에서 실행 / 호스팅 될 수있는 웹 사이트를 만드는 것입니다.

내가 지금까지 시도한 모든 버전의 EF는 너무 느려서 (하나의 왼쪽 조인이있는 하나의 테이블과 같은 간단한 것들조차도) Windows에서는 아니고 결코 권장하지 않습니다.
고유 제약 조건이있는 데이터베이스 또는 varbinary / filestream / hierarchyid 열이있는 경우 특히 EF를 권장하지 않습니다. (스키마 업데이트
에도 해당되지 않습니다 .) 또한 DB 성능이 중요한 상황 (예 : 10 명에서 100 명 이상).
또한 Linux에서 웹 사이트 / 웹 응용 프로그램을 실행하면 조만간 웹 사이트를 디버깅해야합니다.
Linux에서는 .NET Core에 대한 디버깅 지원이 없습니다.(더 이상은 아니지만 JetBrains Rider가 필요합니다.)
MonoDevelop는 .NET Core 프로젝트 디버깅을 지원하지 않습니다.
당신이 문제가 있다면, 당신은 혼자입니다. 광범위한 로깅을 사용해야합니다.
특히 프로그램이 무한 루프 또는 재귀에 진입하는 경우 광범위한 로깅이 디스크를 즉시 채울 것입니다.
로그인에 logfile-space가 필요하기 때문에 웹 응용 프로그램이 루트로 실행되는 경우 특히 위험합니다. 여유 공간이 없으면 더 이상 로그인 할 수 없습니다.
일반적으로 디스크 공간의 약 5 %는 사용자 루트 (Windows의 경우 관리자)를 위해 예약되어 있으므로 디스크가 거의 찼을 경우 최소한 관리자는 여전히 로그인 할 수 있습니다. 그러나 응용 프로그램이 루트로 실행되는 경우 해당 제한이 적용되지 않습니다 디스크 사용률과 로그 파일은 남은 여유 공간의 100 %를 사용할 수 있으므로 관리자조차 더 이상 로그인 할 수
없습니다.

누군가가 그가 “모노”가되기를 원한다고 말했지만 그게 무슨 뜻인지 모르겠습니다.

.NET Core를 사용하지 않거나 Linux / Mac에서 C #을 사용하고 싶다는 의미입니다. 내 생각에 그는 Linux의 웹 응용 프로그램에 C #을 사용하려고합니다. .NET Core는 C #에서 절대적으로 원한다면 그렇게 할 수 있습니다. “Mono proper”를 사용하지 마십시오. 표면적으로는 처음에는 작동하는 것처럼 보이지만 서버가 장기간 (1 일 이상) 실행될 때 Mono의 ASP.NET MVC가 안정적이지 않기 때문에 후회할 것이라고 믿습니다. 이제 경고를 받았습니다. techempower 벤치 마크에서 모노 성능을 측정 할 때 “완료되지 않았습니다”참조도 참조하십시오.

위에 나열된 기술과 함께 .Net Core 1.0 프레임 워크를 사용하고 싶습니다. 그는 또한 “fast cgi”를 사용하고 싶다고 말했다. 그게 무슨 뜻인지 모르겠습니다.

이는 nginx (Engine-X)와 같은 고성능의 완전한 기능을 갖춘 WebServer, 아마도 Apache를 사용하고 싶어한다는 의미입니다.
그런 다음 가상 이름 기반 호스팅 (동일한 IP의 여러 도메인 이름) 및 / 또는로드 균형 조정을 사용하여 mono / dotnetCore를 실행할 수 있습니다. 또한 웹 서버에서 다른 포트 번호를 요구하지 않고도 다른 기술로 다른 웹 사이트를 실행할 수 있습니다. 이는 귀하의 웹 사이트가 fastcgi-server에서 실행되고 nginx가 fastcgi 프로토콜을 통해 특정 도메인에 대한 모든 웹 요청을 해당 서버로 전달 함을 의미합니다. 또한 웹 사이트가 fastcgi-pipeline에서 실행되고 파일을 전송할 때 HTTP 1.1을 사용할 수없는 등의주의를 기울여야합니다.
그렇지 않으면 대상에서 파일이 깨질 수 있습니다. 여기 와 여기도
참조 하십시오 .

결론 :
현재 .NET Core (2016-09-28)는 실제로 이식성이 없으며 크로스 플랫폼 (특히 디버그 도구)도 아닙니다.
특히 ARM의 네이티브 컴파일도 쉽지 않습니다.
그리고 나에게는 아직 개발이 “정말 완료된”것처럼 보이지 않습니다.
예를 들어 System.Data.DataTable / DataAdaper.Update가 누락되었습니다 …
(더 이상 .NET Core 2.0이 아님)
System.Data.Common.IDB * 인터페이스와 함께.(.NET Core 1.1에서는 더 이상 사용되지 않음)
자주 사용되는 클래스가 하나 있으면 DataTable / DataAdapter가 그럴 것입니다 …
또한 적어도 내 컴퓨터에서 Linux 설치 프로그램 (.deb)이 실패합니다. 내가 그 문제가있는 유일한 사람이 아니라는 것을 확신하십시오.
ARM에서 디버깅 할 수 있다면 Visual Studio Code를 사용하여 디버그 할 수 있습니다 (그렇게하면 Scott Hanselman의 블로그 게시물을 따르지 마십시오-github의 VS-Code 위키에는 방법이 있습니다). 그들은 실행 파일을 제공하지 않습니다.
Yeoman도 실패합니다. (나는 당신이 설치 nodejs 버전이 함께 할 수있는 뭔가가 생각 – VS 코드는 또 다른 보좌관 …하지만 그것은 동일한 컴퓨터에서 실행해야합니다, 하나 개의 버전이 필요 꽤 절름발이가.
는 기본적으로 제공되는 노드 버전에서 실행해야 신경 쓰지 마 OS에서.
NodeJS에 대한 의존성이 없어야한다는 것을 잊지 마십시오.
kestell 서버도 진행 중입니다.
그리고 모노 프로젝트에 대한 나의 경험에 비추어 볼 때, FastCGI에서 .NET Core를 테스트했거나 FastCGI 지원이 프레임 워크에 대해 무엇을 의미하는지 전혀 모릅니다. “. 사실, 방금 .NET Core로 fastcgi 응용 프로그램을 만들려고했지만 .NET Core “RTM”용 FastCGI 라이브러리가 없다는 것을 깨달았습니다 …

따라서 nginx 뒤에서 .NET Core “RTM”을 실행하려는 경우 kestrell (반제품 노드 JS에서 파생 된 웹 서버)에 요청을 보내야만 수행 할 수 있습니다. .NET Core에는 현재 fastcgi 지원이 없습니다. “RTM”, AFAIK. .net 코어 fastcgi 라이브러리와 샘플이 없으므로 fastcgi가 예상대로 작동하는지 확인하기 위해 프레임 워크에서 테스트를 수행 한 사람이 거의 없습니다.

또한 성능에 의문을 제기합니다.
에서 (예비) techempower 벤치 마크 (라운드 13) , 최적의 성능을 25 % 상대에 aspnetcore – 리눅스 계급 반면, 비교 최고 성능의 96.9 %에서 이동 (golang) 순위와 같은 프레임 워크 (및 파일없이 일반 텍스트를 반환 할 때 즉 -시스템 액세스 전용). .NET Core는 JSON 직렬화에서 조금 나아지지만 강력 해 보이지는 않습니다 (피크의 98.5 %에 도달, .NET 코어 65 %에 도달). 즉, 그것은 “모노 적절한”보다 나쁠 수는 없습니다.

또한 여전히 비교적 새롭기 때문에 모든 주요 도서관이 아직 포팅되지는 않았으며 일부는 포팅 될 것으로 의심됩니다.
이미징 지원도 가장 의문의 여지가 있습니다.
암호화를 위해서는 대신 BouncyCastle을 사용하십시오.

이 모든 용어를 이해 하고 나의 기대가 현실적 일 수 있도록 도와 줄 수 있습니까?

이 모든 용어를 이해하는 데 도움이 되었기를 바랍니다.
당신의 기대치에 이르기까지 :
리눅스에 대해 전혀 몰라도 리눅스 애플리케이션을 개발하는 것은 처음에는 정말 어리석은 아이디어이며, 어떤 식 으로든 끔찍한 방식으로 실패 할 수밖에 없습니다. 리눅스는 라이센스 비용이 들지 않기 때문에 원칙적으로 좋은 생각이다. 그러나 당신이 무엇을해야할지 모른다면 말이다.
응용 프로그램을 디버깅 할 수없는 플랫폼을위한 응용 프로그램을 개발하는 것은 또 다른 나쁜 생각입니다.
어떤 결과가 있는지 알지 못하고 fastcgi를 개발하는 것은 또 다른 나쁜 아이디어입니다.

프로젝트가 단순한 개인 홈페이지가 아니라면 해당 플랫폼의 세부 사항에 대한 지식이나 디버깅 지원없이 “실험적인”플랫폼에서 이러한 모든 작업을 수행하는 것은 자살입니다. 반면에, 학습 목적으로 개인 홈페이지에서 그것을 수행하는 것은 아마도 매우 좋은 경험 일 것입니다. 그런 다음 프레임 워크와 비 프레임 워크 문제가 무엇인지 알게됩니다.
예를 들어 응용 프로그램에 대소 문자를 구분하지 않는 fat32, hfs 또는 JFS를 프로그래밍 방식으로 루프 마운트하여 대소 문자 구분 문제를 해결할 수 있습니다 (루프 마운트는 프로덕션에서는 권장되지 않음).

요약하면
현재 (2016-09-28) .NET Core (생산 용도)에서 멀리 떨어져 있습니다. 아마도 1-2 년 후에는 또 다른 모습을 볼 수 있지만 이전에는 그렇지 않을 것입니다.
개발중인 새 웹 프로젝트가있는 경우 모노가 아닌 .NET Core에서 시작하십시오.

Linux (x86 / AMD64 / ARMhf) 및 Windows 및 Mac에서 작동하는 프레임 워크를 원하는 경우 (예 : 정적 링크 만, .NET, Java 또는 Windows에 대한 종속성 없음) Golang을 대신 사용하십시오. 성숙도가 높고 성능이 입증되었으며 (Baidu는 100 만 명의 동시 사용자와 함께 사용), golang의 메모리 사용 공간이 현저히 줄었습니다. 또한 golang은 리포지토리에 있으며 .deb는 문제없이 설치되며 소스 코드는 변경없이 컴파일되며 golang은 그 동안 delve 및 JetBrains로 디버깅 지원을 제공합니다.Linux (및 Windows 및 Mac)의 Gogland Golang의 빌드 프로세스 (및 런타임)도 NodeJS에 의존하지 않으며 이는 또 다른 장점입니다.

모노가가는 한 멀리 떨어지십시오.
모노가 얼마나 멀리 왔는지는 놀라운 일이 아니지만 불행히도 프로덕션 애플리케이션의 성능 / 확장 성 및 안정성 문제를 대체 할 수는 없습니다.
또한 단일 개발은 상당히 죽었습니다. Xamarin이 돈을 벌기 때문에 Android 및 iOS와 관련된 부분 만 더 많이 개발합니다.
웹 개발이 일류 Xamarin / mono 시민이 될 것으로 기대하지 마십시오.
.NET Core는 새 프로젝트를 시작하는 경우 가치가있을 수 있지만 기존 대형 웹 양식 프로젝트의 경우 이식이 크게 문제가되지 않으므로 필요한 변경 사항이 엄청납니다. MVC 프로젝트가있는 경우 원래 응용 프로그램 디자인이 제정신 인 경우 대부분의 기존 “소위 적으로”증가 된 “응용 프로그램에는 해당되지 않는 변경 사항을 관리 할 수 ​​있습니다.

2016 년 12 월 업데이트 :
아직 준비되지 않았기 때문에 .NET Core 미리보기에서 네이티브 컴파일이 제거되었습니다 …

원시 텍스트 파일 벤치 마크에서 상당히 크게 개선 된 것처럼 보이지만 다른 한편으로는 매우 버그가 있습니다. 또한 JSON 벤치 마크에서 더욱 악화되었습니다. 또한 엔터티 프레임 워크가 Dapper보다 업데이트 속도가 더 빠르다는 점이 궁금합니다. 이것은 사실이 아닐 것입니다. 아직도 사냥해야 할 버그가 몇 개 이상인 것 같습니다.

또한, 리눅스 IDE의 전면에는 안도감이있는 것 같습니다.
JetBrains는 Visual Studio Project 파일을 처리 할 수있는 Linux (및 Mac 및 Windows) 용 C # /. NET Core IDE의 초기 액세스 미리보기 인 “Project Rider”를 출시했습니다. 마지막으로 C # IDE를 사용할 수 있고 지옥처럼 느리지 않습니다.

결론 : .NET Core는 여전히 2017 년에 출시 될 때 시험판 품질 소프트웨어입니다. 라이브러리를 이식하되 프레임 워크 품질이 안정화 될 때까지 프로덕션 용도로 사용하지 마십시오.
그리고 Project Rider를 주시하십시오.

2017 업데이트
지금 내 (형제) 홈페이지를 .NET Core로 마이그레이션했습니다.
지금까지 Linux의 런타임은 (적어도 작은 프로젝트의 경우) 충분히 안정적 인 것으로 보입니다.로드 테스트를 쉽게 견뎌 냈습니다.
또한 .NET-Core-native와 .NET-Core-self-contained-deployment를 섞은 것처럼 보입니다. 자체 포함 된 배포는 작동하지만 매우 간단하지만 문서화가 약간 부족합니다 (빌드 / 게시 도구는 약간 불안정하지만 “양수 필요-빌드 실패”)-동일한 명령을 다시 실행하십시오. 작동합니다).

당신은 실행할 수 있습니다

dotnet restore -r win81-x64
dotnet build -r win81-x64
dotnet publish -f netcoreapp1.1 -c Release -r win81-x64

참고 : .NET Core 3에 따라 축소 된 모든 내용을 단일 파일 로 게시 할 수 있습니다 .

dotnet publish -r win-x64 -c Release /p:PublishSingleFile=true
dotnet publish -r linux-x64 -c Release /p:PublishSingleFile=true

그러나 이동과 달리 정적으로 링크 된 실행 파일이 아니라 자동 압축 풀기 zip 파일이므로 배포 할 때 특히 임시 디렉토리가 그룹 정책에 의해 잠겨 있거나 다른 문제가있는 경우 문제가 발생할 수 있습니다 . 그러나 hello-world 프로그램에는 잘 작동합니다. 그리고 축소하지 않으면 실행 파일 크기가 약 100MB 정도가됩니다.

또한 .NET 프레임 워크가 설치되지 않은 Windows 8.1 시스템으로 이동하여 실행할 수있는 자체 포함 된 .exe 파일 (게시 디렉토리에 있음)이 제공됩니다. 좋은. 이제 dotNET-Core가 흥미를 갖기 시작했습니다. (아직 빈틈없이 SkiaSharp 는 Windows 8.1 / Windows Server 2012 R2에서 작동하지 않습니다 . [아직]-생태계는 먼저 따라 잡아야합니다. 그러나 흥미롭게도 Skia-dll-load-fail은 전체 서버 / 응용 프로그램-다른 모든 것이 작동합니다)

(참고 : Windows 8.1의 SkiaSharp에는 적절한 VC 런타임 파일 (msvcp140.dll 및 vcruntime140.dll)이 없습니다. publish-directory로 복사하면 Skia가 Windows 8.1에서 작동합니다.)

2017 년 8 월 업데이트
.NET Core 2.0이 릴리스되었습니다.
주의-인증 변경 (거대한 중단)과 함께 제공됩니다 …
거꾸로 DataTable / DataAdaper / DataSet 클래스 등을 가져 왔습니다. Mobius 가 아직 포팅되지 않았기
때문에 Realized .NET Core에서 Apache SparkSQL에 대한 지원이 여전히 누락 되었습니다. IoT Cassandra 클러스터에 대한 SparkSQL 지원이 없기 때문에 조인이 없기 때문에 나쁘다 …
실험적 ARM 지원 (런타임 전용, SDK가 아님-크롬 북 개발에 너무 나쁘다-2.1 또는 3.0을 기대). PdfSharp는 이제 실험적으로 .NET Core로 이식되었습니다. 제트 브레인 라이더

왼쪽 EAP. 이제 Linux에서 .NET Core를 개발 및 디버깅하는 데 사용할 수 있지만 .NET Core 2.0 지원 업데이트가 적용되기 전까지는 .NET Core 1.1 만 가능합니다.

2018 년 5 월 업데이트
.NET Core 2.1 릴리스가 임박했습니다. 어쩌면 이것은 Linux에서 NTLM 인증을 수정합니다 (NTLM 인증은 협상과 같은 여러 인증 헤더가있는 .NET-Core 2.0의 Linux {및 가능하면 Mac}에서는 작동하지 않으며 일반적으로 ms-exchange와 함께 전송 됨) v2.1에서만 수정하고 2.0의 버그 수정 버전은 없습니다.
그러나 내 컴퓨터에 미리보기 릴리스를 설치하지 않습니다. 그래서 기다리고 있습니다.
v2.1은 또한 컴파일 시간을 크게 단축한다고합니다. 좋을 것입니다.

또한 Linux에서 .NET Core는 64 비트 전용입니다 !
Linux에는 x86-32 버전의 .NET Core가 없으며 없을 것 입니다.
ARM 포트는 ARM-32 전용입니다. 아직 ARM-64가 없습니다.
그리고 ARM에서는 현재 (dotnet-SDK가 아닌) 런타임 만 있습니다.

그리고 한 가지 더 :
.NET-Core는 OpenSSL 1.0을 사용하기 때문에 Linux의 .NET Core는 Arch Linux에서 실행되지 않으며 Manjaro (이 시점에서 가장 인기있는 Linux 배포판)에서는 파생되지 않습니다. 리눅스는 OpenSSL 1.1을 사용합니다. 아치 리눅스를 사용한다면 운이 나쁘다 (젠투도 마찬가지다).

편집하다:

.NET Core 2.2+의 최신 버전은 OpenSSL 1.1을 지원합니다. 아치 또는 우분투 19.04+에서 사용할 수 있습니다. 아직 패키지가 없기 때문에 .NET-Core 설치 스크립트 를 사용해야 할 수도 있습니다 .

거꾸로 성능이 확실히 향상되었습니다.

.NET Core 3 :
.NET-Core v 3.0은 WinForms 및 WPF를 .NET-Core로 가져옵니다.
그러나 WinForms 및 WPF는 .NET Core이지만 WinForms / WPF는 Windows-API를 사용하므로 .NET-Core의 WinForms 및 WPF는 Windows에서만 실행됩니다.

참고 :
.NET Core 3.0 (RTM)이 출시되었으며 WinForms 및 WPF가 지원되지만 C # (Windows) 만 지원됩니다. WinForms-Core-Designer 는 없습니다 . 디자이너는 결국 Visual Studio 업데이트를 제공 할 것입니다. VB.NET에 대한 WinForms 지원 은 지원되지 않지만 2020 년 에 .NET 5.0을 위해 계획되어 있습니다.

추신:

echo "DOTNET_CLI_TELEMETRY_OPTOUT=1" >> /etc/environment
export DOTNET_CLI_TELEMETRY_OPTOUT=1 

Windows에서 사용했다면 아마 이것을 보지 못했을 것입니다.

.NET Core 도구는 사용 환경을 개선하기 위해 사용 데이터를 수집합니다.
데이터는 익명이며 명령 줄 인수를 포함하지 않습니다.
데이터는 Microsoft에서 수집하여 커뮤니티와 공유합니다.
자주 사용하는 쉘을 사용하여 DOTNET_CLI_TELEMETRY_OPTOUT 환경 변수를 1로 설정하여 원격 측정을 옵트 아웃 할 수 있습니다.
.NET Core 도구 원격 분석에 대한 자세한 내용은
https://aka.ms/dotnet-cli-telemetry를 참조하십시오 .

필자는 monodevelop (일명 Xamarin Studio, Mono IDE 또는 Visual Studio Mac이 현재 Mac에서 호출 됨)가 상당히 훌륭하게 발전했으며 그 동안 대부분 사용할 수 있다고 생각한다고 언급했습니다.
그러나 JetBrains Rider (이 시점의 2018 EAP)는 Linux 또는 Mac에서 .NET-Core를 개발하는 경우 확실히 훨씬 훌륭하고 안정적입니다 (포함 된 디 컴파일러는 생명을 희생자입니다). MS는 Visual Studio Mac을 제외하고 디버깅 API dll을 라이센스하지 않기 때문에 MonoDevelop는 .NET Core의 Linux에서 Debug-StepThrough를 지원하지 않습니다. 그러나 MonoDevelop 용 Samsung Debugger 의 .NET Core 디버거 확장을 통해 .NET Core 용 Samsung 디버거를 사용할 수 있습니다.

면책 조항 :
저는 Mac을 사용하지 않으므로 여기에 쓴 내용이 FreeBSD-Unix 기반 Mac에도 적용되는지 말할 수 없습니다. JetBrains Rider, mono, MonoDevelop / VisualStudioMac / XamarinStudio 및 .NET-Core의 Linux (Debian / Ubuntu / Mint) 버전을 참조하고 있습니다. 또한 Apple은 Intel 프로세서에서 자체 제조 ARM (ARM-64?) 기반 프로세서로의 전환을 고려하고 있으므로 현재 Mac에 적용되는 많은 부분이 향후 Mac에 적용되지 않을 수 있습니다 (2020+).

또한, “모노가 상당히 불안정하고 느리다”라고 쓸 때, 불안정은 WinFroms & WebForms 애플리케이션과 관련이 있습니다. 특히 fastcgi 또는 XSP (4.x 버전의 모노) 및 XML 직렬화를 통해 웹 애플리케이션을 실행합니다. 처리 특성 및 상당히 느리게 WinForms, 특히 정규식과 관련이 있습니다 (ASP.NET-MVC는 라우팅에도 정규식을 사용합니다).

모노 2.x, 3.x 및 4.x에 대한 내 경험에 대해 글을 쓸 때, 현재 또는이 기사를 읽거나 읽을 때까지 이러한 문제가 해결되지 않았다는 의미는 아닙니다. 나중에 수정되어 이러한 버그 / 기능을 다시 소개하는 회귀가 없을 수 있습니다. 또한 모노 런타임을 포함하면 (dev) 시스템의 모노 런타임을 사용할 때와 동일한 결과를 얻을 수 있습니다. 또한 단일 런타임 (어디서나)을 포함시키는 것이 반드시 무료라는 의미는 아닙니다.

모노가 iOS 또는 Android에 적합하지 않거나 동일한 문제가 있음을 의미하지는 않습니다. 나는 안드로이드 또는 IOS에서 모노를 사용하지 않으므로이 플랫폼의 안정성, 유용성, 비용 및 성능에 대해 아무 말도하지 않습니다 . 분명히 Android에서 .NET을 사용하는 경우 xamarin-weights 대 비용 및 기존 코드를 Java로 이식하는 데 드는 시간 및 비용과 같은 다른 비용 고려 사항도 있습니다. 하나는 안드로이드에서 모노를 듣고 IOS는 꽤 좋을 것입니다. 소금 한알과 함께 섭취하십시오. 하나는 기본 시스템 인코딩이 android / ios와 Windows에서 동일 할 것으로 기대하지 말고 안드로이드 파일 시스템이 대소 문자를 구분하지 않으며 Windows 글꼴이 없을 것으로 예상하지 마십시오 .

---

답변