Решения Visual Studio - правильное расположение служебных EXE-файлов, необходимых для вашего решения - PullRequest
2 голосов
/ 02 апреля 2012

Есть ли подходящее место в решении Visual Studio для .exes, требуемое вашим решением.Например, сейчас я работаю над инструментом, которому нужны VHDCreate.exe, ISOCreate.exe, OSClone.exe и другие exe-файлы.Как правильно включить их в решение?Я унаследовал решение, в котором они просто застряли в папке внутри проекта бизнес-уровня решения.

Я использую Visual Studio 2010.

Ответы [ 3 ]

2 голосов
/ 02 апреля 2012

Я бы предложил иметь хорошо организованную папку инструментов на уровне решения.Затем вы можете использовать папку решения, чтобы организовать ее отдельно от остальных проектов.

0 голосов
/ 02 апреля 2012

Возможно, вы захотите прочитать серию Майка Робертса, Как настроить дерево разработки .Net . На мой взгляд, способ, которым Visual Studio делает это по умолчанию, по сути, нарушен.

Single * .pdf: Как настроить дерево разработки .Net

По сути, ваша структура каталогов должна выглядеть следующим образом:

  • Meta/Development Root
    Обычно отображается в корень системы контроля версий.
    • Solution
      Один каталог, содержащий все ваше решение. Должен быть назван так, чтобы соответствовать решению.
      • Solution.sln
        Сам файл решения.
      • nant.build
        Файл сборки nAnt для решения.
      • lib
        Каталог lib содержит сторонние сборки / dll, на которые ссылаются различные проекты в вашем решении. Он находится под контролем источника. Ссылки на проекты должны указывать здесь.
      • tools
        Каталог tools содержит все сторонние инструменты, необходимые для построения вашего решения. Это тоже находится под контролем источника. Каталог tools должен содержать версии nAnt, nUnit и т. Д., Используемые вашим проектом & mdash; и ваши сценарии сборки должны ссылаться на них, а не на версии, установленные на компьютере разработчика.
      • bin
        Каталог bin содержит выходные данные процесса сборки решения. Каждый проект должен быть настроен так, чтобы он указывал здесь.
        • debug
          отладочная сборка
        • release
          Выпуск сборки
      • obj
        В идеальном мире здесь указывается obj каждого проекта, а также нет места в дереве исходных текстов. К сожалению, Visual Studio не предлагает официального способа сделать это (хотя, как мне сказали, VS можно взломать, если вы достаточно изобретательны).
      • src
        Каталог src является корневым каталогом для фактического исходного кода вашего решения.
        • project1
          Каталог для project1.
          • project .csproj`
            Файл проекта.
          • *.cs и др. Файлы. Исходные файлы.
        • ...
        • project-n

Как структурировать отдельные проекты, я думаю, это совершенно отдельная тема, но должно быть, WRT и для решения, и для отдельных проектов соответствует между пространством имен и иерархией файловой системы. Если для конкретного проекта требуется сторонняя сборка, которая недоступна для других проектов в решении, для каждого каталога таких проектов может быть задан аргумент в его собственную директорию lib, но при этом сторонние сборки будут разбросаны по всему источнику. дерево и так не рекомендуется.

0 голосов
/ 02 апреля 2012

Это с родным .dll, но концепция та же самая.

  • Добавить существующий элемент в решение и выбрать любую папку, в которой существуют двоичные файлы:

Add Existing

  • Выберите добавить как ссылку из любой папки вне решения, в котором вы храните двоичные файлы

Add as Link

  • В обозревателе решений установите его как Copy if newer.

Solution Explorer

  • .exe или .dll будут скопированы в папку вывода сборки при необходимости.

Output Folder

  • Когда оригинальное .exe будет обновлено, сборка вытянет более новую в выходную папку.
...