Re[10]: YAML
От: hi_octane Беларусь  
Дата: 21.10.16 10:02
Оценка:
Q>Почему ты принимаешь за хреновое окошко настроек именно Solution Explorer, а не... хм... хреновое окошко настроек?
Это самый простой пример который показывает что GUI из дерева и поиска для решения задачи выбора нужного тэга (в данном случае файла) таки удобнее чем ползание с текстовым редактором по форматам сериализации. Но из-за косности мышления тех кто пилит окна настроек студии у нас есть странный комплекс из убогого окошка, в которое все настройки во всех сочетаниях ручками впилить никаких бюджетов не хватит + XML-я. Замена XML-я на json не решает проблемы
Re[11]: VSCode
От: Qbit86 Кипр
Дата: 21.10.16 10:08
Оценка:
Здравствуйте, hi_octane, Вы писали:

_>GUI из дерева и поиска для решения задачи выбора нужного тэга (в данном случае файла) таки удобнее чем ползание с текстовым редактором по форматам сериализации.


В VSCode древовидное отображение файлов не мешает text-based настройкам.
Глаза у меня добрые, но рубашка — смирительная!
Re[3]: [Ann] .NET Core Tooling & Common Project System
От: VladD2 Российская Империя www.nemerle.org
Дата: 21.10.16 10:18
Оценка:
Здравствуйте, Михаил Романов, Вы писали:

МР>* Проектную систему отвзяли от VisualStudio. Теперь она разбита на CPS Core (общее ядро, никак не связанное с VS) и CPS VS (которая интегрирует Core в VS). На сколько это существенно, сказать не могу. Вроде


С CPS вопросов нет. Но это поддержка проектов для IDE. И она на безе все того же МСБилда сделана.

МР>* Все многообразие проектных систем (все VSLangProj-VSLangProj140, а также, судя по всему, VCProject) свели к общему знаменателю

МР>* Убрали привязку к COM. Все расширения на основе MEF
МР>* Четко обозначили точки расширения (для модификации существующих или создания собственных типов проектов): создание собственных элементов дерева проектов, свойства проекта, запуск отладчика, деплой, ...

Это все тоже к CPS относится. Формат проекта тут не причем. По сути тупо дали железной линейкам по пальцам всем кто игрался с разными новыми форматами и приказали вернуться к МСБилду. А в пиаре подали это как новаторство.

МР>По большому счету, эти изменения важны для разработчиков различных расширений (таких, которые требуют собственных типов проектов) для VS. Ну и изменения эти примерно как переход в VS 2010 от Language Services к Editor Extensions.


Это и есть часть этого перехода. До появления CPS расширения можно было делать только на уровне редактора кода. А теперь и на уровне проектной системы. По усти просто заменили MPF на CPS. И произошло это за долго до выхода 15-й студии. Уже в 2015-й шарпоуский С++-ный проекты на CPS (если не ошибаюсь) сделаны.

МР>Теоретически, сейчас дорабатывать проектную систему должно стать серьезно проще и быть может, как в случае с Roslyn (после зоопарка компиляторов и языковых сервисов), развитие проектных систем может ускориться.


Это да. Только мало кому нужно дорабатывать проектные системы. Расширения на уровне компилятора намного более востребованы будут.

Это скорее облегчение создания своих проектных систем для других языков, отказ от КОМ-а, ну и общая кодовая база для проектных систем в МС. Все это конечно здорово. Но это именно про CPS и Студию, а не про формат файла проекта в Дотнет Кор.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: VSCode
От: hi_octane Беларусь  
Дата: 21.10.16 11:22
Оценка:
Q>В VSCode древовидное отображение файлов не мешает text-based настройкам.
Ты наверное сразу в 10 ветках отвечаешь. Hint: я никогда не утверждал что в VSCode что-то чему-то мешает
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.