Комментарии 42
Вот момент с генерацией проекта йоменом был вообще неожиданный. У матерых энтерпрайзников не подгорает от использования столь низменной технологии как nodejs?:)
P.S. ничего не имею против .NET, просто многие посматривают свысока на JS вообще и на nodejs в частности.
$ dotnet new --help- Nuget Config
- Web Config
- Solution File
А где ещё шаблоны можно взять для этой команды?
dotnet new -t --help
Unrecognized type: --help
Avaiable types for C# :
- Console
- Web
- Lib
- xunittest
в Preview 4 еще больше проектов
- Console Application console [C#], F# Common/Console
- Class library classlib [C#], F# Common/Library
- Unit Test Project mstest [C#], F# Test/MSTest
- xUnit Test Project xunit [C#], F# Test/xUnit
- Empty ASP.NET Core Web Application web [C#] Web/Empty
- MVC ASP.NET Core Web Application mvc [C#], F# Web/MVC
- Web API ASP.NET Core Web Application webapi [C#] Web/WebAPI
- Nuget Config nugetconfig Config
- Web Config webconfig Config
- Solution File
почти все те-же проекты можно генерировать используя dotnet new
Так почему в примере не используется dotnet new, какие преимущества у йомена в данном случае?
dotnet new 3 шаблона и ни одного веб приложения, только консольное, а для йомена уже наделали кучу, вот только несколько навскидку:- https://github.com/omnisharp/generator-aspnet#readme
- https://github.com/kriasoft/aspnet-starter-kit#readme
- https://github.com/sgbj/generator-aspnetcore-angular2
- https://github.com/deatharrow01/generator-aspnetpostgresql#readme
- https://github.com/digipolisantwerp/generator-dgp-api-aspnetcore_yeoman
- https://github.com/aspnet/JavaScriptServices#readme
- https://github.com/rahulsahay19/generator-aspnetcore-angular-2
Смотри полный список здесь: http://yeoman.io/generators/ по запросу aspnet
Microsoft вводили project.json, потому что хотели быть модными.
И, к счастью, избавляются от него :)
А почему к счастью? Какие проблемы были у project.json?
Чисто декларативное описание это прекрасно, но недостаточно гибко и для введения новой функциональности требует обновления toolset. Msbuild же, при всей громоздкости синтаксиса уже сложился и имеет кучу инструментов, которые упрощают процесс сборки, в том числе сложной и автоматизированной. Когда msbuild не было для платформ, отличных от Windows, в новом инструменте был существенный смысл, но теперь уже нет.
Я уверен, что и project.json можно было развить до такого состояния, но с учётом описанного выше, мне кажется что возврат к msbuild более логичный шаг. К сожалению, Microsoft могли бы додуматься до этого раньше, сложившаяся ситуация с необходимостью миграции, конечно далека от идеала.
Эти сами "многие" просто еще не осознали, что node.js — это не только сервер, но и среда для запуска системных утилит, в том числе компиляторов.
Не использовать babel или tsc только потому что они написаны на js и требуют для запуска ноды — глупость.
С точки зрения веба:
С одной стороны, все стандартные решения из мира node.js хороши тем, что они стандартные (babel, tsc, grunt\gulp, webpack). Но я тестировал grunt, webpack — они куда медленнее применяют изменения на лету, чем старые добрые ASP.NET Bundles. Сохранил, подождал несколько секунд, а бандлы очень быстрые — не успеваю перевести взгляд на окно браузера (на относительно небольшом объеме транслируемого кода и там, и там)
Посматриваю свысока с удовольствием, ваш нематёрый неэнтерпрайзник :)
судя по последним тестам, даже показывает неплохую производительность
Очень любопытные данные. Вот интересно, как так получается, что интерпретируемые языки (JS, Python итп) занимают более высокие позиции, чем даже компилируемые? (т.е. первые места у C\C++, потом могут идти JS, потом снова C++, Java и так далее в перемешку). Обусловлено веб-сервером, СУБД или чем-то иным?
Из минусов — в VS Code пока не удалось нормально настроить отладку (.
Для установки Visual Studio Code также хорошо подойдет ubuntu-make: https://github.com/ubuntu/ubuntu-make
ASP.NET Core: ваше первое приложение на Linux c использованием Visual Studio Code