www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ide - VisualD latest version (v0.49.1) regression under VS2015

reply ShadoLight <ettienne.gilbert gmail.com> writes:
Hi,

I updated my VisualD to latest version v0.49.1 under VS Pro 2015. 
During the update I left the default options as is, which 
includes the update/installation of mago, MSBuild support, etc.

Installation completed successfully but afterwards VS would 
launch, but with some errors (referring to packages updating, etc 
- not specifically for VisualD so I was not sure if this was 
related to VisualD). Once it started I could launch the wizard to 
create projects in both C++ and D, but then for both it fails 
with the same error. For C++ it is:

"Unable to read the project file "abc.vcxproj". C:\Program 
Files(x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Platforms\Win32\ImportBefore\De
ault\d.props(10,9): the expression "System.String[].GetValue(1)" cannot be
evaluated. Index was outside the bounds of the array."

Note that this path "C:\Program 
Files(x86)\MSBuild\Microsoft.Cpp\.." does not exist on my machine.

I tried to uninstall VisualD, but this actually made the problem 
worse, as afterwards VS2015 could not shut down as a modal error 
dialog kept popping up.

Afterwards I uninstalled all add_ons that had their own 
uninstallers, but this had no effect. I eventually had to 
uninstall & re-install VS2015 itself to get VS2015 to behave 
(using 
https://github.com/Microsoft/VisualStudioUninstaller/releases as 
it was impossible to get to the uninstall menu).

I have now retried with my newly installed fresh VS2015 Pro  - 
before the installation of VisualD Visual C++ project 
creation/building worked fine, but after installation of 
Visual,the same problems are back.

Anyone else experienced this?

Rainer, any advice? I am running Win7 x64 but my VS2015 is x32 
bit.
Apr 25 2019
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 25/04/2019 15:36, ShadoLight wrote:

 Hi,
 
 I updated my VisualD to latest version v0.49.1 under VS Pro 2015. During
 the update I left the default options as is, which includes the
 update/installation of mago, MSBuild support, etc.
 
 Installation completed successfully but afterwards VS would launch, but
 with some errors (referring to packages updating, etc - not specifically
 for VisualD so I was not sure if this was related to VisualD). Once it
 started I could launch the wizard to create projects in both C++ and D,
 but then for both it fails with the same error. For C++ it is:
 
 "Unable to read the project file "abc.vcxproj". C:\Program
 Files(x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Platforms\Win32\ImportBefore\Default\d.props(10,9):
 the expression "System.String[].GetValue(1)" cannot be evaluated. Index
 was outside the bounds of the array."
 
 Note that this path "C:\Program Files(x86)\MSBuild\Microsoft.Cpp\.."
 does not exist on my machine.
 
 I tried to uninstall VisualD, but this actually made the problem worse,
 as afterwards VS2015 could not shut down as a modal error dialog kept
 popping up.
 
 Afterwards I uninstalled all add_ons that had their own uninstallers,
 but this had no effect. I eventually had to uninstall & re-install
 VS2015 itself to get VS2015 to behave (using
 https://github.com/Microsoft/VisualStudioUninstaller/releases as it was
 impossible to get to the uninstall menu).
 
 I have now retried with my newly installed fresh VS2015 Pro  - before
 the installation of VisualD Visual C++ project creation/building worked
 fine, but after installation of Visual,the same problems are back.
 
 Anyone else experienced this?
 
 Rainer, any advice? I am running Win7 x64 but my VS2015 is x32 bit.


Sorry to hear that Visual D has caused so many troubles.

The error message happens because I didn't expect VS2015 not to know
about variable MSBuildVersion. You can replace the file with the error
with this version:
https://github.com/rainers/visuald/blob/bd48b5d210a3c742fe76adbd3c69f03363c47779/msbuild/ImportBefore/Default/d.props

I can also reproduce the problems with VS2015 after installation. It can
be corrected by repairing or modifying (much faster) the VS2015
installation afterwards, even with Visual D 0.49.1 still installed.
Strangely, this happens with older Visual D versions, too. I haven't
experienced that before, I'm investigating...
Apr 25 2019
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 25/04/2019 21:56, Rainer Schuetze wrote:

 I can also reproduce the problems with VS2015 after installation. It can
 be corrected by repairing or modifying (much faster) the VS2015
 installation afterwards, even with Visual D 0.49.1 still installed.
 Strangely, this happens with older Visual D versions, too. I haven't
 experienced that before, I'm investigating...
 


Results so far:

- modifying the VS2015 installation sometimes seems to work, but I've
seen it going back to reporting errors with the next start of VS, too

- any new (un)installation brings back the bad behavior (even with
completely unrelated programs)

- repairing the VS installation seems to help, but also probably takes
longer than just reinstalling

- installing 0.49.1 with the correct d.props file, the issue does not
appear, only after uninstall

- when uninstalling 0.49.0, it happens, too.

- it doesn't happen with 0.48.0, also after uninstall

The major difference between 0.48.0 and 0.49.0 that I'm aware of is that
I've switched to VS2019 as the build environment. Maybe this causes some
issues with the .NET framework.
Apr 26 2019
parent reply ShadoLight <ettienne.gilbert gmail.com> writes:
On Friday, 26 April 2019 at 18:25:02 UTC, Rainer Schuetze wrote:

 Results so far:


[snip]


This being the case I think I will stick with 0.48.0 for now 
then. At least until there is a more fail-safe way to uninstall 
0.49.x without the behaviour reappearing in VS.

Thanks anyway for all your effort in researching the issue.



 Apr 26 2019



  parent reply Rainer Schuetze <r.sagitario gmx.de>  writes:


On 27/04/2019 01:57, ShadoLight wrote:

 On Friday, 26 April 2019 at 18:25:02 UTC, Rainer Schuetze wrote:

 Results so far:


 [snip]


 
 This being the case I think I will stick with 0.48.0 for now then. At
 least until there is a more fail-safe way to uninstall 0.49.x without
 the behaviour reappearing in VS.
 
 Thanks anyway for all your effort in researching the issue.


After a long series of trial and error, I've hopefully figured it out:
even if some additional actions are taken to tell VS that extensions
have changed, it doesn't automatically updates its caches.
It seems to be similar to
https://developercommunity.visualstudio.com/content/problem/66084/mef-cache-do-not-updates-when-assembly-version-cha.html
which has been fixed for VS2017.

A new installer with a workaround is available here:
https://github.com/dlang/visuald/releases/tag/v0.49.2



 Apr 28 2019



  parent reply ShadoLight <ettienne.gilbert gmail.com>  writes:


On Sunday, 28 April 2019 at 08:24:38 UTC, Rainer Schuetze wrote:

 On 27/04/2019 01:57, ShadoLight wrote:

 On Friday, 26 April 2019 at 18:25:02 UTC, Rainer Schuetze 
 wrote:

 Results so far:


 [snip]


 
 This being the case I think I will stick with 0.48.0 for now 
 then. At least until there is a more fail-safe way to 
 uninstall 0.49.x without the behaviour reappearing in VS.
 
 Thanks anyway for all your effort in researching the issue.


 After a long series of trial and error, I've hopefully figured 
 it out:
 even if some additional actions are taken to tell VS that 
 extensions
 have changed, it doesn't automatically updates its caches.
 It seems to be similar to
 https://developercommunity.visualstudio.com/content/problem/66084/mef-cache-do-not-updates-when-assembly-version-cha.html
 which has been fixed for VS2017.

 A new installer with a workaround is available here: 
 https://github.com/dlang/visuald/releases/tag/v0.49.2


Thanks Rainer, I will update and test. Very much appreciated.

Regarding VS2105 vs VS2017. At home I can use VS2017 Community 
edition, but at work I can only use VS2015 (Pro version) atm. In 
fact, I don't use D for work at all, I just installed it so that 
I can dabble with my own projects in it when I have some free 
time.



 Apr 29 2019



  parent reply ShadoLight <ettienne.gilbert gmail.com>  writes:


I have been toying with Dub generated VisualD projects vs Dub 
generated projects, and ran into some linking issues between x86 
vs x64 projects.

This is out-of-the-box experience on a newly installed VS2015 
with DMD v2.086.0 and bundled Dub v1.15.0 and VisualD v0.49.2. 
Note I'm only using COFF object format, so this is what newbies 
will experience if they have the same need.

1. Creation of x32 project using 'dub init abc32' and all default 
params: Succeeds
- Building using 'dub build  --arch=x86_mscoff': Build succeeds. 
Using --verbose option I can see dub calls dmd passing -m32mscoff.
- Creation of VisualD project with 'dub generate visuald': 
Succeeds
-- VisualD project created is x64 though. Command line shows -m64 
passed. (I reported this on dub forums).
-- Note only debug configuraiton of VisualD project is created
-- Builing from inside VS2015 fails with the same error as 
described for x64 architecture as described below.

2. Creation of x32project using VisualD 'New|Project...|Visual D 
Win32 Application|Console Application|x86|DMD': Succeeds
- Note I'm deselecting OMF object format, so building COFF format.
- Building from inside VS2015: Build fails.
-- For option: LINK (using C Runtime): Dynamic Release MSCVRT)
--- LINK : fatal error LNK1181: cannot open input file 
'user32.lib'
-- LINK (using C Runtime): Static Release LIBCMT)
--- LINK : fatal error LNK1181: cannot open input file 
'user32.lib'

