我想知道,PCL究竟解决了什么?如果它只是限制了跨平台的类型,那么为什么微软不会通过IDE将其作为标准.NET库中的一个功能?
基本上,我可以轻松编译包含一些POCO对象的.NET库,并在我的Silverlight,WPF和Windows应用商店应用中引用该DLL,而无需重新编译或出现任何问题。是否有任何在PCL中有效的代码难以在标准.NET库中运行?
哦,我知道显然有一些东西可以在标准的.NET库中运行,我并不关心...我想我的问题是:
是否有任何代码可以在可移植类库中编译,如果完全相同的代码在.NET库中,那么它将无法正常运行?
答案 0 :(得分:22)
两件事:
首先,如果您打算创建一个可以在多个平台上运行的库,那么您不希望在运行时发现您不小心使用了并非在所有平台上都可用的API(通过TypeLoadException或MissingMethodException)或者其他的东西)。因此,便携式类库只会为您所定位的所有平台上支持的API提供智能感知,并且您将在该集合之外的任何内容中获得构建错误。
其次,如果您创建的.NET Framework库仅使用所有平台上可用的API,则创建的DLL仍然 无法在其他平台(即Windows Phone和Silverlight)上运行而无需编译它作为这些平台的库。这听起来像你期望它会,这是一个合理的期望,但在过去并不是真的。可移植类库是我们开展工作的方式(事实上,如果您为Windows应用商店应用创建类库并且仅使用可用于.NET Framework和WP8的API,则生成的二进制文件会在这两个平台上都保持不变)。
答案 1 :(得分:5)
我不会太担心代码本身,但只需尝试以下内容,看看为什么便携式类库很有用。
您将收到以下错误消息:
您无法添加对Demo.Utils.dll的引用,因为它未构建 针对Silverlight运行时。 Silverlight项目只会起作用 使用Silverlight程序集。
这本身就是为什么便携式类库非常棒的品味。困难的部分是尝试使代码适应平台不可知,这听起来很容易,但并不像你想象的那么容易。相信我,当你第一次尝试从文件夹中读取文件并意识到PCL不允许FileInfo
时你会感到沮丧,但微软的指导是抽象平台依赖关系并注入一个类实现一个实际处理它的接口。事实上,这是一个nice article。
另一篇有待观察的有用文章介绍了PCL设置方式的一些内部工作原理。本文将帮助您了解为什么 PCL能够定位多个平台。 https://www.simple-talk.com/blogs/2013/04/19/inside-portable-class-libraries/
答案 2 :(得分:3)
我在什么是便携式类库上创建了一个简单的YouTube视频,你可以从这里看到http://www.youtube.com/watch?v=DcBfjdDHlxo
但是让我在这里详细回答。创建类库项目的重点是可重用性。现在,我们希望这种可重用性不仅在.NET应用程序中,而且在整个.NET应用程序中,而且在不同类型的.NET应用程序中。现在不同类型的.NET应用程序意味着WPF,Windows,Silver light,Windows phone等。
现在这些应用程序类型中的每一种都有不同的.NET框架。
例如在Silver light应用程序中,如果您尝试引用一个简单的“类项目”,则会以下面的错误结束。这就是可移植类库的用处。通过创建可移植类,我们可以在任何类型的.NET项目类型中引用它。
答案 3 :(得分:2)
便携式类库实际上解决了什么?
最终会解决很多问题! (像Java一样,但在本世纪)
是否有任何代码可以在可移植类库中编译 如果完全相同的代码在.NET中,则无法正常运行 库中?
按原则我认为不是,反过来不是这样吗?
但我认为,所有应有的尊重,你可能实际上都错过了这一点
考虑复制/粘贴代码,项目克隆,链接代码,条件编译器指令,(甚至是T4模板?),最终结果是引用DLL Hell
和不必要的复杂性,样板,冗长(不是很优雅) ?)
它们不是二元不兼容的解决方法吗?
它很早但我认为这是一个很棒的方向,大多数时候你看到Xamarin和Mono正在努力支持pcl(他们已经部分地做了),我认为它唯一可以保存,因为所有来自Html和Javascript狂热或者代码生成器。 (TypeSafe万岁!)
PCL还可以从Windows机箱中释放c#军队
(但这只是我的意见)
答案 4 :(得分:1)
当您在Visual Studio 2012中进行开发时,可移植类库中存在一些与.NET Framework 4有关的API差异。首先,这涉及System.Net
和{{1}中的一些属性和方法。命名空间。有关详细信息,请参阅this MSDN页面。