Свойство Assembly у экземпляра Type — чтобы получить описание сборки у типа необходимо использовать метод-расширение GetTypeInfo(). Ломает совместимость с текущим кодом, особенно в ресурсных файлах.
Это является проблемой только тогда, когда нужно поддерживать 2 версии проекта (для .NET Core и .NET Framework 4.0).
Чтобы сгладить различия между разными реализациями Reflection, я использую полифиллы (например, TypeInfo.cs и TypeExtensions.cs).
С генерацией ресурсных файлов сложнее. Пришлось отказаться от стандартных генераторов в пользу собственного, написанного под Sake и KoreBuild.
Единственная проблема, что старый солюшен с csproj-проектами перестанет работать, чтобы оба проекта работали side by side есть решение. Выглядит довольно странно, но работает.
Чтобы решить эту проблему я разделил проект на 2 директории: ИМЯ_ПРОЕКТА и ИМЯ_ПРОЕКТА.Net4. В первой директории оставил: xproj-файл, project.json, весь общий код, а также код, необходимый для .NET Core-версии. Во второй: csproj-файл, packages.config и код, необходимый для .NET Framework 4.0-версии (файлы с общим кодом добавляются в csproj-файл в виде ссылок).
Если вдруг для объединения и сжатия файлов вы используете какие-то модули системы управления — отключите их. Модули создают динамический код для объединения файлов, и код этот дополнительно нагружает хостинг и тратит его ресурсы.
В последнее время, часто слышу этот совет от сотрудников Microsoft. Сейчас рекомендуется производить минификацию (и любую другую обработку) стилей и скриптов на этапе сборки проекта (например, с помощью Grunt или Gulp).
Я бы не сказал, что технологии на базе Node.js встраиваются в ASP.NET. Наличие этих технологий в шаблонах проектов и инструментарии Visual Studio не означает, что они часть ASP.NET. В проектах, написанных на ASP.NET 5 Core вы можете использовать вместо них другие технологии: VS-расширения Мэдса Кристенсена или Smidge.
Но нужно понимать, что все современные фронтенд-технологии созданы на базе Node.js (за исключением: Sass, YUI Compressor и Closure Compiler). Никакие .NET-адаптации этих технологий не могут полностью реализовать их функционал – это я говорю вам как автор Bundle Transformer.
Главной причиной добавления поддержки Gulp в шаблоны проектов новой версии ASP.NET является ее кроссплатформенность. Предполагается, что часть разработчиков будет писать ASP.NET 5 Core приложения на компьютерах, на которых установлены Linux и Mac OS. Как правило, эти разработчики уже знакомы с Node.js, Grunt, Gulp и Bower.
Если эти инструменты кажутся вам неудобными, то вы можете использовать вместо них VS-расширения, разработанные Мэдсом Кристенсеном: Bundler & Minifier, Web Compiler и Web Analyzer.
Для меня на данный момент проще всего сделать свойство Configuration класса Startup статическим, чтобы достать из него конфигурацию. Наверное, можно найти более гибкое решение.
Можно зарегистрировать экземпляр IConfiguration как сервис:
public class Startup
{
public IConfiguration Configuration
{
get;
set;
}
public Startup(IHostingEnvironment env, IApplicationEnvironment appEnv)
{
...
Configuration = builder.Build();
...
}
public void ConfigureServices(IServiceCollection services)
{
services.AddInstance(Configuration);
...
}
...
}
А потом получить этот экземпляр с помощью dependency injection (через конструктор или свойство помеченное атрибутом FromServices).
Это является проблемой только тогда, когда нужно поддерживать 2 версии проекта (для .NET Core и .NET Framework 4.0).
Чтобы сгладить различия между разными реализациями Reflection, я использую полифиллы (например, TypeInfo.cs и TypeExtensions.cs).
С генерацией ресурсных файлов сложнее. Пришлось отказаться от стандартных генераторов в пользу собственного, написанного под Sake и KoreBuild.
Чтобы решить эту проблему я разделил проект на 2 директории:
ИМЯ_ПРОЕКТАиИМЯ_ПРОЕКТА.Net4. В первой директории оставил:xproj-файл,project.json, весь общий код, а также код, необходимый для .NET Core-версии. Во второй:csproj-файл,packages.configи код, необходимый для .NET Framework 4.0-версии (файлы с общим кодом добавляются в csproj-файл в виде ссылок).HostingEnvironment.IsDevelopment()фактически является заменойHttpContext.Current.IsDebuggingEnabled.Последовательность перевода проектов на .NET Core следующая:
В последнее время, часто слышу этот совет от сотрудников Microsoft. Сейчас рекомендуется производить минификацию (и любую другую обработку) стилей и скриптов на этапе сборки проекта (например, с помощью Grunt или Gulp).
Скотт Гатри
Нельзя это рекомендовать абсолютно всем IT-никам. Иначе работать будет некому.
Но нужно понимать, что все современные фронтенд-технологии созданы на базе Node.js (за исключением: Sass, YUI Compressor и Closure Compiler). Никакие .NET-адаптации этих технологий не могут полностью реализовать их функционал – это я говорю вам как автор Bundle Transformer.
Если эти инструменты кажутся вам неудобными, то вы можете использовать вместо них VS-расширения, разработанные Мэдсом Кристенсеном: Bundler & Minifier, Web Compiler и Web Analyzer.
Можно зарегистрировать экземпляр
IConfigurationкак сервис:А потом получить этот экземпляр с помощью dependency injection (через конструктор или свойство помеченное атрибутом
FromServices).