Reputation: 322
Im trying to run the linker that comes with VS2012 from a C# program but i get an error saying mspdb110.dll is missing when the linker runs. Why is running the exe from a C# process causing this problem? It works fine from the command line (everywhere else to!). Heres a chunk of code, it works exactly as expected, but link.exe complains. Im not trying to do any fancy process manipulations, i just want to start it with an argument. So the question is what is being done from C# to prevent link.exe from finding a dll. secondly, why does link.exe need this debug related dll to run? And lastly, how should i go about fixing this? Oh, just to make things clear it is link.exe that is giving the errors, nothing else.
private void buildButton_Click(object sender, EventArgs e)
{
string linkerPath = null;
if (File.Exists((linkerPath = Environment.GetFolderPath(Environment.SpecialFolder.ProgramFilesX86) +
"\\Microsoft Visual Studio 11.0\\VC\\bin\\link.exe")))
{
ProcessStartInfo linkInfo = new ProcessStartInfo(linkerPath);
linkInfo.Arguments = "/subsystem:" + subsystemComboBox.Text + " ";
//node.Text is the full file path
foreach (TreeNode node in treeNodes.CSArray)
{
linkInfo.Arguments += "\"" + node.Text + "\" ";
}
linkInfo.Arguments += librariesRichTextBox.Text;
//complete example arg string: /subsystem:console "C:\testdir\test.obj" msvcrt.lib
try
{
Process linkProcess = Process.Start(linkInfo);
linkProcess.WaitForExit();
linkProcess.Close();
}
catch (Exception err)
{
MessageBox.Show(err.Message, "Error!!!", MessageBoxButtons.OK, MessageBoxIcon.Error);
}
}
else
{
MessageBox.Show("the VS linker wasnt found!");
}
}
Upvotes: 0
Views: 1052
Reputation: 111
A quick experiment seems to indicate that the answer will be found in your environment variables.
From within, Visual Studio, select Tools >> Visual Studio 20xx Command Prompt.
Type the LINK command from within that command window. The linker will display its usual "list of things you can tell me to do."
Type the SET command and examine the environment variables. Redirect the SET output to a text file for later reference. Now go to whatever is your normal run-time environment for the offending program. Compare the output of SET with the one you saved.
Eliminate those things which are the same, and one of the remaining values is the magic you seek.
For example, on my own machine, where I'm running VS 2008, I find values like this:
Path=c:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE;c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN;c:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\Tools;c:\Windows\Microsoft.NET\Framework\v3.5;c:\Windows\Microsoft.NET\Framework\v2.0.50727;c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\VCPackages;C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin;C:\Programs\Vim\Vim73\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;c:\Program Files (x86)\Microsoft SQL Server\90\Tools\binn\
VSINSTALLDIR=c:\Program Files (x86)\Microsoft Visual Studio 9.0
WindowsSdkDir=C:\Program Files\Microsoft SDKs\Windows\v6.0A\
_ACP_ATLPROV=c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\Bin\ATLProv.dll
_ACP_INCLUDE=c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include;c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\atlmfc\include;C:\Program Files\Microsoft SDKs\Windows\v6.0A\\include;C:\Program Files\Microsoft SDKs\Windows\v6.0A\include
_ACP_LIB=c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\lib;c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\atlmfc\lib;c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\atlmfc\lib\i386;C:\Program Files\Microsoft SDKs\Windows\v6.0A\\lib;C:\Program Files\Microsoft SDKs\Windows\v6.0A\lib;C:\Program Files (x86)\Microsoft Visual Studio 9.0\;C:\Program Files (x86)\Microsoft Visual Studio 9.0\lib
_ACP_PATH=c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin;C:\Program Files\Microsoft SDKs\Windows\v6.0A\\bin;C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\Tools\bin;C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\tools;C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\ide;C:\Program Files (x86)\HTML Help Workshop;C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin;C:\Windows\Microsoft.NET\Framework\v2.0.50727;C:\Program Files (x86)\Microsoft Visual Studio 9.0\;C:\WINDOWS\SysWow64;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;c:\Program Files (x86)\Microsoft SQL Server\90\Tools\binn\
My mspdb80.dll file (VS 2008) can be found in two directories,
C:\Program Files (x86)\Common Files\microsoft shared\VSA\9.0\VsaEnv\mspdb80.dll
C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\mspdb80.dll
Neither of which paths appear anywhere in my "normal" environment variables, but the ...\Common7\IDE\ folder appears in both PATH and _ACP_PATH in my VS dev environment.
Running linker from normal environment = fail.
Running linker from dev environment = success.
Recommend: locate your mspdb10.dll file, add that path to your environment either in PATH or in _ACP_PATH (or both) and try again.
Upvotes: 1
Reputation: 43300
I'd imagine this is down to the working directory, when you call the process from your applicaton, the working directory used is derived from wherever the application was started from, i.e bin/debug
.
The commandline will most likely be opening it from its native location where the dll also lives.
Therefore your application will be looking in bin/debug
for the dll instead of the correct directory
You can set the working directory to the correct directory through ProcessStartInfo
...
var linkerPath = Path.Combine(
Environment.GetFolderPath(Environment.SpecialFolder.ProgramFilesX86),
"\\Microsoft Visual Studio 11.0\\VC\\bin\\link.exe");
ProcessStartInfo startInfo = new ProcessStartInfo {
FileName = linkerPath,
WorkingDirectory = Path.GetDirectoryName(linkerPath)};
Process p = new Process{
StartInfo = startInfo};
Upvotes: 3