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.

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...

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.

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.

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

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.

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.

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.

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!

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).