Mono 为跨平台开发寻找最佳PCL配置文件

我正在为我的应用扩展支持的平台数量，它过去支持.NET4/Windows商店/Windows手机，但我希望也能涵盖Android和iOS的Mono。我已经将所有业务逻辑、模型和视图模型都放在了可移植类库（PCL）中，但我应该针对哪些平台子集，这是一个很大的难题。每一种组合都会导致某些东西失败。以下是我可能使用的4个平台的结果：

概要文件78（NET45+WP8+Store）：TPL、Wait/async和对CallerMemberName属性的支持（用于BindableBase视图模型基类）没有问题。但是，引用此类库的Mono.Android项目未能构建该库，因为不存在应该引用的System.Runtime.dll

概要文件104（NET45+SL4+WP75+Store）：wait/async不起作用，找不到CallerMember名称，但如果我删除了对它们的所有引用，Android项目就可以正常构建

Profile 147（NET403+SL5+WP8+Store）：wait/async不工作，找不到CallerMember名称，但如果我删除对它们的所有引用，Android项目的构建就可以了

Profile 158（NET45+SL5+WP8+Store）：wait/async不起作用，找不到CallerMember名称，但如果我删除对它们的所有引用，Android项目就可以正常构建

---

所以我真的不确定该选什么。配置文件78、104、147是有限的，配置文件78是唯一支持Wait/async和CallerMemberName使用的BindableBase的配置文件，但它在Android上失败，抱怨System.Runtime.dll。因此，如果您有过PCL配置文件与PCL目标Mono最匹配的经验，请分享您的想法。

思考配置文件编号很难-我更喜欢从平台角度思考

理想情况下，我希望我的项目能够支持：

• .Net 3.5及更高版本
• SL3及以上
• WP7.x手机及更高版本
• 单机器人1.6及以上
• MonoTouch iOS6及更高版本
• （Mac桌面OSX Lion）

---

我支持的主要PCL项目是MvvmCross，它需要像ICommand这样的Mvvm“设施”。这些功能仅在.Net 4.5及更高版本的平台中可用。。。这是一个硬限制-我对此无能为力-因此我需要：

• .Net 3.5及更高版本.Net 4.5
• SL3及以上SL4及以上
• WP7.x手机及更高版本
• 单机器人1.6及以上
• MonoTouch iOS6及更高版本
• （Mac桌面OSX Lion）

有了这个选择，我就得到了一个配置文件编号-104（不知道平台是如何决定的……很久以前就放弃了询问！）

因此，我将MvvmCross定位在概要文件104上——在仍然需要WP7.x支持的情况下，它将保持不变

此选择确实意味着MvvmCross无法开箱即用地支持

async

/

await

和

CallerMemberName

-但这是我们决定做出的折衷-我们有需要WP7的用户

---

然而，有些人询问关于wait/async

为了使用这些新特性，有一些BCL.Async Nuget hack使它们在概要文件104中工作。。。或者，这些用户可以将他们的应用程序定位在更新的配置文件（不支持WP7.x和SL4的配置文件）-这会导致他们在配置文件78中构建应用程序，但会添加对我的配置文件104程序集的引用

目前，这两组解决方案都不能很好地与Xamarin孪生兄弟配合使用-例如，您遇到了诸如缺少System.Runtime.dll程序集之类的问题。然而，我预计，当Xamarin正式支持PCL时（以及在一些alpha/beta测试之后），这些问题将得到解决。这项官方支持很快就要到期了——这就是为什么我不用花太多时间思考这些问题的原因

---

我预计在中期内，MvvmCross将放弃对WP7.x和SL4的支持。当这种情况发生时，我们还可以将核心库移动到profile 78

---

---

据我所知，唯一一个开始支持PCL的大型平台是ReactiveUI。我相信这个平台必须使用profile 78，因为微软的Reactive的PCL版本的目标是78。

一定要使用

Microsoft.Bcl.Async

（这取决于

Microsoft.Bcl

）。这些将async/await/CallerMemberName支持添加到配置文件104/147/158中。Microsoft.Bcl.async只能在Windows平台上分发（到目前为止）。否。@VagifAbilov许可证已在Microsoft.Bcl.Async@NateCook上更改。是的，这是微软的一个伟大举措。谢谢Stuart，一如既往的好答案。我必须检查BindableBase对我的应用程序有多重要。我猜你计划在MvvmCross中替换它。不知道什么是BindableBase？只是添加了

CallerMemberName

方法吗？BindableBase的基本部分是：SetProperty（ref T storage，T value，[CallerMemberName]String propertyName=null）因此，它不仅仅是MvxNotifyPropertyChanged。在我看来，这是同一个类/函数-只是利用c#5特性-当MvvmCross能够向前移动到c#5时，我们可能会将该类型的方法添加到

MvxNotifyPropertyChanged

。另外，我的猜测是，无论您从哪个框架获得的

BindableBase

最初都是在

CallerMemberName

之前拥有的，而且它在当时看起来不同：）不管怎样，我反复回答了这个问题。好的，我想我现在有一个地方使用BindableBase.SetProperty（在Windows应用商店上）。我将尝试只使用Mvx重写它。