Как я могу диагностировать отсутствующие зависимости (или другие сбои загрузчика) в dnx?
Я пытаюсь запустить модифицированную версию образец HelloWeb для ASP.NET vNext на DNX с использованием Kestrel. Я понимаю, что это очень сильно связано с кровотечением, но я надеюсь, что команда ASP.NET, по крайней мере, обеспечит работу с самым простым веб-приложением:)
Окружающая среда:
- Linux (Ubuntu, в значительной степени)
- Моно 3.12.1
- DNX 1.0.0-beta4-11257 (у меня также есть 11249)
"Веб-приложение", в Startup.cs
:
using Microsoft.AspNet.Builder;
public class Startup
{
public void Configure(IApplicationBuilder app)
{
app.UseWelcomePage();
}
}
Конфигурация проекта, в project.json
:
{
"dependencies": {
"Kestrel": "1.0.0-beta4",
"Microsoft.AspNet.Diagnostics": "1.0.0-beta4",
"Microsoft.AspNet.Hosting": "1.0.0-beta4",
"Microsoft.AspNet.Server.WebListener": "1.0.0-beta4",
"Microsoft.AspNet.StaticFiles": "1.0.0-beta4",
"Microsoft.Framework.Runtime": "1.0.0-beta4",
"Microsoft.Framework.Runtime.Common": "1.0.0-beta4",
"Microsoft.Framework.Runtime.Loader": "1.0.0-beta4",
"Microsoft.Framework.Runtime.Interfaces": "1.0.0-beta4",
},
"commands": {
"kestrel": "Microsoft.AspNet.Hosting --server Kestrel --server.urls http://localhost:5004"
},
"frameworks": {
"dnx451": {}
}
}
kpm restore
работает нормально.
Тем не менее, когда я пытаюсь запустить, я получаю исключение, предполагающее, что
Microsoft.Framework.Runtime.IApplicationEnvironment
не может быть найден. Командная строка и ошибка (несколько переформатированная)
.../HelloWeb$ dnx . kestrel
System.IO.FileNotFoundException: Could not load file or assembly
'Microsoft.Framework.Runtime.IApplicationEnvironment,
Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'
or one of its dependencies.
File name: 'Microsoft.Framework.Runtime.IApplicationEnvironment,
Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'
at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke
(System.Reflection.MonoMethod,object,object[],System.Exception&)
at System.Reflection.MonoMethod.Invoke
(System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder,
System.Object[] parameters, System.Globalization.CultureInfo culture)
[0x00000] in <filename unknown>:0
Хотя, очевидно, моя самая насущная необходимость - это исправить это, я также ценю советы о том, как перевести диагноз, что происходит неправильно, поэтому я могу исправить подобные проблемы самостоятельно в будущем. (Это также может сделать этот вопрос более полезным для других.)
Я нашел Microsoft.Framework.Runtime.IApplicationEnvironment
в источнике сборки Microsoft.Framework.Runtime.Interfaces
, и это, похоже, недавно не изменилось. Непонятно, почему исключение показывает имя, как будто это целая сборка сама по себе, а не просто интерфейс внутри другой сборки. Я предполагаю, что это может быть связано с нейтральными интерфейсами сборки, но это неясно из-за ошибки. ([AssemblyNeutral]
мертв, так что не он...)
Ответы
Ответ 1
Хороший вопрос. По вашей конкретной проблеме, похоже, что у вас есть несоответствие в ваших разрешенных зависимостях. Когда такие вещи случаются, это вероятно, потому что вы используете свое приложение на несовместимом dnx. Мы по-прежнему делаем очень большие изменения, поэтому, если вы когда-либо видели, что метод отсутствует в типе отсутствует, скорее всего, вы закончили работу с пакетами betaX
и betaY
dnx или наоборот.
Более конкретно, Нейтральные интерфейсы сборки были удалены в бета-версии 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, называемой плавающей версией. Сегодня он работает только с тегом preerelease, но в следующей версии он будет работать над большей частью версии. Это похоже на синтаксис npm и gem для указания диапазонов версий в файле спецификации пакета.
1.0.0-*
- означает, что версия HIGHEST соответствует префиксу (согласно правилам семантического управления версиями) ИЛИ, если версия не соответствует этому префиксу, используйте обычное поведение и получите мне LOWEST версию >= указанную версию.
Когда вы запустите восстановление в последних сборках, он выпишет файл с именем project.lock.json
. Этот файл будет иметь транзитивное замыкание зависимостей для всех целевых фреймворков, определенных в project.json
.
Если что-то подобное не работает, вы можете сделать следующее:
Взгляните на разрешенные зависимости, используя kpm list
. Это покажет вам разрешенные версии пакетов, на которые ссылается ваш проект, и какая зависимость вытащила его. если A → B, он будет показывать:
A
-> B
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), вы можете посмотреть ссылки node. Он имеет те же данные, что и визуально:
![References node]()
Посмотрите, как выглядит сбой зависимости:
Здесь 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-восстановления показывает следующее:
![enter image description here]()
При диагностике, когда восстановление могло быть неудачным, посмотрите на выполненные HTTP-запросы, они расскажут, какие настроенные источники пакетов kpm просмотрели. Обратите внимание, что в приведенном выше изображении есть запрос CACHE
. Это встроенное кэширование на основе типа ресурса (nupkg или nuspec) и имеет настраиваемый TTL (посмотрите kpm restore --help
). Если вы хотите принудительно нажать kpm
на удаленные источники NuGet, используйте флаг --no-cache
:
![KPM restore --no-cache]()
Эти ошибки также отображаются в Visual Studio в окне вывода журнала диспетчера пакетов:
![enter image description here]()
Боковое примечание!
Источники пакетов
Я расскажу, как работает NuGet.config прямо сейчас (что, вероятно, изменится в будущем). По умолчанию у вас есть NuGet.config с источником по умолчанию NuGet.org, настроенным глобально в %appdata%\NuGet\NuGet.Config
. Вы можете управлять этими глобальными источниками в визуальной студии или с помощью инструмента командной строки 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 по ссылкам node:
![Unresolved dependencies]()
Узлы, отмеченные как желтые, не решены.
Они также отображаются в списке ошибок:
![Error list unresolved dependencies]()
Строительство
Эти ошибки также появляются при создании. При построении из командной строки вывод очень подробный и может быть чрезвычайно полезен при диагностике проблем:
> 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
:
![Missing assemblies on dnxcore50]()
Обратите внимание, что это говорит "использование пакета Microsoft.Owin.Host.SystemWeb", но нет "файла:". Это может быть причиной сбоя сборки.
Здесь заканчивается мой мозговой дамп
Ответ 2
Я до сих пор не знаю, что было не так, но теперь у меня есть ряд шагов, чтобы, по крайней мере, облегчить пробовать:
- В случае сомнений переустановите dnx
- Отключение кэша пакетов может быть полезным
- Проверьте
~/.config/NuGet.config
, чтобы убедиться, что вы используете правильные каналы NuGet.
В результате я использовал следующую командную строку для тестирования различных опций по разумной чистоте:
rm -rf ~/.dnx/packages && rm -rf ~/.dnx/runtimes && dnvm upgrade && kpm restore && dnx . kestrel
Похоже, что моя проблема была вызвана неправильными версиями устанавливаемых зависимостей. Номер версии "1.0.0-beta4"
, по-видимому, совершенно отличается от "1.0.0-beta4-*"
. Например, установленная зависимость Kestrel
установлена версия 1.0.0-beta4-11185, только что указанная как 1.0.0-beta4
, но версия 1.0.0-beta4-11262 с -*
в конце. Я хотел явно указать beta4
, чтобы избежать случайного использования сборки beta3 с помощью
Следующая конфигурация проекта работает нормально:
{
"dependencies": {
"Kestrel": "1.0.0-beta4-*",
"Microsoft.AspNet.Diagnostics": "1.0.0-beta4-*",
"Microsoft.AspNet.Hosting": "1.0.0-beta4-*",
"Microsoft.AspNet.Server.WebListener": "1.0.0-beta4-*",
},
"commands": {
"kestrel": "Microsoft.AspNet.Hosting --server Kestrel --server.urls http://localhost:5004"
},
"frameworks": {
"dnx451": {}
}
}
Ответ 3
Вы можете установить env var с именем DNX_TRACE
на 1
, чтобы увидеть дополнительную информацию о TON. Будьте осторожны, это намного больше информации!
Ответ 4
Чтобы заставить его работать, я изменил свой project.json
.. теперь он выглядит так:
{
"dependencies": {
"Kestrel": "1.0.0-*",
"Microsoft.AspNet.Diagnostics": "1.0.0-*",
"Microsoft.AspNet.Hosting": "1.0.0-*",
"Microsoft.AspNet.Server.WebListener": "1.0.0-*",
"Microsoft.AspNet.StaticFiles": "1.0.0-*"
},
"commands": {
"web": "Microsoft.AspNet.Hosting --server Microsoft.AspNet.Server.WebListener --server.urls http://localhost:5001",
"kestrel": "Microsoft.AspNet.Hosting --server Kestrel --server.urls http://localhost:5004"
},
"frameworks": {
}
}
Ключ, казалось, был секцией фреймворков.
Также переименование изменилось, как k web
работает так, что его теперь dnx . web
или dnx . kestrel
Обновление - бит больше информации
Как ни странно, после запуска без каких-либо фреймворков, он пошел и получил кучу лишних вещей, когда я сделал kpm restore
:
...
Installing Microsoft.Framework.Logging 1.0.0-beta4-11001
Installing Microsoft.Framework.Logging.Interfaces 1.0.0-beta4-11001
Installing Microsoft.Framework.DependencyInjection.Interfaces 1.0.0-beta4-11010
Installing Microsoft.Framework.DependencyInjection 1.0.0-beta4-11010
Installing Microsoft.Framework.ConfigurationModel 1.0.0-beta4-10976
Installing Microsoft.Framework.ConfigurationModel.Interfaces 1.0.0-beta4-10976
Installing Microsoft.AspNet.Hosting.Interfaces 1.0.0-beta4-11328
Installing Microsoft.AspNet.FeatureModel 1.0.0-beta4-11104
Installing Microsoft.AspNet.Http 1.0.0-beta4-11104
Installing Microsoft.AspNet.FileProviders.Interfaces 1.0.0-beta4-11006
Installing Microsoft.Framework.Caching.Interfaces 1.0.0-beta4-10981
Installing Microsoft.AspNet.FileProviders 1.0.0-beta4-11006
Installing Microsoft.AspNet.Http.Core 1.0.0-beta4-11104
Installing Microsoft.AspNet.WebUtilities 1.0.0-beta4-11104
Installing Microsoft.Net.Http.Headers 1.0.0-beta4-11104
Installing Microsoft.AspNet.Http.Interfaces 1.0.0-beta4-11104
Installing Microsoft.Framework.Runtime.Interfaces 1.0.0-beta4-11257
Installing Microsoft.AspNet.Server.Kestrel 1.0.0-beta4-11262
Installing Microsoft.Net.Http.Server 1.0.0-beta4-11698
Installing Microsoft.Net.WebSockets 1.0.0-beta4-11698
Installing Microsoft.Net.WebSocketAbstractions 1.0.0-beta4-10915
Installing Microsoft.Framework.WebEncoders 1.0.0-beta4-11104
Installing Microsoft.Framework.OptionsModel 1.0.0-beta4-10984
Installing Microsoft.AspNet.Http.Extensions 1.0.0-beta4-11104
Installing Microsoft.AspNet.Diagnostics.Interfaces 1.0.0-beta4-12451
Installing Microsoft.AspNet.RequestContainer 1.0.0-beta4-11328
.. тогда он прошел нормально. Затем я переключился в рамку раздела
"frameworks": {
"dnx451": {}
}
.. и он по-прежнему работал, тогда как раньше он выдавал бы ошибку!
Очень странно!
(Im running 1.0.0-beta4-11257
)
Дальнейшее обновление
Я создал новый экземпляр Ubuntu и получил ту же ошибку, что и вы.. Я думал, что проблема может быть вызвана только попыткой получить пакеты из nuget.org
, а не myget.org
(у которого есть новый вещи), поэтому я упал в NuGet.Config
в корень проекта.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<add key="AspNetVNext" value="https://www.myget.org/F/aspnetvnext/" />
<add key="NuGet" value="https://nuget.org/api/v2/" />
</packageSources>
</configuration>
.. это, похоже, исправило это для меня, получив правильные версии (после другого kpm restore
).
Ответ 5
В наши дни все мои версии package.json
заканчиваются на "-rc2-*"
(Только исключения, которые я видел до сих пор, это пакеты Microsoft.Framework.Configuration
, которые должны быть либо "1.0.0-rc1-*"
, либо "1.0.0-*"
)
Что касается "поездок версий", о которых упоминает @davidfowl, кажется, что LOT боли исчезли между бета-версиями и rc2.
dnvm upgrade -u -arch x64 -r coreclr
У меня была лучшая удача на coreclr
с этими двумя каналами NuGet:
"https://www.myget.org/F/aspnetvnext/"
"https://nuget.org/api/v2/"
Когда у меня возникают проблемы с пакетом пакетов, 90% времени это те же самые преступники:
Newtonsoft.Json
Ix-Async
Remotion.Linq
В большинстве случаев я могу обойти их, запустив основной канал NuGet.org:
dnu restore;
dnu restore -s https://nuget.org/api/v2
Вот мой рабочий config.json:
{
"dependencies": {
"Microsoft.AspNet.Diagnostics": "1.0.0-rc2-*",
"Microsoft.AspNet.Diagnostics.Entity": "7.0.0-rc2-*",
"Microsoft.AspNet.Hosting": "1.0.0-rc2-*",
"Microsoft.AspNet.Http": "1.0.0-rc2-*",
"Microsoft.AspNet.Http.Abstractions": "1.0.0-rc2-*",
"Microsoft.AspNet.Mvc.Core": "6.0.0-rc2-*",
"Microsoft.AspNet.Mvc.Razor": "6.0.0-rc2-*",
"Microsoft.AspNet.Owin": "1.0.0-rc2-*",
"Microsoft.AspNet.Routing": "1.0.0-rc2-*",
"Microsoft.AspNet.Server.Kestrel": "1.0.0-rc2-*",
"Microsoft.AspNet.Server.WebListener": "1.0.0-rc2-*",
"Microsoft.AspNet.Session": "1.0.0-rc2-*",
"Microsoft.AspNet.StaticFiles": "1.0.0-rc2-*",
"EntityFramework.Commands": "7.0.0-rc2-*",
"EntityFramework.Core": "7.0.0-rc2-*",
"EntityFramework.InMemory": "7.0.0-rc2-*",
"EntityFramework.MicrosoftSqlServer": "7.0.0-rc2-*",
"EntityFramework.MicrosoftSqlServer.Design": "7.0.0-rc2-*",
"EntityFramework.Relational": "7.0.0-rc2-*",
"EntityFramework7.Npgsql": "3.1.0-beta8-2",
"Microsoft.Extensions.Logging.Abstractions": "1.0.0-rc2-*",
"Microsoft.Extensions.Logging.Console": "1.0.0-rc2-*",
"Microsoft.Extensions.DependencyInjection": "1.0.0-rc2-*",
"Microsoft.Extensions.DependencyInjection.Abstractions": "1.0.0-rc2-*",
"Microsoft.Framework.Configuration.CommandLine": "1.0.0-*",
"Microsoft.Framework.Configuration.EnvironmentVariables": "1.0.0-*",
"Microsoft.Framework.Configuration.Json": "1.0.0-*"
},
"commands": {
"ef": "EntityFramework.Commands",
"dev": "Microsoft.AspNet.Hosting --ASPNET_ENV Development --server Microsoft.AspNet.Server.Kestrel --server.urls http://localhost:5004"
},
"frameworks": {
"dnxcore50": {}
}
}
Ответ 6
У меня также были проблемы с отсутствием зависимостей, пытаясь успокоить ссылки dnxcore50 и dnx451.
Если я понимаю это право "зависимостей": {} разделяются между фреймворками.
Затем "зависимости": {} в рамках "рамки": относятся к этой структуре.
dnxcore50 - это модульная среда выполнения (сама по себе), поэтому она в основном содержит все основные среды выполнения, необходимые для запуска программы, в отличие от классической структуры .net, где у вас есть основные зависимости, разбросанные по всему миру.
Итак, с учетом сказанного я хотел придерживаться минимального подхода, я решил разместить на Mac или Linux в какой-то момент.
Обновление
Разработанные в странные проблемы с зависимостью с представлениями cshtml, теперь просто с dnx451.
Это мой проект .json
{
"webroot": "wwwroot",
"version": "1.0.0-*",
"dependencies": {
"System.Runtime": "4.0.10",
"Microsoft.AspNet.Hosting": "1.0.0-beta4",
"Microsoft.AspNet.Mvc": "6.0.0-beta4",
"Microsoft.AspNet.Server.IIS": "1.0.0-beta6-12075",
"Microsoft.AspNet.Server.WebListener": "1.0.0-beta6-12457",
"Microsoft.Framework.DependencyInjection": "1.0.0-beta4",
"Microsoft.Framework.DependencyInjection.Interfaces": "1.0.0-beta5"
},
"commands": {
"web": "Microsoft.AspNet.Hosting --server Microsoft.AspNet.Server.WebListener --server.urls http://admin.heartlegacylocal.com" },
"frameworks": {
"dnx451": { }
}
},
"publishExclude": [
"node_modules",
"bower_components",
"**.xproj",
"**.user",
"**.vspscc"
],
"exclude": [
"wwwroot",
"node_modules",
"bower_components"
]
}