Investigating I found that the [Environment32] and 
[Environment64] sections sc.ini file has not been updated to 
reflect the new directory structure inside 
c:\D\dmd2\windows\lib64\ as well as 
c:\D\dmd2\windows\lib32mscoff\.

Modifying these sections to...
[Environment64]
LIB=% P%\..\lib64;% P%\..\lib64\mingw;
DFLAGS=%DFLAGS% -L/OPT:NOICF

[Environment32mscoff]
LIB=% P%\..\lib32mscoff;% P%\..\lib32mscoff\mingw
DFLAGS=%DFLAGS% -L/OPT:NOICF

Now the VisualD x32 COFF project builds/runs successfully.

However, this does not solve the issue with x64 applications.

3. Creation of x32project using VisualD 'New|Project...|Visual D 
Win32 Application|Console Application|x64|DMD': Succeeds
- Building from inside VS2015: Build fails.
-- LINK (using C Runtime): Dynamic Release MSCVRT)
--- msvcrtd.lib(utility_desktop.obj) : error LNK2019: unresolved 
external symbol __imp_RtlLookupFunctionEntry referenced in 
function __scrt_fastfail
--- msvcrtd.lib(gs_report.obj) : error LNK2001: unresolved 
external symbol __imp_RtlLookupFunctionEntry
--- msvcrtd.lib(utility_desktop.obj) : error LNK2019: unresolved 
external symbol __imp_RtlVirtualUnwind referenced in function 
__scrt_fastfail
--- msvcrtd.lib(gs_report.obj) : error LNK2001: unresolved 
external symbol __imp_RtlVirtualUnwind
-- LINK (using C Runtime): Static Release LIBCMT)
--- libcmtd.lib(utility_desktop.obj) : error LNK2019: unresolved 
external symbol __imp_RtlLookupFunctionEntry referenced in 
function __scrt_fastfail
--- libcmtd.lib(gs_report.obj) : error LNK2001: unresolved 
external symbol __imp_RtlLookupFunctionEntry
--- libucrtd.lib(invalid_parameter.obj) : error LNK2001: 
unresolved external symbol __imp_RtlLookupFunctionEntry
--- libvcruntimed.lib(trnsctrl.obj) : error LNK2001: unresolved 
external symbol __imp_RtlLookupFunctionEntry
--- libcmtd.lib(utility_desktop.obj) : error LNK2019: unresolved 
external symbol __imp_RtlVirtualUnwind referenced in function 
__scrt_fastfail
--- libcmtd.lib(gs_report.obj) : error LNK2001: unresolved 
external symbol __imp_RtlVirtualUnwind
--- libucrtd.lib(invalid_parameter.obj) : error LNK2001: 
unresolved external symbol __imp_RtlVirtualUnwind
--- libvcruntimed.lib(_chandler_.obj) : error LNK2019: unresolved 
external symbol __imp_RtlUnwindEx referenced in function 
__C_specific_handler
--- libvcruntimed.lib(trnsctrl.obj) : error LNK2001: unresolved 
external symbol __imp_RtlUnwindEx
--- libvcruntimed.lib(_jmpuwind_.obj) : error LNK2019: unresolved 
external symbol RtlUnwindEx referenced in function _local_unwind
--- libvcruntimed.lib(frame.obj) : error LNK2019: unresolved 
external symbol __imp_RtlPcToFileHeader referenced in function 
__CxxExceptionFilter
--- libvcruntimed.lib(throw.obj) : error LNK2001: unresolved 
external symbol __imp_RtlPcToFileHeader

This makes me think it is finding the wrong msvcrtd.lib or 
libcmtd.lib. I can see there are x32 and x64 versions of 
msvcrt100.lib under c:\D\dmd2\windows\lib32mscoff\mingw\ and 
c:\D\dmd2\windows\lib64\mingw\ (but only release versions). But I 
cannot find any libcmt*.lib files under c:\D\dmd2\windows\*.

If I try to add them manually I get a bunch of of "...already 
defined in msvcrt100.lib(msvcr100.dll)". I am anyway sure it 
should not be necessary to add the C runtime libs manually to the 
project.

How do I get the x64 versions to link using VS2015? (I am pretty 
sure this was working in earlier versions of VisualD).

Also, note you have a typo in VisualD GUI under LINK C Runtime 
drop : Dynamic Debug/Release MSCVRT) - it should be MSVCRT, not 
MSCVRT.



 May 07 2019



  parent reply Rainer Schuetze <r.sagitario gmx.de>  writes:


Sorry for the late reply, I've been travelling and been busy otherwise.

On 07/05/2019 14:15, ShadoLight wrote:

 I have been toying with Dub generated VisualD projects vs Dub generated
 projects, and ran into some linking issues between x86 vs x64 projects.
 
 This is out-of-the-box experience on a newly installed VS2015 with DMD
 v2.086.0 and bundled Dub v1.15.0 and VisualD v0.49.2. Note I'm only
 using COFF object format, so this is what newbies will experience if
 they have the same need.
 
 1. Creation of x32 project using 'dub init abc32' and all default
 params: Succeeds
 - Building using 'dub build  --arch=x86_mscoff': Build succeeds. Using
 --verbose option I can see dub calls dmd passing -m32mscoff.
 - Creation of VisualD project with 'dub generate visuald': Succeeds
 -- VisualD project created is x64 though. Command line shows -m64
 passed. (I reported this on dub forums).
 -- Note only debug configuraiton of VisualD project is created


Yeah, dub projects only generate a single configuration, that's pretty lame.


 -- Builing from inside VS2015 fails with the same error as described for
 x64 architecture as described below.
 
 2. Creation of x32project using VisualD 'New|Project...|Visual D Win32
 Application|Console Application|x86|DMD': Succeeds
 - Note I'm deselecting OMF object format, so building COFF format.
 - Building from inside VS2015: Build fails.
 -- For option: LINK (using C Runtime): Dynamic Release MSCVRT)
 --- LINK : fatal error LNK1181: cannot open input file 'user32.lib'
 -- LINK (using C Runtime): Static Release LIBCMT)
 --- LINK : fatal error LNK1181: cannot open input file 'user32.lib'
 
 Investigating I found that the [Environment32] and [Environment64]
 sections sc.ini file has not been updated to reflect the new directory
 structure inside c:\D\dmd2\windows\lib64\ as well as
 c:\D\dmd2\windows\lib32mscoff\.
 
 Modifying these sections to...
 [Environment64]
 LIB=% P%\..\lib64;% P%\..\lib64\mingw;
 DFLAGS=%DFLAGS% -L/OPT:NOICF
 
 [Environment32mscoff]
 LIB=% P%\..\lib32mscoff;% P%\..\lib32mscoff\mingw
 DFLAGS=%DFLAGS% -L/OPT:NOICF


