问题描述
我正在为我的应用扩展支持的平台数量，它曾经支持 .NET4/Windows Store/Windows Phone，但我希望也涵盖适用于 Android 和 iOS 的 Mono.我已经将所有业务逻辑、模型和视图模型都放到了可移植类库 (PCL) 中，但是我的目标平台子集是什么是一个很大的难题.每个组合都会导致某些事情失败.以下是我可能使用的 4 个平台的结果:
I am working on extending number of supported platforms for my app, it used to support .NET4/Windows Store/Windows Phone, but I hope to also cover Mono for Android and iOS. I've put all business logic, models and view models to portable class libraries (PCL) but it's a big dilemma what subset of platforms I should target. Each combination causes something to fail. Here are the results for 4 platforms that I might use:
Profile 78 (NET45+WP8+Store):TPL 没有问题，await/async 和支持 CallerMemberName 属性(在 BindableBase 视图模型基类中使用).但是引用此类库的 Mono.Android 项目无法构建，抱怨应该引用的 System.Runtime.dll 不存在.
Profile 78 (NET45+WP8+Store): no problem with TPL,await/async and support for CallerMemberName attribute (used in BindableBase view model base class). But the Mono.Android project that refers such library fails to build complaining about non-present System.Runtime.dll that should be referenced.
配置文件 104 (NET45+SL4+WP75+Store):等待/异步不起作用，未找到 CallerMember 名称，但如果我删除对它们的所有引用，Android 项目构建良好.
Profile 104 (NET45+SL4+WP75+Store): await/async don't work, CallerMember name not found, but if I remove all references to them, Android project builds fine.
配置文件 147 (NET403+SL5+WP8+Store):等待/异步不起作用，未找到 CallerMember 名称，但如果我删除对它们的所有引用，Android 项目构建良好.
Profile 147 (NET403+SL5+WP8+Store): await/async don't work, CallerMember name not found, but if I remove all references to them, Android project builds fine.
配置文件 158 (NET45+SL5+WP8+Store):等待/异步不起作用，未找到 CallerMember 名称，但如果我删除对它们的所有引用，Android 项目构建正常.
Profile 158 (NET45+SL5+WP8+Store): await/async don't work, CallerMember name not found, but if I remove all references to them, Android project builds fine.
所以我不确定该选择什么.配置文件 78、104、147 是有限的，配置文件 78 是唯一一个同时支持等待/异步和 CallerMemberName 使用 BindableBase 的配置文件，但它在 Android 上失败，抱怨 System.Runtime.dll.因此，如果您对哪种 PCL 配置文件最适合以 Mono 为目标的 PCL 有任何经验，请分享您的想法.
So I am not really sure what to choose. Profiles 78, 104, 147 are limited, profile 78 is the only one that supports both await/async and CallerMemberName used BindableBase, but it fails on Android complaining about System.Runtime.dll. So if you have an experience with what PCL profile is the best match for PCL targeting Mono, please share your thoughts.
推荐答案
考虑个人资料编号很难 - 我更喜欢从平台的角度考虑.
Thinking about profile numbers is hard - I prefer to think in terms of the platforms.
理想情况下，我希望支持我的项目:
Ideally I'd love my projects to support:
- .Net 3.5 及更高版本
- SL3 及更高版本
- WP7.x 手机及更高版本
- MonoDroid 1.6 及更高版本
- MonoTouch iOS6 及更高版本
- (Mac 桌面 OSX Lion)
我支持的主要 PCL 项目是 MvvmCross——它需要像 ICommand 这样的 Mvvm设施".这些工具仅适用于 .Net 4.5 及更高版本的平台......这是一个硬限制 - 我无能为力 - 所以改变我的需求:
The main PCL project I support is MvvmCross - which requires Mvvm 'facilities' like ICommand. These facilities are only available in platforms for .Net 4.5 and higher... that's a hard limit - nothing I can do about it - so changes my needs to:
- .Net 4.5
- SL4 及更高
- WP7.x 手机及更高版本
- MonoDroid 1.6 及更高版本
- MonoTouch iOS6 及更高版本
- (Mac 桌面 OSX Lion)
- .Net 4.5
- SL4 and higher
- WP7.x phone and higher
- MonoDroid 1.6 and higher
- MonoTouch iOS6 and higher
- (Mac desktop OSX Lion)
有了这个选择，然后这会导致我的个人资料编号 - 104(不知道平台是如何决定这个的......很久以前就放弃了！)
With this selection in place, then this leads me to a profile number - 104 (no idea how the platform decided this... gave up asking a long time ago!)
所以我已经将 MvvmCross 定位在配置文件 104 上 - 它会留在那里，而仍然需要 WP7.x 支持.
So I've targeted MvvmCross at profile 104 - and it will stay there while WP7.x support is still needed.
这个选择确实意味着 MvvmCross 不能开箱即用地支持 async/await 和 CallerMemberName 之类的东西 - 但这是我们决定做出妥协 - 我们有需要 WP7的用户.
This selection does mean that MvvmCross cannot out-of-the-box support things like async/await and CallerMemberName - but this is a compromise we've decided to make - we have users who need WP7.
然而，有些人在询问 await/async...
However, some people are asking about await/async...
要使用这些新功能，有一些 BCL.Async Nuget 技巧可以使它们在配置文件 104 中工作...或者这些用户可以将他们的应用程序定位到更新的配置文件(不支持 WP7.x 和 SL4 的配置文件)) - 这导致他们在配置文件 78 中构建他们的应用程序，但添加对我的配置文件 104 程序集的引用.
To use these new features, there are some BCL.Async Nuget hacks to make them work in profile 104... or these users can target their apps at a newer profile (one that doesn't support WP7.x and SL4) - this leads them to build their apps in profile 78, but to add references to my profile 104 assemblies.
这些解决方案都不适用于目前的 Xamarin 双胞胎 - 例如您遇到了诸如缺少 System.Runtime.dll 程序集之类的问题.但是，我预计当 Xamarin 正式支持 PCL 时(并且经过一些 alpha/beta 测试)，这些问题将得到解决.这个官方支持很快就要到期了 - 这就是为什么我不会花太多时间考虑这些问题......
Neither of these sets of solutions works very well with the Xamarin twins at present - e.g. you hit issues like the missing System.Runtime.dll assembly. However, I anticipate that when Xamarin officially supports PCLs (and after some alpha/beta testing) then these problems will be resolved. This official support is due very soon now - which is why I don't bother expending too much of my time thinking about these problems...
我预计 MvvmCross 将在中期放弃对 WP7.x 和 SL4 的支持.发生这种情况时，我们也可能将核心库移至配置文件 78.
I expect in the medium term that MvvmCross will drop support for WP7.x and SL4. When that happens, we may also move the core libraries to profile 78.
我所知道的唯一其他开始支持 PCL 的大型平台是 ReactiveUI.我相信这个平台必须使用配置文件 78，因为来自 Microsoft 的 Reactive PCL 版本的目标是 78.
The only other large platform I know that has started PCL support is ReactiveUI. I believe this platform must use profile 78 because the PCL version of Reactive from Microsoft is targeting 78.
这篇关于为跨平台开发寻找最佳 PCL 配置文件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！