Гарне питання. Що стосується вашої конкретної проблеми, то, схоже, у вас невідповідність вирішеним залежностям. Коли такі випадки трапляються, швидше за все, ви працюєте з додатком на несумісному 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, навіть якщо існують новіші версії. Вказані порожні версії ВЖЕ погано, і в наступних версіях їх буде заборонено.
Існує нова функція, яку ми вводимо в цілісні плаваючі версії. Сьогодні він працює лише над тегом попереднього випуску, але в наступній версії він буде працювати над більшою частиною версії. Це схоже на синтаксис npm та gem для визначення діапазонів версій у файлі специфікації пакета.
1.0.0-*- Значить, дайте мені ВИСОКУ версію, що відповідає префіксу (відповідно до правил семантичної версії ) АБО якщо немає версії, яка відповідає цьому префіксу, використовуйте нормальну поведінку та отримайте мене НАЙНІШКУЮ версію> = вказана версія.
Коли ви запустите відновлення в останніх збірках, він випише файл з назвою project.lock.json. Цей файл матиме транзитивне закриття залежностей для всіх цільових рамок, визначених у project.json.
Якщо щось подібне не вдається, ви можете зробити наступне:
Погляньте на вирішені залежності, використовуючи kpm list. Це покаже вам розв’язані версії пакетів, на які посилається ваш проект, і яку залежність викликав його. Наприклад, якщо A -> B, він покаже:
А
-> В
Б
->
Фактичний вихід списку 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), ви можете подивитися вузол посилань. Він має ті самі дані, які представлені візуально:
Давайте розглянемо, як виглядає поломка залежності:
Ось project.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 . Ви можете керувати цими глобальними джерелами у візуальній студії або за допомогою інструменту командного рядка NuGet. Ви завжди повинні дивитись на ефективні джерела (ті, які перераховані у вихідних даних у хвилину), намагаючись діагностувати збої.
Детальніше про 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, а ви намагаєтеся запустити dnx CoreCLR, може виникнути подібна проблема. Зверніть пильну увагу на цільову рамку у повідомленні про помилку:
Для бігу:
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", але немає "Файл:". Це може бути причиною невдачі в побудові.
Тут закінчується мозок мозку