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)"
Выравнивание и переносы студия сделала сама.
МсБуилд сломался на пробеле после .
Все три десятка проектов надо перепахивать...
Ндаа... форматирование... Ладушки - в ПостБуилде не должно быть пустых строк в начале и в конце - МсБуилд их не понимает...
Постбилд не может быть условным.
-----
А что ему должно мешать? Любая PropertyGroup может иметь Condition=.
PostBuildEvent всего лишь элемент одной из PropertyGroup...
У меня - вполне работает стандартным образом.
А жалуюсь Я на то, что билли у себя никак не смог обеспечить нормальную обработку этого дела.
придумали Solution Configuration
-----
Пока не видел описания. Где почитать без воды, но полно?
Билли - это вообще что-то.
Взял пример из МСДН...
https://msdn.microsoft.com/en-us/library/microsoft.build.b...
Отдал классу Проект один из своих файлов.
Все подохло с криком - Неможу парсить - комментарий встретился...
Да, что депрцировано - Я в курсе, но варианта как жевать проекты актуальным методом пока не попались...
Пока не видел описания. Где почитать без воды, но полно?
Ты никогда не пользовался Solution Configuration'ом или просто троллишь? Solution Configuration
Грубо говоря, делаешь еще одну конфигурацию (скажем Release CI), в этой конфигурации убираешь Post Build Events и в круиз контроле говоришь, что билдить надо не Release, а "Release CI".
в этой конфигурации убираешь Post Build Events
-----
А он не зависит от конфигурации. Студия его создает для ВСЕХ конфигураций.
Собственно, об этом выше и было написано - не понимает билли в Студии условий на ПостБуилде, но МсБуилд будет строить так как написано в условиях. 
Ты никогда не пользовался Solution Configuration'ом
-----
Пользовался, разумеется. Только вот задачки он решает более чем ограниченные...
Я, кстати, просил ссылку на вменяемое описание, а не на биллин бред - что мне толку от интерфейсов, если Я 100% не буду писать расширение?
А вот что-то простое:
- постановка задачи
- действия по использованию
- связанные изменения в системе
- что и где будет работать по-другому
в природе похоже отсутствует... 
----
Блин, проблема выплыла где не ждал - SortedSet неправильно сортируется хотя IComparer вроде корректный...
В результате проектик получает другой приоритет и КИ примитивно зависает...
Пойду искать что не так.
А он не зависит от конфигурации. Студия его создает для ВСЕХ конфигураций.
Как это не зависит?
Прикреплённые файлы
Еще раз тебе повторяю, приведенный скрин - от 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". )
Прикреплённые файлы