使用在2010年VS.NET

“启动外部程序”我已经看到了与此相关的话题，但没有任何确凿的答案几个职位相对路径...使用在2010年VS.NET

调试时我VS.NET 2010的应用程序，我试图启动一个外部程序，它的位置与项目路径有关。我已经看到一些迹象表明，在早期版本的VS.NET中支持宏（如$（ProjectDir）），但它们在VS.NET 2010中似乎不起作用。使用相对路径表示法只会给我一个错误，路径无效。

有没有人遇到过这个？如果是这样，你是如何解决的？

谢谢。

来源

2011-01-23 goombaloon

宏仍可以使用，但需要在`.csproj` XML文件中手动设置。完成此操作后，不要忘记从`.csproj.user`文件中删除相关部分（如果有的话）。 – 2014-06-30 10:25:41

找到了答案here。

在这上面的链接进入死的情况下，总结答案如下：

宏并不在这里工作，所以忘了这一点。
环境变量也不起作用，所以也不要这样。
原来，Visual Studio.NET中（至少2008和2010）使用的两个路径为基准，为在启动外部程序设置中指定的任何相对路径的一个...

如果Visual Studio.NET是通过单击资源管理器中的SLN文件启动的，基本路径将是SLN所在的文件夹（包括“\”）。一旦我修改我的相对路径来解决这个问题，然后通过双击SLN文件启动VS.NET 2010，我的外部程序在按F5时正确启动。

如果从开始菜单的快捷方式启动Visual Studio.NET，然后在Visual Studio.NET中打开SLN，则基本路径将为[Visual Studio安装路径] \ Microsoft Visual Studio [“9.0 “或”10.0“取决于是否使用VS.NET 2008或2010] \ Common7 \ IDE \。

我认为它现在有道理，但它仍然有点臭，VS.NET将只能找到我的外部程序正确取决于我如何启动VS.NET。

来源

2011-01-23 17:28:01 goombaloon

+1我认为这是一个非常奇怪的行为。 – Jonathan 2011-01-25 11:13:27

感谢您发布到我的网站的链接。你们真棒！ – Rhyous 2011-07-25 19:22:36

我知道我发布了一个超过2年的答案的评论，但我想澄清一下这个“奇怪的行为”。实际上，这并不奇怪。如果我理解正确，“工作目录”概念是源自操作系统，而不是VS本身。就操作系统而言，工作目录是从中调用VS的目录（从链接启动时从.sln，VS目录启动时的解决方案目录）。可能奇怪的是，VS在加载解决方案时并不明确地改变工作目录。 – MetaFight 2013-11-20 11:15:17

-5

为VS2010可用的宏的列表在这个网页MSDN

PROJECTDIR宏观列出被列为可用于VS2010

$（PROJECTDIR）项目的目录（定义为驱动器+路径）;包括尾部反斜杠'\'。

但是，如果你遇到麻烦，你可以尝试使用SolutionDir。

$（SolutionDir）解决方案的目录（定义为驱动器+路径）;包括尾部反斜杠'\'。

来源

2011-01-23 16:07:56 Jonathan

谢谢，但我已经试过了，它不起作用。我不认为“开始外部程序”设置支持宏。 – goombaloon 2011-01-23 16:23:04

你有没有试过你的建议？在这种情况下，宏不起作用。 – 2011-08-02 22:28:43

我知道这对派对来说有点迟，但这是我们如何去做的。关键是将“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>

来源

2011-03-10 14:32:06 cfbarbero

什么Yobi21建议，编辑项目文件和项目文件中添加这些行到主<PropertyGroup>类似的工作对我来说：

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

当心在.csproj.user属性文件覆盖常规项目文件中的文件。

这一个难倒我，直到我删除条目。

来源

2011-09-05 19:11:50

如果您在启动外部程序的VS2010中直接使用$（SolutionDir），将无法工作，但如果关闭解决方案并使用记事本打开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>

来源

2012-03-30 21:12:50 Arthis

，而解决方案是封闭，甚至包括相对路径可以在记事本改变。用户的一个例子。然而，这很可怕。实施例：

<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>

预先定义的文件夹的窗口可以太使用。

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

Remeber的XML conifg 。用户文件加载解决方案时，不按开始调试按钮，同时该解决方案被关闭，以便到。用户文件的任何变化必须发生时进行解析。

来源

2016-06-29 11:32:56

使用在2010年VS.NET

回答

相关问题