Как я могу диагностировать отсутствующие зависимости (или другие ошибки загрузчика) в dnx?

Я пытаюсь запустить измененную версию примера HelloWeb для ASP.NET vNext на DNX, используя Kestrel. Я понимаю, что это очень важно, но я надеюсь, что команда ASP.NET по крайней мере поддержит работу самого простого веб-приложения :)

Окружающая среда:

• Linux (Ubuntu, в значительной степени)
• Mono 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]мертв, значит, не то ... )

Хороший вопрос. Для вашей конкретной проблемы похоже, что у вас есть несоответствие в ваших разрешенных зависимостях. Когда такие вещи случаются, скорее всего, потому что вы запускаете свое приложение на несовместимом 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:». Это могло быть причиной сбоя сборки.

Здесь заканчивается мой мозговой дамп

Я до сих пор не знаю полностью, что случилось, но теперь у меня есть ряд шагов, чтобы хотя бы упростить попытки:

• Если сомневаетесь, переустановите 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": {}
  }
}

Вы можете установить env var с именем DNX_TRACEto, 1чтобы увидеть TON больше диагностической информации. Имейте в виду, это намного больше информации!

Чтобы заставить его работать, я изменил мой 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": {}
}

.. и это все еще работало, тогда как прежде это выкинуло бы ошибку!

Очень странно!

(Я бегу 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).

В наши дни все мои package.jsonверсии заканчиваются"-rc2-*"

(Единственные исключения, которые я видел до сих пор, это Microsoft.Framework.Configurationпакеты, которые должны быть либо "1.0.0-rc1-*"или "1.0.0-*")

Что касается «обучающих версий», о которых упоминает @davidfowl, кажется, что МНОГО боли исчезло между бета8 и 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": {}
}
}

У меня также были проблемы с отсутствием зависимости при попытке утешить ссылки на 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"
  ]
}