www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DMD VS2017 Support

reply Jolly James <j.j jmail.com> writes:
DMD does not support VS2017. Therefore I cannot link x64 
applications. DMD installer only offers to install VS2013 (what I 
am absolutely not going to do, as that would be a real shame with 
the disk space it consumes).

Any plans for supporting VS2017?
Apr 19
parent reply Jolly James <j.j jmail.com> writes:
I cannot even fix it myself because DMD is looking for 
"bin\link.exe". But with VS2017 the path would actually be 
something like "\bin\HostX64\x64".
Apr 19
next sibling parent Mike B Johnson <Mikey Ikes.com> writes:
On Wednesday, 19 April 2017 at 20:47:51 UTC, Jolly James wrote:
 I cannot even fix it myself because DMD is looking for 
 "bin\link.exe". But with VS2017 the path would actually be 
 something like "\bin\HostX64\x64".
Edit your sc.ini in the dmd\windows\bin dir or use junctions to map directories. DMD's config system is ancient and they refuse to update it because once you set it up and don't change your system you don't have to do much else. It's sort of like a rite of passage, I guess to weed out the losers.
Apr 19
prev sibling next sibling parent reply Meta <jared771 gmail.com> writes:
On Wednesday, 19 April 2017 at 20:47:51 UTC, Jolly James wrote:
 I cannot even fix it myself because DMD is looking for 
 "bin\link.exe". But with VS2017 the path would actually be 
 something like "\bin\HostX64\x64".
