Как я могу сделать свойство SourcePath файла в проекте установки и развертывания Visual Studio (установщик Windows) относительным, а не абсолютным?
У меня есть относительно простой проект, который находится под контролем источника (svn), и я хотел создать установщик. Я знаю, что мог (должен) использовать WiX, но поскольку я новичок в создании инсталляторов, я думал, что будет проще просто используйте встроенный мастер установки и развертывания Visual Studio (2010).
К сожалению, кажется, что файлы, включая внешнюю (не относящуюся к проекту) документацию, файлы конфигурации и "Content" файлы, добавляются с абсолютными путями. Это, конечно, субоптимально. Я искал в Интернете, но нашел только тот же вопрос, без ответа. Другой пользователь stackoverflow, похоже, задал аналогичный вопрос, но единственный ответ, который предлагает ClickOnce, кажется вне базы (я хотел бы иметь MSI, который я распространяю не на веб-установке).
Кто-нибудь знает, как (или это) это можно исправить?
Ответы
Ответ 1
Теперь это может быть проще, но когда вы начнете сталкиваться с ограничениями инструмента, это будет очень тяжело. Позвольте даже не говорить о плохих практиках, которые он будет поощрять, что может оказаться тяжелым для плохого конечного пользователя, устанавливающего ваш продукт. У вас есть Visual Studio 2010, поэтому InstallShield LE (бесплатно) будет лучшим выбором.
В противном случае, чтобы ответить на ваш вопрос, он будет использовать только абсолютные пути, если он не может окупить относительный путь. (например, c:\foo\foo.vdproj, потребляющий d:\foo.txt, потребляющий c:\test\foo.txt, должен автоматически быть.... \test\foo.txt)
Кстати, если вы решите проверить WiX и хотите "легко" проверить мой проект IsWiX на CodePlex. Я пытаюсь преодолеть разрыв функции между InstallShield и WiX.
Ответ 2
В VS2005 иногда пути, хранящиеся в файле vdproj, были абсолютными, а иногда и родственниками. В моем случае, похоже, было связано с доступом к файлам через канонический путь или нет. Вот конкретный пример:
Источник находится на C:\Views\builddir, откройте решение C:\Views\builddir\solution.sln и добавьте файлы из C:\Views\builddir \.. и VS2005 добавит relative пути в файл vdproj. Однако, если вы сопоставляете этот builddir с буквенным диском, например, сделайте подменю из C:\Views\builddir в s:, откройте решение через S:\solution.sln, а затем добавьте файлы, перейдя по ссылке S: \.., VS2005 будет вставлять абсолютные пути в файлы vdproj. Независимо от того, отображались ли VS2005 пути как абсолютные или родственники, не было никакого отношения к тому, что они хранят в файлах vdproj.
Итак, вполне возможно, что проблема сводится к тому, какой путь вы используете для открытия этого решения. Открытие \\server\shareddir\solution.sln может иметь другое поведение, чем сопоставление \\server\shareddir с W: и открытие w:\solution.sln.
Вы всегда можете добавить файлы, а затем использовать текстовый редактор (например, блокнот), чтобы изменить абсолютные пути в файле vdproj на относительные. С вами все будет в порядке, пока вы снова не измените этот проект.
MS, похоже, действительно не исправляет такие незначительные ошибки, как переписывание кода, чтобы ввести совершенно другой набор ошибок, поэтому VS2010 может по-прежнему действовать таким образом.
FYI, почему нужно отобразить абсолютный путь к вашему builddir? Это был отход от плохих старых дней, когда VS ничего не делал с относительными путями.
Ответ 3
Как упоминалось в tzerb, основным источником путаницы может быть то, что пути отображаются как абсолютные в окне свойств внутри VS, но когда вы просматриваете фактический файл VDPROJ, вы должны видеть, что пути отображаются как относительные. Однако, как упоминал patbob, я считаю, что пути ARE сохраняются как абсолютные, когда они происходят из другого буквенного диска.
