I think it might be VisualD specific, and it seems like a version mismatch.

In sc.ini I have: VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual
Studio 11.0\VC\  (note: the vs2012 path)
And beneath that path exists mspdb110.dll, but apparently the version of
link.exe that VisualD invokes is looking for mspdb100.dll, which it doesn't
find.

We had some discussion where VisualD should try and override the sc.ini paths with the paths that were actually appropriate for the version of Visual Studio being used at the time. This is important to eliminate other version conflicts when linking VC C/C++ and D projects together within one solution. Visual Studio uses the toolset and libs related to the version of the IDE currently in use, therefore VisualD should also tell DMD to use the same toolset for compatibility.

I use vs2010, although I also have vs2005 and vs2013 installed. It seems VisualD is invoking the correct linker since it's complaining about mspdb100.dll, which is the proper version for vs2010, but perhaps DMD is still getting another path for the supporting DLL's from sc.ini, which was set to the vs2012 paths (as noted above)?

My suggestion from before was that under VisualD, DMD should _completely ignore_ sc.ini, and VisualD should provide all paths and arguments. As long as DMD gets any paths from sc.ini, I can only see it leading to problems under VisualD.

Disclaimer: I'm not absolutely certain this is a correct analysis of the situation, but it seems this is what's happening.


On 5 January 2014 10:47, Manu <turkeyman@gmail.com> wrote:

> Fresh install of DMD + VisualD via the installer.
> Building Win64, linker complains: "link.exe: Can't start because
> mspdb100.dll is missing"
>
> We really need to get this right. Not sure what's special about my system.
> Has anything in the installer or VisualD changed?
> Last time I tested it was working.
>

Hmm, so I jigged it so it's able to find mspdb100.dll, but now link.exe complains: "The application was unable to start correctly (0xc000007b)." That's weird.


On 5 January 2014 12:17, Manu <turkeyman@gmail.com> wrote:

> I think it might be VisualD specific, and it seems like a version mismatch.
>
> In sc.ini I have: VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual
> Studio 11.0\VC\  (note: the vs2012 path)
> And beneath that path exists mspdb110.dll, but apparently the version of
> link.exe that VisualD invokes is looking for mspdb100.dll, which it doesn't
> find.
>
> We had some discussion where VisualD should try and override the sc.ini paths with the paths that were actually appropriate for the version of Visual Studio being used at the time. This is important to eliminate other version conflicts when linking VC C/C++ and D projects together within one solution. Visual Studio uses the toolset and libs related to the version of the IDE currently in use, therefore VisualD should also tell DMD to use the same toolset for compatibility.
>
> I use vs2010, although I also have vs2005 and vs2013 installed. It seems VisualD is invoking the correct linker since it's complaining about mspdb100.dll, which is the proper version for vs2010, but perhaps DMD is still getting another path for the supporting DLL's from sc.ini, which was set to the vs2012 paths (as noted above)?
>
> My suggestion from before was that under VisualD, DMD should _completely ignore_ sc.ini, and VisualD should provide all paths and arguments. As long as DMD gets any paths from sc.ini, I can only see it leading to problems under VisualD.
>
> Disclaimer: I'm not absolutely certain this is a correct analysis of the situation, but it seems this is what's happening.
>
>
> On 5 January 2014 10:47, Manu <turkeyman@gmail.com> wrote:
>
>> Fresh install of DMD + VisualD via the installer.
>> Building Win64, linker complains: "link.exe: Can't start because
>> mspdb100.dll is missing"
>>
>> We really need to get this right. Not sure what's special about my
>> system. Has anything in the installer or VisualD changed?
>> Last time I tested it was working.
>>
>
>

On 5 January 2014 12:30, Manu <turkeyman@gmail.com> wrote:

> Hmm, so I jigged it so it's able to find mspdb100.dll, but now link.exe complains: "The application was unable to start correctly (0xc000007b)." That's weird.
>

Okay, my cludge was a 32bit/64bit dll mismatch. Works now, so it is all
about pathing problems.
This shit has really gotta 'just work' out of the box.

Walter: Is it possible to completely override sc.ini? What needs to be done
to get there?
Rainer: What is the current state of VisualD's overriding sc.ini? What's
complicating the process?

