c# - 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 工具现在已被废弃，不会得到维护。

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

• 用于异步 IO 源的完整 async/await:请注意，这对 IL emit 极不友好，但实现起来几乎令人尴尬在 C# 中
• “pipelines”/“channels”/“streams 2”——不管这周叫什么；但是:在 Kestrel 中使用的新的无分配 IO 概念(我在早期阶段帮助解决了这个问题，所以我很熟悉需要做什么)——注意这个 也与async/await
相关联
• 当然还有:以上所有内容如何与预生成相关

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

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