【问题标题】:Is there any way to share code between UWP apps and WPF apps?有没有办法在 UWP 应用和 WPF 应用之间共享代码?
【发布时间】:2016-04-27 02:13:17
【问题描述】:

明确地说,我遵循 MVVM 模式,并且我想构建我的项目,以便我可以在 UWP 应用程序和标准 WPF 应用程序之间共享我的模型代码。我要分享的代码没有 UI。我不喜欢寻找新工具来替代我多年来一直在使用的工具来处理某些任务,例如日志记录、连接到面向文档的数据库等。

我尝试开始围绕我已经拥有的一些代码编写 UWP 包装器并直接引用模型项目。 Visual Studio 拒绝让这种情况发生,向我显示一条错误消息,显示“无法添加对项目 'ACK.Model' 的引用”。当我试图将模型放入通用库并从 WPF 应用程序中引用它时,同样的事情发生了。我不想分享 WPF 代码。只是没有引用 UI 库的模型层。

这是一个可怕的提议,因为这意味着如果我想做任何实质性的事情,我必须选择 100% 跳到 UWP 或保持 100% WPF。 NewtonSoft.JSON 可能有一个通用分布 (ASP.NET MVC),但是 ElasticSearch.NET 和其他制作重要应用程序所需的工具呢?


我找到了“可移植类库”项目类型的隐藏位置。 PCL 将允许我在 WPF 和通用应用程序之间共享 我的 代码,因为这是其中一种选择。这解决了我的代码中模型部分的简单情况,但我(仍然)不能使用我想要的一些库。我仍然需要大量没有 PCL 可用的库。

【问题讨论】:

  • 欢迎来到我们的困境,我的朋友,就目前而言,我认为没有。在 UWP 对我们开放后,我们试图搜索这个。目前我们仍然依赖于 WebAPI。共享代码并将它们作为可重复使用的代码作为一种解决方案甚至参考重新使用目前没有帮助。由于 UWP 仍然专注于 Windows 家庭应用程序,而不是 ASP 的 Web 应用程序。如果您找到一种方法,请在您的问题中重新发布。
  • 您必须抽象代码,这些代码使用第三方库并将其替换为适用于 WPF/UWP 的库。即,您不直接使用 NewtonSoft.JSON,而是使用 IJsonProvider 接口。例如,在 UWP 上,您使用 microsoft Json 堆栈和在 WPF JsonSoft 上
  • 谁投票结束了这个问题,你能详细说明为什么你觉得这不是主题。这不是关于计算的一般问题。这是一个关于不同C#平台之间代码共享的问题。
  • @JoaquínLuisMonleónIrisarri,当 NetStandard 不存在时,我问了这个问题。在 NetStandard 可用后,我也更新了我的答案,从那以后故事变得更好了。

标签: c# wpf mvvm uwp


【解决方案1】:

大约一年后,随着 Visual Studio 2017 的出现,出现了更完整的解决方案。如果您将库定位到 .Net Standard,则该库与 .Net Core 应用程序和整体 .Net 目标应用程序兼容。对标准 .Net 库和 API 的支持相当完整,对现代 C# 语言功能的支持也是如此。

现在的一般建议是这样的:

  • 所有库的目标.Net Standard
  • 针对您的实际应用选择合适的平台。 (UWP 或 WPF)。

注意:如果您的库必须与 C 库或应用程序交互,您必须格外小心以确保加载正确的版本。


似乎有一个解决方案,但它必须被您要使用的整个工具链采用。当 Microsoft 在 Windows 8 中引入 Windows Store 应用程序时,他们还引入了一个可移植类库 (PCL)。 PCL 的目的是在应用程序的不同部分之间共享代码。

在 Visual Studio 2015 中创建 PCL 时,您可以指定希望从以下位置访问它的 API 类型:

  • 通用应用程序
  • 单声道
  • .Net Core 5
  • .Net 4.6

这当然会限制您可以使用的 API,但您想要使用的大多数 API 都可以,只要它与 UI 无关。还有其他限制:

  • 您的项目只能在 Visual Studio 2015 或更高版本中编辑
  • 您无权访问环境变量中的特殊目录(即用户文档目录等)
  • 您不能链接到仅为您的一个目标平台(即 libgit2sharp 等)设计的库
  • 没有办法浏览这个子集的 API——MSDN 需要坚持下去。 MSDN 已经更新了很多 API 文档,但仍然很难弄清楚哪些内容适用于你的PCL

但是,您可以将专为单一目标平台设计的任何库链接到您的 PCL。这并不理想,但总比没有好。

ASP.NET MVC 堆栈已移植到使用 PCL,因此您可以直接使用 NewtonSoft.JSON 以及该应用程序使用的任何其他库。但是,有几个库尚未移植。

这种安排迫使您考虑如何更好地整合。 .Net Core 5 似乎很稳定,但支持还处于起步阶段。截至 VS 2015 更新 1 的当前一代通用应用程序直接使用 .Net Core 5。

Nuget 的一些功能目前不受支持,即使工作正在进行中:

  • MS Build 扩展(对 MSBuild 和 project.json 结构的重大更改)
  • 安装/卸载脚本(与删除安装概念有关)
  • 内容(与安装/卸载相关,但相关工作正在进行中)
  • 内容转换(与缺少安装/卸载有关)

我希望我有一个更完整的答案。但这是我发现 PCL 以及它是如何为当前基础架构发展起来的。


我正在创建一个包含版本控制的游戏创建工具包。我希望能够将游戏部署为 Windows 10 应用程序或标准 WPF 应用程序,但由于我用于集成版本控制的库,我需要将编辑器创建为标准 WPF 应用程序。在构建共享代码和导入正确的库时,我必须有点创意。

首先,我的项目层次结构:

  • Project.Model(可移植类库)
  • Project.Model.Versioning(标准 C# 库)
  • Mvvm.Toolkit(可移植类库)
  • 编辑器(标准 WPF 应用程序)

我希望核心 PCL 能够加载项目并反序列化 JSON 编码对象。 PCL 确实可以访问System.IO,但令人惊讶的是,它与标准 C# 库中定义的不同。以下是我必须解决的问题:

  • 添加对NewtonSoft.JSON的包引用后,我不得不更改packages.config文件中的目标框架:

    <package id="Newtonsoft.Json" version="8.0.2" targetFramework="portable-net452+win81" />

  • 依赖于我的 Project.Model 类的所有项目都必须从 nuget 安装 `system.io.filesystem' 包,以便 System.IO.FileInfo 等对象相同。

    李>

虽然这绝对不是灵丹妙药,但也不是死胡同。我敢肯定还有更多的陷阱,但这至少有助于解决一些问题。

【讨论】:

    【解决方案2】:

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2017-07-27
      • 2017-12-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多