Changes:
* VS/VC roots are classified by their installed features (e.g, devenv.com, vcexpress.com, etc.). This provides for special-case verification of batch file arguments based on the internal classification.
* Consistent with earlier behavior, express versions are used for the non-express msvc version symbol for 14.1 and 8.0 when the express version is the only version installed.
* There is a strong possibility that 14.0Exp may not have been detected correctly.  It appears that registry keys for earlier versions of msvc are not populated.  Refined detection of 14.0Exp was added.
* Special case handling of VS2015 BuildTools was added.  The msvc batch files restrict the arguments available as compared to full versions.  The arguments may be accepted and ignored possibly resulting in build failures that are likely not easy to diagnose.
* Special case handling og VS2015 Express was added.  The msvc batch files restrict the arguments available as compared to full versions.  For example, store/UWP build are only available for x86 targets.
* Windows/Platform SDK installations of 7.1, 7.0, and 6.1 populate registry keys and installation folders that were detected by scons (versions 10.0 and 9.0).  Unfortunately, the generated files are intended to be used via SetEnv.cmd and result in errors.  The detection of sdk-only installations was added and the roots are ignored.
* The relative imports of the MSCommon module were changed to top-level absolute imports in a number of microsoft tools.  Moving any of the tools to the site tools folder failed on import (i.e., the relative paths become invalid when moved).
* VS2005 to VS2015 vcvarsall.bat dispatches to a dependent batch file when configuring the msvc environment.  In certain installation scenarios, the dependent batch file (e.g., vcvars64.bat) may not exist.  The existence of vcvarsall.bat, the dependent batch file, and the compiler executable are now verified.
* MSVC configuration data specific to versions VS2005 to VS2008 was added as the dependent batch files have different names than the batch files for VS2010 and later.  VC++ For Python is handled as a special case as the dependent batch files: are not used and are in different locations.
* When VC++ For Python is installed using the ALLUSERS=1 command-line option, the registry keys written are under HKLM rather than HKCU.  VC++ For Python installed for all users is now correctly detected.
* The existing detection configuration for vswhere and the registry was refactored to separate the two methods of detection.
* The detection of the msvc compiler executable has been modified and no longer considers the os environment.  The detection of the msvc compiler executable was modified to provide more detailed warning messages.

…c path from json output.

Test failures when the vc path from json is normalized.
Test failure for AddOption help output.

…where command-line argument

…turning None. Change processing of user-specified vswhere path.

TODO:
* revisit MSVC.Util.process_path due to realpath behavior for some windows specifications (drive specifications, etc).

Changes:
* Added MSVC detection priority.
* Added VS2015 edition limitations.
* Updated SDK batch file known issues.
* Added footnotes for MSVC batch file argument limitations.
* Added footnote for Windows SDK version numbers (Windows 10 and Windows 11)

Manually resolved conflicts in CHANGES.txt and SCons/Tool/MSCommon/vc.py.

…ical errors to prepare for merge with latest.

Manually resolve conflicts:
* CHANGES.txt
* RELEASE.txt
* SCons/Tool/MSCommon/vc.py

…ots).

Add vswhere roots for:
* winget
* scoop

Manually resolve conflicts:
	CHANGES.txt
	RELEASE.txt
	SCons/Tool/MSCommon/vc.py

Changes:
* Bug fix for not found toolset version in vcTests.py
* Re-work sdk list tests in vcTests.py when run on machine that may not have sdks installed (no msvc or older msvc).  Potential future problem lurking as the gap between supported sdk versions grows with future releases.
* Update the tolerance for precompiled header "fast enough" in msvc.py. This test, more than others, has a tendency to fail when run in a virtual machine on Windows.
* Explicity run "foo.exe" instead of "foo" in vs-14.3-exec.py.  A recent change in VS2022 appears to create a "foo" folder which causes the test to fail.

…tructures when vswhere finds new msvc roots.

Manually resolve conflicts:
* SCons/Tool/msvc.xml

…thon).

Changes:
* An express installation of the IDE binary is used when no other IDE edition is detected.
* A full development edition (e.g., Professional) of VS2008 is elected before a Visual C++ For Python edition.
* Update detection order in README.rst and remove hard tabs.
* Minor fixes lingering from original VSWHERE implementation where all call chains were not updated when the environment argument was added.

vswhere changes:
* Split the current vswhere paths list into two lists:
  * the visual studio installer locations,
  * the package manager locations.
* Add additional user vswhere priority groups:
  * before the vs installer locations [high priority],
  * after the vs installer locations [default priority], and
  * after the package manager locations [low priority].
* Adjust tests for vswhere path list changes accordingly.
* Add vswhere location functions to:
  * register user vswhere executable paths by priority,
  * get the currently configured vswhere executable location,
  * freeze the vswhere executable location used for detection.
* Assign the environment VSWHERE construction variable in Tool/MSCommon/vc.py.
* Remove the assignment of the environment VSWHERE construction variable in Tool/msvc.py
* Update the test suite function signature for finding the msvc product directory with vswhere.
* Freeze the vswhere executable in the following functions before the cache is evaluated which will raise an exception if the vswhere executable has changed since the initial detection (if necessary):
  * MSCommon.vc.get_installed_visual_studios,
  * MSCommon.vc.find_vc_pdir,
  * MSCommon.vc.msvc_setup_env,
  * MSCommon.vs.get_installed_visual_studios

Manually resolved:
* CHANGES.txt
* RELEASE.txt

Manually resolve conflicts:
* RELEASE.txt

…d of document).

Changes:
* add vswhere_exe argument to msvc_quert_version_toolset function in MSCommon/README.rst
* fix: pass normalized path for vswhere_norm in vswhere binary named tuple constructor
* add freeze argument for vswhere_register_executable

Manually resolved conflicts:
* CHANGES.txt
* RELEASE.txt
* test/MSVS/vs-14.3-exec.py

Manually resolve conflicts:
* RELEASE.txt

… msvc buildtools v143.

Changes:
* Add msvc build series data structure.
* Change msvc build tools data structure to contain list of build series.
* Update script argument validation and tests.

Changes:
* Add context manager functions to temporary change the policy for msvc not found and msvc script errors within a context block.
* Change msvc_query_version_toolset function behavior: raise exceptions if not found and for argument validation errors; otherwise return msvc version and toolset version.
* Additional logging of exception messages .
* Update tests for 14.3X/14.4X toolsets for VS 2022.

Changes:
* Add function to return msvc version and toolset version pairs for all installed vcs.
* Construct set of installed toolset vcs for determining if msvc_query_version_toolset should raise an exception.

…o 1.00).

…ersionToolsetTests.

Changes:
* module-level initialization index was not renamed from vc_version to msvc_version.
* Add function to return toolset sxs map and versions list in ScriptArguments.py
* Add additional fields to extended version components
* Add data structure for installed vcs versions/toolsets for testing
* Update vcTests.py to new data structure.

# Manually resolved conflicts:
#	RELEASE.txt