没有 frameworkAssemblies 无法解决程序集引用问题 [英] Unable to resolve assembly reference issue without frameworkAssemblies

问题描述

我正在尝试验证 Protocol Buffers 将与 ASP.NET 团队的新可移植运行时一起使用，并且理想情况下，大多数其他现代环境.3.0.0-alpha4 版本是不久前使用 profile259 创建的，所以我希望在某些情况下需要进行一些更改，但我想我会试一试.我知道 Oren Novotny 关于定位 .NET Core 的帖子，并且预计必须对 Google.Protobuf nuspec 文件进行一些更改，但我遇到的错误让我很难过.

I'm trying to validate that Protocol Buffers is going to work with the new portable runtimes from the ASP.NET team and ideally most other modern environments. The 3.0.0-alpha4 build was created a while ago using profile259, so I would expect some changes to be required in some cases, but I thought I'd give it a try. I'm aware of Oren Novotny's post about targeting .NET Core, and expected to have to make some changes to the Google.Protobuf nuspec file, but the error I'm running into has me stumped.

DNX 版本:1.0.0-rc1-update1

DNX version: 1.0.0-rc1-update1

我目前正在尝试测试的场景是针对 dnx451 的控制台应用程序.我有一个非常简单的示例应用程序:

The scenario I'm currently trying to test is a console app targeting dnx451. I have a very simple sample app:

using Google.Protobuf.WellKnownTypes;
using System;

public class Program
{
    public static void Main(string[] args)
    {
        Duration duration = new Duration { Seconds = 100, Nanos = 5555 };
        Console.WriteLine(duration);
    }
}

... 和一个很小的 ​​project.json:

... and a tiny project.json:

{
  "compilationOptions": { "emitEntryPoint": true },
  "dependencies": { "Google.Protobuf": "3.0.0-alpha4" },

  "frameworks": {
    "dnx451": { }
  }
}

请注意，我什至没有在这里使用 dnxcore* - 具有讽刺意味的是，我让 that 正常工作.

Note that I'm not even using dnxcore* here - ironically, I got that to work without issues.

dnu restore 工作正常；dnx run 失败:

错误:c:UsersJonTestProjectsprotobuf-coreclrsrcProtobufTestProgram.cs(9,9): DNX,Version=v4.5.1 错误 CS0012: 定义了对象"类型在未引用的程序集中.您必须添加对程序集System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"的引用.

Error: c:UsersJonTestProjectsprotobuf-coreclrsrcProtobufTestProgram.cs(9,9): DNX,Version=v4.5.1 error CS0012: The type 'Object' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.

以下更改导致相同的错误:

The following changes result in the same error:

• 在框架的 dependencies 部分中显式添加对 "System.Runtime": "4.0.0" 的依赖项
• 在框架的 dependencies 部分中显式添加对 "System.Runtime": "4.0.0-beta-23109" 的依赖关系，对于 4.0.10-beta-*、4.0.20-beta-* 和 4.0.21-beta*.
• 将依赖项添加到 NuGet 包(本地)中的 System.Runtime 并针对它进行重建 - project.lock.json 已更新为包含 System.Runtime v4.0.0，但发生了同样的错误
• 同上，在包中包含 libdotnet 目录以及依赖项

• Explicitly adding a dependency to "System.Runtime": "4.0.0" in the dependencies section for the framework
• Explicitly adding a dependency to "System.Runtime": "4.0.0-beta-23109" in the dependencies section for the framework, and likewise for 4.0.10-beta-*, 4.0.20-beta-* and 4.0.21-beta*.
• Adding dependencies to System.Runtime within the NuGet package (locally) and rebuilding against that - project.lock.json was updated to include System.Runtime v4.0.0, but the same error occurred
• Ditto including a libdotnet directory in the package, as well as the dependencies

确实工作的步骤(独立，并且没有 dependencies 条目)，但让我感到困惑:

Steps that did work (independently, and with no dependencies entries), but confuse me:

• 将 Console.WriteLine 调用更改为仅 Console.WriteLine("foo")(但没有其他更改)
• 将 duration 变量的类型更改为 object 而不是 Duration
• 完全删除协议缓冲区的所有提示，而是使用 TimeSpan 或类似的

