Здравствуйте, Qbit86, Вы писали:

Q>Здравствуйте, Andrii_Avramenko, Вы писали:

A_A>>так для запуска msbuild не из студии все равно батник нужен
A_A>>какой смысл запускать msbuild, который будет запускать NuGet, если мона сразу запустить NuGet?

Q>Чтобы выгрузка пакетов была частью процесса сборки. Т.е. на билд-сервере не нужны никакие ручные запуски каких-то батников.
Именно так и есть.
Q>Чистый чекаут репозитория даёт достаточное для сборки окружение.
Только локально, когда делаешь чекаут — NuGet не вызывается, запускаем батник отдельно
Предполагаю, можно как post-update для svn сделать, но руки еще не дошли
А вы как это настроили?

Здравствуйте, Andrii_Avramenko, Вы писали:

A_A>Здравствуйте, AlexNek, Вы писали:

AN>>Здравствуйте, Andrii_Avramenko, Вы писали:

A_A>>>Здравствуйте, Геннадий Васильев, Вы писали:

A_A>>>Мы, собственно, всегда под AnyCPU в Release и собираем — зачем иначе?
AN>>Попробуйте установить прогу на 64 битную ось.
A_A>Так сервера на продакшене все 64-битные. Ничего не пересобирается.
A_A>Оно ж AnyCpu. В чем проблема?
Может и поэтому, что бильд на 64 или никаких внешних либ не требуется.
Истоками проблемы специально не интересовался. Но есть два проги, которым пришлось изменить AnyCPU на x86 из за проблем с запуском под 64 битами.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, AlexNek, Вы писали:

AVK>>>Что значит в одном месте? Есои репозиторий единый, для апдейта нужно нажать кнопку ровно один раз ровно в одном месте.
AN>>Во первых, в репо не один проект.

AVK>Ну и что? Тебе места на диске жалко?
Его просто физически не хватит на все.

AN>> Во вторых, в ветке проекта, не только исходники, но и все сопутствующее.

AVK>Не понял. И при чем тут это сопутствующее?
Ну так сделали. Все тесты, документация, бранчи, релизы, сетапы и пр.

AN>>В третьих, скорость.

AVK>Скорость чего?
Скорость обновления.

AN>> В четвертых, все слепо коммитить запрещено.

AVK>Ну так и не надо все слепо коммитить.
Тогда нельзя жать одну конпку один раз.

AN>> Ну и в основном, работа происходит через плагин к студии.

AVK>И что?
Коммитится только то что включено в солушин.

AN>> Если брать с роота обновления, то будет длиться довольно долгое время.

AVK>Да ну нафик. Долгое время это сколько? 1 минуту? 2?
Бывает и часы, если все брать с нуля. Вполне может 5-10 минут быть.

AN>>Но дело ведь не в чтении, но и в записи.

AVK>И что с ней не так?
То что нельзя всю солушин коммитить, нужно по частям которые планировалось изменить.
И про какую-то часть можно забыть.

Здравствуйте, Andrii_Avramenko, Вы писали:

A_A>Здравствуйте, AlexNek, Вы писали:

AN>>Допустим раньше параметр не проверялся на ноль, а теперь сделали. Но вылет все равно проиходит по нулю (Длл-ка не обновилась). Смотрим исходники все нормально, AN>не может там такого быть.
AN>>Ну а все всегда не перекроешь.
A_A>Это один из самых неприятных багов.
A_A>Если версия либы будет соответствовать версии ревизии коммита, то эта проблема уйдет.
Так поэтому и спрашивал, кто это будет проверять?

A_A>>>Автоматизация без участия человека не допустит рассогласования исходников с бинарниками.
AN>>Это будет только в том случае когда прогу также роботы писать будут, а за ними будут другие роботы наблюдать. А так можно почти всегда найти ситуации в которых механизм даст сбой.
A_A>Давайте расскажу поподробнее за этот механизм.
A_A>При создании новой версии либы, разработчик делает билд на CI с таргетом "Deploy".
У нас разработчик не имеет доступа "записи" к CI, все идет чисто на автомате.
A_A>Если этот проект не поддерживает такой таргет
A_A>(т.е. не Database project or Web project etc.) тогда мы получим фейл билда и узнаем сразу.
A_A>Если процесс версионирования NuGet настироен неправильно -> получим фейл билда и узнаем сразу.
A_A>Итак, билд прошел успешно.
A_A>Если мы укажем несуществующую версию либы(т.е. кот орой нет физически в фиде NuGet) -> получим фейл апдейта батника NuGet и узнаем чуть по-позже.
A_A>имхо, вероятность сбоя невелика.
Не в этой цепочке. Типа как поломали защиту видео ДВД и как крадут секреты/деньги.
Вот первое, что пришло в голову.
Исправили два файла, но забыли один закоммитить. Потом вспомнили, закоммитили, после этого кто то взял исходники и начал работать с первым билдом.

