Невозможно решить проблему со ссылкой на сборку без frameworkAssemblies

Так что, если вы прищуритесь и посмотрите на project.json, это в основном nuspec с небольшим количеством goop, чтобы описать, какие параметры компиляции и исходники необходимы для сборки проекта. Nuspecs сегодня имеет 2 раздела: frameworkAssemblies для «встроенных» вещей и dependencies для других зависимостей nuget. Здесь он имеет тот же смысл. Когда вы используете что-то из «фреймворка», это необходимо указать в frameworkAssemblies, а не как зависимость пакета nuget.

Теперь о частностях:

При использовании библиотеки на основе PCL или .NET Core в .NET Framework ссылки указывают на сборки (иногда называемые контрактными сборками). Некоторыми примерами этого являются такие вещи, как System.Runtime, System.Threading и т. д. При использовании проектов на основе MSBUILD выполняется задача, которая в основном автоматически добавляет все ссылки System.* в компилятор C#, чтобы избежать этого беспорядка. Эти сборки называются фасадами в .NET Framework. К сожалению, он добавляет ВСЕ из них, даже если они не используются. Зависимость от System.Runtime является триггером для такого поведения (при работе с файлами csproj на основе .NET Framework).

Причина, по которой добавление ссылки на тот же пакет не работает, заключается в том, что в папке .NET Framework (net4*) для этих сборок контрактов (например, System.Runtime) нет библиотек DLL. Если вы посмотрите на эти папки, вы увидите пустой файл _._. Причина этого в том, что когда вы объявляете пакет nuget со ссылкой frameworkAssembly на System.Runtime, системы проекта msbuild не могут его установить (очень сложная ошибка и проблема дизайна).

Это, наверное, сделало вещи более нечеткими...

Я принял ответ Дэвида Фаулера как причину, почему все это произошло. Теперь с точки зрения того, что я должен сделать с этим, похоже, мне просто нужно добавить элемент frameworkAssemblies в файл nuspec для Google.Protobuf:

<package>
  <metadata>
    ...
    <frameworkAssemblies>
      <frameworkAssembly assemblyName="System.Runtime" targetFramework="net45" />
    </frameworkAssemblies>
  </metadata>
  ...
</package>

Затем эта ссылка frameworkAssembly оказывается в project.lock.json в клиентском проекте, и все в порядке.

Однако, судя по другому комментарию Дэвида («Мы собираемся исправить это»), мне все равно ничего не нужно делать...

Мне кажется, что ваша проблема существует только потому, что вы выбрали Консольное приложение вместо «Веб-приложение ASP.NET»/«Шаблоны ASP.NET 5»/«Пустой». Я сделал простое тестовое использование Пустого шаблона, добавил "Google.Protobuf": "3.0.0-alpha4" из NuGet и, наконец, просто изменил Startup.cs, чтобы он использовал Google.Protobuf.WellKnownTypes:

• добавил using Google.Protobuf.WellKnownTypes;
• добавлено var duration = new Duration { Seconds = 100, Nanos = 5555 }; внутри Configure
• изменено await context.Response.WriteAsync("Hallo World!"); на await context.Response.WriteAsync(duration.ToString());

Окончательный код Startup.cs:

using Microsoft.AspNet.Builder;
using Microsoft.AspNet.Hosting;
using Microsoft.AspNet.Http;
using Microsoft.Extensions.DependencyInjection;
using Google.Protobuf.WellKnownTypes;

namespace ProtobufTest
{
    public class Startup
    {
        // This method gets called by the runtime. Use this method to add services to the container.
        // For more information on how to configure your application, visit http://go.microsoft.com/fwlink/?LinkID=398940
        public void ConfigureServices(IServiceCollection services)
        {
        }

        // This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
        public void Configure(IApplicationBuilder app)
        {
            app.UseIISPlatformHandler();

            var duration = new Duration { Seconds = 100, Nanos = 5555 };

            app.Run(async context =>
            {
                await context.Response.WriteAsync(duration.ToString());
            });
        }

        // Entry point for the application.
        public static void Main(string[] args) => WebApplication.Run<Startup>(args);
    }
}

Полученное приложение ASP.NET 5 успешно отображается 100.5555s в веб-браузере.

Демонстрационный проект можно загрузить с здесь.

ОБНОВЛЕНО: я проанализировал проблему с чисто консольным DNX-приложением, которое использует код, и смог найти причину проблемы в методе duration.ToString(), который работает в среде ASP.NET , но не в чистом консольном приложении. Причина проблемы интересна, и я пытаюсь разобраться, но я хотел поделиться своими текущими результатами с другими.

Я мог бы заставить работать следующий код:

using Google.Protobuf.WellKnownTypes;
using System;

namespace ConsoleApp3
{
    public class Program
    {
        public static void Main(string[] args)
        {
            var duration = new Duration { Seconds = 100, Nanos = 5555 };
            Console.WriteLine("{0}.{1:D4}s", duration.Seconds, duration.Nanos);
        }
    }
}

Рабочий проект можно скачать здесь. сильный>

//[assembly: Guid("b31eb124-49f7-40bd-b39f-38db8f45def3")]

{
  ...

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

  "frameworks": {
    "dnx451": { },
    "dnxcore50": {
      "dependencies": {
        "System.Console": "4.0.0-beta-23516"
      }
    }
  }
}

Console.WriteLine("{0}.{1:D4}s", duration.Seconds, duration.Nanos);

Console.WriteLine((object)duration);

"dnx451": { },

{
  "dependencies": {
    "Google.Protobuf": "3.0.0-alpha4",
    "Microsoft.AspNet.Hosting": "1.0.0-rc1-final"
  }
}