.net System.Drawing.Color和System.Windows.Media.Color之间有什么区别？

基本上，为什么需要一个非常简单的概念的两个抽象？

System.Windows.Media.Color是名称空间的一部分：

提供了允许在Windows演示基础（WPF）应用程序中集成富媒体，包括绘图、文本和音频/视频内容的类型。

System.Drawing.Color

是名称空间的一部分：

System.Drawing命名空间提供对GDI+基本图形功能的访问。System.Drawing.Drawing2D、System.Drawing.Imaging和System.Drawing.Text命名空间中提供了更高级的功能

我猜后者是Windows专用的，而前者更通用，更容易移植到Mac OS等，用于Silverlight应用程序

在后一个名称空间上也有这样的注意事项，它倾向于支持这一点：

Windows或ASP.NET服务中不支持System.Drawing命名空间中的类。试图在这些应用程序类型中使用这些类可能会产生意外问题，例如服务性能降低和运行时异常

我不认为有这样的“需要”，只是他们早期（可能是错误的）决定将Color类放入WinForms特定的System.Drawing中——因为当时，Win32和WinForms是唯一的选择

---

后来，当他们想要增强“颜色”中的概念时，他们不希望WPF依赖WinForms。因此，他们没有通过将更抽象的颜色类移动到通用程序集来修复这种情况，而是在WPF中复制粘贴了一个新的颜色类。

WPF vs Window Forms。两个UI层，两组定义。为了进一步混淆这一点，我注意到WPF/Silverlight中的笔刷类型属性在设计器中从System.Drawing.Color（在System.Windows.Media.Color中不可用）中选择值，尽管Silverlight无法使用此名称空间。但让我更加困惑的是，System.Drawing.Color在其方法中比System.Windows.Media.Color具有更多的功能（例如FromArgb具有各种重载）。所有颜色的枚举/列表实际上有不同的名称：System.Drawing.Color vs System.Windows.Media.Color！图形颜色具有更多功能，例如名称属性。例如，System.Drawing.Color.Blue.Name应该与nameof（System.Windows.Media.Colors.Blue）相似，但System.Windows.Media.Color（不带“s”）类也包含来自argb的静态方法，但重载较少）一个非常不幸的进一步发展是UWP和.NET标准使用System.Drawing.Color。您可能认为Media.Color较新的版本将取代Drawing.Color。事实并非如此。看起来Media.Color是孤立的。对于建立WPF和UWP通用库的人来说，这是个坏消息。虽然技术上是正确的，但它并没有回答为什么微软决定将颜色的概念链接到图形中这个更基本的问题。