Please ignore Mike's answer. Visual D is maintained by Rainers Schuetze and is hosted here[1] on github. From the readme: For more information on installation, a quick tour of Visual D with some screen shots and feedback, please visit the project home for Visual D at http://rainers.github.io/visuald/visuald/StartPage.html. There's a forum dedicated to IDE discussions (http://forum.dlang.org/group/digitalmars.D.ide), where you can leave your comments and suggestions. Bug reports can be filed to the D bugzilla database for Component VisualD. Have fun, Rainer Schuetze 1. https://github.com/dlang/visuald
Apr 19
next sibling parent reply Jolly James <j.j jmail.com> writes:
On Thursday, 20 April 2017 at 00:13:29 UTC, Meta wrote:
 On Wednesday, 19 April 2017 at 20:47:51 UTC, Jolly James wrote:
 [...]
Please ignore Mike's answer. Visual D is maintained by Rainers Schuetze and is hosted here[1] on github. From the readme: For more information on installation, a quick tour of Visual D with some screen shots and feedback, please visit the project home for Visual D at http://rainers.github.io/visuald/visuald/StartPage.html. There's a forum dedicated to IDE discussions (http://forum.dlang.org/group/digitalmars.D.ide), where you can leave your comments and suggestions. Bug reports can be filed to the D bugzilla database for Component VisualD. Have fun, Rainer Schuetze 1. https://github.com/dlang/visuald
What has the DMD compiler to do with a VS plugin that I am not using?
Apr 20
parent reply Meta <jared771 gmail.com> writes:
On Thursday, 20 April 2017 at 14:29:28 UTC, Jolly James wrote:
 What has the DMD compiler to do with a VS plugin that I am not 
 using?
You said in your original post "DMD installer only offers to install VS2013". This isn't the DMD installer but the Visual D installer that installs the plugin for the appropriate version of Visual Studio. As Mike said, though, you can also just edit sc.ini if you don't want to use Visual D.
Apr 20
parent reply Mike Parker <aldacron gmail.com> writes:
On Thursday, 20 April 2017 at 14:44:54 UTC, Meta wrote:
 On Thursday, 20 April 2017 at 14:29:28 UTC, Jolly James wrote:
 What has the DMD compiler to do with a VS plugin that I am not 
 using?
You said in your original post "DMD installer only offers to install VS2013". This isn't the DMD installer but the Visual D installer that installs the plugin for the appropriate version of Visual Studio. As Mike said, though, you can also just edit sc.ini if you don't want to use Visual D.
It actually does offer to install both VS 2013 and Visual D.
Apr 20
parent reply Meta <jared771 gmail.com> writes:
On Thursday, 20 April 2017 at 17:06:15 UTC, Mike Parker wrote:
 On Thursday, 20 April 2017 at 14:44:54 UTC, Meta wrote:
 On Thursday, 20 April 2017 at 14:29:28 UTC, Jolly James wrote:
 What has the DMD compiler to do with a VS plugin that I am 
 not using?
You said in your original post "DMD installer only offers to install VS2013". This isn't the DMD installer but the Visual D installer that installs the plugin for the appropriate version of Visual Studio. As Mike said, though, you can also just edit sc.ini if you don't want to use Visual D.
It actually does offer to install both VS 2013 and Visual D.
Wow, I did not know that. Seems a little excessive.
Apr 20
parent Jolly James <j.j jmail.com> writes:
On Thursday, 20 April 2017 at 17:10:05 UTC, Meta wrote:
 On Thursday, 20 April 2017 at 17:06:15 UTC, Mike Parker wrote:
 On Thursday, 20 April 2017 at 14:44:54 UTC, Meta wrote:
 On Thursday, 20 April 2017 at 14:29:28 UTC, Jolly James wrote:
 What has the DMD compiler to do with a VS plugin that I am 
 not using?
You said in your original post "DMD installer only offers to install VS2013". This isn't the DMD installer but the Visual D installer that installs the plugin for the appropriate version of Visual Studio. As Mike said, though, you can also just edit sc.ini if you don't want to use Visual D.
It actually does offer to install both VS 2013 and Visual D.
Wow, I did not know that. Seems a little excessive.
But anyway, that's how it is. By the way: installing VS2013 is only offered to you, if no compatible version (atm VS2015 or older) is found on your machine.
Apr 20
prev sibling parent Mike B Johnson <Mikey Ikes.com> writes:
On Thursday, 20 April 2017 at 00:13:29 UTC, Meta wrote:
 On Wednesday, 19 April 2017 at 20:47:51 UTC, Jolly James wrote:
 I cannot even fix it myself because DMD is looking for 
 "bin\link.exe". But with VS2017 the path would actually be 
 something like "\bin\HostX64\x64".
Please ignore Mike's answer. Visual D is maintained by Rainers Schuetze and is hosted here[1] on github. From the readme:
Why should I be ignored? Specially when I'm right?
Apr 20
prev sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Wednesday, 19 April 2017 at 20:47:51 UTC, Jolly James wrote:
 I cannot even fix it myself because DMD is looking for 
 "bin\link.exe". But with VS2017 the path would actually be 
 something like "\bin\HostX64\x64".
You can install the MS Build Tools 2015. DMD will work with that. You have two options to do so -- download the installer at the link below or run the VS 2017 installer and select it in the "Individual Components" tab. I'm on my MacBook now and can't recall exactly, but it may be listed as some thing like "Platform toolset v140". With both options, you have the added benefit that you can choose to use either the 2015 or 2017 build tools when compiling C & C++ projects in VS 2017 (and, I assume, Visual D). https://www.microsoft.com/en-us/download/details.aspx?id=48159
Apr 19
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Thursday, 20 April 2017 at 04:58:55 UTC, Mike Parker wrote:
 You can install the MS Build Tools 2015. DMD will work with 
 that. You have two options to do so -- download the installer 
 at the link below or run the VS 2017 installer and select it in 
 the "Individual Components" tab. I'm on my MacBook now and 
 can't recall exactly, but it may be listed as some thing like 
 "Platform toolset v140". With both options, you have the added 
 benefit that you can choose to use either the 2015 or 2017 
 build tools when compiling C & C++ projects in VS 2017  (and, I 
 assume, Visual D).

 https://www.microsoft.com/en-us/download/details.aspx?id=48159
I should add that Mike's suggestion to edit sc.ini should do the trick, but I find it convenient to have both toolsets installed.
Apr 19
parent Jolly James <j.j jmail.com> writes:
On Thursday, 20 April 2017 at 05:02:37 UTC, Mike Parker wrote:
 On Thursday, 20 April 2017 at 04:58:55 UTC, Mike Parker wrote:
 [...]
I should add that Mike's suggestion to edit sc.ini should do the trick, but I find it convenient to have both toolsets installed.
I'll give it a try, thanks to you and Mike J.! 👍🏻
Apr 20
prev sibling parent reply NotSpooky <zoteman94 gmail.com> writes:
On Thursday, 20 April 2017 at 04:58:55 UTC, Mike Parker wrote:
 You can install the MS Build Tools 2015. DMD will work with 
 that.
I'd be very nice if instead of offering to install VS, it offered the build tools. Also mentioning which installations are compatible so that the user can select the one he/she prefers. A lot of people are confused with this.
Apr 21
parent reply Mike Parker <aldacron gmail.com> writes:
On Friday, 21 April 2017 at 14:37:40 UTC, NotSpooky wrote:

 I'd be very nice if instead of offering to install VS, it 
 offered the build tools. Also mentioning which installations 
 are compatible so that the user can select the one he/she 
 prefers.

 A lot of people are confused with this.
There's no issue with compatibility. DMD is perfectly compatible with all recent versions of VS, including 2017. The issue is that 2017 has changed its directory tree and the DMD *installer* can't pick it up automatically. Now that the breakage is known, the next the installer will be updated and the next (hopefully) DMD release will include it.
Apr 21
parent reply NotSpooky <zoteman94 gmail.com> writes:
On Saturday, 22 April 2017 at 02:13:09 UTC, Mike Parker wrote:

 There's no issue with compatibility. DMD is perfectly 
 compatible with all recent versions of VS, including 2017. The 
 issue is that 2017 has changed its directory tree and the DMD 
 *installer* can't pick it up automatically. Now that the 
 breakage is known, the next the installer will be updated and 
 the next (hopefully) DMD release will include it.
Oh ok so it works with all of them. I don't have Windows so I don't know if this has changed, but last time I tried to install dmd there it asked to install VS 2013, I know some people that didn't want to install DMD because VS is huge, now that the build tools are an option maybe that's the one the installer should suggest (or maybe even suggest both).
Apr 21
next sibling parent reply evilrat <evilrat666 gmail.com> writes:
On Saturday, 22 April 2017 at 02:22:56 UTC, NotSpooky wrote:
 On Saturday, 22 April 2017 at 02:13:09 UTC, Mike Parker wrote:

 There's no issue with compatibility. DMD is perfectly 
 compatible with all recent versions of VS, including 2017. The 
 issue is that 2017 has changed its directory tree and the DMD 
 *installer* can't pick it up automatically. Now that the 
 breakage is known, the next the installer will be updated and 
 the next (hopefully) DMD release will include it.
Oh ok so it works with all of them. I don't have Windows so I don't know if this has changed, but last time I tried to install dmd there it asked to install VS 2013, I know some people that didn't want to install DMD because VS is huge, now that the build tools are an option maybe that's the one the installer should suggest (or maybe even suggest both).
That was discussed so many times... DMD don't need VS itself but rather compilers and tools, which is included in Windows SDK's, and takes just 4GB or so. But this is not an issue for anyone dealing with native development on Windows since all this stuff is neccessary. Also VS 2017 is much more modular now, so its now lighter than ever before. but of course for C++ (and D) you still need Windows SDK. IIRC D also can be used without VS or WinSDK at all, just forget about m32mscoff and x64 builds
Apr 21
parent reply Mike Parker <aldacron gmail.com> writes:
On Saturday, 22 April 2017 at 02:39:41 UTC, evilrat wrote:

 Also VS 2017 is much more modular now, so its now lighter than 
 ever before.
 but of course for C++ (and D) you still need Windows SDK.
The SDK stuff is installed with VS.
 IIRC D also can be used without VS or WinSDK at all, just 
 forget about m32mscoff and x64 builds
Yes, that is correct. But that comes with its own headaches.
Apr 21
parent reply Igor <stojkovic.igor gmail.com> writes:
On Saturday, 22 April 2017 at 02:46:30 UTC, Mike Parker wrote:
 On Saturday, 22 April 2017 at 02:39:41 UTC, evilrat wrote:

 Also VS 2017 is much more modular now, so its now lighter than 
 ever before.
 but of course for C++ (and D) you still need Windows SDK.
The SDK stuff is installed with VS.
 IIRC D also can be used without VS or WinSDK at all, just 
 forget about m32mscoff and x64 builds
Yes, that is correct. But that comes with its own headaches.
I had a working VS 2015 with VisualD and DMD. Today I uninstalled VS2015 and VisualD, then installed VS2017 and latest VisualD but when I create new D windows app and try to run it I get this error: Command Line set PATH=C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.10.25017\bin\HostX86\x86;C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE;C:\Program Files (x86)\Windows Kits\8.1\bin\x86;.\windows\bin;%PATH% dmd -g -debug -X -Xf"Win32\Debug\testapp.json" -deps="Win32\Debug\testapp.dep" -c -of"Win32\Debug\testapp.obj" winmain.d if errorlevel 1 goto reportError set LIB= echo. > D:\git\testapp\testapp\Win32\Debug\testapp.build.lnkarg echo "Win32\Debug\testapp.obj","Win32\Debug\testapp.exe","Win32\Debug\tes app.map",ole32.lib+ >> D:\git\testapp\testapp\Win32\Debug\testapp.build.lnkarg echo kernel32.lib+ >> D:\git\testapp\testapp\Win32\Debug\testapp.build.lnkarg echo user32.lib+ >> D:\git\testapp\testapp\Win32\Debug\testapp.build.lnkarg echo comctl32.lib+ >> D:\git\testapp\testapp\Win32\Debug\testapp.build.lnkarg echo comdlg32.lib+ >> D:\git\testapp\testapp\Win32\Debug\testapp.build.lnkarg echo user32.lib+ >> D:\git\testapp\testapp\Win32\Debug\testapp.build.lnkarg echo kernel32.lib/NOMAP/CO/NOI/DELEXE /SUBSYSTEM:WINDOWS >> D:\git\testapp\testapp\Win32\Debug\testapp.build.lnkarg "C:\Program Files (x86)\VisualD\pipedmd.exe" -deps Win32\Debug\testapp.lnkdep link.exe D:\git\testapp\testapp\Win32\Debug\testapp.build.lnkarg if errorlevel 1 goto reportError if not exist "Win32\Debug\testapp.exe" (echo "Win32\Debug\testapp.exe" not created! && goto reportError) goto noError :reportError echo Building Win32\Debug\testapp.exe failed! :noError Output Microsoft (R) Incremental Linker Version 14.10.25019.0 Copyright (C) Microsoft Corporation. All rights reserved. "Win32\Debug\testapp.obj,Win32\Debug\testapp.exe,Win32\Debug\testapp.map,ole32.lib+" kernel32.lib+ user32.lib+ comctl32.lib+ comdlg32.lib+ user32.lib+ kernel32.lib/NOMAP/CO/NOI/DELEXE /SUBSYSTEM:WINDOWS LINK : fatal error LNK1181: cannot open input file 'Win32\Debug\testapp.obj,Win32\Debug\testapp.exe,Win32\Debug\testapp.map,ole32.lib+' Building Win32\Debug\testapp.exe failed! I tried updating sc.ini to new paths but I still get this error. Can someone offer some advice?
Apr 30
parent reply Mike Parker <aldacron gmail.com> writes:
On Sunday, 30 April 2017 at 14:56:44 UTC, Igor wrote:

 I tried updating sc.ini to new paths but I still get this 
 error. Can someone offer some advice?
Which paths did you set?
Apr 30
parent reply Igor <stojkovic.igor gmail.com> writes:
On Sunday, 30 April 2017 at 15:53:07 UTC, Mike Parker wrote:
 On Sunday, 30 April 2017 at 14:56:44 UTC, Igor wrote:

 I tried updating sc.ini to new paths but I still get this 
 error. Can someone offer some advice?
Which paths did you set?
These are the ones I changed: VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.10.25017\ UCRTVersion=10.0.15063.0 LINKCMD=%VCINSTALLDIR%\bin\HostX64\x64\link.exe PATH=%PATH%;%VCINSTALLDIR%\bin\HostX64\x64 LIB=%LIB%;"%VCINSTALLDIR%\lib\x64" Same for x86 environment, except, of course I replaced x64 with x86 in the values. I should also mention that compiling using DUB works. It only doesn't work from VS.
Apr 30
next sibling parent reply John Chapman <johnch_atms hotmail.com> writes:
On Sunday, 30 April 2017 at 16:05:10 UTC, Igor wrote:
 On Sunday, 30 April 2017 at 15:53:07 UTC, Mike Parker wrote:
 On Sunday, 30 April 2017 at 14:56:44 UTC, Igor wrote:

 I tried updating sc.ini to new paths but I still get this 
 error. Can someone offer some advice?
Which paths did you set?
These are the ones I changed: VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.10.25017\ UCRTVersion=10.0.15063.0 LINKCMD=%VCINSTALLDIR%\bin\HostX64\x64\link.exe PATH=%PATH%;%VCINSTALLDIR%\bin\HostX64\x64 LIB=%LIB%;"%VCINSTALLDIR%\lib\x64" Same for x86 environment, except, of course I replaced x64 with x86 in the values. I should also mention that compiling using DUB works. It only doesn't work from VS.
Here are mine, if it helps: VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC WindowsSdkDir=C:\Program Files (x86)\Windows Kits\10 UniversalCRTSdkDir=C:\Program Files (x86)\Windows Kits\10 UCRTVersion=10.0.15063.0 LINKCMD=%VCINSTALLDIR%\Tools\MSVC\14.10.25017\bin\HostX64\x64\link.exe PATH=%PATH%;%VCINSTALLDIR%\Tools\MSVC\14.10.25017\bin\HostX64\x64 LIB=%LIB%;"%VCINSTALLDIR%\Tools\MSVC\14.10.25017\lib\x64" LIB=%LIB%;"%UniversalCRTSdkDir%\Lib\%UCRTVersion%\um\x64" LIB=%LIB%;"%UniversalCRTSdkDir%\Lib\%UCRTVersion%\ucrt\x64"
Apr 30
parent reply Igor <stojkovic.igor gmail.com> writes:
On Sunday, 30 April 2017 at 16:31:13 UTC, John Chapman wrote:
 Here are mine, if it helps:
I tried but still the same problem. I also tried reinstalling VisualD after changing sc.ini in DMD but that didn't help either.
Apr 30
parent Mike B Johnson <Mikey Ikes.com> writes:
On Sunday, 30 April 2017 at 16:52:52 UTC, Igor wrote:
 On Sunday, 30 April 2017 at 16:31:13 UTC, John Chapman wrote:
 Here are mine, if it helps:
I tried but still the same problem. I also tried reinstalling VisualD after changing sc.ini in DMD but that didn't help either.
You are going to have to figure it out. Visual Studio does some stupid path stuff that doesn't make any sense really(seems like it could do a much better job). What you could do is: 1. Create a "library" folder. e.g., C:\DMD\Libs\Coff\x86 C:\DMD\Libs\Coff\x64 C:\DMD\Libs\OMF\x86 C:\DMD\Libs\OMF\x64 <- not used as there is no x64 omf 2. Point sc.ini to these. 3. Copy the lib files from the VS or win SDK to these folders. 4. Do the magic that it takes to get it to work(which is finding the right libs that are needed, using procmon to see where dmd is looking, etc). This involves building and checking the errors then trying to resolve them. Once done, you have a solid set of libs that once works, won't change. When you update VS you can update the libs here and there but it is not needed very often. Sometimes you'll have to pull in different libs from different versions and such. DMD comes with the some libs that you can use for x86. Once you get it working you shouldn't have to mess with it much. If you accidentally overwrite sc.ini(which is ridiculous that it does this on install), you know EXACTLY where the libs are and don't have to go hunt for them again. If you want, you can use junctions instead of copying but these might need to be updated again when VS changes.
Apr 30
prev sibling parent reply evilrat <evilrat666 gmail.com> writes:
On Sunday, 30 April 2017 at 16:05:10 UTC, Igor wrote:
 I should also mention that compiling using DUB works. It only 
 doesn't work from VS.
Check your VisualD settings and make sure it has DMD path set up. See under Tools>Options>Projects and solutions>Visual D Settings
Apr 30
parent reply Igor <stojkovic.igor gmail.com> writes:
On Monday, 1 May 2017 at 01:54:30 UTC, evilrat wrote:
 On Sunday, 30 April 2017 at 16:05:10 UTC, Igor wrote:
 I should also mention that compiling using DUB works. It only 
 doesn't work from VS.
Check your VisualD settings and make sure it has DMD path set up. See under Tools>Options>Projects and solutions>Visual D Settings
That was it. It didn't occur to me that this was the problem because I payed closed attention during VisualD installation and saw it properly recognized where DMD was installed but for some reason the path wasn't set in Options. Once I did set it, compile and build worked. Thanks evilrat! So in conclusion it seems the problem is in VisualD installation which doesn't set the path properly even though it recognizes where DMD is installed. Hope the author takes a look at this problem so beginners wanting to try D don't give up on a problem like this.
May 01
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 01.05.2017 10:03, Igor wrote:
 On Monday, 1 May 2017 at 01:54:30 UTC, evilrat wrote:
 On Sunday, 30 April 2017 at 16:05:10 UTC, Igor wrote:
 I should also mention that compiling using DUB works. It only doesn't
 work from VS.
Check your VisualD settings and make sure it has DMD path set up. See under Tools>Options>Projects and solutions>Visual D Settings
That was it. It didn't occur to me that this was the problem because I payed closed attention during VisualD installation and saw it properly recognized where DMD was installed but for some reason the path wasn't set in Options. Once I did set it, compile and build worked. Thanks evilrat! So in conclusion it seems the problem is in VisualD installation which doesn't set the path properly even though it recognizes where DMD is installed. Hope the author takes a look at this problem so beginners wanting to try D don't give up on a problem like this.
VS 2017 uses a "private" registry that the Visual D installer doesn't have access to. I'll change the registry location in the next release. Please note that the next dmd installer will also detect VS2017 and setup directories correctly in sc.ini: https://github.com/dlang/installer/pull/227
May 01
parent Igor <stojkovic.igor gmail.com> writes:
On Monday, 1 May 2017 at 18:30:53 UTC, Rainer Schuetze wrote:
 VS 2017 uses a "private" registry that the Visual D installer 
 doesn't have access to. I'll change the registry location in 
 the next release.

 Please note that the next dmd installer will also detect VS2017 
 and setup directories correctly in sc.ini: 
 https://github.com/dlang/installer/pull/227
That is great news! Thanks for quick response.
May 01
prev sibling parent Mike Parker <aldacron gmail.com> writes:
On Saturday, 22 April 2017 at 02:22:56 UTC, NotSpooky wrote:
 I don't have Windows so I don't know if this has changed, but 
 last time I tried to install dmd there it asked to install VS 
 2013, I know some people that didn't want to install DMD 
 because VS is huge, now that the build tools are an option 
 maybe that's the one the installer should suggest (or maybe 
 even suggest both).
Realistically, anyone who does serious Windows development is likely going to have Visual Studio installed anyway. The build tools are fine for the rest, but anyone wanting to use Visual D will need VS. Since the installer offers to install Visual D, it only makes sense to offer to install VS. It might be good to offer a choice between the build tools and VS, or at the very least offer links to the build tools and more recent versions of VS to be installed manually.
Apr 21