On 5 January 2014 12:17, Manu <turkeyman@gmail.com> wrote:
>
>> I think it might be VisualD specific, and it seems like a version mismatch.
>>
>> In sc.ini I have: VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual
>> Studio 11.0\VC\  (note: the vs2012 path)
>> And beneath that path exists mspdb110.dll, but apparently the version of
>> link.exe that VisualD invokes is looking for mspdb100.dll, which it doesn't
>> find.
>>
>> We had some discussion where VisualD should try and override the sc.ini paths with the paths that were actually appropriate for the version of Visual Studio being used at the time. This is important to eliminate other version conflicts when linking VC C/C++ and D projects together within one solution. Visual Studio uses the toolset and libs related to the version of the IDE currently in use, therefore VisualD should also tell DMD to use the same toolset for compatibility.
>>
>> I use vs2010, although I also have vs2005 and vs2013 installed. It seems VisualD is invoking the correct linker since it's complaining about mspdb100.dll, which is the proper version for vs2010, but perhaps DMD is still getting another path for the supporting DLL's from sc.ini, which was set to the vs2012 paths (as noted above)?
>>
>> My suggestion from before was that under VisualD, DMD should _completely ignore_ sc.ini, and VisualD should provide all paths and arguments. As long as DMD gets any paths from sc.ini, I can only see it leading to problems under VisualD.
>>
>> Disclaimer: I'm not absolutely certain this is a correct analysis of the situation, but it seems this is what's happening.
>>
>>
>> On 5 January 2014 10:47, Manu <turkeyman@gmail.com> wrote:
>>
>>> Fresh install of DMD + VisualD via the installer.
>>> Building Win64, linker complains: "link.exe: Can't start because
>>> mspdb100.dll is missing"
>>>
>>> We really need to get this right. Not sure what's special about my
>>> system. Has anything in the installer or VisualD changed?
>>> Last time I tested it was working.
>>>
>>
>>
>

New exciting error:
1>LINK : fatal error LNK1101: incorrect MSPDB100.DLL version; recheck
installation of this product

Strangely, it works fine on the very first build, or of I rebuild-all, but any build after producing a valid exe gives this error.


On 5 January 2014 12:38, Manu <turkeyman@gmail.com> wrote:

> On 5 January 2014 12:30, Manu <turkeyman@gmail.com> wrote:
>
>> Hmm, so I jigged it so it's able to find mspdb100.dll, but now link.exe complains: "The application was unable to start correctly (0xc000007b)." That's weird.
>>
>
> Okay, my cludge was a 32bit/64bit dll mismatch. Works now, so it is all
> about pathing problems.
> This shit has really gotta 'just work' out of the box.
>
> Walter: Is it possible to completely override sc.ini? What needs to be
> done to get there?
> Rainer: What is the current state of VisualD's overriding sc.ini? What's
> complicating the process?
>
> On 5 January 2014 12:17, Manu <turkeyman@gmail.com> wrote:
>>
>>> I think it might be VisualD specific, and it seems like a version mismatch.
>>>
>>> In sc.ini I have: VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual
>>> Studio 11.0\VC\  (note: the vs2012 path)
>>> And beneath that path exists mspdb110.dll, but apparently the version of
>>> link.exe that VisualD invokes is looking for mspdb100.dll, which it doesn't
>>> find.
>>>
>>> We had some discussion where VisualD should try and override the sc.ini paths with the paths that were actually appropriate for the version of Visual Studio being used at the time. This is important to eliminate other version conflicts when linking VC C/C++ and D projects together within one solution. Visual Studio uses the toolset and libs related to the version of the IDE currently in use, therefore VisualD should also tell DMD to use the same toolset for compatibility.
>>>
>>> I use vs2010, although I also have vs2005 and vs2013 installed. It seems VisualD is invoking the correct linker since it's complaining about mspdb100.dll, which is the proper version for vs2010, but perhaps DMD is still getting another path for the supporting DLL's from sc.ini, which was set to the vs2012 paths (as noted above)?
>>>
>>> My suggestion from before was that under VisualD, DMD should _completely ignore_ sc.ini, and VisualD should provide all paths and arguments. As long as DMD gets any paths from sc.ini, I can only see it leading to problems under VisualD.
>>>
>>> Disclaimer: I'm not absolutely certain this is a correct analysis of the situation, but it seems this is what's happening.
>>>
>>>
>>> On 5 January 2014 10:47, Manu <turkeyman@gmail.com> wrote:
>>>
>>>> Fresh install of DMD + VisualD via the installer.
>>>> Building Win64, linker complains: "link.exe: Can't start because
>>>> mspdb100.dll is missing"
>>>>
>>>> We really need to get this right. Not sure what's special about my
>>>> system. Has anything in the installer or VisualD changed?
>>>> Last time I tested it was working.
>>>>
>>>
>>>
>>
>