You should not add these library paths, these are automatic fallback for
dmd if it doesn't find a VS installation.

Instead you should install any Windows SDK (e.g. the one that comes with
the VS installer). I've recently updated the installation documentation
to that respect.


 
 Now the VisualD x32 COFF project builds/runs successfully.



 
 However, this does not solve the issue with x64 applications.
 
 3. Creation of x32project using VisualD 'New|Project...|Visual D Win32
 Application|Console Application|x64|DMD': Succeeds
 - Building from inside VS2015: Build fails.
 -- LINK (using C Runtime): Dynamic Release MSCVRT)
 --- msvcrtd.lib(utility_desktop.obj) : error LNK2019: unresolved
 external symbol __imp_RtlLookupFunctionEntry referenced in function
 __scrt_fastfail
 --- msvcrtd.lib(gs_report.obj) : error LNK2001: unresolved external
 symbol __imp_RtlLookupFunctionEntry
 --- msvcrtd.lib(utility_desktop.obj) : error LNK2019: unresolved
 external symbol __imp_RtlVirtualUnwind referenced in function
 __scrt_fastfail
 --- msvcrtd.lib(gs_report.obj) : error LNK2001: unresolved external
 symbol __imp_RtlVirtualUnwind
 -- LINK (using C Runtime): Static Release LIBCMT)
 --- libcmtd.lib(utility_desktop.obj) : error LNK2019: unresolved
 external symbol __imp_RtlLookupFunctionEntry referenced in function
 __scrt_fastfail
 --- libcmtd.lib(gs_report.obj) : error LNK2001: unresolved external
 symbol __imp_RtlLookupFunctionEntry
 --- libucrtd.lib(invalid_parameter.obj) : error LNK2001: unresolved
 external symbol __imp_RtlLookupFunctionEntry
 --- libvcruntimed.lib(trnsctrl.obj) : error LNK2001: unresolved external
 symbol __imp_RtlLookupFunctionEntry
 --- libcmtd.lib(utility_desktop.obj) : error LNK2019: unresolved
 external symbol __imp_RtlVirtualUnwind referenced in function
 __scrt_fastfail
 --- libcmtd.lib(gs_report.obj) : error LNK2001: unresolved external
 symbol __imp_RtlVirtualUnwind
 --- libucrtd.lib(invalid_parameter.obj) : error LNK2001: unresolved
 external symbol __imp_RtlVirtualUnwind
 --- libvcruntimed.lib(_chandler_.obj) : error LNK2019: unresolved
 external symbol __imp_RtlUnwindEx referenced in function
 __C_specific_handler
 --- libvcruntimed.lib(trnsctrl.obj) : error LNK2001: unresolved external
 symbol __imp_RtlUnwindEx
 --- libvcruntimed.lib(_jmpuwind_.obj) : error LNK2019: unresolved
 external symbol RtlUnwindEx referenced in function _local_unwind
 --- libvcruntimed.lib(frame.obj) : error LNK2019: unresolved external
 symbol __imp_RtlPcToFileHeader referenced in function __CxxExceptionFilter
 --- libvcruntimed.lib(throw.obj) : error LNK2001: unresolved external
 symbol __imp_RtlPcToFileHeader


Again, wrong libraries. The import libs in the mingw folder are for the
VS2010 runtime, not anything newer.


 This makes me think it is finding the wrong msvcrtd.lib or libcmtd.lib.
 I can see there are x32 and x64 versions of msvcrt100.lib under
 c:\D\dmd2\windows\lib32mscoff\mingw\ and c:\D\dmd2\windows\lib64\mingw\
 (but only release versions). But I cannot find any libcmt*.lib files
 under c:\D\dmd2\windows\*.
 
 If I try to add them manually I get a bunch of of "...already defined in
 msvcrt100.lib(msvcr100.dll)". I am anyway sure it should not be
 necessary to add the C runtime libs manually to the project.
 
 How do I get the x64 versions to link using VS2015? (I am pretty sure
 this was working in earlier versions of VisualD).


I guess you had a Windows SDK installed then.


 
 Also, note you have a typo in VisualD GUI under LINK C Runtime drop :
 Dynamic Debug/Release MSCVRT) - it should be MSVCRT, not MSCVRT.


Thanks, fixed.



 May 15 2019



 next sibling parent reply ShadoLight <ettienne.gilbert gmail.com>  writes:


On Thursday, 16 May 2019 at 06:31:10 UTC, Rainer Schuetze wrote:

 Sorry for the late reply, I've been travelling and been busy 
 otherwise.


Np. I fully appreciate it was D Conf happening over the same time 
period.


[snip]


 You should not add these library paths, these are automatic 
 fallback for dmd if it doesn't find a VS installation.


Ok, noted.


 Instead you should install any Windows SDK (e.g. the one that 
 comes with the VS installer). I've recently updated the 
 installation documentation to that respect.


I actually do have the VS SDK installed - my VS2015 
(Professional) shows installed under 'Universal Windows App 
Development Tools' that 'Tools (1.4.1) and Windows 10 SDK 
(10.0.1393)' is installed. I did not install the 2 earlier 
Windows 10 SDK versions also available on the VS2015 media..

I wonder ... I've recently uninstalled VS2010 and installed 
VS2015.... maybe I have some legacy VS2010 artifacts 
(environmental vars, paths, etc) lying around, which are causing 
problems for DMD. I'll have a look.

[snip]


 Again, wrong libraries. The import libs in the mingw folder are 
 for the VS2010 runtime, not anything newer.


Ok, noted.


 I guess you had a Windows SDK installed then.


Yes, but I uninstalled the previous one along with VS2010. And 
then reinstalled the later version bundled with VS2015.

Once again, thanks for the assistance - as well as for VisualD!



 May 16 2019



  parent reply Alex <AJ gmail.com>  writes:


On Thursday, 16 May 2019 at 21:06:02 UTC, ShadoLight wrote:

 On Thursday, 16 May 2019 at 06:31:10 UTC, Rainer Schuetze wrote:

 Sorry for the late reply, I've been travelling and been busy 
 otherwise.


 Np. I fully appreciate it was D Conf happening over the same 
 time period.


 [snip]


 You should not add these library paths, these are automatic 
 fallback for dmd if it doesn't find a VS installation.


 Ok, noted.


 Instead you should install any Windows SDK (e.g. the one that 
 comes with the VS installer). I've recently updated the 
 installation documentation to that respect.


 I actually do have the VS SDK installed - my VS2015 
 (Professional) shows installed under 'Universal Windows App 
 Development Tools' that 'Tools (1.4.1) and Windows 10 SDK 
 (10.0.1393)' is installed. I did not install the 2 earlier 
 Windows 10 SDK versions also available on the VS2015 media..

 I wonder ... I've recently uninstalled VS2010 and installed 
 VS2015.... maybe I have some legacy VS2010 artifacts 
 (environmental vars, paths, etc) lying around, which are 
 causing problems for DMD. I'll have a look.

 [snip]


 Again, wrong libraries. The import libs in the mingw folder 
 are for the VS2010 runtime, not anything newer.


 Ok, noted.


 I guess you had a Windows SDK installed then.


 Yes, but I uninstalled the previous one along with VS2010. And 
 then reinstalled the later version bundled with VS2015.

 Once again, thanks for the assistance - as well as for VisualD!


