default *.csproj - немного улучшаем
От: Kolesiki  
Дата: 01.12.15 17:50
Оценка: 6 (2)
Когда студия создаёт проект, сразу же его закрываю и в *.csproj файле делаю вот такие изменения:

<OutputPath>bin\Debug\</OutputPath>  меняю на <OutputPath>bin_Debug\</OutputPath> - уменьшить вложенность каталогов (и bin\Release тоже)
<BaseIntermediateOutputPath>R:\TEMP\obj\$(ProjectGuid)\</BaseIntermediateOutputPath> - указываю, где студия должна создавать всю временную шнягу (это RAM-диск)

Для внешних библиотек:
<HintPath>..\SomeLib\bin_$(Configuration)\lib.dll</HintPath> - позволяет собирать релиз из релизных сборок других библиотек (и дебаг из дебаговых).


Надеюсь, кому-то будет полезным.
Re: default *.csproj - немного улучшаем
От: Mr.Delphist  
Дата: 02.12.15 12:48
Оценка:
Здравствуйте, Kolesiki, Вы писали:

K>Когда студия создаёт проект, сразу же его закрываю и в *.csproj файле делаю вот такие изменения:


K><BaseIntermediateOutputPath>R:\TEMP\obj\$(ProjectGuid)\</BaseIntermediateOutputPath> — указываю, где студия должна создавать всю временную шнягу (это RAM-диск)

Это может быть полезно, да

K><OutputPath>bin\Debug\</OutputPath> меняю на <OutputPath>bin_Debug\</OutputPath> — уменьшить вложенность каталогов (и bin\Release тоже)

А зачем эта экономия на спичках — не понимаю.

Более того, она влечёт за собой вот эту костылизацию (бедняга Nuget плюс ручной патчинг тех 3rd party-либ, которые мы получаем из сырцов):
K><HintPath>..\SomeLib\bin_$(Configuration)\lib.dll</HintPath> — позволяет собирать релиз из релизных сборок других библиотек (и дебаг из дебаговых).
Re[2]: default *.csproj - немного улучшаем
От: Sinix  
Дата: 02.12.15 14:10
Оценка: +4
Здравствуйте, Mr.Delphist, Вы писали:

Как всегда с "оптимизаторами", одно чиним, другое ломаем

K>><BaseIntermediateOutputPath>R:\TEMP\obj\$(ProjectGuid)\</BaseIntermediateOutputPath> — указываю, где студия должна создавать всю временную шнягу (это RAM-диск)

MD>Это может быть полезно, да

А вот тут я не уверен.
Насколько помню, очистка obj-папок приводит к поломке incremental build. Перезагрузился — получи full rebuild в подарок.
Получается, что для мелких проектов хинт очевидно бесполезен, для крупных вреден.

Плюс, мы только что поломали clone and build аж двумя способами.
Во-первых, все разработчики теперь должны держать рамдиск (ну, или замапить любой из разделов). То же самое для билдсервера.
Во-вторых, теперь нельзя держать рядом две ветки исходников, получим конфликт путей.

Купить ssd не проще?

K>><OutputPath>bin\Debug\</OutputPath> меняю на <OutputPath>bin_Debug\</OutputPath> — уменьшить вложенность каталогов (и bin\Release тоже)

MD>А зачем эта экономия на спичках — не понимаю.
+1
Re[3]: default *.csproj - немного улучшаем
От: Слава  
Дата: 02.12.15 14:21
Оценка: +2
Здравствуйте, Sinix, Вы писали:

S>А вот тут я не уверен.

S>Насколько помню, очистка obj-папок приводит к поломке incremental build. Перезагрузился — получи full rebuild в подарок.
S>Получается, что для мелких проектов хинт очевидно бесполезен, для крупных вреден.

Есть рам-диски с синхронизацией на винт (и назваются они "файловый кэш", гм, да, полезность-то сомнительна). Во-вторых, машина перезагружается раз в неделю а то и реже, с какой целю это вообще делать? Только если обновления системы требуют.
Re[4]: default *.csproj - немного улучшаем
От: Sinix  
Дата: 02.12.15 14:37
Оценка:
Здравствуйте, Слава, Вы писали:

С>Есть рам-диски с синхронизацией на винт (и назваются они "файловый кэш", гм, да, полезность-то сомнительна). Во-вторых, машина перезагружается раз в неделю а то и реже, с какой целю это вообще делать? Только если обновления системы требуют.


Про перезагрузки согласен, не так критично. С вторым абзацем чего делать?
Re: default *.csproj - немного улучшаем
От: flаt  
Дата: 02.12.15 15:13
Оценка: 20 (1)
Здравствуйте, Kolesiki, Вы писали:

K>Когда студия создаёт проект, сразу же его закрываю

