У меня есть куча модулей:
F:\Common_VB2013\1.1.1\m_module1.vb
F:\Common_VB2013\1.1.1\m_module2.vb
...
F:\Common_VB2013\1.1.1\m_moduleN.vb

Добавлены в разные проекты по принципу
Проект -> Добавить существующий элемент -> Добавить как связь
(мне так удобно, т.к. я ссылаюсь из разных проектов)

Допустим я хочу при написании новой версии
зафиксировать папку F:\Common_VB2013\1.1.1\
скопировать ее содержимое в F:\Common_VB2013\1.2.1\
и далее работать с файлами в новой папке

Т.е. проект теперь должен ссылаться на
F:\Common_VB2013\ 1.2.1 \m_module1.vb
F:\Common_VB2013\ 1.2.1 \m_module2.vb
...
F:\Common_VB2013\ 1.2.1 \m_moduleN.vb

И как это быстро поменять в проекте?
В VB6 это делалось тупым открыванием файла проекта в блокноте и автозаменой 1.1.1 -> 1.2.1
А здесь походу все запрятано в бяка-форматы.

Можно конечно ручками удалить, добавить. Но долго это если несколько десятков ссылок.

Есть идеи?

Нашел

Project -> Project -> Project.VBPROJ

Открыть с помощью -> блокнот




Ну и тупо меняем 1.1.1 ->1.2.1 как и в VB6.
Вроде достаточно.

bazileДмитрий77, какой ужас. Здесь так и просится система контроля версий.
Не, пасиб. У меня свои схемы.
Принцип простой, пока "версия проги" в разработке, я могу менять код в модулях \1.1.1 причем из любого подпроекта.
Как 1.1.1 выходит в "релиз", содержание 1.1.1 фиксируется.
И копируется в 1.2.1. Далее работаем с папкой 1.2.1.

Я уже намучился с COM-обертками под разные версии .Net и COM, еле подвел к общему знаменателю, так что мне эти все прибамбасы не очень нравятся.

P.S. То о чем я спрашивал я ответ нашел.

Изопропил,

Не. Просто принялся за новую версию проекта, ибо первая (имеется ввиду первая на .Net) успешно реализована (и реализуется, а как же без этого), а идеи как бы еще не иссякли. Для начала надо ее замультиязычить, чтоб потом с этим всякий раз не мудохаться.

bazileСистемы контроля версий позволяют сделать все что ты описал.
Ну и как мне иначе (в блокноте это делается в пару шагов)название папочки заменить? Не удаляя и не добавляя модули ручками по одному?
У меня количество пристыкованных модулей к примеру 30.

Естественно я все храню и резервирую. И цель, что если я открою "старую" версию проекта, то она должна открыться с пристыкованными модулями из "старой" папочки, а не новой, где модули уже могут быть модифицированы.

bazile,

Ну, понял я тебя.
Я вот в этом люблю копаться:
http://sourceforge.net/p/opalvoip/code/HEAD/tree/opal/trunk/
И даже там, знаешь как баги ищу.
Например, версия 20500 работает как надо, а версия 21700 почему то не делает то что мне надо.
Берем (21700+20500)/2=21100, компилируем ее целиком и смотрим, есть баг или нет.
И в зависимости от результата делим один или другой диапазон пополам.
В итоге приходим к месту бага по кратчайшему пути.
Ну и читаем комменты, и откатываем кусок кода, иногда это одна строчка которую я ну не хрена не понимаю.

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

В примере по ссылке - крайне нужная вещь.
В применении к моим VB6(.Net) проектам ИМХО - неоправданный перебор.

Ну и да, честно сам никогда ни CVS ни CVN глубоко не копал, знаком с ними на уровне что командной строкой надо скачать конкретный транк, ну и историю изменений между соседними транками в web поглядеть.

Не, не надо продолжать. Стремлюсь поддержать беседу, отвлекаюсь от дел насущных.

bazile,

У меня стоит SlikSvn, причем помнится я нарочно не устанавливал GUI-версию (насчет GUI могу путать с CVS), чтоб не мусорить комп.
И я уже давно эти транки не качаю, уважаемый Роберт (автор этого дела) настолько умудрился все испортить в последнее время, что пытаться реанимировать бесполезно. У меня есть пара стабильных сборок мной кастомизированных и мне этого хватит судя по всему надолго, если не навсегда.
Если под IVR начну копать по-хорошему, тогда возможно придется в эти репозитории опять влезать.
А сейчас просто времени на это нет.