Здравствуйте, Andrii_Avramenko, Вы писали:

A_A>Здравствуйте, AlexNek, Вы писали:

A_A>>>Делаете пилотные проекты(лучше скопировать текущие самые сложные, с наибольшим количеством зависимостей) — на них играетесь
AN>>Кто даст время, деньги, ресурсы?
A_A>Заказчик конечно.
Во первых, заказчик — это другой отдел. Во вторых, все уже давным давно распланировано и деньги и ресурсы.
A_A>А вот твоя задача — объяснить ему, что эти затраты для него окупятся Плюс он еще и заработает на этом в ближайшем будущем.
Вот это совсем туманно. Если бы отличия были настолько существенны все бы использовали одну лучшую систему,а SVN забили бы досками с большой мигалкой — опасно.
A_A>Насчет ближайшего будущего лучше поделикатней, конечно, без гарантий.
A_A>>>Потом постепенно переводите текущие на новую систему.
A_A>>>Риски всегда есть. Чтобы о них узнать заранее нужно проводить ресерч.
AN>>Прототип можно и за час сделать, а вот уже довести его до ума и подкрутить все мелочи — это уже время.
A_A>>>А по поводу переходить или нет — выписываешь в список плюсы и минусы существующей системы и новой(насколько возможно собрать информацию)
A_A>>>и будет ясно.
AN>>Можно долго и нудно все выписывать и подсчитывать, но вот как быть с неким правилом — "не трогай рабочую систему".
A_A>Оо, это самое вкусное.
A_A>На прошлой конторе заказчики были из Израиля — все решения о не то что переводе на что-то более удобное в разработке,
A_A>а о банальном рефакторинге в легаси-коде(который находится в активной разработке еще), проходили с жуткими боями в виде закидывания аргументами.
A_A>После замеров времени выполнения трех(самых веселых) методов сервисов бизнес-логики и выкладывания этого всего дела в виде красивых графиков,
A_A>моя рекомендация по переводу проектов с .NET 2.0 на .NET 4.0 была воспринята без единого спора. (А те проекты были на 2.0 с 2005 года).
A_A>Разница во времени выполнения была в 7.5 раз
Ну можно сказать повезло. А если разница была бы в полтора раза?
И отчего такая разница во времени? Просто у нас также 2.0
A_A>В старом коде были абсолютно неиспользуемые(т.е. тупо холостые) вызовы методов со стек-трейсом до
A_A>12 методов, которые даже в базу лезли. Но менеджерам я об этом естесственно не говорил.
А какие бы были затраты просто оптимизировать существующий код?
A_A>Все это делалось конечно в свободное от работы время(менеджеры считали это не приносящим профита) — оно ведь мне нужно было-то.
A_A>Т.е. к чему я: заказчику или менеджерам надо предоставлять факты и цифры, глядя на которые они сами попросят вас сделать это все как можно быстрее.
Это если есть что измерять.

Здравствуйте, Andrii_Avramenko, Вы писали:

A_A>Только локально, когда делаешь чекаут — NuGet не вызывается, запускаем батник отдельно :crash:
A_A>Предполагаю, можно как post-update для svn сделать, но руки еще не дошли :crash:
A_A>А вы как это настроили?

