Visual Studio 15 SP 1
в одном из проектов откуда-то появилась ссылка на файл с тестами...
Бывало что то подобное, проклинаешь Билли, а после оказывается, сам сделал только связи не увидел. Хотя бывает и наоборот.
Нашелся еще один глюк.
Причем место такое, что должно быть вылизано на все 100%.
И так - метод: System.IO.Path.Combine(part1, part2);
Ожидается - составленный из двух частей путь. Предлагается выполнить следующее:
string myPath;
// ссылаемся на каталог World на один уровень выше.
myPath = Path.Combine(AppContext.BaseDirectory, @"../World");
// ссылаемся на каталог Afrika в World
myPath = Path.Combine(myPath, @"/Afrika");
Можно смеятся - реальная ссылка - на Африку в корневом каталоге диска...
Прэлэстно! (с) Пробито очередное днище.
MSDN:
If path2 does not include a root (for example, if path2
does not start with a separator character or a drive specification),
the result is a concatenation of the two paths, with an intervening
separator character. If path2 includes a root, path2 is returned.
Ну не то, так это...
Шаблончик:
<#@ template language="C#" #><#@ assembly name="System.Core" #><#String part1 = @"C:\inetpub\ftproot\";String part2 = @"My\Best\Folder";#>cd <#= part1 #>\<#= part2 #>
Никаких нарушений синтаксиса не вижу, но... не компилируется.
Проблема - некорректная обработка бэкслеша перед <#=.
Очередная клямпочка от мелкомягких...
Файл проекта.
В ПостБилде Проекту предписано проверить наличие двух папок и скопировать библиотеки в другую папку...
Сделано - для плугинов, чтобы сложить их в отдельную папочку и не парится.
Стандартный код выглядит так:
if not exist "$(TargetDir)" EXIT /B 89
if not exist "$(TargetDir)..\..\Publish\" EXIT /B 88
echo f | xcopy /Y /F "$(TargetDir)$(TargetFileName)" "$(TargetDir)..\..\Publish\$(TargetFileName)"
Для КруисеКонтрол мне потребовалось это дело отменить - там у меня другой механизм отработки. Стало выглядеть так:
if not exist "$(TargetDir)" EXIT /B 89
if not exist "$(TargetDir)..\..\Publish\" EXIT /B 88
echo f | xcopy /Y /F "$(TargetDir)$(TargetFileName)" "$(TargetDir)..\..\Publish\$(TargetFileName)"
Выравнивание и переносы студия сделала сама.
МсБуилд сломался на пробеле после .
Все три десятка проектов надо перепахивать...
Ндаа... форматирование... Ладушки - в ПостБуилде не должно быть пустых строк в начале и в конце - МсБуилд их не понимает...
Дааа... Билли еще не понимает, что ПостБуилд может быть условным...
Постбилд не может быть условным. Для того, чтобы биздить с тругими параметрами придумали Solution Configuration в целом и Configuration Manager в частности.
Постбилд не может быть условным.
-----
А что ему должно мешать? Любая PropertyGroup может иметь Condition=.
PostBuildEvent всего лишь элемент одной из PropertyGroup...
У меня - вполне работает стандартным образом.
А жалуюсь Я на то, что билли у себя никак не смог обеспечить нормальную обработку этого дела.
придумали Solution Configuration
-----
Пока не видел описания. Где почитать без воды, но полно?
Билли - это вообще что-то.
Взял пример из МСДН...
https://msdn.microsoft.com/en-us/library/microsoft.build.b...
Отдал классу Проект один из своих файлов.
Все подохло с криком - Неможу парсить - комментарий встретился...
Да, что депрцировано - Я в курсе, но варианта как жевать проекты актуальным методом пока не попались...
Сделано - для плугинов, чтобы сложить их в отдельную папочку и не парится.
Обычно для копирования делаю fake проект, не требуется никаких постбилдов
Пока не видел описания. Где почитать без воды, но полно?
Ты никогда не пользовался Solution Configuration'ом или просто троллишь? Solution Configuration
Грубо говоря, делаешь еще одну конфигурацию (скажем Release CI), в этой конфигурации убираешь Post Build Events и в круиз контроле говоришь, что билдить надо не Release, а "Release CI".
в этой конфигурации убираешь Post Build Events
-----
А он не зависит от конфигурации. Студия его создает для ВСЕХ конфигураций.
Собственно, об этом выше и было написано - не понимает билли в Студии условий на ПостБуилде, но МсБуилд будет строить так как написано в условиях.
Ты никогда не пользовался Solution Configuration'ом
-----
Пользовался, разумеется. Только вот задачки он решает более чем ограниченные...
Я, кстати, просил ссылку на вменяемое описание, а не на биллин бред - что мне толку от интерфейсов, если Я 100% не буду писать расширение?
А вот что-то простое:
- постановка задачи
- действия по использованию
- связанные изменения в системе
- что и где будет работать по-другому
в природе похоже отсутствует...
----
Блин, проблема выплыла где не ждал - SortedSet неправильно сортируется хотя IComparer вроде корректный...
В результате проектик получает другой приоритет и КИ примитивно зависает...
Пойду искать что не так.
Возможно, что у тебя более полная Студия или специфика С++.
Потому как у меня:
Плюсовые проекты билдятся несколько по-другому.
У меня VS2015 Pro. И это был C++ проект :)
Только что попробовал создать новый Win32 проект и ожидаемо тот же самый эффект.
И это был C++ проект :)
------
Повторюсь - С++ проекты билдятся сильно по другому.
Если проще - не посредством МсБуилд.
Еще раз тебе повторяю, приведенный скрин - от C++ проекта и его билдет TeamCity и естественно msbuild'ом. Post-Build events различные для резиза и для дебага и все билдится так, как надо.
Проблема где-то в другом месте.
Кстати, пост-билд-эвенты всегда различались для релиза и для дебага хотябы только из-за того, что, как правило, релиз и дебаг имеют разные зависимости (в одном случае релиз-версии, в другом случае - дебаг версии) и, соответственно, зависимости эти бедутся либо из разных катологов, либо файлы называются по разному, либо и то и другое. Кстати, в мире C++ это обычная практика добавлять букву "d" к дебаг версии.
Так что проблемы где-то у тебя, а у Билли ;)
-----
Можно добесконечности повторять, но...
https://social.msdn.microsoft.com/Forums/en-US/14b5ef06-79...
пункт 1. ФАКа...
Провел у себя на домашнем компе эксперимент - поискал файлик с именем vcbuild.exe и... такого файлика нету.
У меня дома правда VS2017, но думаю, что в этом плане VS2015 на том же уровне.
Т.е. VS2017 ну никак не может билдить С++ проекты vcbuild'ом. FAQ - это все конечно хорошо, но совсем не обязательно, что то, что было правильно в 2010-ом году, остается правильным и в 2017-ом.
Кстати, у меня так выглядят проперти C# проекта на VS2017, а не C++.
Настройки C++ проекта выглядят так:
Ну а для для C# можно написать условие для каждой конфигурации:
if $(ConfigurationName) == Debug ( copy "$(TargetDir)myapp.dll" "c:\delivery\bin" /y copy "$(TargetDir)myapp.dll.config" "c:\delivery\bin" /y ) ELSE ( echo "why, Microsoft, why". )