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?

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.

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"

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.

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.

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

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.

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

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.

On Monday, 1 May 2017 at 18:30:53 UTC, Rainer Schuetze wrote:
> 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

I really like this philosophy:
"It does not work, a fix is available, but it won't be rolled out (for now). Who cares about those who cannot use the broken software?"