Necromance.
Cung cấp một câu trả lời thực tế.
Sự khác biệt giữa .Net Core và Mono là gì?
.NET Core chính thức là tương lai của .NET. Nó bắt đầu với hầu hết các phần với việc viết lại khung ASP.NET MVC và các ứng dụng bảng điều khiển, tất nhiên bao gồm các ứng dụng máy chủ. (Vì đây là Turing-đầy đủ và hỗ trợ interop với dlls C, bạn có thể, nếu bạn hoàn toàn muốn, cũng viết các ứng dụng máy tính để bàn của riêng bạn với nó, ví dụ thông qua thư viện của bên thứ 3 như Avalonia, một chút rất cơ bản tại lần đầu tiên tôi viết bài này, điều đó có nghĩa là bạn bị giới hạn khá nhiều đối với công cụ web hoặc máy chủ.) Theo thời gian, nhiều API đã được thêm vào .NET Core, đến mức sau phiên bản 3.1, .NET Core sẽ chuyển sang phiên bản 5.0, được gọi là .NET 5.0 mà không có "Core" và đó sẽ là tương lai của .NET Framework. Cái từng là .NET Framework đầy đủ sẽ tồn tại trong chế độ bảo trì như Full .NET Framework 4.8.x trong vài thập kỷ, cho đến khi nó chết (có thể vẫn còn một số nâng cấp, nhưng tôi nghi ngờ về điều đó). Nói cách khác, .NET Core là tương lai của .NET và Full .NET Framework sẽ đi theo con đường của Dodo / Silverlight / WindowsPhone .
Điểm chính của .NET Core, ngoài hỗ trợ đa nền tảng, là cải thiện hiệu năng và cho phép "biên dịch gốc" / triển khai khép kín (vì vậy bạn không cần cài đặt .NET framework / VM trên máy đích .
một mặt, các phương tiện này docker.io hỗ trợ trên Linux, và mặt khác, triển khai khép kín rất hữu ích trong "điện toán đám mây", vì sau đó bạn chỉ có thể sử dụng bất kỳ phiên bản của khuôn khổ dotnet-CORE bạn thích, và bạn không phải lo lắng về phiên bản .NET framework nào mà sysadmin đã thực sự cài đặt.
Mặc dù thời gian chạy .NET Core hỗ trợ nhiều hệ điều hành và bộ xử lý, SDK là một câu chuyện khác. Và trong khi SDK hỗ trợ nhiều HĐH, hỗ trợ ARM cho SDK vẫn đang được thực hiện. .NET Core được hỗ trợ bởi Microsoft. Dotnet-Core không đi kèm với WinForms hoặc WPF hoặc bất cứ thứ gì tương tự.
- Kể từ phiên bản 3.0, WinForms và WPF cũng được .NET Core hỗ trợ, nhưng chỉ trên Windows và chỉ bởi C #. Không phải bởi VB.NET (hỗ trợ VB.NET được lên kế hoạch cho v5 vào năm 2020). Và không có Trình thiết kế biểu mẫu trong .NET Core: nó sẽ được gửi cùng với bản cập nhật Visual Studio sau đó, tại một thời điểm không xác định.
- WebForms vẫn chưa được .NET Core hỗ trợ và chưa có kế hoạch hỗ trợ chúng ( Blazor là đứa trẻ mới trong thị trấn vì điều đó).
- .NET Core cũng đi kèm với System.R.78, thay thế mscorelib.
- Thông thường, .NET Core được trộn lẫn với NetSt Chuẩn , là một phần của trình bao bọc xung quanh System.R.78 / mscorelib (và một số người khác), cho phép bạn viết các thư viện nhắm mục tiêu .NET Core, Full .NET Framework và Xamarin (iOS / Android), tất cả cùng một lúc.
- .NET Core SDK không / không hoạt động trên ARM, ít nhất là lần trước tôi đã kiểm tra.
" Dự án Mono " cũ hơn nhiều so với .NET Core.
Mono là tiếng Tây Ban Nha và có nghĩa là Khỉ, và như một nhận xét phụ, tên này không liên quan gì đến bệnh bạch cầu đơn nhân (gợi ý: bạn có thể nhận được một danh sách nhân viên theo http://primates.imumian.com /).
Mono được bắt đầu vào năm 2005 bởi Miguel de Icaza (người bắt đầu Gnome - và một vài người khác) khi triển khai .NET Framework cho Linux (Ximian / SuSe / Novell). Mono bao gồm Web-Forms, Winforms, MVC, Olive và IDE có tên là MonoDevelop(còn được gọi là Xamarin Studio hoặc Visual Studio Mac). Về cơ bản tương đương với (OpenJDK) JVM và (OpenJDK) JDK / JRE (trái ngược với SUN / Oracle JDK). Bạn có thể sử dụng nó để có được các ứng dụng ASP.NET-WebForms + WinForms + ASP.NET-MVC hoạt động trên Linux.
Mono được hỗ trợ bởi Xamarin (tên công ty mới của Ximian, khi họ tập trung vào thị trường Di động, thay vì thị trường Linux), chứ không phải bởi Microsoft.
(kể từ khi Xamarin được Microsoft mua, về mặt kỹ thuật [nhưng không phải về mặt văn hóa] Microsoft.)
Bạn thường sẽ lấy công cụ C # của mình để biên dịch trên đơn âm, nhưng không phải là công cụ VB.NET.
Mono bỏ lỡ một số tính năng nâng cao, như WSE / WCF và WebParts.
Nhiều triển khai Mono không đầy đủ (ví dụ: ném NotImcellenceedException trong mã hóa ECDSA), lỗi (ví dụ ODBC / ADO.NET với Firebird), hoạt động khác với .NET (ví dụ như tuần tự hóa XML) hoặc không ổn định (ASP.NET MVC) và chậm chấp nhận (Regex). Mặt khác, chuỗi công cụ Mono cũng hoạt động trên ARM.
Theo như .NET Core có liên quan, khi họ nói rằng đa nền tảng, đừng mong đợi rằng đa nền tảng có nghĩa là bạn thực sự có thể chỉ cần cài đặt .NET Core trên ARM-Linux, giống như bạn có thể với ElasticSearch. Bạn sẽ phải biên dịch toàn bộ khung từ nguồn.
Đó là, nếu bạn có không gian đó (ví dụ: trên Chromebook, có tổng HD từ 16 đến 32 GB).
Nó cũng được sử dụng để có các vấn đề không tương thích với OpenSSL 1.1 và libcurl.
Những người đã được chỉnh sửa trong phiên bản .NET Core phiên bản 2.2 mới nhất.
Quá nhiều cho đa nền tảng.
Tôi tìm thấy một tuyên bố trên trang web chính thức có nội dung: "Mã được viết cho nó cũng có thể di động trên các ngăn xếp ứng dụng, chẳng hạn như Mono".
Miễn là mã đó không phụ thuộc vào các cuộc gọi WinAPI, Windows-dll-pinvokes, COM-Components, hệ thống tệp không phân biệt chữ hoa chữ thường, mã hóa hệ thống mặc định (codepage) và không có vấn đề phân tách thư mục, đó là chính xác. Tuy nhiên, mã .NET Core chạy trên .NET Core chứ không phải trên Mono. Vì vậy, trộn hai sẽ khó khăn. Và vì Mono khá không ổn định và chậm (đối với các ứng dụng web), nên dù sao tôi cũng không khuyên dùng nó. Hãy thử xử lý hình ảnh trên lõi .NET, ví dụ WebP hoặc di chuyển GIF hoặc nhiều trang hoặc viết văn bản trên một hình ảnh, bạn sẽ rất ngạc nhiên.
Lưu ý:
Kể từ .NET Core 2.0, có System.Drawing.Common (NuGet), chứa hầu hết các chức năng của System.Drawing. Nó nên có ít nhiều tính năng hoàn chỉnh trong .NET-Core 2.1. Tuy nhiên, System.Drawing.Common sử dụng GDI +, và do đó sẽ không làm việc trên Azure (thư viện System.Drawing có sẵn trong Azure đám mây dịch vụ [về cơ bản chỉ là một VM], nhưng không phải trong Azure Web App [về cơ bản chia sẻ lưu trữ?])
Vì vậy, cho đến nay, System.Drawing.Common hoạt động tốt trên Linux / Mac, nhưng có vấn đề trên iOS / Android - nếu nó hoạt động hoàn toàn, ở đó.
Trước .NET Core 2.0, tức là vào khoảng giữa tháng 2 năm 2017, bạn có thể sử dụng SkiaSharp để chụp ảnh (ví dụ) (bạn vẫn có thể).
Đăng .net-core 2.0, bạn sẽ nhận thấy SixLabors ImageSharplà cách để đi, vì System.Drawing không nhất thiết phải bảo mật và có nhiều rò rỉ bộ nhớ thực hoặc tiềm năng, đó là lý do tại sao bạn không nên sử dụng GDI trong các ứng dụng web; Lưu ý rằng SkiaSharp nhanh hơn ImageSharp rất nhiều, vì nó sử dụng các thư viện gốc (cũng có thể là một nhược điểm). Ngoài ra, lưu ý rằng mặc dù GDI + hoạt động trên Linux & Mac, điều đó không có nghĩa là nó hoạt động trên iOS / Android.
Mã không được viết cho .NET (không phải Core) không thể di chuyển sang .NET Core.
Có nghĩa là, nếu bạn muốn một thư viện C # không GPL như PDFSharp để tạo tài liệu PDF (rất phổ biến), bạn đã hết may mắn(tại thời điểm này)( không còn nữa ). Đừng bận tâm đến điều khiển ReportViewer, sử dụng Windows-pInvokes (để mã hóa, tạo tài liệu mcdf qua COM và để lấy phông chữ, ký tự, thông tin, phông chữ, đo chuỗi và thực hiện ngắt dòng và thực sự vẽ các đoạn có chất lượng chấp nhận được) và thậm chí không chạy trên Mono trên Linux
( Tôi đang làm việc trên đó ).
Ngoài ra, mã được viết bằng .NET Core không thể chuyển sang Mono, vì Mono thiếu các thư viện thời gian chạy .NET Core (cho đến nay).
Mục tiêu của tôi là sử dụng C #, LINQ, EF7, studio trực quan để tạo một trang web có thể chạy / lưu trữ trong linux.
EF trong bất kỳ phiên bản nào mà tôi đã thử cho đến nay đều rất chậm (ngay cả trên những thứ đơn giản như một bàn có một người tham gia trái), tôi cũng không khuyên dùng nó - không phải trên Windows.
Tôi đặc biệt không khuyến nghị EF nếu bạn có cơ sở dữ liệu với các ràng buộc duy nhất hoặc các cột varbinary / filestream / hVELyid. (Không phải để cập nhật lược đồ.)
Và cũng không phải trong trường hợp hiệu năng DB là quan trọng (giả sử 10+ đến hơn 100 người dùng đồng thời).
Ngoài ra, chạy một trang web / ứng dụng web trên Linux sớm hay muộn cũng có nghĩa là bạn sẽ phải gỡ lỗi nó.
Không có hỗ trợ sửa lỗi cho .NET Core trên Linux.(Không còn nữa, nhưng yêu cầu JetBrains Rider.)
MonoDevelop không (chưa) hỗ trợ gỡ lỗi các dự án .NET Core.
Nếu bạn có vấn đề, bạn phải tự lo liệu. Bạn sẽ phải sử dụng đăng nhập rộng rãi.
Hãy cẩn thận, lưu ý rằng đăng nhập rộng rãi sẽ lấp đầy đĩa của bạn ngay lập tức, đặc biệt nếu chương trình của bạn đi vào một vòng lặp vô hạn hoặc đệ quy.
Điều này đặc biệt nguy hiểm nếu ứng dụng web của bạn chạy bằng root, vì đăng nhập yêu cầu không gian logfile - nếu không còn chỗ trống, bạn sẽ không thể đăng nhập được nữa.
(Thông thường, khoảng 5% không gian đĩa được dành riêng cho người dùng root [hay còn gọi là quản trị viên trên Windows], do đó, ít nhất quản trị viên vẫn có thể đăng nhập nếu đĩa gần đầy. Nhưng nếu ứng dụng của bạn chạy bằng root, hạn chế đó không áp dụng cho việc sử dụng đĩa của họ và do đó logfiles của họ có thể sử dụng 100% dung lượng trống còn lại, do đó, ngay cả quản trị viên cũng không thể đăng nhập nữa.)
Do đó, tốt hơn hết là đừng mã hóa đĩa đó, nghĩa là, nếu bạn coi trọng dữ liệu / hệ thống của mình.
Ai đó nói với tôi rằng anh ấy muốn nó là "trong Mono", nhưng tôi không biết điều đó có nghĩa là gì.
Điều đó có nghĩa là anh ta không muốn sử dụng .NET Core hoặc anh ta chỉ muốn sử dụng C # trên Linux / Mac. Tôi đoán là anh ta chỉ muốn sử dụng C # cho một ứng dụng web trên Linux. .NET Core là cách để thực hiện điều đó, nếu bạn hoàn toàn muốn làm điều đó trong C #. Đừng đi với "Mono thích hợp"; Nhìn bề ngoài, nó có vẻ hoạt động lúc đầu - nhưng tin tôi đi, bạn sẽ hối hận vì ASP.NET MVC của Mono không ổn định khi máy chủ của bạn chạy dài hạn (dài hơn 1 ngày) - bạn đã được cảnh báo. Xem thêm các tài liệu tham khảo "chưa hoàn thành" khi đo hiệu suất Mono trên điểm chuẩn của techempower.
Tôi biết tôi muốn sử dụng khung .Net Core 1.0 với các công nghệ tôi đã liệt kê ở trên. Ông cũng nói rằng ông muốn sử dụng "cgi nhanh". Tôi cũng không biết điều đó có nghĩa là gì.
Điều đó có nghĩa là anh ta muốn sử dụng một WebServer đầy đủ tính năng hiệu suất cao như nginx (Engine-X), có thể là Apache.
Sau đó, anh ta có thể chạy mono / dotnetCore với lưu trữ dựa trên tên ảo (nhiều tên miền trên cùng một IP) và / hoặc cân bằng tải. Anh ta cũng có thể chạy các trang web khác với các công nghệ khác mà không yêu cầu số cổng khác trên máy chủ web. Điều đó có nghĩa là trang web của bạn chạy trên máy chủ fastcgi và nginx chuyển tiếp tất cả các yêu cầu web cho một tên miền nhất định thông qua giao thức fastcgi đến máy chủ đó. Điều đó cũng có nghĩa là trang web của bạn chạy trong một đường ống nhanh và bạn phải cẩn thận với những gì bạn làm, ví dụ: bạn không thể sử dụng HTTP 1.1 khi truyền tệp.
Nếu không, các tập tin sẽ bị cắt xén tại đích.
Xem thêm ở đây và ở đây .
Để kết luận:
.NET Core hiện tại (2016-09-28) không thực sự di động, cũng không thực sự đa nền tảng (đặc biệt là các công cụ gỡ lỗi).
Cũng không phải là biên dịch gốc dễ dàng, đặc biệt là cho ARM.
Và đối với tôi, nó cũng không giống như sự phát triển của nó là "thực sự kết thúc".
Ví dụ: System.Data.DataTable / DataAdaper.Update bị thiếu ...
(không còn nữa với .NET Core 2.0)
Cùng với các giao diện System.Data.Common.IDB *.(không còn nữa với .NET Core 1.1)
nếu đã từng có một lớp thường được sử dụng, DataTable / DataAd CHƯƠNG sẽ là ...
Ngoài ra, trình cài đặt Linux (.deb) không thành công, ít nhất là trên máy của tôi và tôi ' Tôi chắc chắn tôi không phải là người duy nhất gặp vấn đề đó.
Gỡ lỗi, có thể bằng Visual Studio Code, nếu bạn có thể xây dựng nó trên ARM (Tôi đã quản lý để làm điều đó - KHÔNG theo dõi bài đăng trên blog của Scott Hanselman nếu bạn làm điều đó - có một hướng dẫn trong wiki của VS-Code trên github), bởi vì họ không cung cấp thực thi.
Yeoman cũng thất bại. (Tôi đoán nó có liên quan đến phiên bản nodejs mà bạn đã cài đặt - Mã VS yêu cầu một phiên bản, Yeoman khác ... nhưng nó sẽ chạy trên cùng một máy tính. Khá khập khiễng
rằng nó nên chạy trên phiên bản nút được vận chuyển theo mặc định trên HĐH.
Đừng bận tâm rằng không nên phụ thuộc vào NodeJS ngay từ đầu.
Máy chủ kestell cũng đang hoạt động.
Và đánh giá theo kinh nghiệm của tôi với dự án đơn, tôi rất nghi ngờ họ đã từng thử nghiệm .NET Core trên FastCGI, hoặc họ có ý tưởng nào về việc hỗ trợ FastCGI cho khung của họ không, nói gì đến việc họ đã thử nghiệm nó để đảm bảo "mọi thứ đều hoạt động ". Trên thực tế, tôi vừa thử tạo một ứng dụng fastcgi với .NET Core và chỉ nhận ra rằng không có thư viện FastCGI cho .NET Core "RTM" ...
Vì vậy, khi bạn sẽ chạy .NET Core "RTM" phía sau nginx, bạn chỉ có thể thực hiện điều đó bằng cách ủy quyền các yêu cầu cho kestrell (máy chủ web có nguồn gốc từ nút bán kết thúc đó) - hiện tại không có hỗ trợ fastcgi trong .NET Core "RTM", AFAIK. Vì không có thư viện fastcgi lõi .net và không có mẫu, nên rất khó có ai thực hiện bất kỳ thử nghiệm nào trên khung để đảm bảo fastcgi hoạt động như mong đợi.
Tôi cũng đặt câu hỏi về hiệu suất.
Trong tiêu chuẩn công nghệ (sơ bộ) (vòng 13) , aspnetcore-linux xếp hạng 25% so với hiệu suất tốt nhất, trong khi các khung so sánh như Go (golang) xếp hạng 96,9% hiệu suất cao nhất (và đó là khi trả về bản rõ mà không có tệp chỉ truy cập hệ thống). .NET Core làm tốt hơn một chút về tuần tự hóa JSON, nhưng nó cũng không hấp dẫn (đạt 98,5% mức cao nhất, lõi .NET 65%). Điều đó nói rằng, nó có thể không thể tồi tệ hơn "đơn điệu".
Ngoài ra, vì nó vẫn còn tương đối mới, không phải tất cả các thư viện lớn đã được chuyển (chưa), và tôi nghi ngờ rằng một số trong số chúng sẽ được chuyển.
Hỗ trợ hình ảnh cũng là câu hỏi tốt nhất.
Đối với bất cứ điều gì mã hóa, thay vào đó hãy sử dụng BouncyCastle.
Bạn có thể giúp tôi hiểu tất cả các điều khoản này và nếu kỳ vọng của tôi là thực tế ?
Tôi hy vọng tôi đã giúp bạn có ý nghĩa hơn với tất cả các điều khoản này.
Theo như các cuộc thám hiểm của bạn:
Phát triển một ứng dụng Linux mà không biết gì về Linux là một ý tưởng thực sự ngu ngốc ngay từ đầu, và nó cũng chắc chắn sẽ thất bại theo cách này hay cách khác. Điều đó nói rằng, bởi vì Linux không có chi phí cấp phép, về nguyên tắc, đó là một ý tưởng tốt, NHƯNG CHỈ NẾU BẠN BIẾT BẠN LÀM GÌ.
Phát triển một ứng dụng cho một nền tảng mà bạn không thể gỡ lỗi ứng dụng của mình là một ý tưởng thực sự tồi tệ khác.
Phát triển cho fastcgi mà không biết hậu quả gì là một ý tưởng thực sự tồi tệ khác.
Làm tất cả những điều này trên nền tảng "thử nghiệm" mà không có bất kỳ kiến thức nào về các chi tiết cụ thể của nền tảng đó và không có hỗ trợ gỡ lỗi là tự sát, nếu dự án của bạn không chỉ là trang chủ cá nhân. Mặt khác, tôi đoán làm việc đó với trang chủ cá nhân của bạn cho mục đích học tập có lẽ sẽ là một trải nghiệm rất tốt - sau đó bạn có thể biết khung công tác và các vấn đề phi khung là gì.
Ví dụ, bạn có thể (lập trình) gắn kết vòng lặp fat32, hfs hoặc JFS không phân biệt chữ hoa chữ thường cho ứng dụng của bạn, để giải quyết các vấn đề về độ nhạy trường hợp (không nên sử dụng vòng lặp trong sản xuất).
Để tóm tắt
Hiện tại (2016-09-28), tôi sẽ tránh xa .NET Core (để sử dụng sản xuất). Có thể trong một đến hai năm, bạn có thể có một cái nhìn khác, nhưng có lẽ không phải trước đây.
Nếu bạn có một dự án web mới mà bạn phát triển, hãy khởi động nó trong .NET Core chứ không phải đơn âm.
Nếu bạn muốn một khung làm việc trên Linux (x86 / AMD64 / ARMhf) và Windows và Mac, không có phụ thuộc, tức là chỉ liên kết tĩnh và không phụ thuộc vào .NET, Java hoặc Windows, hãy sử dụng Golang thay thế. Nó trưởng thành hơn và hiệu suất của nó đã được chứng minh (Yahoo sử dụng nó với 1 triệu người dùng đồng thời) và golang có dung lượng bộ nhớ thấp hơn đáng kể. Ngoài ra golang nằm trong kho lưu trữ, cài đặt .deb không có vấn đề, biên dịch mã nguồn - không yêu cầu thay đổi - và golang (trong khi đó) có hỗ trợ gỡ lỗi với delve và JetBrainsGogland trên Linux (và Windows và Mac). Quá trình xây dựng (và thời gian chạy) của Golang cũng không phụ thuộc vào NodeJS, đây là một điểm cộng khác.
Theo như mono đi, tránh xa nó.
Không có gì đáng ngạc nhiên khi mono đã đi được bao xa, nhưng thật không may, điều đó không thay thế cho các vấn đề về hiệu suất / khả năng mở rộng và độ ổn định của nó cho các ứng dụng sản xuất.
Ngoài ra, phát triển đơn nhân đã khá chết, họ chủ yếu chỉ phát triển các phần có liên quan đến Android và iOS nữa, vì đó là nơi Xamarin kiếm tiền của họ.
Đừng mong đợi Phát triển Web là công dân hạng nhất Xamarin / mono.
.NET Core có thể đáng giá, nếu bạn bắt đầu một dự án mới, nhưng đối với các dự án dạng web lớn hiện có, việc chuyển qua phần lớn là không cần thiết, những thay đổi cần thiết là rất lớn. Nếu bạn có một dự án MVC, số lượng thay đổi có thể quản lý được, nếu thiết kế ứng dụng ban đầu của bạn là lành mạnh, điều này hầu như không xảy ra đối với hầu hết các ứng dụng được gọi là "phát triển trong lịch sử".
Cập nhật tháng 12 năm 2016: Trình
biên dịch gốc đã bị xóa khỏi bản xem trước .NET Core, vì nó chưa sẵn sàng ...
Có vẻ như họ đã cải thiện khá nhiều về điểm chuẩn tệp văn bản thô, nhưng mặt khác, nó đã bị lỗi khá nhiều. Ngoài ra, nó tiếp tục xấu đi trong các điểm chuẩn JSON. Cũng tò mò rằng khung thực thể sẽ được cập nhật nhanh hơn Dapper - mặc dù cả hai đều chậm. Điều này rất khó xảy ra. Có vẻ như vẫn còn nhiều hơn một vài lỗi để săn.
Ngoài ra, dường như có sự giải thoát trên mặt trận Linux IDE.
JetBrains đã phát hành "Project Rider", bản xem trước truy cập sớm của C # /. NET Core IDE cho Linux (và Mac và Windows), có thể xử lý các tệp Visual Studio Project. Cuối cùng, một IDE C # có thể sử dụng được và nó không chậm như địa ngục.
Kết luận: .NET Core vẫn là phần mềm chất lượng trước khi phát hành vào năm 2017. Chuyển các thư viện của bạn, nhưng tránh xa nó để sử dụng sản xuất, cho đến khi chất lượng khung ổn định.
Và để mắt đến Project Rider.
Cập nhật 2017
Đã chuyển trang chủ của tôi (anh trai) sang .NET Core.
Cho đến nay, thời gian chạy trên Linux dường như đủ ổn định (ít nhất là đối với các dự án nhỏ) - nó đã vượt qua thử nghiệm tải một cách dễ dàng - mono chưa bao giờ làm.
Ngoài ra, có vẻ như tôi đã trộn lẫn triển khai .NET-Core -igen và .NET-Core-khép kín. Việc triển khai khép kín hoạt động, nhưng nó hơi kém, mặc dù nó rất dễ dàng (công cụ xây dựng / xuất bản hơi không ổn định - tuy nhiên - nếu bạn gặp phải "Số dương yêu cầu. - Xây dựng FAILED." - chạy lại lệnh tương tự, Và nó hoạt động).
Bạn có thể chạy
dotnet restore -r win81-x64
dotnet build -r win81-x64
dotnet publish -f netcoreapp1.1 -c Release -r win81-x64
Lưu ý: Theo .NET Core 3, bạn có thể xuất bản mọi thứ được rút gọn thành một tệp duy nhất :
dotnet publish -r win-x64 -c Release /p:PublishSingleFile=true
dotnet publish -r linux-x64 -c Release /p:PublishSingleFile=true
Tuy nhiên, không giống như go, nó không phải là tệp thực thi được liên kết tĩnh mà là tệp zip tự giải nén, vì vậy khi triển khai, bạn có thể gặp sự cố, đặc biệt là nếu thư mục tạm thời bị khóa bởi chính sách nhóm hoặc một số vấn đề khác . Mặc dù vậy, hoạt động tốt cho một chương trình hello-world. Và nếu bạn không thu nhỏ, kích thước thực thi sẽ ở mức khoảng 100 MB.
Và bạn nhận được một tệp .exe độc lập (trong thư mục xuất bản), bạn có thể chuyển sang máy Windows 8.1 mà không cần cài đặt .NET framework và để nó chạy. Đẹp. Ở đây, dotNET-Core mới bắt đầu trở nên thú vị. (lưu ý đến các lỗ hổng, SkiaSharp không hoạt động trên Windows 8.1 / Windows Server 2012 R2, [chưa] - hệ sinh thái phải bắt kịp trước - nhưng thật thú vị, Skia-dll-load-fail không làm sập toàn bộ máy chủ / ứng dụng - vì vậy mọi thứ khác hoạt động)
(Lưu ý: SkiaSharp trên Windows 8.1 thiếu các tệp thời gian chạy VC thích hợp - msvcp140.dll và vcr nb140.dll. Sao chép chúng vào thư mục xuất bản và Skia sẽ hoạt động trên Windows 8.1.)
Tháng 8 năm 2017 Cập nhật
.NET Core 2.0 được phát hành.
Hãy cẩn thận - đi kèm với các thay đổi (phá vỡ lớn) trong xác thực ...
Về mặt ưu điểm, nó đã đưa các lớp DataTable / DataAdaper / Dataset trở lại và nhiều hơn nữa.
.NET Core đã thực hiện vẫn thiếu hỗ trợ cho Apache SparkQuery, vì Mobius chưa được chuyển. Điều đó thật tệ, bởi vì điều đó có nghĩa là không có hỗ trợ SparkQuery cho IoT Cassandra Cluster của tôi, vì vậy không tham gia ...
Hỗ trợ ARM thử nghiệm (chỉ thời gian chạy, không phải SDK - quá tệ cho việc phát triển trên Chromebook của tôi - mong chờ 2.1 hoặc 3.0).
PdfSharp hiện được chuyển thử nghiệm sang .NET Core.
Kỵ sĩ phản lựccòn lại EAP. Bây giờ bạn có thể sử dụng nó để phát triển và gỡ lỗi .NET Core trên Linux - mặc dù cho đến nay chỉ có .NET Core 1.1 cho đến khi bản cập nhật cho hỗ trợ .NET Core 2.0 được phát hành.
Tháng 5 năm 2018 Cập nhật
.NET Core 2.1 sắp phát hành. Có thể điều này sẽ khắc phục xác thực NTLM trên Linux (xác thực NTLM không hoạt động trên Linux {và có thể cả Mac} trong .NET-Core 2.0 với nhiều tiêu đề xác thực, như đàm phán, thường được gửi bằng trao đổi ms và rõ ràng là chúng chỉ sửa nó trong v2.1, không phát hành lỗi cho 2.0).
Nhưng tôi không cài đặt bản phát hành xem trước trên máy của mình. Vì vậy, chờ đợi.
v2.1 cũng được cho là làm giảm đáng kể thời gian biên dịch. Sẽ tốt thôi.
Ngoài ra, lưu ý rằng trên Linux, .NET Core chỉ là 64-bit !
Không có, và sẽ không có phiên bản .NET Core x86-32 trên Linux .
Và cổng ARM chỉ là ARM-32. Chưa có ARM-64.
Và trên ARM, bạn (hiện tại) chỉ có thời gian chạy, không có dotnet-SDK.
Và một điều nữa:
Bởi vì .NET-Core sử dụng OpenSSL 1.0, .NET Core trên Linux không chạy trên Arch Linux và do phái sinh không phải trên Manjaro (bản phân phối Linux phổ biến nhất tại thời điểm này), bởi vì Arch Linux sử dụng OpenSSL 1.1.Vì vậy, nếu bạn đang sử dụng Arch Linux, bạn cũng sẽ gặp may (với Gentoo).
Biên tập:
Phiên bản mới nhất của .NET Core 2.2+ hỗ trợ OpenSSL 1.1. Vì vậy, bạn có thể sử dụng nó trên Arch hoặc (k) Ubuntu 19.04+. Bạn có thể phải sử dụng tập lệnh cài đặt .NET-Core , vì chưa có gói nào.
Về mặt tích cực, hiệu suất chắc chắn đã được cải thiện:
Lõi .NET 3:
.NET-Core v 3.0 được cho là sẽ mang WinForms và WPF lên .NET-Core.
Tuy nhiên, trong khi WinForms và WPF sẽ là .NET Core, WinForms và WPF trong .NET-Core sẽ chỉ chạy trên Windows, vì WinForms / WPF sẽ sử dụng API Windows.
Lưu ý:
.NET Core 3.0 hiện đã ra (RTM) và có hỗ trợ WinForms và WPF, nhưng chỉ dành cho C # (trên Windows). Không có WinForms-Core-Designer . Cuối cùng, nhà thiết kế sẽ đi kèm với bản cập nhật Visual Studio. Hỗ trợ WinForms cho VB.NET không được hỗ trợ , nhưng được lên kế hoạch cho .NET 5.0 vào năm 2020 .
Tái bút
echo "DOTNET_CLI_TELEMETRY_OPTOUT=1" >> /etc/environment
export DOTNET_CLI_TELEMETRY_OPTOUT=1
Nếu bạn đã sử dụng nó trên windows, có lẽ bạn chưa bao giờ thấy điều này:
Các công cụ .NET Core thu thập dữ liệu sử dụng để cải thiện trải nghiệm của bạn.
Dữ liệu là ẩn danh và không bao gồm các đối số dòng lệnh.
Dữ liệu được Microsoft thu thập và chia sẻ với cộng đồng.
Bạn có thể từ chối từ xa bằng cách đặt biến môi trường DOTNET_CLI_TELEMETRY_OPTOUT thành 1 bằng cách sử dụng trình bao yêu thích của bạn.
Bạn có thể đọc thêm về các công cụ .NET Core từ xa @
https://aka.ms/dotnet-cli-telemetry .
Tôi nghĩ rằng tôi đã đề cập đến việc tôi nghĩ rằng monodevelop (hay còn gọi là Xamarin Studio, Mono IDE hay Visual Studio Mac như bây giờ được gọi trên Mac) đã phát triển khá độc đáo và - trong khi đó - phần lớn có thể sử dụng được.
Tuy nhiên, JetBrains Rider (EAP 2018 tại thời điểm này) chắc chắn là đẹp hơn và đáng tin cậy hơn (và trình dịch ngược bao gồm là an toàn hơn cho cuộc sống), nghĩa là, nếu bạn phát triển .NET-Core trên Linux hoặc Mac. Mặc dù vậy, MonoDevelop không hỗ trợ Debug-StepTh khóa trên Linux trong .NET Core, vì MS không cấp phép cho dll API gỡ lỗi của họ (ngoại trừ VisualStudio Mac ...). Tuy nhiên, bạn có thể sử dụng trình gỡ lỗi Samsung cho .NET Core thông qua phần mở rộng trình gỡ lỗi .NET Core cho Samsung Debugger cho MonoDevelop
Tuyên bố miễn trừ trách nhiệm:
Tôi không sử dụng Mac, vì vậy tôi không thể nói nếu những gì tôi viết ở đây cũng áp dụng cho Mac dựa trên FreeBSD-Unix. Tôi đang đề cập đến phiên bản Linux (Debian / Ubuntu / Mint) của JetBrains Rider, mono, MonoDevelop / VisualStudioMac / XamarinStudio và .NET-Core. Ngoài ra, Apple đang dự tính chuyển từ bộ xử lý Intel sang bộ xử lý dựa trên ARM (ARM-64?) Tự sản xuất, rất nhiều điều áp dụng cho Mac ngay bây giờ có thể không áp dụng cho Mac trong tương lai (2020+).
Ngoài ra, khi tôi viết "mono khá không ổn định và chậm", sự không ổn định liên quan đến các ứng dụng WinFroms & WebForms, đặc biệt là thực thi các ứng dụng web thông qua fastcgi hoặc với XSP (trên phiên bản 4.x của mono), cũng như tuần tự hóa XML đặc thù - thủ công và khá chậm liên quan đến WinForms và các biểu thức thông thường nói riêng (ASP.NET-MVC cũng sử dụng các biểu thức chính quy để định tuyến).
Khi tôi viết về trải nghiệm của mình về mono 2.x, 3.x và 4.x, điều đó cũng không nhất thiết có nghĩa là những vấn đề này chưa được giải quyết vào lúc này, hoặc vào lúc bạn đang đọc nó, cũng không phải nếu chúng là đã sửa bây giờ, rằng không thể có hồi quy sau đó giới thiệu lại bất kỳ lỗi / tính năng nào trong số này. Điều đó cũng không có nghĩa là nếu bạn nhúng thời gian chạy đơn, bạn sẽ nhận được kết quả giống như khi bạn sử dụng thời gian chạy đơn của hệ thống (dev). Điều đó cũng không có nghĩa là việc nhúng thời gian chạy đơn (bất cứ nơi nào) là hoàn toàn miễn phí.
Tất cả điều đó không nhất thiết có nghĩa là mono không phù hợp với iOS hoặc Android hoặc nó có cùng một vấn đề ở đó. Tôi không sử dụng mono trên Android hoặc IOS, vì vậy tôi không có ý định nói gì về tính ổn định, tính khả dụng, chi phí và hiệu suất trên các nền tảng này. Rõ ràng, nếu bạn sử dụng .NET trên Android, bạn cũng có một số cân nhắc về chi phí khác, chẳng hạn như trọng số xamarin-chi phí so với chi phí và thời gian để chuyển mã hiện có sang Java. Một người nghe thấy mono trên Android và IOS sẽ khá tốt. Mang nó theo một hạt muối. Đối với một người, đừng hy vọng mã hóa hệ thống mặc định giống nhau trên Android / ios so với Windows và đừng hy vọng hệ thống tệp android không phân biệt chữ hoa chữ thường và đừng mong đợi bất kỳ phông chữ windows nào xuất hiện .