On 2014-01-05 03:38, Manu wrote:
> On 5 January 2014 12:30, Manu <turkeyman@gmail.com
> <mailto:turkeyman@gmail.com>> wrote:
>
>     Hmm, so I jigged it so it's able to find mspdb100.dll, but now
>     link.exe complains: "The application was unable to start correctly
>     (0xc000007b)."
>     That's weird.
>
>
> Okay, my cludge was a 32bit/64bit dll mismatch. Works now, so it is all
> about pathing problems.
> This shit has really gotta 'just work' out of the box.
>
> Walter: Is it possible to completely override sc.ini? What needs to be
> done to get there?
> Rainer: What is the current state of VisualD's overriding sc.ini? What's
> complicating the process?

This is the places DMD will look for sc.ini:

http://dlang.org/dmd-windows.html#sc_ini

What about if the installer for VisualD included DMD? Then it could install it anywhere it wanted, provide a custom sc.ini and avoid conflict with any other sc.ini files.

-- 
/Jacob Carlborg

On 5 January 2014 19:50, Jacob Carlborg <doob@me.com> wrote:

> On 2014-01-05 03:38, Manu wrote:
>
>> On 5 January 2014 12:30, Manu <turkeyman@gmail.com
>>
>> <mailto:turkeyman@gmail.com>> wrote:
>>
>>     Hmm, so I jigged it so it's able to find mspdb100.dll, but now
>>     link.exe complains: "The application was unable to start correctly
>>     (0xc000007b)."
>>     That's weird.
>>
>>
>> Okay, my cludge was a 32bit/64bit dll mismatch. Works now, so it is all
>> about pathing problems.
>> This shit has really gotta 'just work' out of the box.
>>
>> Walter: Is it possible to completely override sc.ini? What needs to be
>> done to get there?
>> Rainer: What is the current state of VisualD's overriding sc.ini? What's
>> complicating the process?
>>
>
> This is the places DMD will look for sc.ini:
>
> http://dlang.org/dmd-windows.html#sc_ini
>
> What about if the installer for VisualD included DMD? Then it could install it anywhere it wanted, provide a custom sc.ini and avoid conflict with any other sc.ini files.


It's common to have multiple parallel installations of different versions of Visual Studio. VisualD integrates with all of them. When building, it should be using the appropriate environment for the version of Visual Studio currently in use so that it can link properly against C/C++ projects building in the same environment.

On 05.01.2014 03:38, Manu wrote:
> On 5 January 2014 12:30, Manu <turkeyman@gmail.com
> <mailto:turkeyman@gmail.com>> wrote:
>
>     Hmm, so I jigged it so it's able to find mspdb100.dll, but now
>     link.exe complains: "The application was unable to start correctly
>     (0xc000007b)."
>     That's weird.
>
>
> Okay, my cludge was a 32bit/64bit dll mismatch. Works now, so it is all
> about pathing problems.
> This shit has really gotta 'just work' out of the box.
>
> Walter: Is it possible to completely override sc.ini? What needs to be
> done to get there?
> Rainer: What is the current state of VisualD's overriding sc.ini? What's
> complicating the process?

I guess you are using the latest beta of Visual D, don't you?

The situation with multiple versions of Visual Studio installed is dealt with by always calling the linker separately (not through dmd). This still captures all settings from sc.ini, but overrides some if "override linker settings" is enabled.

What seems to happen is that the default executable paths do not contain <VSInstallDir>\Common7\IDE, but this is needed by the linker to find the mspdb*.dll. PATH is modified to that respect in sc.ini, but it is patched by the D installer to the latest VS version only.

So please try adding $(VCInstallDir)\..\Common7\IDE to the executable paths for x64 builds. I'll add this to the defaults aswell.

