Проект .NET Core под управлением .NET Framework "Не удается найти справочную сборку Microsoft.CSharp.dll" - PullRequest
0 голосов
/ 31 октября 2019

Я недавно добавил MVC в мой проект .NET Core 2.0, который работает на .NET Framework 4.7 (<TargetFramework>net47</TargetFramework>). Это веб-проект, который размещается локально через Kestrel-сервер. До того, как я добавил MVC, проблем не было.

Я собираю его на своем компьютере разработчика (Visual Studio 2017), и когда я запускаю его там, он работает правильно. (поскольку существует папка: C: \ Program Files (x86) \ Справочные сборки \ Microsoft \ Framework.NETFramework \ v4.7 со всеми необходимыми сборками). Они добавляются в проект в виде сборок (автоматически).

Но когда я копирую bin / release на новый компьютер Win10 (где установлен .NET Framework 4.7) и пытаюсь запустить его там, происходит сбойследующее исключение:

System.InvalidOperationException: не удается найти файл справочной сборки .NETFramework / v4.7 / Microsoft.CSharp.dll для пакета Microsoft.CSharp.Reference

Если я копирую эту dll вручную в корзину, исключение продолжает появляться из-за следующей dll. Я скопировал: Microsoft.CSharp, mscorlib, System, System.ComponentModel.Composition, System.ComponentModel.DataAnnotations, System.Core, System.Data, System.Drawing, System.IO.Compression.FileSystem, ... Итак, вы видите этоне заканчивается.

Я также попробовал следующие предложения:

  • добавление <PackageReference Include="Microsoft.Extensions.DependencyModel" Version="2.0.0" /> к .csproj (https://github.com/dotnet/sdk/issues/1488)
  • добавление <DependsOnNETStandard>netstandard2.0</DependsOnNETStandard> к .csproj
  • добавление <MvcRazorCompileOnPublish>true</MvcRazorCompileOnPublish> <MvcRazorExcludeRefAssembliesFromPublish>false</MvcRazorExcludeRefAssembliesFromPublish> в .csproj ( Asp.net Core 2.0 с .net framework 4.6.1 - Не удается найти справочную сборку '.NETFramework / v4.6.1 / Microsoft.CSharp.dll )
  • создание нового проекта .NET core 2.0 с .NET Framework 4.7 и добавление MVC. Я проверил, будет ли он работать на другом компьютере, и это так. Не было отсутствующих сборок. -> Затем я сравнил эторешение моего решения, сравнил пакеты NuGet и Startup.cs, но я не смог найти ничего, что отличалось бы.

Просто в моем проекте должно быть что-то не так, но сейчас я действительно не понимаючто это может быть, и я был бы чрезвычайноПодумайте, если кто-нибудь может дать мне совет.

1 Ответ

0 голосов
/ 31 октября 2019

Если предположить, что чистый проект с использованием mvc (.net 4.7 framework) выполняется как на компьютере разработчика, так и на рабочем компьютере, то я считаю:

  1. Работают как веб-серверы Kestrel, так и рабочий, и рабочий. правильно.
  2. Чистый проект .net core 2.0 и .net 4.7 framework установлены и правильно ссылаются.
  3. Это может означать, что у проекта разработки есть внутренние ссылочные пути, которые напрямую связаны с машиной разработкипути (иногда это происходит во время разработки проекта, если ссылки добавляются вручную или используются разные менеджеры пакетов), а не динамически связаны в пакете развертывания.

Следующим шагом, если я попытаюсь найти проблему, будет изменение цели выпуска релизов Visual Studio на путь к производственным серверам по сети вместо машины разработки или, если сеть не подключена, то опубликоватьавтономный пакет развертывания (на основе папок), который вы переносите на рабочий компьютер и развертываете на веб-сервере.

Без более подробной информации это, вероятно, столько, сколько я могу помочь в данный момент.

Просто примечание в текущей среде смены версий и ссылок. У меня было много таких проблем, и я нашел простое решение, которое может помочь в будущих проектах. Когда я добавляю библиотеки или фреймворки, для которых требуются различные сопоставления для управления версиями и ссылками на схемы, я создаю библиотечные проекты, которые выступают в качестве моей собственной обертки и контроля версий для фреймворка, развертываю их в диспетчере пакетов и затем связываю этот проект обертки с основным проектом черезменеджер пакетов. Это дает вам преимущество, заключающееся в том, что вы можете управлять обслуживанием (путями и связыванием) управления версиями и ссылками на себя, а не на прямую привязку к основному проекту (все ссылки имеют собственные стандартизированные привязки)

Надеюсь, это помоглонайти решение.

...