I recently installed 2019 and everything worked. I uninstalled 
everything I had related to VS before that.

You can use something like process monitor to figure out what 
files it is looking for. Usually this is a path issue. I had it 
once.

You could uninstall everything VS related if it's not too much 
trouble and start from scratch and try to get a very basic 
working case then add back in whatever else you need until it 
breaks.

What I've noticed is that VS loves to install a bunch of SDK's 
and eventually are not needed and this can cause some problems. I 
saved about 25GB of space uninstalling all the built up junk over 
the years even with VS2019 installed(it was 50GB total).



 May 16 2019



  parent  ShadoLight <ettienne.gilbert gmail.com>  writes:


On Friday, 17 May 2019 at 01:00:38 UTC, Alex wrote:

 On Thursday, 16 May 2019 at 21:06:02 UTC, ShadoLight wrote:


[snip]

 You can use something like process monitor to figure out what 
 files it is looking for. Usually this is a path issue. I had it 
 once.


Yep, it seems to be a path issue... and an issue with my y 
Windows SDK version.



 May 22 2019



prev sibling  parent reply ShadoLight <ettienne.gilbert gmail.com>  writes:


On Thursday, 16 May 2019 at 06:31:10 UTC, Rainer Schuetze wrote:
[snip]

 You should not add these library paths, these are automatic 
 fallback for dmd if it doesn't find a VS installation.


OK, original state of sc.ini restored.


 Instead you should install any Windows SDK (e.g. the one that 
 comes with the VS installer). I've recently updated the 
 installation documentation to that respect.


I do in fact have multiple Windows SDKs installed - probably from 
earlier versions of VS + SDKs I had installed. Under 'c:\Program 
Files (x86)\Windows Kits\' I still have folders for:
- 8.0
- 8.1
- 10
- NETFXSDK

The VS uninstall feature does not uninstall the SDKs, so I still 
have a number of previous SDK versions.

If I revert the original state of sc.ini I still have the issue 
that it cannot find 'user32.lib' and fails with a linking error.

As mentioned in my previous post there are 'user32.lib' versions 
under 'c:\D\dmd2\windows\lib64\mingw\' and  
'c:\D\dmd2\windows\lib32mscoff\mingw\', but ok, as you indicated, 
these are for VS2010 and I should link to the versions under my 
Windows SDK if I have a later version of VS installed.

My *current* set of Library search paths (Tools -> Options -> 
VisualD Settings -> DMD -> x64) shows:
$(VCINSTALLDIR)lib\amd64
$(UniversalCRTSdkDir)Lib\$(UCRTVersion)\ucrt\x64
$(UniversalCRTSdkDir)Lib\$(UCRTVersion)\ucrt\arm64
$(DMDInstallDir)windows\bin

There is no 'user32.lib' present under $(VCINSTALLDIR)lib\amd64 
and the
"$(UniversalCRTSdkDir)Lib\$(UCRTVersion)\ucrt\x64" resolve to...
$(UniversalCRTSdkDir) = C:\Program Files (x86)\Windows Kits\10\
$(UCRTVersion)= 10.0.10240.0
  .... eg. the latest Windows SDK installed (v10).

There is no 'user32.lib' present here either (c:\Program Files 
(x86)\Windows Kits\10\Lib\10.0.10240.0\ucrt\x64\).

OTOH, there is a 'user32.lib' present in c:\Program Files 
(x86)\Windows Kits\8.1\Lib\winv6.3\um\x64\ i.e. under Windows SDK 
8.1. If I add this path to the Library search paths the app now 
successfully links - and my very trivial test program runs fine.

Interestingly, I found I only have 'user32.lib' present in 
Windows SDK 8.1, but in neither of 8.0 or 10.0.

The exact same story also applies to x32 COFF libs. At this point 
I can easily add the SDK 8.1 to the Library search seach paths 
for x64 and x32COFF, but is it a good idea to mix SDK 10 and 8.1 
like this? The search order will link to libs from 10 if they are 
present in SDK 10, and only use libs from SDK 8.1 if they are not 
present in SDK 10.

I am rather going to change my Lib search paths to only use the 
SDK 8.1, but are these known restrictions with SDK 8.0. and 10.0? 
Or is there something wrong with my SDK 10 installation? (I have 
2 versions of SDK 10, and both show very few libs compared to 8.1)



 May 22 2019



 next sibling parent reply ShadoLight <ettienne.gilbert gmail.com>  writes:


On Wednesday, 22 May 2019 at 08:42:21 UTC, ShadoLight wrote:

 On Thursday, 16 May 2019 at 06:31:10 UTC, Rainer Schuetze wrote:
 [snip]

 You should not add these library paths, these are automatic 
 fallback for dmd if it doesn't find a VS installation.


 OK, original state of sc.ini restored.


 Instead you should install any Windows SDK (e.g. the one that 
 comes with the VS installer). I've recently updated the 
 installation documentation to that respect.


 I do in fact have multiple Windows SDKs installed - probably 
 from earlier versions of VS + SDKs I had installed. Under 
 'c:\Program Files (x86)\Windows Kits\' I still have folders for:
 - 8.0
 - 8.1
 - 10
 - NETFXSDK

 The VS uninstall feature does not uninstall the SDKs, so I 
 still have a number of previous SDK versions.

 If I revert the original state of sc.ini I still have the issue 
 that it cannot find 'user32.lib' and fails with a linking error.

 As mentioned in my previous post there are 'user32.lib' 
 versions under 'c:\D\dmd2\windows\lib64\mingw\' and  
 'c:\D\dmd2\windows\lib32mscoff\mingw\', but ok, as you 
 indicated, these are for VS2010 and I should link to the 
 versions under my Windows SDK if I have a later version of VS 
 installed.

 My *current* set of Library search paths (Tools -> Options -> 
 VisualD Settings -> DMD -> x64) shows:
 $(VCINSTALLDIR)lib\amd64
 $(UniversalCRTSdkDir)Lib\$(UCRTVersion)\ucrt\x64
 $(UniversalCRTSdkDir)Lib\$(UCRTVersion)\ucrt\arm64
 $(DMDInstallDir)windows\bin

 There is no 'user32.lib' present under $(VCINSTALLDIR)lib\amd64 
 and the
 "$(UniversalCRTSdkDir)Lib\$(UCRTVersion)\ucrt\x64" resolve to...
 $(UniversalCRTSdkDir) = C:\Program Files (x86)\Windows Kits\10\
 $(UCRTVersion)= 10.0.10240.0
  .... eg. the latest Windows SDK installed (v10).

 There is no 'user32.lib' present here either (c:\Program Files 
 (x86)\Windows Kits\10\Lib\10.0.10240.0\ucrt\x64\).

 OTOH, there is a 'user32.lib' present in c:\Program Files 
 (x86)\Windows Kits\8.1\Lib\winv6.3\um\x64\ i.e. under Windows 
 SDK 8.1. If I add this path to the Library search paths the app 
 now successfully links - and my very trivial test program runs 
 fine.

 Interestingly, I found I only have 'user32.lib' present in 
 Windows SDK 8.1, but in neither of 8.0 or 10.0.

 The exact same story also applies to x32 COFF libs. At this 
 point I can easily add the SDK 8.1 to the Library search seach 
 paths for x64 and x32COFF, but is it a good idea to mix SDK 10 
 and 8.1 like this? The search order will link to libs from 10 
 if they are present in SDK 10, and only use libs from SDK 8.1 
 if they are not present in SDK 10.

 I am rather going to change my Lib search paths to only use the 
 SDK 8.1, but are these known restrictions with SDK 8.0. and 
 10.0? Or is there something wrong with my SDK 10 installation? 
 (I have 2 versions of SDK 10, and both show very few libs 
 compared to 8.1)