[Unfortunately it seems this is a slight simplification, because for the VS2013 shell, the appropriate files are in $(VCInstallDir)\bin.

On 5 January 2014 21:23, Rainer Schuetze <r.sagitario@gmx.de> wrote:

>
>
> On 05.01.2014 03:38, Manu wrote:
>
>> On 5 January 2014 12:30, Manu <turkeyman@gmail.com <mailto:turkeyman@gmail.com>> wrote:
>>
>>     Hmm, so I jigged it so it's able to find mspdb100.dll, but now
>>     link.exe complains: "The application was unable to start correctly
>>     (0xc000007b)."
>>     That's weird.
>>
>>
>> Okay, my cludge was a 32bit/64bit dll mismatch. Works now, so it is all
>> about pathing problems.
>> This shit has really gotta 'just work' out of the box.
>>
>> Walter: Is it possible to completely override sc.ini? What needs to be
>> done to get there?
>> Rainer: What is the current state of VisualD's overriding sc.ini? What's
>> complicating the process?
>>
>
> I guess you are using the latest beta of Visual D, don't you?
>

Actually, I'm using the latest release. What's new in the beta?

The situation with multiple versions of Visual Studio installed is dealt
> with by always calling the linker separately (not through dmd). This still captures all settings from sc.ini, but overrides some if "override linker settings" is enabled.
>
> What seems to happen is that the default executable paths do not contain <VSInstallDir>\Common7\IDE, but this is needed by the linker to find the mspdb*.dll. PATH is modified to that respect in sc.ini, but it is patched by the D installer to the latest VS version only.
>
> So please try adding $(VCInstallDir)\..\Common7\IDE to the executable paths for x64 builds. I'll add this to the defaults aswell.
>

Perfect, that did the trick. Thanks!
I was pointing at an mspdb100.dll in a different directory. It was
complaining about version mismatch on rebuilds. This one seems to be the
correct one, and the complaining is gone.

[Unfortunately it seems this is a slight simplification, because for the
> VS2013 shell, the appropriate files are in $(VCInstallDir)\bin.

Nothing's ever so simple ;)

On 05.01.2014 12:51, Manu wrote:
> On 5 January 2014 21:23, Rainer Schuetze <r.sagitario@gmx.de
> <mailto:r.sagitario@gmx.de>> wrote:
>
>     I guess you are using the latest beta of Visual D, don't you?
>
> Actually, I'm using the latest release. What's new in the beta?

See here for beta releases with a change list: https://github.com/D-Programming-Language/visuald/releases


>
>     So please try adding $(VCInstallDir)\..\Common7\IDE to the
>     executable paths for x64 builds. I'll add this to the defaults aswell.
>
>
> Perfect, that did the trick. Thanks!
> I was pointing at an mspdb100.dll in a different directory. It was
> complaining about version mismatch on rebuilds. This one seems to be the
> correct one, and the complaining is gone.

Argh, incompatible identically named dlls? Where did you find it?

On 6 January 2014 00:35, Rainer Schuetze <r.sagitario@gmx.de> wrote:

>
>
> On 05.01.2014 12:51, Manu wrote:
>
>> On 5 January 2014 21:23, Rainer Schuetze <r.sagitario@gmx.de <mailto:r.sagitario@gmx.de>> wrote:
>>
>>     I guess you are using the latest beta of Visual D, don't you?
>>
>> Actually, I'm using the latest release. What's new in the beta?
>>
>
> See here for beta releases with a change list: https://github.com/D- Programming-Language/visuald/releases


I installed the latest beta, and it overwrite my setting where I added the
search path to the x64 executable paths.
I had to add it again. Is working.


    So please try adding $(VCInstallDir)\..\Common7\IDE to the
>>     executable paths for x64 builds. I'll add this to the defaults aswell.
>>
>>
>> Perfect, that did the trick. Thanks!
>> I was pointing at an mspdb100.dll in a different directory. It was
>> complaining about version mismatch on rebuilds. This one seems to be the
>> correct one, and the complaining is gone.
>>
>
> Argh, incompatible identically named dlls? Where did you find it?
>

Mine are here:
C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\amd64 (I tried
using this one before)
C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE (this one
works)