Как я могу диагностировать отсутствующие зависимости (или другие сбои загрузчика) в 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"
  ]
}