UWP/.NET Native 和 iOS 上的 Protobuf-net

Question

我有一个基于 .NET Standard 1.4 的 Xamarin.Forms 应用程序，它使用 protobuf-net 将对象存储在数据库中，稍后将发送到 WCF 服务。

在 Android 和 UWP 上“托管”一切正常，但是 - 在搜索无法再访问的存储库、文章和博文之后，以及在尝试让预编译工具工作但失败之后 - 我有一个简单（可能不是）问题：如何让 protobuf-net 在 UWP/.NET Native 和 iOS/Xamarin 等“受限”环境中工作？

Answer 1

目前对于这种情况，我没有很好的解决方案。我知道有些人已经成功了，但我在 UWP/Native/iOS 方面不够专业，无法为您提供可靠的“这是成功之路”的说明。

UWP / .NET Native 和 iOS 共享（如您所知）一个常见问题：缺乏完整的运行时发射。我明白为什么会这样。这只是：棘手。

从历史上看，protobuf-net 曾尝试通过一个构建工具来解决这个问题，该构建工具重复通常在运行时完成的现有 IL-emit - 作为构建时工具。这是丑陋和讨厌的，但它工作。的种类。为了解决一些平台限制，protobuf-net 使用了一些 IKVM 工具来帮助解决这个问题，但是随着 .NET 框架场景的不断扩展，这基本上是不可行的。另外：IKVM 工具现已弃用，不再维护。

与此同时，研究一些新概念的动力越来越大：

• 完整的 async/await 用于异步 IO 源：请注意，这非常对 IL 发射不友好，但在 C# 中实现起来几乎令人尴尬
• “pipelines”/“channels”/“streams 2”——不管它本周被称为什么；但是：在 Kestrel 中使用的新的无分配 IO 概念（我在早期阶段帮助踢了这个球，所以我熟悉需要做什么） - 注意这个 也 关联到async/await
• 当然还有：以上所有内容与预生成有何关系

目前，我非常认为，最好的前进路线是让 pre-gen 场景切换到通过构建时工具发出 C#。我曾多次向 MS 请求改进基于 Roslyn 的自动 C# 发射，但到目前为止：没有喜悦（令人烦恼的是：asp.net 的东西甚至有一个完全工作的概念证明，但它被搁置了）。所以现在我在想：我们需要假设这不会发生，并且基本上是独立编写的。这必要并不像听起来那么复杂（而且：各种形式的代码生成对我来说非常熟悉）。这里 C# emit 的优点是我不需要与每个框架的复杂性作斗争——我只需要让它编译（好吧，很明显，然后运行）。

那么：是什么阻碍了我？理论上：没有。我只需要编写和部署这些东西。在现实中：生活、时间等。我对优先考虑每天影响我的事情感到内疚，而现实是我并不是这些平台的真正日常用户，这意味着我不是感受你所感受到的痛苦。但是：我清楚地听到你的声音，我正在努力加强应该解决这些问题的 v3 工作。我真的希望拥有一个关于这些事情的好故事——我的目标是通过转向 C#-emit 模型（至少对于 pre-gen）：它对我有帮助时间>。如果它对我有帮助，我知道它不会是阁楼/地下室中被遗忘的玩具，我知道在那里，但很难找到去的动力找的麻烦。