开发者

Using relative path for "Start external program" in VS.NET 2010

开发者 https://www.devze.com 2023-02-06 19:50 出处:网络
I\'ve seen a few posts related to this topic but none with any conclusive answers... When debugging my VS.NET 2010 app, I\'m trying to start an external program whose locatio开发者_运维百科n is relat

I've seen a few posts related to this topic but none with any conclusive answers...

When debugging my VS.NET 2010 app, I'm trying to start an external program whose locatio开发者_运维百科n is relative to the project path. I've seen some indications that macros (like $(ProjectDir)) were supported in earlier versions of VS.NET, but they don't seem to work in VS.NET 2010. Using relative path notation just gives me an error that the path is invalid.

Has anyone run into this? If so, how did you address?

Thanks.


I know this is a little late to the party, but here's how we do it. The key to this is to set the 'OutputPath' explicitly to the Build directory. This re-bases it to working directory and not the VS install directory.

  1. Update output path for the project to be:
    <OutputPath>$(MSBuildProjectDirectory)\bin\</OutputPath>

  2. Update StartProgram for the project to be:
    <StartProgram>$(OutputPath)Relative.exe</StartProgram>

Here is a sample configuration 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>


Similar to what Yobi21 suggested, editing the project file and adding these lines to the main <PropertyGroup> in the project file worked for me:

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

Watch out for the properties in the .csproj.user file overriding those in your regular project file. Note: Starting with Visual Studio 2017, these properties are contained in the launchsettings.json file.

This one stumped me until I deleted the entries.


Found the answer here.

In the event that the above link goes dead, the summarized answer is as follows:

  1. Macros don't work here, so forget about that.
  2. Environment variables don't work either, so forget about that as well.
  3. It turns out that Visual Studio.NET (at least 2008 and 2010) uses one of two paths as the base for any relative path specified in the Start external program setting...

If Visual Studio.NET was launched by clicking on the SLN file in Explorer, the base path will be the folder (including the "\") where the SLN resides. Once I modified my relative path to account this and then launched VS.NET 2010 by double-clicking the SLN file, my external program correctly launched when hitting F5.

If Visual Studio.NET was launched from the shortcut on the Start Menu and then the SLN was opened from within Visual Studio.NET, the base path will be [Visual Studio install path]\Microsoft Visual Studio ["9.0" or "10.0" depending on whether using VS.NET 2008 or 2010]\Common7\IDE\.

I guess it makes sense now, but it still kinda stinks that VS.NET will only find my external program correctly depending on how I launch VS.NET.


$(SolutionDir) will not work if you use it directly in VS2010 in the start external programm, but if you close your solution and open the YourProject.csproj.user with notepad, you can change the path and include the $(SolutionDir).

Reopen VS 2010 and it works like a charm.

here an example of my project "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>


You can change the .user in notepad while solution is closed to even include relative paths. It is ,however, horrific. Example:

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

This is without scroll

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

Using relative path for "Start external program" in VS.NET 2010

The windows predefined folders can be used too.

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

Remeber the xml conifg .user file is parsed when loading the solution not when pressing the Start debug button so any changes to the .user file must happen while the solution is closed.


Something I stumbled upon, which seems to not interfere or redefine existing macros: Looks like you can define your own macros and use them

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


The list of available macros for vs2010 are listed in this web MSDN

ProjectDir macro are listed as available for VS2010

$(ProjectDir) The directory of the project (defined as drive + path); includes the trailing backslash '\'.

But if you're having throubles with it, you can try using SolutionDir.

$(SolutionDir) The directory of the solution (defined as drive + path); includes the trailing backslash '\'.

0

精彩评论

暂无评论...
验证码 换一张
取 消