Extension fails to write QT in <projectname>.vcxproj.user when solution name is "x86"

The context

I noticed the following situation: Visual Studio 2017 now defaults to creating solutions with the following configuration and platform combinations when creating a new Window application project:

• Configuration is either Debug or Release
• Platform is either x86 or x64

While at the solution level platforms can be renamed to whatever one wants, they can't be renamed at the project level and are still one of *ARM,  Win32 or x64.* This means that when the platform at the solution level is x86, at the project level it's still named Win32.

The bug

When selecting the default Qt version, the Qt visual studio extension is supposed to write the QTDIR variable to <projectname>.vcxproj.user. For example:

<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'">      
  <QTDIR>C:\Qt\5.12.0\msvc2017_64</QTDIR>
  <LocalDebuggerEnvironment>PATH=$(QTDIR)\bin%3b$(PATH)</LocalDebuggerEnvironment>
</PropertyGroup>

But it fails to do so when the platform name at the solution and the project level don't align.

The consequence is that writing <QTDIR>..</QTDIR> in the <projectname>.vcxproj.user file only works when the platform names at the solution level are either Win32 or x64.

In other words, when the platform name at the solution level doesn't correspond to the name at the project level, the extension fails to write the <QTDIR>...</QTDIR> entry:

<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">      
  <LocalDebuggerEnvironment>PATH=$(QTDIR)\bin%3b$(PATH)</LocalDebuggerEnvironment>
</PropertyGroup>

The possible solution?

The Qt extension should inspect the data of what Visual Studio calls "the configuration manager" and follow the solution/project mappings. These mappings are in fact stored in the .sln file itself.