Каждый проект (который нуждается в NuGet-пакетах) импортирует targets-файл примерно такого вида:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <PropertyGroup>
        <NuGetToolsPath>$(Build)</NuGetToolsPath>
        <NuGetExePath>$(NuGetToolsPath)nuget.exe</NuGetExePath>
        <PackagesConfig>$(ProjectDir)packages.config</PackagesConfig>
        <PackagesDir>$(SolutionDir)Packages</PackagesDir>

        <!-- Package sources used to restore packages. By default will used the registered sources under %APPDATA%\NuGet\NuGet.Config -->
        <PackageSources>""</PackageSources>

        <!-- Enable the restore command to run before builds -->
        <RestorePackages Condition="$(RestorePackages) == ''">true</RestorePackages>

        <!-- Commands -->
        <RestoreCommand>"$(NuGetExePath)" install "$(PackagesConfig)" -source $(PackageSources) -o "$(PackagesDir)"</RestoreCommand>

        <!-- Make the build depend on restore packages -->
        <BuildDependsOn Condition="$(RestorePackages) == 'true'">
            RestorePackages;
            $(BuildDependsOn);
        </BuildDependsOn>
    </PropertyGroup>
    
    <Target Name="CheckPrerequisites">
        <!-- Raise an error if we're unable to locate nuget.exe  -->
        <Error Condition="!Exists('$(NuGetExePath)')" Text="Unable to locate '$(NuGetExePath)'." />
    </Target>
    
    <Target Name="RestorePackages" DependsOnTargets="CheckPrerequisites">
        <Exec Command="$(RestoreCommand)"
              LogStandardErrorAsError="true"
              Condition="Exists('$(PackagesConfig)')" />
    </Target>
</Project>

В случае, если нет какого-то пакета из packages.config проекта, он будет скачан командой «nuget.exe install».

Здравствуйте, AlexNek, Вы писали:

AN>Истоками проблемы специально не интересовался. Но есть два проги, которым пришлось изменить AnyCPU на x86 из за проблем с запуском под 64 битами.
Походу из-за того, что у тех прог были какие-то референсные сборки, собранные под x86.
попробуй пересобрать все зависимости под единую платформу.

недавно в наших проектах специально поудалял все конфигунации кроме AnyCPU — чтоб возможности собрать под другую платформу не было

Здравствуйте, AlexNek, Вы писали:

A_A>>При создании новой версии либы, разработчик делает билд на CI с таргетом "Deploy".
AN>У нас разработчик не имеет доступа "записи" к CI, все идет чисто на автомате.
А клиент доступа к CI у вас есть?

Здравствуйте, Andrii_Avramenko, Вы писали:

AVK>>Не понял. И при чем тут это сопутствующее?
A_A>при том, что оно абсолютно не нужно для решения текущей задачи, и его может быть сотни мегабайтов
A_A>и нафига его тянуть?

А зачем всякую фигню на сотни мег класть рядом с исходниками?

AVK>>Да ну нафик. Долгое время это сколько? 1 минуту? 2?
A_A>Долгое время это 2 минуты в сравнении с 10 секундами.
A_A>И так ежедневно, от пяти раз на день.

Да уж, огромная потеря времени.

Здравствуйте, AlexNek, Вы писали:

AVK>>Ну и что? Тебе места на диске жалко?
AN>Его просто физически не хватит на все.

То ли у тебя проект несколько сотен гиг, толи работодатель редкий жмот.

AVK>>Не понял. И при чем тут это сопутствующее?
AN>Ну так сделали. Все тесты, документация, бранчи, релизы, сетапы и пр.

Зачем тесты, документацию класть прям в исходники? И при чем тут бранчи и релизы?

AVK>>Ну так и не надо все слепо коммитить.
AN>Тогда нельзя жать одну конпку один раз.

Почему это? У тебя нет диалога выбора того, что надо коммитить?

AVK>>И что?
AN>Коммитится только то что включено в солушин.

А добавить остальное религия мешает?

AVK>>Да ну нафик. Долгое время это сколько? 1 минуту? 2?
AN>Бывает и часы, если все брать с нуля.

А зачем все брать с нуля? И часы — это, видимо, опять жлобство работодателя.

AN> Вполне может 5-10 минут быть.

Ужас то какой.

AN>>>Но дело ведь не в чтении, но и в записи.
AVK>>И что с ней не так?
AN>То что нельзя всю солушин коммитить, нужно по частям которые планировалось изменить.

Нафига???

AN>И про какую-то часть можно забыть.

Ну да, как обычно — создаем себе проблемы, а потом с ними сражаемся.

Здравствуйте, AlexNek, Вы писали:

AN>Здравствуйте, Andrii_Avramenko, Вы писали:

A_A>>Здравствуйте, AlexNek, Вы писали:

A_A>>>>Делаете пилотные проекты(лучше скопировать текущие самые сложные, с наибольшим количеством зависимостей) — на них играетесь
AN>>>Кто даст время, деньги, ресурсы?
A_A>>Заказчик конечно.
AN>Во первых, заказчик — это другой отдел.
так он всегда и будет "другим отделом". причем попытка на такие разговоры всегда дается только одна — не тщательно подготовился с аргументами
и ответами на возможные вопросы — второго раза не будет
AN>Во вторых, все уже давным давно распланировано и деньги и ресурсы.
Поверь, так будет всегда. Под лежачий камень вода не течет. кстати, сейчас почти оптимальное время — до апреля будет распил бюджета на следующий год

A_A>>После замеров времени выполнения трех(самых веселых) методов сервисов бизнес-логики и выкладывания этого всего дела в виде красивых графиков,
A_A>>моя рекомендация по переводу проектов с .NET 2.0 на .NET 4.0 была воспринята без единого спора. (А те проекты были на 2.0 с 2005 года).
A_A>>Разница во времени выполнения была в 7.5 раз
AN>Ну можно сказать повезло. А если разница была бы в полтора раза?
AN>И отчего такая разница во времени? Просто у нас также 2.0
Разница была конечно, в основном не из-за фреймворка. Там были дикие ненужные ветки выполнения, которые просто не удаляли после изменений.
В базе были процедуры аля GetCustomerById, вместо этого дергалась GetMemberChildren(CustomerId) — вытягивалась вся простыня кастомеров
(доходило до 14 тыщ) и в бизнес-логике искался нужный кастомер
Еще всякие ненужные бешенные циклы по таким коллекциям с тройным уровнем вложенности.
И все добро всегда выполнялось в одном потоке
A_A>>В старом коде были абсолютно неиспользуемые(т.е. тупо холостые) вызовы методов со стек-трейсом до
A_A>>12 методов, которые даже в базу лезли. Но менеджерам я об этом естесственно не говорил.
AN>А какие бы были затраты просто оптимизировать существующий код?
так его в итоге и оптимизировали — по модулям, по очереди, начиная с самых важных
A_A>>Все это делалось конечно в свободное от работы время(менеджеры считали это не приносящим профита) — оно ведь мне нужно было-то.
A_A>>Т.е. к чему я: заказчику или менеджерам надо предоставлять факты и цифры, глядя на которые они сами попросят вас сделать это все как можно быстрее.
AN>Это если есть что измерять.
Так надо найти, даже если и мерять нечего. Когда поставишь цель найти — само найдется.

Здравствуйте, Qbit86, Вы писали:

Q>Здравствуйте, Andrii_Avramenko, Вы писали:

A_A>>Только локально, когда делаешь чекаут — NuGet не вызывается, запускаем батник отдельно
A_A>>Предполагаю, можно как post-update для svn сделать, но руки еще не дошли
A_A>>А вы как это настроили?

Q>Каждый проект (который нуждается в NuGet-пакетах) импортирует targets-файл примерно такого вида:
[...]
Q>В случае, если нет какого-то пакета из packages.config проекта, он будет скачан командой «nuget.exe install».
Так а таргет этот кто дергает при апдейте СКВ?
Или вы его зашиваете в файлы проектов?

Здравствуйте, Andrii_Avramenko, Вы писали:

A_A>Так а таргет этот кто дергает при апдейте СКВ?
A_A>Или вы его зашиваете в файлы проектов?

Нет, не при апдейте — при сборке. Это ж разруливание зависимостей.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Andrii_Avramenko, Вы писали:

AVK>>>Не понял. И при чем тут это сопутствующее?
A_A>>при том, что оно абсолютно не нужно для решения текущей задачи, и его может быть сотни мегабайтов
A_A>>и нафига его тянуть?

AVK>А зачем всякую фигню на сотни мег класть рядом с исходниками?

Никакой фигни — куча сорцов, причем процентов 70 — легаси кода.
К примеру в транке две папки двух веток проектов, слабо, но связанных друг с другом. И надо сделать один коммит с изменениями в обоих папках.
Нажимаешь Check for modifications — и идешь на обед, пока svn все проверит, если чекаутов всякого сопутствующего уже понаделывал.

AVK>>>Да ну нафик. Долгое время это сколько? 1 минуту? 2?
A_A>>Долгое время это 2 минуты в сравнении с 10 секундами.
A_A>>И так ежедневно, от пяти раз на день.

