[Что курят эти люди] [Кто бы их всех убил] ака Visual Studio 2005

[metaclass]

В общем, я окончательно убеждаюсь, что все программистские тулсы рассчитываются на постоянные рабочие места. Т.е., пришел на настроенный когда-то комп, открыл сделанный кем-то когда-то проект, дописал пару строчек кода за день, чекинил в svn и пошел домой. Такого, что код надо бы и резервную копию сделать без всяких svn, или выложить людям добрым на поругание или перенести на новый комп или домой отнести поработать - не бывает.

Свежий пример: Visual Studio 2005, солюшн с веб-сервисом. Для обычных проектов понятно - ссылки на соседние проекты указываются в файле csproj. То же самое было в 2003 студии для веб-сервисов. В 2005 же у веб-сервиса файла csproj нет. Ссылки на соседние проекты указываются в виде лежащих в папке bin откомпилированных модулей проектов(!!!!). Для ссылок на внешние по отношению к солюшену сборки в папке bin лежит файлик имя_сборки.dll.refresh с указанным в нем абсолютным(!) путем к оригиналу сборки.

Обычная ситуация: архивируем исходный код, папки bin исключая. Или импортируем в svn, настроенный игнорировать *.dll которые постоянно меняются при перекомпиляции. Или вообще игнорирующий папки bin, как это сделано у меня сейчас. Что получит человек, доставший архив кода или сделавший чекаут из svn при попытке откомпилировать солюшн? Правильно, фигу с маслом, т.е. неизвестные ссылки в коде сервиса. А если он получит все файлы, в том числе dll и bin, но у него папка с проектом расположена по другому пути? Хрен внешняя ссылка обновиться по тому пути что записан в *.dll.refresh.

В общем, те кто это проектировал, сидят на стандартных рабочих местах и думают что все сидят точно так же.

Comments

[sbj-ss.livejournal.com]

В VSS? :D

[metaclass.livejournal.com]

Как жыж вы утомице :) Суть не в используемой системе контроля версий, а в том, что проектировщики дятлы, не знающие что такое логический круг. Чтобы появилась dll ссылки - нужно чтобы она уже была.