Issue #12 / -products *

[odalet]

No description provided.

[3F]

Thanks for your contribution!

As I already voiced in last reply, -vsw-priority ... may help control appetite of -products *

Before merge, Please try to also test this scenario for a long term solution because of Product.TeamExplorer, Product.TestAgent, ... etc

[odalet]

Hi, sorry for the late reply (been quite busy at work).

I gave a try to playing with -vsw-priority. Well it does not work out of the box:

hMSBuild.bat -vsw-priority Microsoft.VisualStudio.Product.BuildTools

does not return the msbuild I'm looking for.

This is because the content of vswPriority is affected to vswFilter and then passed to the -requires option of vswhere.
I have a working prototype that:

• does not initialize vswFilter with anything
• when defined, uses vswPriority to construct a -products option.

This works for my use case, but I may be missing the point of the -vsw-priority and may be introducing regressions... What troubles me is that -vsw-priority accepts workload/component IDs, but something like Microsoft.VisualStudio.Product.BuildTools is a product ID, not a workload/component ID; it is supposed to go to the -products option, not the -requires one...

Don't we need a new argument to hmsbuild allowing to specify a product ID?

For information, here is my current experiment (in frontend.bat @ line 458):
https://github.com/3F/hMSBuild/compare/master...odalet:issue-12-experiment?diff=unified

[3F]

@odalet,

Hi, sorry for the late reply (been quite busy at work).

Don't worry, it's okay for OSS :) On the contrary thank you for continuing review!

This is because the content of vswPriority is affected to vswFilter

I think you did not understand my point.

For -products * we will search in any available products lile VS Pro, or a BuildTools product, and so on.

So, my idea is similar to IDs (#8) for specified components use.

For example, we need to compile C++ project, thus we need any related products that contains:

• A) msbuild component for build;
• B) C++ component that's ready for your project due to libs, tools, headers, etc. See MSB4019 error in my example.

Therefore, we need just specify such as:

Microsoft.VisualStudio.Component.VC.Tools.x86.x64

• Cmake: Microsoft.VisualStudio.Component.VC.CMake.Project
• ATL: Microsoft.VisualStudio.Component.VC.ATL

This still should return ANY products (because of -products *) but it will guarantee ability to get the expected result due to specific IDs.

Try to test this:

hMSBuild -vsw-priority Microsoft.VisualStudio.Component.VC.Tools.x86.x64

hMSBuild -vsw-priority Microsoft.VisualStudio.Component.VC.Tools.x86.x64 Microsoft.VisualStudio.Component.VC.ATL

or other related for your project.

Don't we need a new argument to hmsbuild allowing to specify a product ID?

Undesirable because of -vsw-priority feature. However, it can be considered anyway if it will not work as expected. We need a bit of tests in real use.

Please check this out for your components with your environments. Thanks.

[3F]

By the way, you can specify test cases via this: https://github.com/3F/hMSBuild/blob/master/tests/diffversions.bat#L16
it would be also good point for this PR

[odalet]

I think you did not understand my point.

I'm sure I didn't and not sure I do... In fact I'm not sure anymore what I should test.

For now, if I'm using your version, whatever the id (even ones I'm sure were not installed) I pass to -vsw-priority, hmsbuild always returns the (fallback) MSBuild 4.
But, when I use my version (with the -products *), my hmsbuild always returns the VS2019 MSBuild 16.

I experience though another difference: when I use your version, whatever the component id, I get a warning telling me:

[*] WARN: Tools was not found for: <whatever id I passed>

When I use mine, I only get the warning when the component was not installed. This makes sense to me as without -products *, vswhere doesn't bother at all with searching for components...

[3F]

I pass to -vsw-priority, hmsbuild always returns the (fallback) MSBuild 4.

I meant together with this PR/ after your patch for -products *

Because as I said, after -products * patch hmsbuild will also search in other unrelated products. And we need to be sure for -vsw-priority filter for problems like it was described in #8 (where C++ project is tried to be built by VS .NET instance).

So, please also test this for your env as possible to avoid any errors like above.

[odalet]

ok, I think that makes more sense to me. I'll try my best to understand the issue in #8 and see if I can come with a repro.