AVK>Да уж, огромная потеря времени.
Не скажу, что огромная, но отсутствие оптимизации рабочего процесса присутствует.

Здравствуйте, Qbit86, Вы писали:

Q>Здравствуйте, Andrii_Avramenko, Вы писали:

A_A>>Так а таргет этот кто дергает при апдейте СКВ?
A_A>>Или вы его зашиваете в файлы проектов?

Q>Нет, не при апдейте — при сборке. Это ж разруливание зависимостей.
ну да
как я понял, этот таргет присутствует во всех файлах проектов.
Зашили его в шаблоны, на которых создаете новые проекты?

Здравствуйте, Andrii_Avramenko, Вы писали:

A_A>как я понял, этот таргет присутствует во всех файлах проектов.
A_A>Зашили его в шаблоны, на которых создаете новые проекты?

Да :) Не сам таргет, его импорт:

<Import Project="$(Build)NuGet.targets" />

Здравствуйте, Qbit86, Вы писали:

Q>Здравствуйте, Andrii_Avramenko, Вы писали:

A_A>>Только локально, когда делаешь чекаут — NuGet не вызывается, запускаем батник отдельно
A_A>>Предполагаю, можно как post-update для svn сделать, но руки еще не дошли
A_A>>А вы как это настроили?

Q>Каждый проект (который нуждается в NuGet-пакетах) импортирует targets-файл примерно такого вида:
Туплю, тока сейчас эту строчку заметил

Здравствуйте, Andrii_Avramenko, Вы писали:

ГВ>>>>А если сборка всех ваших исходников укладывается в час-два (сторонние библиотеки сейчас не считаем), то уместно иметь полную копию всех исходных текстов.
AN>>>Я бы сформулировал следующее. Если проект находится в конечном листе иерарахии проектов, то с целью экономии времени, лучше поключать Длл-ки.
ГВ>>Да экономия времени-то не ахти какая большая, прямо скажем.
A_A>Но она есть — и это факт.
[...]

Согласен. Я бы всё же посоветовал присмотреться к такому варианту:

— "Эталонный" солюшен содержит полный комплект ссылок на проекты, но референсы расставлены на бинарные сборки (не на сами проекты);
— Локальные солюшены каждый может сделать какие угодно, не выкладывая их на SVN: проекты уже готовы к изолированному использованию.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Согласен. Я бы всё же посоветовал присмотреться к такому варианту:
ГВ>- "Эталонный" солюшен содержит полный комплект ссылок на проекты, но референсы расставлены на бинарные сборки (не на сами проекты);
ГВ>- Локальные солюшены каждый может сделать какие угодно, не выкладывая их на SVN: проекты уже готовы к изолированному использованию.

Информация о том, что «референсы расставлены на бинарные сборки (не на сами проекты)», хранится не в солюшенах, а в MsBuild-скриптах сборки (в csproj-проектах). Солюшены по большему счёту нафиг не нужны, для последних проектов у нас они даже в репозтории с исходниками не хранятся.

Есть другой вариант (я его, возможно, попробую в будущем). Можно настроить условные ссылки. Т.е. при каком-то определённом окружении будет выбираться <Reference> или <ProjectReference> в зависимости от определённого свойства (msbuild property).

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Здравствуйте, Andrii_Avramenko, Вы писали:

ГВ>>>>>А если сборка всех ваших исходников укладывается в час-два (сторонние библиотеки сейчас не считаем), то уместно иметь полную копию всех исходных текстов.
AN>>>>Я бы сформулировал следующее. Если проект находится в конечном листе иерарахии проектов, то с целью экономии времени, лучше поключать Длл-ки.
ГВ>>>Да экономия времени-то не ахти какая большая, прямо скажем.
A_A>>Но она есть — и это факт.
ГВ>[...]

ГВ>Согласен. Я бы всё же посоветовал присмотреться к такому варианту:

ГВ>- "Эталонный" солюшен содержит полный комплект ссылок на проекты,
Так и есть.
ГВ>но референсы расставлены на бинарные сборки (не на сами проекты);
Так референсы то в проектах сидят. Приходится делать копию проекта с другим именем и другим солюшен. Я так "переключаюсь" от бинарников Дев. Экспресса к исходникам.
Все бы хорошо, но проекты приходится ручками синхронизировать.