使用在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

回答

相關問題