[odalet]

I also had a quick look at the test harness you mentioned. Not sure yet how I can use it, but I'll try too.

[odalet]

I ran a few tests this morning.

First, here is my setup. I tested on my dev machine which has installed:

• VS 2017 (15.8) Enterprise with plenty of workloads
• VS 2019 (16.0) Enterprise with approximately the same workloads
• And (for the record) VS 2013 Shell + Beckhoff TwinCAT plugin... should not get in the way of the vswhere behavior. But in previous experiments, when going passed vswhere, MSBuild 12 sometimes showed up.

If I simply run hmsbuild, the returned version of MSBuild is 15.8 (btw I don't know why the more recent 16.0 one is not picked...)

If I pass an ID to -vsw-priority I know exists in both versions, 15.8 is also returned

If I pass an ID that I know does not exist in VS2017, then 16.0 is returned:

> hMSBuild -vsw-priority Microsoft.VisualStudio.Component.VC.v141.x86.x64
hMSBuild: "C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\amd64\MSBuild.exe"
Microsoft (R) Build Engine version 16.0.461+g6ff56ef63c pour .NET Framework
Copyright (C) Microsoft Corporation. Tous droits réservés.

MSBUILD : error MSB1003: Spécifiez un fichier projet ou solution. Le répertoire de travail actif n'en contient aucun.

And I obtain the same results whether I use your hmsbuild or mine.

Hence I suppose -products * does not get in the way. Is this test relevant enough? I have no Build Tools or other special products (TestAgent, TeamExplorer...) installed on this machine.

[3F]

thanks for additional testing!

I have no Build Tools or other special products (TestAgent, TeamExplorer...) installed on this machine.

It makes sense for -products *

Anyway, I've also checked today the following case via clean VM :

• Visual Studio Build 2019 (C++ components only)
• VS 2019 Community (.NET components only)

>hmsbuild -debug -only-path

[ 5:31:59.34 ] trying via vswhere...
[ 5:31:59.36 ] bat/exe:  C:\Users\reg\Desktop\test\vswhere
[ 5:31:59.37 ] bat/exe:  C:\Program Files (x86)\Microsoft Visual Studio\Installer\vswhere
[ 5:31:59.39 ] vswbin:  "C:\Program Files (x86)\Microsoft Visual Studio\Installer\vswhere.exe"
[ 5:31:59.39 ] attempts with filter:
[ 5:31:59.48 ] vspath:  C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools
[ 5:31:59.50 ] vsver:  16.1.29102.190
[ 5:31:59.50 ] found path via vswhere:  C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\MSBuild\Current\Bin
[ 5:31:59.52 ] found /amd64
C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\MSBuild\Current\Bin\amd64\MSBuild.exe

>hmsbuild -debug -only-path -vsw-priority Microsoft.Net.Component.4.7.2.TargetingPack

[ 5:32:09.12 ] trying via vswhere...
[ 5:32:09.12 ] bat/exe:  C:\Users\reg\Desktop\test\vswhere
[ 5:32:09.14 ] bat/exe:  C:\Program Files (x86)\Microsoft Visual Studio\Installer\vswhere
[ 5:32:09.17 ] vswbin:  "C:\Program Files (x86)\Microsoft Visual Studio\Installer\vswhere.exe"
[ 5:32:09.17 ] attempts with filter:  Microsoft.Net.Component.4.7.2.TargetingPack
[ 5:32:09.28 ] vspath:  C:\Program Files (x86)\Microsoft Visual Studio\2019\Community
[ 5:32:09.28 ] vsver:  16.1.29102.190
[ 5:32:09.30 ] found path via vswhere:  C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin
[ 5:32:09.30 ] found /amd64
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\amd64\MSBuild.exe

Looks good because it returns msbuild from Microsoft.VisualStudio.Product.BuildTools by default without filter, and we still can affect for this via our -vsw-priority.

The general product Microsoft.VisualStudio.Product.Community is also searched well.

So I think -products * still is manageable enough through -vsw-priority.

[3F]

@odalet Your PR approved as a permanent solution!
Public release planned for tomorrow or earlier.

[odalet]

Thanks for the hard work testing in a vm!