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

问题描述

我正在尝试验证协议缓冲区是否可以与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 * 在这里-具有讽刺意味的是，我让那个可以正常工作。

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

dnu restore 工作正常； dnx运行失败，并显示以下内容：

dnu restore works fine; dnx run fails with:

错误：c：\Users\Jon \测试\项目\protobuf-coreclr\src\ProtobufTest\Program.cs（9,9）：DNX，Version = v4.5.1错误CS0012：类型'对象'在以下程序集中定义未引用。您必须添加对程序集'System.Runtime，Version = 4.0.0.0，Culture = neutral，PublicKeyToken = b03f5f7f11d50a3a'的引用。

Error: c:\Users\Jon\Test\Projects\protobuf-coreclr\src\ProtobufTest\Program.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:

• 显式向 System.Runtime添加依赖项： 4.0框架的依赖项部分中的.0


• 明确为<$ c $添加依赖项c> System.Runtime：框架的 dependencies 部分中的 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，但发生了相同的错误


• Ditto包括软件包中的 lib\dotnet 目录以及相关性

• 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 lib\dotnet directory in the package, as well as the 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.

我希望，如果我能找到一种使依赖项起作用的方法，那么我可以将该依赖项添加到协议缓冲区本身中，这将是很好-但是由于对project.lock文件中的System.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，它基本上就是一个nuspec，带有一点点糊涂，可以描述构建项目所需的编译选项和源代码。 ， frameworkAssemblies 表示内置内容，依赖项表示其他nuget依赖项。在这里含义相同。使用框架中的内容，则需要在 frameworkAssemblies 中进行指定，而不是使用nuget packa

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.

现在介绍细节：

在上使用基于PCL或.NET Core的库时。在NET Framework中，引用是引用程序集（有时称为合同程序集）。这些示例包括 System.Runtime ， System.Threading 等。在使用基于MSBUILD的项目时，一个运行的任务，该任务基本上会自动添加 System的 all 。* 对C＃编译器的引用以避免这种混乱。这些程序集在.NET Framework上称为Facades。不幸的是，即使不使用它们也会添加 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。如果您查看这些文件夹，则会看到一个空的 _._ 文件。这样做的原因是因为当您声明带有 System.Runtime 的 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屋！