как скомпилировать один проект с разными версиями одной длл

[Malaja]

ситуация:
есть проект на c#, естирующий совместимость софта в двух версиях (вапример, в V1 и V2). Для этого к проекту линкуются (через references) определенные длл-лины из V1 и V2. Пока все ОК.
Но сейчас, т.к. сдали уже следующую версию софта, возникла потребность тестировать на совместимость V2 и V3.
Сам код тестового проекта должен остаться таким же (тестируем тот же набор функций), поменяться должны только линкуемые библиотеки. При этом предыдущий тест должен быть всегда под рукой, т.е. убрать одни длл-лины и заменить их другими нельзя.
Естественно, просто тупо копировать код неохота...

В с++ - проектах в свойствах линкера всегда можно было задать список линкуемых элементов и ни о чем не думать. А вот как это сделать в c#?...
Т.е .понятно, что надо создать новую конфигурацию, но как сказать компилятору, какую длл-лину при какой конфигурации линковать?

[Джон]

Ну я думаю он будет линковать ту dll-ину, которая в Reference указана.

[Malaja]

Джон,

в том-то и дело... В References у тебя всегда прилинкована одна версия текущей длл-ли... И сделать свич на основании типа конфигурации (например: при DEBUG_V1 линкуем client_v1.dll / при DEBUG_V2 линкуем client_v2.dll ) не выходит...

Пока вижу один выход:
- длл-ли для V1 находятся в папке client_v1 (это уже так и есть)
- длл-ли для V2 должны находиться в папке client_v2 (это надо будет сделать)
в prebuild-е задать скрипт, в котором будет создаваться какая-то временная папка current_client и затем, в зависимости от константы, которую мы определили для каждой конфигурации, соответствующие длл-ли будут копироваться из client_v1 или client_v2 в current_client.

Или я неправа в корне?

[Dimka]

Malaja, напиши код динамической загрузки тестируемых DLL по параметрам командной строки...

Вот тут недавно обсуждали.
https://forum.shelek.ru/index.php/topic,24493.0.html

[Malaja]

Дим,
не выйдет...
Проблема заключается в том, что речь идет о целой куче длл-лей, которые играют вместе - на основании этого создается клиент, а в нем определенные объекты. Посему мне нужно все скомпилировать правильной кучей.

[Malaja]

Описаный мной метод с prebuild-ом вроде бы работает (сделала маленький примерчик).
Других вариантов пока так и не нашла.

[Джон]

Ир, эти dll (разные варианты) находятся в одном с ехе solution? Если да, то это можно таки сделать на уровне конфигурации.

Для этого в Configuration Manager ставишь/убираешь соответственно галочки Build у нужной/ненужной dll.

[Malaja]

Джон,
к сожалению, у меня в руках только длл-ли, а не проекты... Т.е. в моем solution находится только мой проект, а эти длл-ли прикреплены в виде References...
Если бы были проекты, вопросов бы не возникало...

[Джон]

Ну, тогда можно попробовать так извернуться:

1. Делаешь копию проектного файла и переименовываешь его в, например, *_V2.csproj

2. В копии генеришь новый GUID и заменяешь:
<ProjectGuid>{AB6A1D24-E98E-43DC-BD21-CE87E8D2875A}</ProjectGuid>

3. Добавляешь "существующий проект" к solution.

В итоге у тебя два проекта, каждый из которых работает с одними и теми же файлами. Ну и ессно можешь в нём другие зависимости установить. Или, к примеру, изменить имя ехе-шника.

Конечно, на каждый вариант придётся делать по копии проекта. Но может такой вариант тебя больше устроит?

[Malaja]

Джон,
спасибочки за идею! Это проще и безопасней!
Муррр
И что обидно - вроде вчера ленилась-ленилась, но легкий путь не нашла... Трудолюбивая пчела на свою голову, прости господи... 

[Malaja]

Джон,

после бури восторга последовало отрезвление, в связи с чем возникло пару вопрос насчет guid-ов...
1) что делать с guid-ом, стоящим в AssemblyInfo.cs? Получается один AssemblyInfo.cs для обоих проектов...
2) в .sln - файле есть еще один guid...
3) итого - 3 разных идентификатора, но с ними пока не разобралась.
точнее - ясно, что guid проекта - guid для идентификации сборки, а guid в csproj - для идентификации проекта. Мне непонятен третий - из AssemblyInfo.cs

[Джон]

Не не. Делай только то, что я сказал.

В sln он сам добавится, когда ты этот проект добавишь. Смотри. Всё просто. Проект-файл просто описывает, что к проекту относится плюс настройки. У тебя это всё одинаковое. Так?

Те тебе нужен клон с другими References, правильно? Вот ты и делаешь его. Но: 1. По определению, в одной папке не могут находиться два файла с одинаковым именем -> новое имя проект-файла; 2. Проект идентифицируется через его GUID - поэтому нужен новый GUID. Ну представь себе, что ты просто добавляешь другой, уже существующий, проект к solution. Толькo в данном случае у тебя есть только один единственный проект-файл. Вот и всё.


AssemblyInfo.cs - ну и что? Тамошний GUID используется для COM, у тебя COM? Что стоит в [assembly: ComVisible()]?
Да это и не важно. Ведь по сути у тебя ничего не меняется. Другими словами ты можешь выбросить оригинальный проект и работать только с клоном. Что изменилось? НИЧЕГО!

зы ты до скольки сегодня работаешь? Если я тебе между 16:20 и 16:30 звякну? Хэнди не поменялся?

[Malaja]

Джон,
1) сегодня сижу тут до 8 вечера
2) телефон не поменялся
3) sln я и трогала, т.к. знаю, что при открытии проекта он обновится
3) насчет третьего guid-а в AssemblyInfo.cs - уже поняла. Мне почему-то казалось, что guid проекта и com-а тут д.б. одинаковыми... (незнание матчасти никогда до добра не доводит)
4) тогда все действительно получается без проблем и заморочек.