Fresh install of VisualD (0.3.40-b1) into VS2010. New console app, solution defaults to 32bit, add 64bit via the configuration manager, try and build, linking fails, complains about mspdb100.dll. The problem: tools -> options -> project and solutions -> visual d settings -> dmd directories -> x64 tab The x64 tab has some additional options, particularly: "override linker settings from sc.ini" which is ticked, and the path in linker defaults to $(VCINSTALLDIR)\bin\link.exe This path is wrong, that is the 32bit linker. The correct path is: $(VCINSTALLDIR)\bin\amd64\link.exe I changed the path and it works as expected.
Actually the 32-bit linker is used explicitely because - it works just as well to build x64 binaries - it allows building x64 executables on 32-bit systems - the filemonitor that records dependencies only works with the 32-bit linker I guess what's wrong instead is that the PATH environment variable or the executable path settings contain the path to the amd64 folder, so that the wrong mspdb100.dll is found. Maybe the linker executable has to be analyzed for its architecture to set the appropriate PATH. > Fresh install of VisualD (0.3.40-b1) into VS2010. BTW: in case you missed that, there is a beta2 with basic C++ support.
Hmmm. So you really think the settings are correct? Well it needs to be fixed in some way that it actually works at least :) I'll leave that decision with you, but in my case, I updated the path to point to the 64bit linker and had no problems... what problems should I expect? I had noticed the updates. I've been in the process of moving house and starting a new job recently, so I haven't had a chance to try it out, but I'll get on to it some time soon and let you know how I go :) Thanks again!
(In reply to Manu from comment #2) > I'll leave that decision with you, but in my case, I updated the path to > point to the 64bit linker and had no problems... what problems should I > expect? Obviously, the settings didn't match for your installation. I'll have to check where the appropriate DLLs are in a VS2010 installation, but I don't have that version on my computer ATM. My guess is that $(VSInstallDir)\Common7\IDE needs to added to PATH, but not if the 64-bit linker is used. The expected problem is that "monitoring OPTlink" will not work, it's also tried with the MS linker. The net effect is that the project always wants to rebuild. > > I had noticed the updates. I've been in the process of moving house and > starting a new job recently, so I haven't had a chance to try it out, but > I'll get on to it some time soon and let you know how I go :) np, and good luck with your new job. If you find the time, it'd be nice if you could check whether the reported bugs that I couldn't reproduce, are still valid: Issue 13198, 11549/11033, 12021, 11029.
On my installation of VS2010 vcvars64.bat adds Common7\IDE to path, but VC\BIN\amd64 comes first, so 64-bit mspdb100.dll is picked from there.
I just installed DMD+VisualD on another fresh installation with VS2010, and the same problem. It definitely doesn't work on fresh installs with 2010. The linker path just needs to be set to bin/amd64/link.exe instead of bin/link.exe and it's fine.
I couldn't install VS2010, but it seems the problem also exist on VS2012: - the 32-bit link.exe is in $(VSINSTALLDIR)\VC\bin - the 32-bit mspdb110.dll is in $(VSINSTALLDIR)\Common7\IDE - the 64-bit link.exe is in $(VSINSTALLDIR)\VC\bin\amd64 - the 64-bit mspdb110.dll also is in $(VSINSTALLDIR)\VC\bin\amd64 As long as the DLL is in the same folder as the linker executable, it should be fine. In VS2013, $(VSINSTALLDIR)\VC\bin also contains mspdb120.dll, so you don't run into any issues. So, to make both 32bit and 64-bit linker work, adding $(VSINSTALLDIR)\Common7\IDE to the executable paths should do the trick.
Next time you have to install Visual D, please try https://github.com/D-Programming-Language/visuald/releases/tag/v0.3.40-beta3
please try remove C:\Program Files (x86)\VisualD\filemonitor.dll
(In reply to sdv from comment #8) > please try remove C:\Program Files (x86)\VisualD\filemonitor.dll Replaced by tracker.exe from msbuild now.
fix released in 0.3.40.