Wow... have now found I cannot fix this linking issue by sticking 
just with libs from SDK 8.1.

If I remove the search path to libs from SDK 10.0, a basic D app 
now fails to link because of a missing 'libucrtd.lib', which I 
can only find under SDK 10. And likewise can only find 
'user32.lib' under SDK 8.1.

This is becoming really strange now... do I really need 2 
versions of the Windows SDK to be able to build using VisualD 
under VS 2015? Or are one (or both) of my SDKs broken?

To make linking succeed my lib search paths for x64 now looks 
like this:

$(VCINSTALLDIR)lib\amd64
"c:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\x64"  
<-SDK 8.1 path hard-coded
$(UniversalCRTSdkDir)Lib\$(UCRTVersion)\ucrt\x64  <-'Default' 
SDK; v10.0 in this case
$(UniversalCRTSdkDir)Lib\$(UCRTVersion)\ucrt\arm64
$(DMDInstallDir)windows\bin

I also don't understand (even thought this is not an issue for me 
at the moment since I am not targeting ARM), how the 'default' 
global search paths here for both ARM and x32/x64 can co-exist...
$(UniversalCRTSdkDir)Lib\$(UCRTVersion)\ucrt\x64
$(UniversalCRTSdkDir)Lib\$(UCRTVersion)\ucrt\arm64

... the above search order will always cause an ARM target to 
find the corresponding x32/x64 lib first - and try to link to 
that (since the basic ARM/x32/x86 lib names (like user32.lib) are 
all identical). Or are there some trick to this that I am missing?

In fact, why even have ARM lib search paths under the DMD 
compiler settings? AFAIK you cannot target ARM anyway with DMD, 
no? ARM paths may be valid paths for LDC or GDC, but VisualD has 
separate forms for those paths - I am just referring to the  DMD 
case here.

I know you can specify the lib search paths at a local project 
level too, but these DMD 'global' search paths (with the 
exception of the SDK 8.1 one I added) were created by the VisualD 
installer, so this was actually my 'default' installation.

I would like to seamlessly switch from building with dub to 
debugging with VS+VisualD (after generating VisualD project using 
dub) if required - this should actually be pretty much the 
standard work-flow for users of VS+VisualD and allows to leverage 
the strength of both. But I have also found some issues on the 
dub side as well with generating VisualD projects. I'll have a 
stab at fixing them but I want to use VS+VisualD to debug dub for 
this so, even though I can successfully compile+link at the 
moment in VS+VisualD, I'm suspicious of having to link against 
libs from 2 SDKs...?



 May 22 2019



  parent  Rainer Schuetze <r.sagitario gmx.de>  writes:


On 22/05/2019 18:35, ShadoLight wrote:

 Wow... have now found I cannot fix this linking issue by sticking just
 with libs from SDK 8.1.
 
 If I remove the search path to libs from SDK 10.0, a basic D app now
 fails to link because of a missing 'libucrtd.lib', which I can only find
 under SDK 10. And likewise can only find 'user32.lib' under SDK 8.1.
 
 This is becoming really strange now... do I really need 2 versions of
 the Windows SDK to be able to build using VisualD under VS 2015? Or are
 one (or both) of my SDKs broken?
 
 To make linking succeed my lib search paths for x64 now looks like this:
 
 $(VCINSTALLDIR)lib\amd64
 "c:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\x64"  <-SDK 8.1
 path hard-coded
 $(UniversalCRTSdkDir)Lib\$(UCRTVersion)\ucrt\x64  <-'Default' SDK; v10.0
 in this case
 $(UniversalCRTSdkDir)Lib\$(UCRTVersion)\ucrt\arm64
 $(DMDInstallDir)windows\bin


I suspect that you have the UCRT libraries in the Win10 folder (where
they usually are), but no Win10 SDK installed. It can also happen that
both exist, but with different versions.

So your patch to add the Win8.1 SDK looks good. Visual D should also set
it to "$(WindowsSdkDir)Lib\winv6.3\um\x64" as the default at first start
(but doesn't change the values once they have been edited).



 I also don't understand (even thought this is not an issue for me at the
 moment since I am not targeting ARM), how the 'default' global search
 paths here for both ARM and x32/x64 can co-exist...
 $(UniversalCRTSdkDir)Lib\$(UCRTVersion)\ucrt\x64
 $(UniversalCRTSdkDir)Lib\$(UCRTVersion)\ucrt\arm64


Yes, the arm library should be removed, aswell as the dmd bin directory.



 May 22 2019



prev sibling  parent reply Rainer Schuetze <r.sagitario gmx.de>  writes:


On 22/05/2019 10:42, ShadoLight wrote:

 My *current* set of Library search paths (Tools -> Options -> VisualD
 Settings -> DMD -> x64) shows:
 $(VCINSTALLDIR)lib\amd64
 $(UniversalCRTSdkDir)Lib\$(UCRTVersion)\ucrt\x64
 $(UniversalCRTSdkDir)Lib\$(UCRTVersion)\ucrt\arm64
 $(DMDInstallDir)windows\bin


This looks pretty broken, you should not try to link ARM libraries.

The VS2015 default for x64 is:

$(VCINSTALLDIR)lib\amd64
$(UCRTSdkDir)Lib\$(UCRTVersion)\ucrt\x64

and for Win32-COFF:

$(VCINSTALLDIR)lib
$(UCRTSdkDir)Lib\$(UCRTVersion)\ucrt\x86

Starting with VS2015, the VC runtime requires the universal runtime (UCRT).

You can see the resulting paths in the build logs in the output
directory. The are passed to the linker with the /LIBPATH option.



 May 22 2019



  parent reply Rainer Schuetze <r.sagitario gmx.de>  writes:


On 22/05/2019 19:32, Rainer Schuetze wrote:

 
 The VS2015 default for x64 is:
 
 $(VCINSTALLDIR)lib\amd64
 $(UCRTSdkDir)Lib\$(UCRTVersion)\ucrt\x64


Argh, sorry, this is what you get without any Windows SDK installed.
If the Win10 SDK is detected, this gets added, too:

$(WindowsSdkDir)lib\$(WindowsSdkVersion)\um\x64


 
 and for Win32-COFF:
 
 $(VCINSTALLDIR)lib
 $(UCRTSdkDir)Lib\$(UCRTVersion)\ucrt\x86


$(WindowsSdkDir)lib\$(WindowsSdkVersion)\um\x86


 
 Starting with VS2015, the VC runtime requires the universal runtime (UCRT).
 
 You can see the resulting paths in the build logs in the output
 directory. The are passed to the linker with the /LIBPATH option.
 





 May 22 2019



  parent reply ShadoLight <ettienne.gilbert gmail.com>  writes:


On Wednesday, 22 May 2019 at 20:12:49 UTC, Rainer Schuetze wrote:

 On 22/05/2019 19:32, Rainer Schuetze wrote:

 
 The VS2015 default for x64 is:
 
 $(VCINSTALLDIR)lib\amd64
 $(UCRTSdkDir)Lib\$(UCRTVersion)\ucrt\x64


 Argh, sorry, this is what you get without any Windows SDK 
 installed. If the Win10 SDK is detected, this gets added, too:

 $(WindowsSdkDir)lib\$(WindowsSdkVersion)\um\x64


 
 and for Win32-COFF:
 
 $(VCINSTALLDIR)lib
 $(UCRTSdkDir)Lib\$(UCRTVersion)\ucrt\x86


 $(WindowsSdkDir)lib\$(WindowsSdkVersion)\um\x86


 
 Starting with VS2015, the VC runtime requires the universal 
 runtime (UCRT).
 
 You can see the resulting paths in the build logs in the 
 output directory. The are passed to the linker with the 
 /LIBPATH option.




