Хороший вопрос. Для вашей конкретной проблемы похоже, что у вас есть несоответствие в ваших разрешенных зависимостях. Когда такие вещи случаются, скорее всего, потому что вы запускаете свое приложение на несовместимом dnx. Мы по-прежнему вносим очень серьезные изменения, поэтому, если вы когда-нибудь увидите, что отсутствует метод пропущенного типа, скорее всего, вы в конечном итоге запустили betaXпакеты и betaYdnx или наоборот.
Более конкретно, в бета4 версии были удалены сборочные нейтральные интерфейсы, но похоже, что приложение, которое вы используете, все еще использует их.
Мы планируем сделать так, чтобы пакеты могли отмечать минимальный dnx, необходимый для запуска, чтобы сделать сообщение об ошибке более понятным. Кроме того, со временем разрушительные изменения стихнут.
В общем, я чувствую, что пришло время написать руководство о том, как диагностировать подобные проблемы при использовании dnx (так как он сильно отличается от существующего .NET).
Зависимости, которые вы вводите, project.jsonотносятся только к верхнему уровню. Версии также всегда минимальны (это как пакет NuGet). Это означает, что когда вы указываете, Foo 1.0.0-beta4вы действительно указываете Foo >= 1.0.0-beta4. Это означает, что если вы попросите указать MVC 0.0.1минимальную версию в настроенном фиде MVC 3.0.0, вы ее получите. Мы также НИКОГДА не публикуем вашу версию, если вы не укажете ее. Если вы запрашиваете 1.0.0, и она существует, вы получите 1.0.0, даже если существуют более новые версии. Указание пустых версий ВСЕГДА плохо и будет запрещено в более поздних сборках.
Мы представляем nuget новую функцию, называемую плавающими версиями. Сегодня он работает только с тегом предварительной версии, но в следующей версии он будет работать и с другими частями версии. Это похоже на синтаксис npm и gem для указания диапазонов версий в файле спецификации пакета.
1.0.0-*- Средства дают мне HIGHEST-версию, соответствующую префиксу (в соответствии с правилами семантического управления версиями ) ИЛИ, если не существует версии, соответствующей этому префиксу, используйте нормальное поведение и получите мне LOWEST-версию> = указанной версии.
Когда вы запускаете восстановление в последних сборках, он записывает файл с именем project.lock.json. Этот файл будет иметь транзитивное закрытие зависимостей для всех целевых платформ, определенных в project.json.
Когда что-то подобное не получается, вы можете сделать следующее:
Взгляните на разрешенные зависимости с помощью kpm list. Это покажет вам разрешенные версии пакетов, на которые ссылается ваш проект, и какая зависимость вытащила его. Например, если A -> B, он покажет:
A
-> Б
В
->
Фактический вывод списка KPM:
Список зависимостей для ClassLibrary39 (C: \ Users \ davifowl \ Documents \ Visual Studio 14 \ Projects \ ClassLibrary39 \ src \ ClassLibrary39 \ project.json)
[Target framework DNX,Version=v4.5.1 (dnx451)]
framework/Microsoft.CSharp 4.0.0.0
-> ClassLibrary39 1.0.0
framework/mscorlib 4.0.0.0
-> ClassLibrary39 1.0.0
framework/System 4.0.0.0
-> ClassLibrary39 1.0.0
framework/System.Core 4.0.0.0
-> ClassLibrary39 1.0.0
*Newtonsoft.Json 6.0.1
-> ClassLibrary39 1.0.0
[Target framework DNXCore,Version=v5.0 (dnxcore50)]
*Newtonsoft.Json 6.0.1
-> ClassLibrary39 1.0.0
System.Runtime 4.0.20-beta-22709
-> ClassLibrary39 1.0.0
* означает прямую зависимость.
Если у вас есть работающая визуальная студия (которая сейчас не работает с DNX), вы можете посмотреть узел ссылок. Он имеет те же данные, представленные визуально:
Давайте посмотрим, как выглядит сбой зависимости:
Вот проект. Json
{
"version": "1.0.0-*",
"dependencies": {
"Newtonsoft.Json": "8.0.0"
},
"frameworks" : {
"dnx451" : {
"dependencies": {
}
},
"dnxcore50" : {
"dependencies": {
"System.Runtime": "4.0.20-beta-22709"
}
}
}
}
Newtonsoft.Json 8.0.0не существует Таким образом, запуск восстановления kpm показывает следующее:
При диагностировании, когда восстановление может быть неудачным, посмотрите на сделанные HTTP-запросы, они сообщают вам, в каких настроенных исходных пакетах просматриваются kpm. Обратите внимание, что на изображении выше есть CACHEзапрос. Это встроенное кэширование на основе типа ресурса (nupkg или nuspec) и имеет настраиваемый TTL (см. kpm restore --help). Если вы хотите принудительно kpmпоразить удаленные источники NuGet, используйте --no-cacheфлаг:
Эти ошибки также отображаются в Visual Studio в окне вывода журнала диспетчера пакетов:
Примечание!
Источники пакетов
Я опишу, как NuGet.config работает прямо сейчас (что, вероятно, изменится в будущем). По умолчанию у вас есть NuGet.config с исходным кодом NuGet.org по умолчанию, настроенным глобально %appdata%\NuGet\NuGet.Config. Вы можете управлять этими глобальными источниками в Visual Studio или с помощью инструмента командной строки NuGet. Вы должны всегда смотреть на свои эффективные источники (те, которые перечислены в выводе kpm), пытаясь диагностировать сбои.
Узнайте больше о NuGet.config здесь
Обратно в реальность:
Когда зависимости не разрешены, запуск приложения даст вам следующее:
> dnx . run
System.InvalidOperationException: Failed to resolve the following dependencies for target framework 'DNX,Version=v4.5.1':
Newtonsoft.Json 8.0.0
Searched Locations:
C:\Users\davifowl\Documents\Visual Studio 14\Projects\ClassLibrary39\src\{name}\project.json
C:\Users\davifowl\Documents\Visual Studio 14\Projects\ClassLibrary39\test\{name}\project.json
C:\Users\davifowl\.dnx\packages\{name}\{version}\{name}.nuspec
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.1\{name}.dll
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.1\Facades\{name}.dll
C:\WINDOWS\Microsoft.NET\assembly\GAC_32\{name}\{version}\{name}.dll
C:\WINDOWS\Microsoft.NET\assembly\GAC_64\{name}\{version}\{name}.dll
C:\WINDOWS\Microsoft.NET\assembly\GAC_MSIL\{name}\{version}\{name}.dll
Try running 'kpm restore'.
at Microsoft.Framework.Runtime.DefaultHost.GetEntryPoint(String applicationName)
at Microsoft.Framework.ApplicationHost.Program.ExecuteMain(DefaultHost host, String applicationName, String[] args)
at Microsoft.Framework.ApplicationHost.Program.Main(String[] args)
Среда выполнения в основном пытается проверить, что весь граф зависимостей разрешен перед попыткой запуска. Если он предлагает выполнить kpm restoreэто, потому что он не может найти перечисленные зависимости.
Другая причина, по которой вы можете получить эту ошибку, заключается в том, что вы используете неправильный вариант dnx. Если ваше приложение указывает только dnx451 и вы пытаетесь запустить CoreCLR dnx, вы можете столкнуться с подобной проблемой. Обратите особое внимание на целевой фреймворк в сообщении об ошибке:
Для бега:
dnx4x - runs on dnx-clr-{etc}
dnxcore50 - runs on dnx-coreclr-{etc}
Когда вы пытаетесь запустить, вы должны помнить, что ментальное отображение от clr к целевой структуре определено в вашем project.json.
Это также отображается в Visual Studio под узлом ссылки:
Узлы, отмеченные желтым, не разрешены.
Они также отображаются в списке ошибок:
Здание
Эти ошибки также отображаются при сборке. При сборке из командной строки вывод очень подробный и может быть чрезвычайно полезен при диагностике проблем:
> kpm build
Building ClassLibrary39 for DNX,Version=v4.5.1
Using Project dependency ClassLibrary39 1.0.0
Source: C:\Users\davifowl\Documents\Visual Studio 14\Projects\ClassLibrary39\src\ClassLibrary39\project.json
Using Assembly dependency framework/mscorlib 4.0.0.0
Source: C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.1\mscorlib.dll
Using Assembly dependency framework/System 4.0.0.0
Source: C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.1\System.dll
Using Assembly dependency framework/System.Core 4.0.0.0
Source: C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.1\System.Core.dll
Using Assembly dependency framework/Microsoft.CSharp 4.0.0.0
Source: C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.1\Microsoft.CSharp.dll
Building ClassLibrary39 for DNXCore,Version=v5.0
Using Project dependency ClassLibrary39 1.0.0
Source: C:\Users\davifowl\Documents\Visual Studio 14\Projects\ClassLibrary39\src\ClassLibrary39\project.json
Using Package dependency System.Console 4.0.0-beta-22709
Source: C:\Users\davifowl\.dnx\packages\System.Console\4.0.0-beta-22709
File: lib\contract\System.Console.dll
Using Package dependency System.IO 4.0.10-beta-22231
Source: C:\Users\davifowl\.dnx\packages\System.IO\4.0.10-beta-22231
File: lib\contract\System.IO.dll
Using Package dependency System.Runtime 4.0.20-beta-22231
Source: C:\Users\davifowl\.dnx\packages\System.Runtime\4.0.20-beta-22231
File: lib\contract\System.Runtime.dll
Using Package dependency System.Text.Encoding 4.0.10-beta-22231
Source: C:\Users\davifowl\.dnx\packages\System.Text.Encoding\4.0.10-beta-22231
File: lib\contract\System.Text.Encoding.dll
Using Package dependency System.Threading.Tasks 4.0.10-beta-22231
Source: C:\Users\davifowl\.dnx\packages\System.Threading.Tasks\4.0.10-beta-22231
File: lib\contract\System.Threading.Tasks.dll
В выходных данных показаны все сборки, переданные в компилятор из пакетов и ссылок на проекты. Когда вы начинаете получать ошибки сборки, полезно посмотреть здесь, чтобы убедиться, что используемый вами пакет действительно работает на этой целевой платформе.
Вот пример пакета, который не работает на dnxcore50:
{
"version": "1.0.0-*",
"dependencies": {
"Microsoft.Owin.Host.SystemWeb": "3.0.0"
},
"frameworks": {
"dnx451": {
"dependencies": {
}
},
"dnxcore50": {
"dependencies": {
"System.Console": "4.0.0-beta-22709"
}
}
}
}
Microsoft.Owin.Host.SystemWeb версии 3.0.0 не имеет сборок, работающих на dnxcore50 (взгляните на папку lib распакованного пакета). Когда мы бежим kpm build:
Заметьте, что там написано «используя пакет Microsoft.Owin.Host.SystemWeb», но там нет «File:». Это могло быть причиной сбоя сборки.
Здесь заканчивается мой мозговой дамп