Đối với các giải pháp dựa trên cửa sổ doanh nghiệp, .NET đôi khi là sự lựa chọn tốt nhất. Mono nhìn vào các doanh nghiệp phải sử dụng Linux như thế nào (hay đúng hơn là thích sử dụng Linux)? Giả sử rằng các nhà phát triển không phải là một vấn đề và họ đã quen thuộc với .NET / Mono và các đối thủ cạnh tranh có thể khác như Java.
Liệu một công ty vừa / lớn có chạy Mono trên máy chủ của họ trái ngược với các công nghệ như Java không? Bạn có biết công ty nào như vậy không?
Câu trả lời:
Chúng tôi đã sử dụng nó trong tập đoàn lớn nơi tôi làm việc. Chúng tôi đã không lên kế hoạch cho nó từ khi bắt đầu dự án nhưng nó đã hoạt động theo cách đó.
Chúng tôi đã có một dự án nội bộ mà chúng tôi đã phát triển bằng .NET, khi chúng tôi tham gia vào UAT, chủ doanh nghiệp muốn mở ứng dụng cho một số khách hàng cũng như nhân viên nội bộ. Phần lớn các máy chủ bên ngoài (DMZ) của chúng tôi đều dựa trên Linux và các máy chủ Windows trong DMZ không phù hợp (quá gần với dung lượng). Thay vì mua phần cứng mới, có người đề nghị chạy ứng dụng trên Mono. Chúng tôi đã dành vài ngày để thực hiện thử nghiệm của riêng mình và sau đó phát hành ứng dụng cho QA, sau đó là UAT. Chúng tôi không có vấn đề.
Nếu chúng tôi đã được đưa ra yêu cầu khi bắt đầu dự án, chúng tôi có thể không chọn viết nó bằng .NET, nhưng đây là một kết quả tốt cho sự thay đổi yêu cầu rất, rất muộn. Bây giờ chúng tôi khá tự tin rằng nếu nó xuất hiện trở lại, chúng tôi có thể triển khai thành công Mono (mặc dù tôi nghĩ cuối cùng chúng tôi sẽ phải điều chỉnh một số mã, tôi nghĩ rằng chúng tôi đã gặp may mắn).
Tôi chưa sử dụng đơn thương mại, nhưng tôi sử dụng riêng, vì tôi làm việc trong một công ty Windows, nhưng riêng tôi là người dùng Linux (vì vậy tôi có thể sử dụng lại những gì tôi làm trong công việc).
Nhìn chung, tôi đồng ý với Miguel de Icaza, người nói:
- 25% ứng dụng .NET hoạt động tốt với mono
- 25% khác có thể được thực hiện để làm việc trong vòng một ngày hoặc ít hơn
- hơn 25% có thể được thực hiện để làm việc trong vòng một tuần
- 25% cuối cùng yêu cầu viết lại hoàn toàn ứng dụng (WinForms / COM)
Mono hoạt động khá tốt, nhưng có một số vấn đề:
- VB.NET chỉ hỗ trợ cho .NET <= 2.0
- Xác thực Windows không được thực hiện
- WPF không được thực hiện
- Hỗ trợ WCF không đầy đủ
- Khung thực thể không được triển khai và không có kế hoạch thực hiện
- "Phần Web ASP.NET" không được triển khai
- Không hỗ trợ COM-interop
- Kết nối Sybase cho phiên bản 15,5 (mới nhất) không hoạt động
- Lỗi và không đầy đủ trong thư viện lớp C # (ví dụ: XML bị lỗi trong đơn âm <2.6)
- Kiểm soát trình duyệt web Linux yêu cầu GTK #
Sau đó, các vấn đề nhỏ:
- Windows Forms hoạt động, nhưng không phải lúc nào cũng được hiển thị đúng
- MonoDevelop không thể thiết kế các mẫu cửa sổ
- MonoDevelop 'bước qua' gỡ lỗi không thực sự hoạt động
- Dịch vụ đơn nhân gặp sự cố sau 5 giờ ...
Hình thành những gì tôi có thể nói:
- Chức năng dịch vụ web xuất sắc
- Nếu bạn chạy WebApplication, nó hoạt động khá tốt (nếu nó không sử dụng WebParts).
- Nếu bạn chạy WindowsForms, nó sẽ luôn trông rất đẹp (ít nhất là như vậy).
- Không có dịch vụ tương đương với Dịch vụ báo cáo của Microsoft (FYIreporting là thứ gần gũi nhất với nó, nhưng nó chậm, lỗi và rất không đầy đủ, cộng với không có hoạt động nào sau hơn một năm)
- Bạn sẽ gặp vấn đề nếu bạn cần tạo tài liệu Word hoặc Excel.
Nếu bạn muốn phát triển .NET trên Linux
- Bạn có thể phát triển ASP.NET ở đó (gỡ lỗi và từng bước hoạt động rất tệ)
- Bạn thực sự không thể phát triển WinForms trên Linux
- Bạn cần sử dụng GTK # thay vì WinForms
Nói cách khác:
- Mono có chỗ trong việc chạy các ứng dụng web và WebService và MailServers.
- Nhưng không thể chạy các ứng dụng WindowsForms, bạn cần viết các ứng dụng với GTK #
- Nó thiếu một giải pháp báo cáo và hỗ trợ định dạng tệp MS (hoặc do đó thư viện làm việc)
Chỉnh sửa (cập nhật 2015):
Bây giờ tôi muốn thêm rằng, 'từng bước' gỡ lỗi hoạt động xuất sắc và bạn có thể sử dụng MonoDevelop để phát triển các ứng dụng web trên Linux, ngay cả với các phụ thuộc nuGet. Vấn đề với các thư viện Excel và Word cũng không còn nữa, và khung thực thể hiện là nguồn mở. Phần còn lại là khá nhiều "như hiện tại" (không biết liệu dịch vụ đơn có được sửa hay không, nhưng tôi sẽ hy vọng như vậy).
Điều cải thiện là giờ đây bạn có thể có các gói hiện tại cho bản phân phối của mình, nghĩa là bạn không cần đợi đến bản phát hành tiếp theo, nói Debian / Ubuntu, cho đến khi bạn có được phiên bản đơn âm mới nhất (mà không phải tự biên dịch chúng ). Đây là một thời gian lớn an toàn hơn.
Ngoài ra, với việc phát hành Roslyn, hỗ trợ VB.NET sẽ tốt hơn rất nhiều trong tương lai gần.
Công ty của tôi phát triển một ứng dụng chủ yếu là .NET. Phát hành các phiên bản Linux chạy trên Mono, vì vậy tôi sẽ nói có, chắc chắn có một vị trí cho Mono trong các giải pháp dựa trên Windows dành cho doanh nghiệp.
Chúng tôi gói Mono với việc cài đặt ứng dụng của chúng tôi, không yêu cầu người dùng cài đặt riêng (và cách này chúng tôi cũng kiểm soát phiên bản).
Tôi nghĩ rằng mối quan tâm chính mà nhiều tập đoàn sẽ có là vấn đề giấy phép giữa Mono và Microsoft. Tôi hiểu rằng trong khi Microsoft đã chính thức đồng ý rằng Mono có thể sử dụng các công nghệ .NET cốt lõi, nhưng bên ngoài đó, bao gồm cả những thứ được sử dụng rất phổ biến, là một khu vực màu xám hợp pháp với Microsoft không nêu rõ vị trí của nó theo cách này hay cách khác
Điều đó rõ ràng để ngỏ khả năng rằng họ sẽ yêu cầu lệ phí cấp giấy phép hoặc chỉ kiện vi phạm bằng sáng chế. Không chắc là điều đó sẽ xảy ra từ cách họ cư xử ngay bây giờ nhưng hầu hết các doanh nghiệp không thích sự không chắc chắn đó, đặc biệt là khi nó đi kèm với các khoản nợ và chi phí tiềm năng kèm theo.
Tôi không nghĩ có nhiều không gian cho Mono ở đó:
Java đã được thiết lập nền tảng trên Linux, với cộng đồng lớn và rất nhiều thư viện và công cụ chất lượng doanh nghiệp, cả thương mại và nguồn mở. Tôi không thấy bất kỳ lý do nào để chọn Mono qua Java khi bắt đầu dự án mới nhắm mục tiêu Linux (hoặc Mac), trừ khi có một số trường hợp cụ thể (xem câu trả lời của Walter).
Trước khi sử dụng mono, chúng tôi phải đảm bảo không có mã hóa '\' cho chuỗi đường dẫn (sử dụng tiền tố Path.Combine ()) hoặc "COM" (chỉ chấp nhận chuỗi thay vì số nguyên) cho cổng nối tiếp trong chương trình.
Những gì hoạt động tốt:
Những vấn đề bắt gặp:
Tốt hơn là sử dụng mono trong nội bộ (như hệ thống ERP) làm môi trường được kiểm soát.
Mono là một thay thế tuyệt vời nếu bạn đã có mã .NET cần chạy trên môi trường đa nền tảng. Mono được sử dụng khá rộng rãi trong thế giới kinh doanh đặc biệt để giải quyết vấn đề này.
Tôi sẽ tranh luận về việc sử dụng sự tồn tại của Mono như một cái cớ để bắt đầu một dự án với .NET mà bạn biết sẽ cần phải đa nền tảng. Lý do cho điều này là độ trễ giữa công nghệ tiên tiến với .NET so với tốc độ phát triển của Mono.
Mặt khác, nếu bạn làm có ý định sử dụng Mono trong một dự án trong tương lai, tôi sẽ thận trọng bạn nhắm mục tiêu khuôn khổ Mono và chạy trên NET như một lựa chọn phổ thông kể từ Mono phần lớn là một tập hợp con của các chức năng đầy đủ NET.