А в C# нет файла шаблона проекта у студии, на основе которого она создаёт? В VC есть, удобно подобные исправления сделать один раз для своей машины.

K>уменьшить вложенность каталогов

Смысл?

K>указываю, где студия должна создавать всю временную шнягу (это RAM-диск)

Делал подобное для C++ проектов, когда не было SSD (и пока экономил перезапись на них). Из плюсов — ускорение сборки (для C# менее актуально, думаю) и винт не шуршит.
Из минусов:
* пересборка после ребута (выше отметили про сохранение RAM-диска, но я не делал его)
* возня с путями на другом компе — решил через $(Temp) вместо "R:\Temp"
* ограниченность объёма рам-диска (сборка Boost уже не влезает в память), сейчас не актуально
* был ещё косяк с рассинхронизацией времени на разделах с NTFS (сорцы) и FAT32 (RAM), что ломало incremental build
Re[2]: default *.csproj - немного улучшаем
От: Kolesiki  
Дата: 02.12.15 19:03
Оценка:
Здравствуйте, Mr.Delphist, Вы писали:

K>><OutputPath>bin\Debug\</OutputPath> меняю на <OutputPath>bin_Debug\</OutputPath> — уменьшить вложенность каталогов (и bin\Release тоже)

MD>А зачем эта экономия на спичках — не понимаю.

А зачем чесать левое ухо правой рукой? Когда мне нужны файлы сборки, открываю каталог проекта и вот они, bin_Debug! Или вам нравится щёлкать по десяткам папок?

MD>Более того, она влечёт за собой вот эту костылизацию (бедняга Nuget плюс ручной патчинг тех 3rd party-либ, которые мы получаем из сырцов):

K>><HintPath>..\SomeLib\bin_$(Configuration)\lib.dll</HintPath> — позволяет собирать релиз из релизных сборок других библиотек (и дебаг из дебаговых).

Почему "костыль"-то?? Обычная настройка билд-конфига, в нём ДЕСЯТКИ таких $(что-то). Зато в продакшен не попадает дебаговой ерунды.
Re[3]: default *.csproj - немного улучшаем
От: Kolesiki  
Дата: 02.12.15 19:32
Оценка: 2 (1)
Здравствуйте, Sinix, Вы писали:

K>>><BaseIntermediateOutputPath>R:\TEMP\obj\$(ProjectGuid)\</BaseIntermediateOutputPath> — указываю, где студия должна создавать всю временную шнягу (это RAM-диск)

MD>>Это может быть полезно, да

S>А вот тут я не уверен.

S>Насколько помню, очистка obj-папок...

Они не очищаются — RAM диск сохраняет всё при ребуте.

S> приводит к поломке incremental build. Перезагрузился — получи full rebuild в подарок.


Хоспыдя... вы там Убунту компиляете что ли? Я жду максимум секунд 5 (на гнусных WPF-проектах, где куча автогенерации). Даже специально делаю REbuild.

S>Получается, что для мелких проектов хинт очевидно бесполезен, для крупных вреден.


Ошибочка! РАМ-диск ускоряет канпеляние.

S>Плюс, мы только что поломали clone and build аж двумя способами.

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

Во-первых, во всех адекватных командах ВСЕГДА есть некие соглашения — где держать сорсы, куда класть патчи/релизы и т.п. Завести лишнюю букву в компе — ни бог весть какой труд.
Во-вторых, если диска нет, билдер спокойно это разруливает, вводя ещё один хинт <IntermediateOutputPath>, где указывается безопасный каталог для времянки.

S>Во-вторых, теперь нельзя держать рядом две ветки исходников, получим конфликт путей.


Ну тебе ж хватило сил сделать копию файлов? Можешь отредактировать конфиг копии, введя другой каталог. Да и копия — ОДНОВРЕМЕННО (с исходной) она никогда не была нужна, а если что — перекомпиляю текущую открытую.

S>Купить ssd не проще?


А ты сходи к менеджеру проекта, спроси Тут второй монитор выдают чуть ли не за почку, а уж SSD — под обещание 200% повышения кодинга! Не у всех хватает бюджета/щедрости/интеллекта снабжать прогеров передовым железом: "Долго компиляется? Пиши в простоях документацию!". Хотя домой я конечно себе купил. Но лучше дрючить RAM, чем SSD.

K>>><OutputPath>bin\Debug\</OutputPath> меняю на <OutputPath>bin_Debug\</OutputPath> — уменьшить вложенность каталогов (и bin\Release тоже)

MD>>А зачем эта экономия на спичках — не понимаю.
S>+1

Это экономия нервов, а они дороже спичек! Плюс, всегда видно, где и какой билд не был сделан.
Видимо, такие же "труднисты" как вы рассуждали про "c:\Users\юзер-пупузер\Documents" — чё те, сложно на ОДНОЮЗЕРСКОМ КОМПЕ(!!!!!!!!) сходить на три вложенности каталогов?! Это такой же бред, как и вся концепция Desktop'а — она провальная и юзеру нужен один нормальный каталог: c:\Docs; (и это будет верно ровно до тех пор, пока мы вынуждены работать хоть с какими-то ни было путями)
Уменьшил вложенность — ускорил навигацию по каталогам. Уж поверьте, были бы это "спички", я б и пальцем не пошевелил (ибо ленив как все).
Re[4]: default *.csproj - немного улучшаем
От: Sinix  
Дата: 02.12.15 20:20
Оценка: +3
Здравствуйте, Kolesiki, Вы писали:

K>Хоспыдя... вы там Убунту компиляете что ли? Я жду максимум секунд 5 (на гнусных WPF-проектах, где куча автогенерации). Даже специально делаю REbuild.

Я ж говорю — даже на средних проектах вы не работали. Средние — эдак 250 проектов и время пересборки в 20 минут на ssd.
А для мелочёвки вообще разницы нет, что 5 секунд рамдиска, что 7 ssd.

Довод про дорого? Серьёзно? Считаем стоимость часа разработчика и сравниваем с 3-4 килорублями за ssd. Не забываем про сэкономленные пару гигов памяти (~килорубль). Тем более, что для памяти есть куда полезнее применение, лучше уж на пару виртуалок её отдать.

Блин, да на карманные деньги можно взять, если шефы даже на такую мелочь жопятся. За счёт плюса к морали окупится уже за месяц.

K>Во-первых, во всех адекватных командах ВСЕГДА есть некие соглашения — где держать сорсы, куда класть патчи/релизы и т.п. Завести лишнюю букву в компе — ни бог весть какой труд.

Снова нет. Средние проекты начинаются с критерия "одна миникоманда в 5-7 человек физически не способна поддерживать весь код". Т.е. вы не владеете всем кодом и для принятия каких-либо решений вам надо общаться как минимум через один уровень иерархии плюс получить добро от it-отдела на установку софта на полтора десятка машин минимум. В общем, это всё очень небыстро и недёшево получается.

K>Ну тебе ж хватило сил сделать копию файлов? Можешь отредактировать конфиг копии, введя другой каталог. Да и копия — ОДНОВРЕМЕННО (с исходной) она никогда не была нужна, а если что — перекомпиляю текущую открытую.

См выше про размер среднего проекта. На самом деле способ решения есть, но подсказывать неспортивно

Сценарий очевиднейший — одновременно разработка в main + патчи в ветке для прошедшего релиза.

Я ж говорю, в более-менее серьёзном проекте все "да чо там думать" и "мне не нужно == никому не нужно" внезапно перестают работать. Тупо за счёт масштаба.


K>Уменьшил вложенность — ускорил навигацию по каталогам. Уж поверьте, были бы это "спички", я б и пальцем не пошевелил (ибо ленив как все).

О как Вы что, открываете папки с результатами сборки? Зачем?

Тестеры берут артефакты с билд-сервера, софт в продакшн уходит оттуда же, запуск из студии f5/ctrl-f5, для особо сложных случаев пишутся сценарии и вешаются на хоткей.
Серьёзно, что вы забыли в build-output-папках?
Re[4]: default *.csproj - немного улучшаем
От: Mr.Delphist  
Дата: 03.12.15 09:12
Оценка: +2
Здравствуйте, Kolesiki, Вы писали:

K>Хоспыдя... вы там Убунту компиляете что ли? Я жду максимум секунд 5 (на гнусных WPF-проектах, где куча автогенерации). Даже специально делаю REbuild.


Вот промерял текущий WPF-проект, 20 секунд ребилд. Но это 6 проектов и 2 сторонних либы, реально мелочёвка. Более толстые середнячки с историей развития в несколько лет уже дадут минуты полной пересборки. Про кровавый энтерпрайз даже заикаться не буду...
Re[3]: default *.csproj - немного улучшаем
От: xy012111  
Дата: 03.12.15 12:09
Оценка:
Здравствуйте, Sinix, Вы писали:

S>Плюс, мы только что поломали clone and build аж двумя способами.

S>Во-первых, все разработчики теперь должны держать рамдиск (ну, или замапить любой из разделов). То же самое для билдсервера.
S>Во-вторых, теперь нельзя держать рядом две ветки исходников, получим конфликт путей.

Тут есть экзюк, которому в параметрах командной строки задаётся путь к солюшену и путь, где держать временные файлы. Экзюк может пропатчить все проекты в солюшене и либо выставить кастомный IntermediatePath либо оставить дефолтовый. Какая-никакая автоматизация. С ветками так же никаких проблем. Если всё в СВН, то для разных веток указывается разный путь в замапленом диске.

S>Купить ssd не проще?


Вот именно. У меня опретивки всего 16Г, методика с рам-дисками ни капли себя не оправдала. Возможно, если есть 64Г и хорошей качественное памяти, будет лучше Но даже и пытаться не охота.
Re[3]: default *.csproj - немного улучшаем
От: Mr.Delphist  
Дата: 03.12.15 12:26
Оценка:
Здравствуйте, Kolesiki, Вы писали:

K>Почему "костыль"-то?? Обычная настройка билд-конфига, в нём ДЕСЯТКИ таких $(что-то). Зато в продакшен не попадает дебаговой ерунды.


У нормальных либ для релизной сборки автоматом выбирается релизный же билд-конфиг. Но если автор почему-то решил отойти от студийных naming conventions, то да, будут хлопоты и для Debug/Release, и для таргетирования x86/x64/AnyCPU
Re[4]: default *.csproj - немного улучшаем
От: Sinix  
Дата: 03.12.15 13:36
Оценка: +1
Здравствуйте, xy012111, Вы писали:

X>Тут есть экзюк, которому в параметрах командной строки задаётся путь к солюшену и путь, где держать временные файлы.

Не, решение конечно есть,
  хинт
<Import Project="$(SolutionDir)ProjectBuildProperties.targets"/>

Но зачем облегчать топикстартеру задачу?
Взялся доказывать, что решение правильное — пусть сам выкручивается.
Re[5]: default *.csproj - немного улучшаем
От: xy012111  
Дата: 03.12.15 14:06
Оценка: 20 (1) +1
Здравствуйте, Sinix, Вы писали:

X>>Тут есть экзюк, которому в параметрах командной строки задаётся путь к солюшену и путь, где держать временные файлы.

S>Не, решение конечно есть, …
S>Но зачем облегчать топикстартеру задачу?
S>Взялся доказывать, что решение правильное — пусть сам выкручивается.

Не представляю, что и как тут можно доказать. У ТС нет возможности поставить ССД, а с РАМ диском ему быстрее. Тут только можно посоветовать как облегчить (из вашего примера), тем более, если все в команде готовы на подобное пойти.

Я пытался заимпортить (это конечно более правильно) такой таргетс в .юзер-файле, что бы не не править проектник вообще как-то и не коммитить изменения, но с первого раза не вышло и сделал хардово, а потом убедился, что проку не очень много. Вернее, компилция действительно летала, но и данные сбрасывались и диск периодически пропадал да и 16Г маловато и на то что бы без свопа жить и на хранение там ещё временных файлов.
Re: default *.csproj - немного улучшаем
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 04.12.15 06:55
Оценка: +1
Здравствуйте, Kolesiki, Вы писали:

K><BaseIntermediateOutputPath>R:\TEMP\obj\$(ProjectGuid)\</BaseIntermediateOutputPath> — указываю, где студия должна создавать всю временную шнягу (это RAM-диск)


Много приятных слов от сотоварищей по проекту тебе гарантировано
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
AVK Blog
Re[4]: default *.csproj - немного улучшаем
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 09.12.15 19:16
Оценка:
Здравствуйте, Kolesiki, Вы писали:

K>Они не очищаются — RAM диск сохраняет всё при ребуте.


При штатном ребуте.

K>А ты сходи к менеджеру проекта, спроси Тут второй монитор выдают чуть ли не за почку, а уж SSD — под обещание 200% повышения кодинга! Не у всех хватает бюджета/щедрости/интеллекта снабжать прогеров передовым железом


Да уж, передовое железо стоимостью в дневную зарплату. Может тебе просто работу поменять?
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
AVK Blog
Re[5]: default *.csproj - немного улучшаем
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 09.12.15 19:16
Оценка:
Здравствуйте, Sinix, Вы писали:

S>Тестеры берут артефакты с билд-сервера


Что то мне подсказывает, что никакого билд-сервера у него нет. Хорошо если VCS какая нибудь используется не сильно древняя.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
AVK Blog
Re[6]: default *.csproj - немного улучшаем
От: Sinix  
Дата: 09.12.15 20:09
Оценка:
Здравствуйте, AndrewVK, Вы писали:

S>>Тестеры берут артефакты с билд-сервера


AVK>Что то мне подсказывает, что никакого билд-сервера у него нет. Хорошо если VCS какая нибудь используется не сильно древняя.

Ну, мало ли, всякое бывает

Может человек best practices собирает таким нетривиальным способом.
Аля "пойдем сложным путем. Привези мне, батюшка, цветочек аленький…" (с)
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.