Подтвердить что ты не робот

Использование относительного пути для "Начать внешнюю программу" в VS.NET 2010

Я видел несколько сообщений, относящихся к этой теме, но ни с какими окончательными ответами...

При отладке моего приложения VS.NET 2010 я пытаюсь запустить внешнюю программу, местоположение которой относительно пути к проекту. Я видел некоторые признаки того, что макросы (например, $(ProjectDir)) поддерживались в более ранних версиях VS.NET, но они, похоже, не работают в VS.NET 2010. Использование относительной записи пути просто дает мне ошибку, что путь недействителен.

Кто-нибудь сталкивался с этим? Если да, то как вы обращались?

Спасибо.

4b9b3361

ОТВЕТЫ

Ответ 1

Нашел ответ здесь.

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

  • Макросы здесь не работают, поэтому забудьте об этом.
  • Переменные среды тоже не работают, поэтому забудьте об этом также.
  • Оказывается, что Visual Studio.NET(по крайней мере, 2008 и 2010) использует один из двух путей в качестве базы для любого относительного пути, указанного в настройке Начать внешнюю программу...

Если Visual Studio.NET был запущен, нажав на файл SLN в проводнике, базовым путем будет папка (включая "\" ), где находится SLN. Как только я изменил свой относительный путь для учетной записи, а затем запустил VS.NET 2010, дважды щелкнув файл SLN, моя внешняя программа правильно запускается при нажатии F5.

Если Visual Studio.NET был запущен из ярлыка в меню "Пуск", а затем SLN был открыт из Visual Studio.NET, базовый путь будет [Путь установки Visual Studio]\Microsoft Visual Studio [ 9.0 "или" 10.0 "в зависимости от того, используете ли они VS.NET 2008 или 2010]\Common7\IDE\.

Я предполагаю, что это имеет смысл сейчас, но он все еще воняет, что VS.NET будет только правильно искать мою внешнюю программу в зависимости от того, как я запускаю VS.NET.

Ответ 2

Я знаю, что это немного поздно для вечеринки, но вот как мы это делаем. Ключом к этому является установка "OutputPath" явно в каталог Build. Это переустанавливает его в рабочий каталог, а не на каталог установки VS.

  • Обновить выходной путь для проекта:
    <OutputPath>$(MSBuildProjectDirectory)\bin\</OutputPath>

  • Обновить StartProgram для проекта:
    <StartProgram>$(OutputPath)Relative.exe</StartProgram>

Вот пример конфигурации PropertyGroup:

<PropertyGroup Condition="'$(Configuration)|$(Platform)' == '0-Local|AnyCPU'">
   <!-- default values you should already have in your csproj -->
   <PlatformTarget>AnyCPU</PlatformTarget>
   <DebugSymbols>true</DebugSymbols>
   <DebugType>full</DebugType>
   <DefineConstants>DEBUG;TRACE</DefineConstants>
   <ErrorReport>prompt</ErrorReport>

   <!-- actual output path and start action definition -->
   <OutputPath>$(MSBuildProjectDirectory)\bin\</OutputPath>
   <StartAction>Program</StartAction>
   <StartProgram>$(OutputPath)NServiceBus.Host.exe</StartProgram>
   <StartArguments>NServiceBus.Integration</StartArguments>
</PropertyGroup>

Ответ 3

Подобно тому, что предложил Yobi21, редактирование файла проекта и добавление этих строк к основному <PropertyGroup> в файле проекта сработало для меня:

<StartAction>Program</StartAction>
<StartProgram>$(MSBuildProjectDirectory)\Path\Relative\To\CSProj\Folder</StartProgram>
<StartArguments>Any Required Arguments</StartArguments>

Следите за свойствами в файле .csproj.user, которые переопределяют свойства вашего обычного файла проекта. Примечание. Начиная с Visual Studio 2017, эти свойства содержатся в файле launchsettings.json.

Этот озадачил меня, пока я не удалил записи.

Ответ 4

$(SolutionDir) не будет работать, если вы используете его непосредственно в VS2010 в стартовой внешней программе, но если вы закроете свое решение и откройте файл YourProject.csproj.user с помощью блокнота, вы можете изменить путь и включить $( SolutionDir).

Повторно открыть VS 2010 и работает как шарм.

вот пример моего проекта "ApplicationService_NSB.csproj.user" 

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Debug|AnyCPU'">
    <StartAction>Program</StartAction>
    <StartProgram>$(SolutionDir)\Super\ApplicationService_NSB\bin\Debug\NServiceBus.Host.exe</StartProgram>
  </PropertyGroup>
</Project>

Ответ 5

Вы можете изменить .user в блокноте, пока решение закрыто, чтобы включить относительные пути. Это, однако, ужасно. Пример:

<StartProgram>$([System.IO.Path]::GetDirectoryName($([System.IO.Path]::GetDirectoryName($(SolutionDir))))\MyCustomBindir\MyCustomProgram.exe</StartProgram>

Это без прокрутки

<StartProgram>
$([System.IO.Path]::GetDirectoryName($([System.IO.Path]::GetDirectoryName( $(SolutionDir))
))\MyCustomBindir\MyCustomProgram.exe
</StartProgram>

введите описание изображения здесь

Также можно использовать предопределенные папки Windows.

<StartProgram>$(AppData)\MyCustomBindir\MyCustomProgram.exe</StartProgram>

Помните, что файл XML файла xil conifg .user анализируется при загрузке решения не при нажатии кнопки Начать отладка, так что любые изменения в файле .user должны произойти, когда решение закрывается.

Ответ 6

Что-то, на что я наткнулся, которое, кажется, не мешает и не переопределяет существующие макросы: похоже, вы можете определять свои собственные макросы и использовать их

<StartAction>Program</StartAction>
<MyMacro>$(MSBuildProjectDirectory)your_folder_path_here\</MyMacro>
<StartProgram>$(MyMacro)MyApp.exe</StartProgram>

Ответ 7

Список доступных макросов для vs2010 указан в этом веб-сайте MSDN

Макросы ProjectDir перечислены как доступные для VS2010

$(ProjectDir) Каталог проекта (определяется как диск + путь); включает обратную косую черту '\'.

Но если у вас проблемы с этим, вы можете попробовать использовать SolutionDir.

$(SolutionDir) Каталог решения (определяется как диск + путь); включает обратную косую черту '\'.