Công Nghệ & Ứng Dụng

Những ứng dụng sẽ bị loại bỏ trong .NET 5

Wikicabinet – Kênh thông tin tri thức nhân loại kính chào quý độc giả ở kỳ trước chúng tôi đã giới thiệu các chủ đề về:

Blockchain và tín dụng phân tán

Kỳ này wikicabinet xin giới thiệu đến độc giả một chủ đề Những ứng dụng sẽ bị loại bỏ trong .NET 5. Mời quý độc giả đón theo dõi chủ đề này cùng wikicabinet nhé!

Trong bài viết này, chúng tôi sẽ xem xét một số công nghệ .NET trước đây không vào được .NET Core. Điều thú vị là các API của những công nghệ này đã bị sao chép, điều này ngụ ý rằng Microsoft đang xem xét triển khai chúng trong .NET Core trong tương lai.

Bộ nhớ cache lắp ráp toàn cầu

Lý thuyết đằng sau Global Assembly Cache (GAC) là tất cả các thư viện .NET có thể được lưu trữ ở một vị trí tập trung duy nhất. Theo cách này, nó tương tự như thư viện COM. Nhưng không giống như COM, nó có thể lưu trữ nhiều phiên bản của mỗi thư viện. Bằng cách này, Microsoft hy vọng sẽ tránh được viễn cảnh “DLL hell” đã từng gây ra cho các ứng dụng trong những năm 1990.

Tuy nhiên, vấn đề phiên bản vẫn tồn tại. Ngoài ra, nhu cầu lấy chứng chỉ ký mã và tính bảo mật được tăng cường mà Windows Vista mang lại khiến GAC trở thành một công nghệ khó chịu. Vào thời điểm phát hành .NET 4.5, một số ứng dụng sử dụng GAC cho các thư viện không phải của Microsoft. Ngoại lệ chính là các thư viện thương mại, nhưng ngay cả những thư viện này cũng đã chuyển sang mô hình phân phối thân thiện hơn với NuGet.

Do đó, không có gì ngạc nhiên khi Microsoft đã thay đổi cơ bản triết lý của họ trong .NET Core. Trong mô hình mới, tất cả các phụ thuộc thư viện được triển khai cùng với ứng dụng, điều này cho phép ứng dụng được cách ly khỏi các ứng dụng .NET Core khác. Do đó, không có khái niệm GAC trong .NET Core.

Tuy nhiên, API GAC vẫn tồn tại trong .NET Core. Chúng không làm được gì nhiều, ví dụ, thuộc tính cho biết liệu assembly có trong GAC hay không được mã hóa cứng để trả về false.

Để làm rõ thêm ý định, tất cả các API GAC hiện được đánh dấu là lỗi thời và Microsoft đang xem xét loại bỏ chúng trong một phiên bản trong tương lai, chẳng hạn như .NET 5.

Remoting

.NET Remoting được lấy cảm hứng từ DCOM và Java Remoting (Java RMI). Ý tưởng cơ bản của ba phương pháp này là một ứng dụng có thể sử dụng các đối tượng proxy để thao tác các đối tượng thực đang chạy trong một ứng dụng khác. Mặc dù nó hoạt động về mặt kỹ thuật, .NET Remoting chưa bao giờ phổ biến vì rất khó sử dụng nó một cách chính xác và thường được coi là dễ hỏng.

Với lưu ý này, .NET Core chưa bao giờ triển khai .NET Remoting API. Cũng giống như API GAC, nó chỉ có các trình giữ chỗ không thể hoạt động. Do đó, chúng cũng bị đánh dấu là lỗi thời, và mục tiêu cuối cùng là xóa chúng trong .NET 5.

Bảo mật truy cập mã

Tiếp tục chủ đề này, Code Access Security (CAS) là một công nghệ .NET Framework khác đã được sao chép sang .NET Core nhưng bị đánh dấu là lỗi thời.

Bảo mật truy cập mã đã được tạo trước khi các vùng chứa biệt lập như Docker. Trong kỷ nguyên của .NET Framework, nhiều ứng dụng sẽ được lưu trữ trong một phiên bản duy nhất của Máy chủ Thông tin Internet (IIS). Về lý thuyết, mỗi ứng dụng sẽ được cách ly với một miền ứng dụng riêng, nhưng không khó để phá vỡ sự cô lập này và can thiệp vào các ứng dụng khác đang chạy trong IIS.

Bảo mật truy cập mã được tạo ra để hạn chế thiệt hại có thể xảy ra này. Ý tưởng cơ bản là các API nguy hiểm sẽ được thêm vào các thuộc tính chỉ ra rủi ro. Các máy chủ như IIS có thể được cấu hình để chạy các ứng dụng với các mức độ “tin cậy” khác nhau, về lý thuyết, đặt chúng trong một hộp cát.

Một cách sử dụng khác của CAS là dành cho các ứng dụng được lưu trữ trên trình duyệt. Rất lâu trước khi Silverlight xuất hiện, người ta đã có thể chạy các ứng dụng Windows Forms trong Internet Explorer. Mức độ tin cậy của một ứng dụng phụ thuộc một phần vào nơi nó được tải và các trang web nội bộ sẽ nhận được quyền cao hơn.

Nhưng giống như nhiều công nghệ .NET ban đầu, rất khó để triển khai CAS một cách chính xác. Có nhiều cách để các ứng dụng độc hại vượt qua các hạn chế của CAS và các ứng dụng lành tính thường bị hạn chế bởi những hạn chế này. Do đó, các ứng dụng được lưu trữ trên trình duyệt nhanh chóng vô hiệu hóa nó và IIS phần lớn bỏ qua mức độ tin cậy CAS.

Thread.Abort

Điều này có thể làm bạn ngạc nhiên. Thread.Abort chưa bao giờ được triển khai trong .NET Core. Mặc dù luôn được coi là nguy hiểm nhưng nó luôn không thể tránh khỏi. Trong ASP.NET, những thứ đơn giản như thời gian chờ yêu cầu hoặc ngắt kết nối máy khách sẽ kích hoạt cuộc gọi Thread.Abort . Nếu bạn không viết mã cẩn thận để đối phó với nó, điều này có thể dẫn đến rò rỉ tài nguyên, chẳng hạn như khóa có được hoặc giao dịch cơ sở dữ liệu mở.

Vào thời điểm ASP.NET Core được tạo, CancelToken đã trở thành một giải pháp thay thế an toàn và được chấp nhận rộng rãi cho Thread.Abort , vì vậy không cần phải triển khai nó trong phiên bản .NET Core đầu tiên. Mặc dù .NET Core đã mở rộng chức năng của nó ra ngoài trang Web, nhưng các khung ứng dụng chính khác không yêu cầu Thread.Abort , vì vậy nó sẽ tiếp tục ném PlatformNotSupportedException .

Trong .NET 5, phương pháp này cuối cùng đã bị đánh dấu là lỗi thời.

Trong kỳ tiếp theo, Wikicabinet  trân trọng mời độc giả đón đọc chủ đề Triển vọng cho các sản phẩm mới của Apple vào năm 2021.

Nếu có những thắc mắc hay muốn tìm hiểu về bất kỳ chủ đề nào, hãy liên hệ với Wikicabinet bằng cách bình luận ở phía dưới nhé.

Leave a Reply