Linking issues VisualD generated vs Dub generated projects

[ShadoLight]

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)