Сообщение Re[27]: [OFF] Научная фантастика :) от 09.03.2017 1:03
Изменено 09.03.2017 1:42 Mystic Artifact
Re[27]: [OFF] Научная фантастика :)
Здравствуйте, fddima, Вы писали:
F> Ещё, что ты собственно и написал — я согласен на все сто. Более того, я попробовал неткору в 2017 и почти рарыдался сразу по мелочам. Всё ещё очень похоже на сторонний плагин от сторонней команды.
Я лично, да и энтэрпрайз с таким подходом думаю, как минимум до нетстандарт2.0 даже не начнет шевелится. Имхо. А кто и начнет — то подальше от. 
Хотя и катастрофы нет никакой. Просто имхо планка качества упала. Правда скорость реакции повысилась, а это нынче модно.
Sinix вот поставил мне... весьма высокую оценку за вполне флеймовый вброс. Отработаю.
Банально. Они решили,
Конечно же — страшный энтэрпрайз об этом позаботился.
1. Так было всегда ДО того как их "индусы" осознали что есть шаблоны включения файлов.
2. Я практически генерирую .csproj проект, файлы в него. Я когда указываю файлы явно — могу не заботится о чистоте директорий. Согласитесь — это же естественно для любого итерационного билд скрипта. Оказался лишний файл в выходной директории? Ну и хер с ним — он просто не включён в проект и потому не компилируется.
3. Естественно студия совершенно не знает ничего о EnableDefaultCompileItems. Если оно запрещено оно всё равно не добавляет новосозданные файлы в проект. Простите, но мы более 10 лет 99% правок в csproj проводим как раз через студию и лишь некоторые включения делаем руками, которые студия давно не трогает. Есть отличнейше отлаженный механизм.
Я на фоне этого чувствую себя обманутым — слава богу что нет более project.json и настоящий msbuild работает! Ура! Ура! Ура! Но поддержка тех же самых проектов в студии — стала много хуже.
Для людей которым достаточно **/*.cs — достаточно было и project.json. Но это бред, особенно учитывая насколько это тесно интегрировано в тулчейн.
Теперь вопрос на очереди у меня такой: можно ли работать с .net core в таком русле, что бы output директории вынести out-of-source-tree? Это более чем стандартный подход. Более того, я считаю его единственно вменяемым. То, что они ложат bin/obj прям рядом... какая разница куда ложить это тулчейну? Ему нужно знать только где искать и куда ложить. С копыт — получил только ошибки. Может и можно. Не знаю. Но, афаик — они это прошили везде где могли. Так или иначе — это ещё один, уже традиционный идиотизм. Можете спорить с этим, но 99% всех проектов которые мне встречались — либо не навязывают, либо out директория лежит вне src. Это банально удобно. С нормальным дотнетом для не вебовых проектов — это было возможно. Сейчас сходу (переопредив OutputPath — получаешь ошибки — часть пишет в OutputPath — часть нихера не находит). Извините — output директории — это личное дело проекта. Если "технология" настолько тупа — то... страшно даже предположить что они ещё наворотили там.
Как-то так.
PS: Все возможные оценки за это сообщение получено в предыдущем сообщении.
F> Ещё, что ты собственно и написал — я согласен на все сто. Более того, я попробовал неткору в 2017 и почти рарыдался сразу по мелочам. Всё ещё очень похоже на сторонний плагин от сторонней команды.
Я лично, да и энтэрпрайз с таким подходом думаю, как минимум до нетстандарт2.0 даже не начнет шевелится. Имхо. А кто и начнет — то подальше от. Хотя и катастрофы нет никакой. Просто имхо планка качества упала. Правда скорость реакции повысилась, а это нынче модно.Sinix вот поставил мне... весьма высокую оценку за вполне флеймовый вброс. Отработаю.
Банально. Они решили,
<Compile Include="**/*.cs" />Конечно же — страшный энтэрпрайз об этом позаботился.
<EnableDefaultCompileItems>false</EnableDefaultCompileItems>1. Так было всегда ДО того как их "индусы" осознали что есть шаблоны включения файлов.
2. Я практически генерирую .csproj проект, файлы в него. Я когда указываю файлы явно — могу не заботится о чистоте директорий. Согласитесь — это же естественно для любого итерационного билд скрипта. Оказался лишний файл в выходной директории? Ну и хер с ним — он просто не включён в проект и потому не компилируется.
3. Естественно студия совершенно не знает ничего о EnableDefaultCompileItems. Если оно запрещено оно всё равно не добавляет новосозданные файлы в проект. Простите, но мы более 10 лет 99% правок в csproj проводим как раз через студию и лишь некоторые включения делаем руками, которые студия давно не трогает. Есть отличнейше отлаженный механизм.
Я на фоне этого чувствую себя обманутым — слава богу что нет более project.json и настоящий msbuild работает! Ура! Ура! Ура! Но поддержка тех же самых проектов в студии — стала много хуже.
Для людей которым достаточно **/*.cs — достаточно было и project.json. Но это бред, особенно учитывая насколько это тесно интегрировано в тулчейн.
Теперь вопрос на очереди у меня такой: можно ли работать с .net core в таком русле, что бы output директории вынести out-of-source-tree? Это более чем стандартный подход. Более того, я считаю его единственно вменяемым. То, что они ложат bin/obj прям рядом... какая разница куда ложить это тулчейну? Ему нужно знать только где искать и куда ложить. С копыт — получил только ошибки. Может и можно. Не знаю. Но, афаик — они это прошили везде где могли. Так или иначе — это ещё один, уже традиционный идиотизм. Можете спорить с этим, но 99% всех проектов которые мне встречались — либо не навязывают, либо out директория лежит вне src. Это банально удобно. С нормальным дотнетом для не вебовых проектов — это было возможно. Сейчас сходу (переопредив OutputPath — получаешь ошибки — часть пишет в OutputPath — часть нихера не находит). Извините — output директории — это личное дело проекта. Если "технология" настолько тупа — то... страшно даже предположить что они ещё наворотили там.
Как-то так.
PS: Все возможные оценки за это сообщение получено в предыдущем сообщении.
Re[27]: [OFF] Научная фантастика :)
Здравствуйте, fddima, Вы писали:
F> Ещё, что ты собственно и написал — я согласен на все сто. Более того, я попробовал неткору в 2017 и почти рарыдался сразу по мелочам. Всё ещё очень похоже на сторонний плагин от сторонней команды. Я лично, да и энтэрпрайз с таким подходом думаю, как минимум до нетстандарт2.0 даже не начнет шевелится. Имхо. А кто и начнет — то подальше от. Хотя и катастрофы нет никакой. Просто имхо планка качества упала. Правда скорость реакции повысилась, а это нынче модно.
Sinix вот поставил мне... весьма высокую оценку за вполне флеймовый вброс. Отработаю.
Банально. Они решили,
Конечно же — страшный энтэрпрайз об этом позаботился.
1. Так было всегда ДО того как их "индусы" осознали что есть шаблоны включения файлов.
2. Я практически генерирую .csproj проект, файлы в него. Я когда указываю файлы явно — могу не заботится о чистоте директорий. Согласитесь — это же естественно для любого итерационного билд скрипта. Оказался лишний файл в выходной директории? Ну и хер с ним — он просто не включён в проект и потому не компилируется.
3. Естественно студия совершенно не знает ничего о EnableDefaultCompileItems. Если оно запрещено оно всё равно не добавляет новосозданные файлы в проект. Простите, но мы более 10 лет 99% правок в csproj проводим как раз через студию и лишь некоторые включения делаем руками, которые студия давно не трогает. Есть отличнейше отлаженный механизм.
Я на фоне этого чувствую себя обманутым — слава богу что нет более project.json и настоящий msbuild работает! Ура! Ура! Ура! Но поддержка тех же самых проектов в студии — стала много хуже.
Для людей которым достаточно **/*.cs — достаточно было и project.json. Но это бред, особенно учитывая насколько это тесно интегрировано в тулчейн.
Теперь вопрос на очереди у меня такой: можно ли работать с .net core в таком русле, что бы output директории вынести out-of-source-tree? Это более чем стандартный подход. Более того, я считаю его единственно вменяемым. То, что они ложат bin/obj прям рядом... какая разница куда ложить это тулчейну? Ему нужно знать только где искать и куда ложить. С копыт — получил только ошибки. Может и можно. Не знаю. Но, афаик — они это прошили везде где могли. Так или иначе — это ещё один, уже традиционный идиотизм. Можете спорить с этим, но 99% всех проектов которые мне встречались — либо не навязывают, либо out директория лежит вне src. Это банально удобно. С нормальным дотнетом для не вебовых проектов — это было возможно. Сейчас сходу (переопредив OutputPath — получаешь ошибки — часть пишет в OutputPath — часть нихера не находит). Извините — output директории — это личное дело проекта. Если "технология" настолько тупа — то... страшно даже предположить что они ещё наворотили там.
Как-то так.
PS: Все возможные оценки за это сообщение получено в предыдущем сообщении.
PPS: В общем если в итоге окажется, что изменить выходную директорию совсем никак нельзя — то, я скажу, что это не технология, а... "новогодняя ёлка" и это слово — буду использовать или до тех пор пока не пофиксят или до 2018.
F> Ещё, что ты собственно и написал — я согласен на все сто. Более того, я попробовал неткору в 2017 и почти рарыдался сразу по мелочам. Всё ещё очень похоже на сторонний плагин от сторонней команды.
Я лично, да и энтэрпрайз с таким подходом думаю, как минимум до нетстандарт2.0 даже не начнет шевелится. Имхо. А кто и начнет — то подальше от. Хотя и катастрофы нет никакой. Просто имхо планка качества упала. Правда скорость реакции повысилась, а это нынче модно.Sinix вот поставил мне... весьма высокую оценку за вполне флеймовый вброс. Отработаю.
Банально. Они решили,
<Compile Include="**/*.cs" />Конечно же — страшный энтэрпрайз об этом позаботился.
<EnableDefaultCompileItems>false</EnableDefaultCompileItems>1. Так было всегда ДО того как их "индусы" осознали что есть шаблоны включения файлов.
2. Я практически генерирую .csproj проект, файлы в него. Я когда указываю файлы явно — могу не заботится о чистоте директорий. Согласитесь — это же естественно для любого итерационного билд скрипта. Оказался лишний файл в выходной директории? Ну и хер с ним — он просто не включён в проект и потому не компилируется.
3. Естественно студия совершенно не знает ничего о EnableDefaultCompileItems. Если оно запрещено оно всё равно не добавляет новосозданные файлы в проект. Простите, но мы более 10 лет 99% правок в csproj проводим как раз через студию и лишь некоторые включения делаем руками, которые студия давно не трогает. Есть отличнейше отлаженный механизм.
Я на фоне этого чувствую себя обманутым — слава богу что нет более project.json и настоящий msbuild работает! Ура! Ура! Ура! Но поддержка тех же самых проектов в студии — стала много хуже.
Для людей которым достаточно **/*.cs — достаточно было и project.json. Но это бред, особенно учитывая насколько это тесно интегрировано в тулчейн.
Теперь вопрос на очереди у меня такой: можно ли работать с .net core в таком русле, что бы output директории вынести out-of-source-tree? Это более чем стандартный подход. Более того, я считаю его единственно вменяемым. То, что они ложат bin/obj прям рядом... какая разница куда ложить это тулчейну? Ему нужно знать только где искать и куда ложить. С копыт — получил только ошибки. Может и можно. Не знаю. Но, афаик — они это прошили везде где могли. Так или иначе — это ещё один, уже традиционный идиотизм. Можете спорить с этим, но 99% всех проектов которые мне встречались — либо не навязывают, либо out директория лежит вне src. Это банально удобно. С нормальным дотнетом для не вебовых проектов — это было возможно. Сейчас сходу (переопредив OutputPath — получаешь ошибки — часть пишет в OutputPath — часть нихера не находит). Извините — output директории — это личное дело проекта. Если "технология" настолько тупа — то... страшно даже предположить что они ещё наворотили там.
Как-то так.
PS: Все возможные оценки за это сообщение получено в предыдущем сообщении.
PPS: В общем если в итоге окажется, что изменить выходную директорию совсем никак нельзя — то, я скажу, что это не технология, а... "новогодняя ёлка" и это слово — буду использовать или до тех пор пока не пофиксят или до 2018.