Many moons later... on a new clean Win7 x64 laptop with VS2015 
Pro I had a chance to start from scratch and see what happens 
with the above SDK scenario:

After a "clean" install of DMD (2.089.0) and VisualD (0.50.1), I 
got the following VD Library Paths:
Win32:
(empty)
x64:
$(VCINSTALLDIR)lib\amd64
$(UCRTSdkDir)Lib\$(UCRTVersion)\ucrt\x64
Win32-COFF:
$(VCINSTALLDIR)lib
$(UCRTSdkDir)Lib\$(UCRTVersion)\ucrt\x86

I did not get the following 2 paths (you mentioned above) added:
x64:
$(WindowsSdkDir)lib\$(WindowsSdkVersion)\um\x64
Win32-COFF:
$(WindowsSdkDir)lib\$(WindowsSdkVersion)\um\x86

So neither the paths for the Win10 SDK nor Wn8.1 SDK were added.

Creating a Win32 app in VS then fails with "LNK1181: cannot open 
input file 'user32.lib'".

Adding the above 2 paths for Win10 SDK does not solve the above 
Link error - it still cannot link to 'user32.lib'. From the 
calc2.buildlog.html I can see:

/LIBPATHs: C:\Program Files (x86)\Microsoft Visual Studio 
14.0\VC\lib;
	C:\Program Files (x86)\Windows Kits\10\Lib\10.0.10240.0\ucrt\x86;
	C:\Program Files (x86)\Windows Kits\10\lib\\um\x86

This gives the following values:
$(VCINSTALLDIR): C:\Program Files (x86)\Microsoft Visual Studio 
14.0\VC
$(UCRTSdkDir): C:\Program Files (x86)\Windows Kits\10
$(UCRTVersion): 10.0.10240.0
$(WindowsSdkDir): C:\Program Files (x86)\Windows Kits\10
$(WindowsSdkVersion):

This seems to indicate VD thinks Win10 SDK is installed. However, 
even though there is a "c:\Program Files (x86)\Microsoft 
SDKs\Windows\v10.0A\" folder, there is no Lib folder in it 
neither any *.lib files.

Searching for 'user32.lib' in C:\Program Files (x86) I get:
c:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Lib\User32.Lib
c:\Program Files (x86)\Microsoft 
SDKs\Windows\v7.1A\Lib\x64\User32.Lib
c:\Program Files (x86)\Windows 
Kits\8.1\Lib\winv6.3\um\arm\User32.Lib
c:\Program Files (x86)\Windows 
Kits\8.1\Lib\winv6.3\um\x64\User32.Lib
c:\Program Files (x86)\Windows 
Kits\8.1\Lib\winv6.3\um\x86\User32.Lib

Replacing $(WindowsSdkDir)lib\$(WindowsSdkVersion)\um\x86 with a 
hardcoded "c:\Program Files (x86)\Windows 
Kits\8.1\Lib\winv6.3\um\x86\User32.Lib" solves the Linking issue 
- app is build and runs successfully.

But this indicates to me that the required SDK on my machine is 
actually Win8.1 SDK. And for $(WindowsSdkDir) should be 
"c:\Program Files (x86)\Windows Kits\8.1\" and for 
$(WindowsSdkVersion) should be "winv6.3".

I cross-checked in VC++ whether these enviro variables are 
defined and what their values are in VC++ and get:
$(WindowsSdkDir): "c:\Program Files (x86)\Windows Kits\8.1\"
$(WindowsSdkVersion): Not defined at all.

So it seems VC++ correctly maps to the Win8.1 SDK, but not VD. 
I'm actually surprised by this... surely  $(WindowsSdkDir) should 
be the same for both...?

IS it possible to set/change these enviro variables for VD to 
their proper values?



 Nov 29 2019



  parent reply Rainer Schuetze <r.sagitario gmx.de>  writes:


On 30/11/2019 00:59, ShadoLight wrote:

 On Wednesday, 22 May 2019 at 20:12:49 UTC, Rainer Schuetze wrote:

 On 22/05/2019 19:32, Rainer Schuetze wrote:

 The VS2015 default for x64 is:

 $(VCINSTALLDIR)lib\amd64
 $(UCRTSdkDir)Lib\$(UCRTVersion)\ucrt\x64


 Argh, sorry, this is what you get without any Windows SDK installed.
 If the Win10 SDK is detected, this gets added, too:

 $(WindowsSdkDir)lib\$(WindowsSdkVersion)\um\x64


 and for Win32-COFF:

 $(VCINSTALLDIR)lib
 $(UCRTSdkDir)Lib\$(UCRTVersion)\ucrt\x86


 $(WindowsSdkDir)lib\$(WindowsSdkVersion)\um\x86


 Starting with VS2015, the VC runtime requires the universal runtime
 (UCRT).

 You can see the resulting paths in the build logs in the output
 directory. The are passed to the linker with the /LIBPATH option.




 
 Many moons later... on a new clean Win7 x64 laptop with VS2015 Pro I had
 a chance to start from scratch and see what happens with the above SDK
 scenario:
 
 After a "clean" install of DMD (2.089.0) and VisualD (0.50.1), I got the
 following VD Library Paths:
 Win32:
 (empty)
 x64:
 $(VCINSTALLDIR)lib\amd64
 $(UCRTSdkDir)Lib\$(UCRTVersion)\ucrt\x64
 Win32-COFF:
 $(VCINSTALLDIR)lib
 $(UCRTSdkDir)Lib\$(UCRTVersion)\ucrt\x86
 
 I did not get the following 2 paths (you mentioned above) added:
 x64:
 $(WindowsSdkDir)lib\$(WindowsSdkVersion)\um\x64
 Win32-COFF:
 $(WindowsSdkDir)lib\$(WindowsSdkVersion)\um\x86
 
 So neither the paths for the Win10 SDK nor Wn8.1 SDK were added.
 
 Creating a Win32 app in VS then fails with "LNK1181: cannot open input
 file 'user32.lib'".
 
 Adding the above 2 paths for Win10 SDK does not solve the above Link
 error - it still cannot link to 'user32.lib'. From the
 calc2.buildlog.html I can see:
 
 /LIBPATHs: C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\lib;
     C:\Program Files (x86)\Windows Kits\10\Lib\10.0.10240.0\ucrt\x86;
     C:\Program Files (x86)\Windows Kits\10\lib\\um\x86
 
 This gives the following values:
 $(VCINSTALLDIR): C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC
 $(UCRTSdkDir): C:\Program Files (x86)\Windows Kits\10
 $(UCRTVersion): 10.0.10240.0
 $(WindowsSdkDir): C:\Program Files (x86)\Windows Kits\10
 $(WindowsSdkVersion):
 
 This seems to indicate VD thinks Win10 SDK is installed. However, even
 though there is a "c:\Program Files (x86)\Microsoft
 SDKs\Windows\v10.0A\" folder, there is no Lib folder in it neither any
 *.lib files.
 
 Searching for 'user32.lib' in C:\Program Files (x86) I get:
 c:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Lib\User32.Lib
 c:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Lib\x64\User32.Lib
 c:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\arm\User32.Lib
 c:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\x64\User32.Lib
 c:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\x86\User32.Lib
 
 Replacing $(WindowsSdkDir)lib\$(WindowsSdkVersion)\um\x86 with a
 hardcoded "c:\Program Files (x86)\Windows
 Kits\8.1\Lib\winv6.3\um\x86\User32.Lib" solves the Linking issue - app
 is build and runs successfully.
 
 But this indicates to me that the required SDK on my machine is actually
 Win8.1 SDK. And for $(WindowsSdkDir) should be "c:\Program Files
 (x86)\Windows Kits\8.1\" and for $(WindowsSdkVersion) should be "winv6.3".
 
 I cross-checked in VC++ whether these enviro variables are defined and
 what their values are in VC++ and get:
 $(WindowsSdkDir): "c:\Program Files (x86)\Windows Kits\8.1\"
 $(WindowsSdkVersion): Not defined at all.
 
 So it seems VC++ correctly maps to the Win8.1 SDK, but not VD. I'm
 actually surprised by this... surely  $(WindowsSdkDir) should be the
 same for both...?
 
 IS it possible to set/change these enviro variables for VD to their
 proper values?
 
 