• 在 dnx451 部分的 project.json 中添加以下内容:

• Changing the Console.WriteLine call to just Console.WriteLine("foo") (but no other changes)
• Changing the type of the duration variable to object instead of Duration
• Removing all hint of Protocol Buffers entirely, and instead using TimeSpan or similar

• Adding the following to project.json in the dnx451 section:

"frameworkAssemblies": {
  "System.Runtime": ""
}

最终，我不希望用户必须这样做 - 至少，不是为了协议缓冲区.我假设这与我们构建协议缓冲区的方式有关，但由于我无法正确理解原因，因此很难修复.

Ultimately, I don't want users to have to do this - at least, not for the sake of Protocol Buffers. I'm assuming this is something to do with how we're building Protocol Buffers, but as I don't understand the cause properly, it's hard to fix.

我希望如果我能找到一种使 dependencies 条目工作的方法，然后我可以将该依赖项添加到 Protocol Buffers 本身中，这很好 - 但对 System 有依赖项project.lock 文件中的 .Runtime v4.0.0 似乎没有帮助，我一定遗漏了一些东西:(

I expect that if I could work out a way of making a dependencies entry work, I could then add that dependency into Protocol Buffers itself, which would be fine - but as having a dependency on System.Runtime v4.0.0 in the project.lock file doesn't seem to help, I must be missing something :(

推荐答案

所以如果你眯着眼睛看project.json，它基本上是一个带有一点goop的nuspec来描述构建需要哪些编译选项和源项目.今天的 Nuspecs 有 2 个部分，frameworkAssemblies 用于内置"内容，dependencies 用于其他 nuget 依赖项.这里的意思是一样的.当您使用框架"中的某些内容时，需要在 frameworkAssemblies 中指定它而不是作为 nuget 包依赖项.

So if you squint and look at the project.json, it's basically a nuspec with a little bit of goop to describe what compilation options and sources are needed to build to project. Nuspecs today have 2 sections, frameworkAssemblies for "built in" stuff and dependencies for other nuget dependencies. It has the same meaning here. When you use something from "the framework", it needs to be specified in frameworkAssemblies vs being a nuget package dependency.

现在进入细节:

当您在 .NET Framework 上使用基于 PCL 或 .NET Core 的库时，引用是对引用程序集(有时称为协定程序集)的引用.其中的一些示例是 System.Runtime、System.Threading 等.当使用基于 MSBUILD 的项目时，有一个运行的任务基本上会自动添加 allSystem.* 的 引用 C# 编译器来避免这种混乱.这些程序集在 .NET Framework 上称为外观.不幸的是，即使它们没有被使用，它也会添加 ALL .对 System.Runtime 的依赖是此行为的触发器(在基于 .NET Framework 的 csproj 文件上运行时).

When you use a PCL or .NET Core based library on .NET Framework, the references are to reference assemblies (sometimes called contract assemblies). Some examples of these are things like System.Runtime, System.Threading etc. When using MSBUILD based projects, there is a task that runs which basically automatically adds all of the System.* references to the C# compiler to avoid this mess. These assemblies are called facades on .NET Framework. The unfortunate part is that it adds ALL of them even if they aren't used. A dependency on System.Runtime is the trigger for this behavior (when running on .NET Framework based csproj files).

添加对同一包的引用不起作用的原因是这些合同程序集(如 System.Runtime)的 .NET Framework 文件夹 (net4*) 中没有任何 dll.如果您查看这些文件夹，您会看到一个空的 _._ 文件.这样做的原因是因为当您声明一个带有 frameworkAssembly 引用的 nuget 包时，msbuild 项目系统无法安装它(非常复杂的错误和设计问题).

The reason adding a reference to the same package doesn't work is because the .NET Framework folder (net4*) for those contract assemblies (like System.Runtime), don't have any dlls in them. If you look at those folders, you'll see an empty _._ file. The reasoning for this is because when you declare a nuget package with a frameworkAssembly reference to System.Runtime, the msbuild project systems fails to install it (very complicated bug and design problem).

这可能让事情变得更加模糊......

That probably made things fuzzier...

这篇关于没有 frameworkAssemblies 无法解决程序集引用问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！