Как сделать свойство SourcePath файла в проекте установки и развертывания Visual Studio (установщик Windows) относительным, а не абсолютным?

Question

У меня есть относительно простой проект, который находится под контролем исходного кода (svn), и я хотел создать установщик. Я знаю, что могу (должен) использовать WiX , но поскольку я новичок в создании установщиков, я подумал, что будет проще использовать встроенный мастер установки и развертывания Visual Studio (2010).

К сожалению, похоже, что файлы, включая внешнюю (не поддерживаемую проектом) документацию, файлы конфигурации и файлы "Содержимое" , добавляются с абсолютными путями. Это, конечно, неоптимально. Я искал в Интернете, но нашел только тот же вопрос , без ответа. Другой пользователь stackoverflow, кажется, задал подобный вопрос , но единственный ответ, который предполагает ClickOnce , кажется неосновным (я хотел бы иметь MSI, который я распространяю, а не установка через Интернет).

Кто-нибудь знает, как (или можно ли) это исправить?

Answer 1

В VS2005 иногда пути, хранящиеся в файле vdproj, были абсолютными, а иногда и родственниками.В моем случае это было связано с доступом к файлам по каноническому пути или нет.Вот конкретный пример:

Источник находится в C: \ Views \ builddir, откройте решение C: \ Views \ builddir \ solution.sln и добавьте файлы из C: \ Views \ builddir \ .. и VS2005 добавит относительные пути в файл 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 все еще может действоватьтаким образом.

К вашему сведению, почему кто-то хочет сопоставить абсолютный путь к вашему builddir?Это было пережитком плохих старых дней, когда VS не делал ничего правильного с относительными путями.

Answer 2

Как упоминал tzerb, основным источником путаницы может быть то, что пути отображаются как абсолютные под окном свойств внутри VS, но когда вы посмотрите на фактический файл VDPROJ, вы увидите, что пути отображаются как относительные.Однако, как упоминал Патбоб, я считаю, что пути сохраняются как абсолютные, когда они поступают с другого буквенного диска.

Answer 3

Теперь это может быть проще, но когда вы начнете сталкиваться с ограничениями инструмента, это станет очень сложно. Давайте даже не будем говорить о плохих методах, которые он будет поощрять, что может оказаться очень трудным для неимущего конечного пользователя, устанавливающего ваш продукт. У вас есть Visual Studio 2010, так что InstallShield LE (бесплатно) будет лучшим выбором.

В противном случае, чтобы ответить на ваш вопрос, он будет использовать только абсолютные пути, если не сможет рассчитать относительный путь. (например, c: \ foo \ foo.vdproj, потребляющий d: \ foo.txt, потребляющий c: \ test \ foo.txt, должен автоматически быть .... \ test \ foo.txt)

Кстати, если вы решили проверить WiX и хотите немного "просто" проверить мой проект IsWiX на CodePlex. Я пытаюсь преодолеть разрыв между функциями InstallShield и WiX.