As the Windows SDK environment variable is usually not set in the system
environment, Visual D mimicks vcvarsall.bat from the VC installation to
determine it and uses the first hit:

- read registry entry HKLM\\SOFTWARE\\Microsoft\\Windows Kits\\Installed
Roots\\KitsRoot10 and checks if it has a lib folder

- read registry entry HKLM\\SOFTWARE\\Microsoft\\Microsoft
SDKs\\Windows\\v8.1\\InstallationFolder and checks if it has a lib folder

- read registry entry HKLM\\SOFTWARE\\Microsoft\\Microsoft
SDKs\\Windows\\v8.0\\InstallationFolder and checks if it has a lib folder

- read registry entry SOFTWARE\\Microsoft\\Microsoft
SDKs\\Windows\\CurrentInstallFolder and checks if it has a lib folder

- environment variable WindowsSdkDir

Could you please check where it gets the "C:\Program Files (x86)\Windows
Kits\10" folder from?

Usually, the library search path are set once, and they are not altered
automatically later. You can reevaluate the default settings with the
"Reset Settings..." button.



 Nov 30 2019



  parent reply ShadoLight <ettienne.gilbert gmail.com>  writes:


On Saturday, 30 November 2019 at 08:53:32 UTC, Rainer Schuetze 
wrote:

 On 30/11/2019 00:59, ShadoLight wrote:

 On Wednesday, 22 May 2019 at 20:12:49 UTC, Rainer Schuetze 
 wrote:

 On 22/05/2019 19:32, Rainer Schuetze wrote:

 The VS2015 default for x64 is:

 $(VCINSTALLDIR)lib\amd64
 $(UCRTSdkDir)Lib\$(UCRTVersion)\ucrt\x64


 Argh, sorry, this is what you get without any Windows SDK 
 installed. If the Win10 SDK is detected, this gets added, too:

 $(WindowsSdkDir)lib\$(WindowsSdkVersion)\um\x64


 and for Win32-COFF:

 $(VCINSTALLDIR)lib
 $(UCRTSdkDir)Lib\$(UCRTVersion)\ucrt\x86


 $(WindowsSdkDir)lib\$(WindowsSdkVersion)\um\x86


 Starting with VS2015, the VC runtime requires the universal 
 runtime
 (UCRT).

 You can see the resulting paths in the build logs in the 
 output directory. The are passed to the linker with the 
 /LIBPATH option.




 
 Many moons later... on a new clean Win7 x64 laptop with VS2015 
 Pro I had a chance to start from scratch and see what happens 
 with the above SDK scenario:
 
 After a "clean" install of DMD (2.089.0) and VisualD (0.50.1), 
 I got the
 following VD Library Paths:
 Win32:
 (empty)
 x64:
 $(VCINSTALLDIR)lib\amd64
 $(UCRTSdkDir)Lib\$(UCRTVersion)\ucrt\x64
 Win32-COFF:
 $(VCINSTALLDIR)lib
 $(UCRTSdkDir)Lib\$(UCRTVersion)\ucrt\x86
 
 I did not get the following 2 paths (you mentioned above) 
 added:
 x64:
 $(WindowsSdkDir)lib\$(WindowsSdkVersion)\um\x64
 Win32-COFF:
 $(WindowsSdkDir)lib\$(WindowsSdkVersion)\um\x86
 
 So neither the paths for the Win10 SDK nor Wn8.1 SDK were 
 added.
 
 Creating a Win32 app in VS then fails with "LNK1181: cannot 
 open input file 'user32.lib'".
 
 Adding the above 2 paths for Win10 SDK does not solve the 
 above Link error - it still cannot link to 'user32.lib'. From 
 the calc2.buildlog.html I can see:
 
 /LIBPATHs: C:\Program Files (x86)\Microsoft Visual Studio 
 14.0\VC\lib;
     C:\Program Files (x86)\Windows 
 Kits\10\Lib\10.0.10240.0\ucrt\x86;
     C:\Program Files (x86)\Windows Kits\10\lib\\um\x86
 
 This gives the following values:
 $(VCINSTALLDIR): C:\Program Files (x86)\Microsoft Visual 
 Studio 14.0\VC
 $(UCRTSdkDir): C:\Program Files (x86)\Windows Kits\10
 $(UCRTVersion): 10.0.10240.0
 $(WindowsSdkDir): C:\Program Files (x86)\Windows Kits\10
 $(WindowsSdkVersion):
 
 This seems to indicate VD thinks Win10 SDK is installed. 
 However, even though there is a "c:\Program Files 
 (x86)\Microsoft SDKs\Windows\v10.0A\" folder, there is no Lib 
 folder in it neither any *.lib files.
 
 Searching for 'user32.lib' in C:\Program Files (x86) I get:
 c:\Program Files (x86)\Microsoft 
 SDKs\Windows\v7.1A\Lib\User32.Lib
 c:\Program Files (x86)\Microsoft 
 SDKs\Windows\v7.1A\Lib\x64\User32.Lib
 c:\Program Files (x86)\Windows 
 Kits\8.1\Lib\winv6.3\um\arm\User32.Lib
 c:\Program Files (x86)\Windows 
 Kits\8.1\Lib\winv6.3\um\x64\User32.Lib
 c:\Program Files (x86)\Windows 
 Kits\8.1\Lib\winv6.3\um\x86\User32.Lib
 
 Replacing $(WindowsSdkDir)lib\$(WindowsSdkVersion)\um\x86 with 
 a
 hardcoded "c:\Program Files (x86)\Windows
 Kits\8.1\Lib\winv6.3\um\x86\User32.Lib" solves the Linking 
 issue - app
 is build and runs successfully.
 
 But this indicates to me that the required SDK on my machine 
 is actually
 Win8.1 SDK. And for $(WindowsSdkDir) should be "c:\Program 
 Files
 (x86)\Windows Kits\8.1\" and for $(WindowsSdkVersion) should 
 be "winv6.3".
 
 I cross-checked in VC++ whether these enviro variables are 
 defined and
 what their values are in VC++ and get:
 $(WindowsSdkDir): "c:\Program Files (x86)\Windows Kits\8.1\"
 $(WindowsSdkVersion): Not defined at all.
 
 So it seems VC++ correctly maps to the Win8.1 SDK, but not VD. 
 I'm actually surprised by this... surely  $(WindowsSdkDir) 
 should be the same for both...?
 
 IS it possible to set/change these enviro variables for VD to 
 their proper values?
 
 


 As the Windows SDK environment variable is usually not set in 
 the system environment, Visual D mimicks vcvarsall.bat from the 
 VC installation to determine it and uses the first hit:


Hi Rainer,

Thanks for the very prompt reply!

Ok, checking this...


 - read registry entry HKLM\\SOFTWARE\\Microsoft\\Windows 
 Kits\\Installed Roots\\KitsRoot10 and checks if it has a lib 
 folder


--> No KitsRoot10 present.
--> Only KitsRoots present under 
HKLM\\SOFTWARE\\Microsoft\\Windows Kits\\Installed Roots\\:
         ..\\KitsRoot: C:\Program Files (x86)\Windows Kits\8.0\
         ..\\KitsRoot81: C:\Program Files (x86)\Windows Kits\8.1\

 - read registry entry HKLM\\SOFTWARE\\Microsoft\\Microsoft 
 SDKs\\Windows\\v8.1\\InstallationFolder and checks if it has a 
 lib folder


--> This is close, but no banana! There are 3 SDKs listed under 
KLM\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\... namely 
v7.1A, v8.0A and v8.1A. But note that it is *v8.1A*, not *v8.1*. 
But there are anyway no lib folder at the registry entry for 
v8.1A.


 - read registry entry HKLM\\SOFTWARE\\Microsoft\\Microsoft 
 SDKs\\Windows\\v8.0\\InstallationFolder and checks if it has a 
 lib folder


--> Same story as previous check.. it has *v8.0A*, not *v8.0*. 
Also, no lib folder present at registry entry for v8.0A.


 - read registry entry SOFTWARE\\Microsoft\\Microsoft 
 SDKs\\Windows\\CurrentInstallFolder and checks if it has a lib 
 folder


--> The registry entry is 'C:\Program Files (x86)\Microsoft 
SDKs\Windows\v8.1A\', which has no 'lib' folder.


 - environment variable WindowsSdkDir


--> Set to 'C:\Program Files (x86)\Windows Kits\10'according to 
buildlog.html.

 Could you please check where it gets the "C:\Program Files 
 (x86)\Windows
 Kits\10" folder from?


--> I really have no idea, since it does not look like there is 
any 'hit' from the above.

 Usually, the library search path are set once, and they are not 
 altered automatically later. You can reevaluate the default 
 settings with the "Reset Settings..." button.


OK, thanks - I will try this.

On my system it looks like the valid entries were all under 
HKLM\\SOFTWARE\\Microsoft\\Windows Kits\\Installed Roots\\.., so 
the following sequence would have been preferable (still taking 
the 1st hit):

- read registry entry HKLM\\SOFTWARE\\Microsoft\\Windows 
Kits\\Installed Roots\\KitsRoot10 and checks if it has a lib 
folder

- read registry entry HKLM\\SOFTWARE\\Microsoft\\Windows 
Kits\\Installed Roots\\KitsRoot81 and checks if it has a lib 
folder

- read registry entry HKLM\\SOFTWARE\\Microsoft\\Windows 
Kits\\Installed Roots\\KitsRoot80 and checks if it has a lib 
folder

- read registry entry HKLM\\SOFTWARE\\Microsoft\\Windows 
Kits\\Installed Roots\\KitsRoot and checks if it has a lib folder

- read registry entry HKLM\\SOFTWARE\\Microsoft\\Microsoft 
SDKs\\Windows\\v8.1\\InstallationFolder and checks if it has a 
lib folder

- read registry entry HKLM\\SOFTWARE\\Microsoft\\Microsoft 
SDKs\\Windows\\v8.0\\InstallationFolder and checks if it has a 
lib folder

- read registry entry SOFTWARE\\Microsoft\\Microsoft 
SDKs\\Windows\\CurrentInstallFolder and checks if it has a lib 
folder

- environment variable WindowsSdkDir



 Dec 01 2019



  parent reply Rainer Schuetze <r.sagitario gmx.de>  writes:


On 01/12/2019 23:49, ShadoLight wrote:

 On Saturday, 30 November 2019 at 08:53:32 UTC, Rainer Schuetze wrote:


[...]

 As the Windows SDK environment variable is usually not set in the
 system environment, Visual D mimicks vcvarsall.bat from the VC
 installation to determine it and uses the first hit:


 Hi Rainer,
 
 Thanks for the very prompt reply!
 
 Ok, checking this...
 

 - read registry entry HKLM\\SOFTWARE\\Microsoft\\Windows
 Kits\\Installed Roots\\KitsRoot10 and checks if it has a lib folder


 --> No KitsRoot10 present.
 --> Only KitsRoots present under HKLM\\SOFTWARE\\Microsoft\\Windows
 Kits\\Installed Roots\\:
         ..\\KitsRoot: C:\Program Files (x86)\Windows Kits\8.0\
         ..\\KitsRoot81: C:\Program Files (x86)\Windows Kits\8.1\

 - read registry entry HKLM\\SOFTWARE\\Microsoft\\Microsoft
 SDKs\\Windows\\v8.1\\InstallationFolder and checks if it has a lib folder


 --> This is close, but no banana! There are 3 SDKs listed under
 KLM\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\... namely v7.1A,
 v8.0A and v8.1A. But note that it is *v8.1A*, not *v8.1*. But there are
 anyway no lib folder at the registry entry for v8.1A.
 

 - read registry entry HKLM\\SOFTWARE\\Microsoft\\Microsoft
 SDKs\\Windows\\v8.0\\InstallationFolder and checks if it has a lib folder


 --> Same story as previous check.. it has *v8.0A*, not *v8.0*. Also, no
 lib folder present at registry entry for v8.0A.
 

 - read registry entry SOFTWARE\\Microsoft\\Microsoft
 SDKs\\Windows\\CurrentInstallFolder and checks if it has a lib folder


 --> The registry entry is 'C:\Program Files (x86)\Microsoft
 SDKs\Windows\v8.1A\', which has no 'lib' folder.
 

 - environment variable WindowsSdkDir


 --> Set to 'C:\Program Files (x86)\Windows Kits\10'according to
 buildlog.html.

 Could you please check where it gets the "C:\Program Files (x86)\Windows
 Kits\10" folder from?


 --> I really have no idea, since it does not look like there is any
 'hit' from the above.

 Usually, the library search path are set once, and they are not
 altered automatically later. You can reevaluate the default settings
 with the "Reset Settings..." button.


 
 OK, thanks - I will try this.
 
 On my system it looks like the valid entries were all under
 HKLM\\SOFTWARE\\Microsoft\\Windows Kits\\Installed Roots\\.., so the
 following sequence would have been preferable (still taking the 1st hit):
 
 - read registry entry HKLM\\SOFTWARE\\Microsoft\\Windows Kits\\Installed
 Roots\\KitsRoot10 and checks if it has a lib folder
 
 - read registry entry HKLM\\SOFTWARE\\Microsoft\\Windows Kits\\Installed
 Roots\\KitsRoot81 and checks if it has a lib folder
 
 - read registry entry HKLM\\SOFTWARE\\Microsoft\\Windows Kits\\Installed
 Roots\\KitsRoot80 and checks if it has a lib folder
 
 - read registry entry HKLM\\SOFTWARE\\Microsoft\\Windows Kits\\Installed
 Roots\\KitsRoot and checks if it has a lib folder
 
 - read registry entry HKLM\\SOFTWARE\\Microsoft\\Microsoft
 SDKs\\Windows\\v8.1\\InstallationFolder and checks if it has a lib folder
 
 - read registry entry HKLM\\SOFTWARE\\Microsoft\\Microsoft
 SDKs\\Windows\\v8.0\\InstallationFolder and checks if it has a lib folder
 
 - read registry entry SOFTWARE\\Microsoft\\Microsoft
 SDKs\\Windows\\CurrentInstallFolder and checks if it has a lib folder
 
 - environment variable WindowsSdkDir


Thanks for digging through this. I've now added checking all the legacy
SDKs 7/8.0/1(A).

For now, you should be fine with manually setting the library search
path to the respective lib folders of the 7.1A/8.1 SDK.



 Dec 02 2019



  parent  ShadoLight <ettienne.gilbert gmail.com>  writes:


On Tuesday, 3 December 2019 at 07:31:55 UTC, Rainer Schuetze 
wrote:


[snip]

 For now, you should be fine with manually setting the library 
 search path to the respective lib folders of the 7.1A/8.1 SDK.


Yep, indeed I've set it manually, so all is good!



 Dec 03 2019