3f / hmsbuild Goto Github PK

.bat scripts with full Package Manager inside for searching and wrapping MSBuild tools. All Visual Studio and .NET Framework versions

License: MIT License

Batchfile 100.00%

msbuild vswhere visual-studio build portable embeddable tools getnutool distribution ci

hmsbuild's Introduction












	`More ...`

*update every hour

[ ☕ ]

hmsbuild's People

Contributors

Stargazers

Watchers

Forkers

pavithrarani gerhardol radtek mdonatas

hmsbuild's Issues

Find MSBuild when only Build Tools are installed

I installed a new machine only with VS2019 Build Tools and hmsbuild only finds C:\Windows\Microsoft.NET\Framework64\v4.0.30319\\MSBuild.exe. Well that's not good because my build really needs a recent MSBuild.

After having a look at the un-minified source code here + vswhere conditions for detecting Build Tools (it does not by default, which, imo, is a pity...), I hacked directly in the minified hmsbuild and added the -products * in the call to vswhere. And bam, here my brand new MSBuild from VS2019 appears...

Could you add this option? This would be really helpful for CI machines. Thanks!

PS: Attached is my modified hMSBuild. The interesting line is #292
hMSBuild.bat.txt

Update logic for searching of vswhere locally and via NuGet

vswhere is now available as part of the install starting today with Visual Studio 15.2 preview 2:

microsoft/vswhere#41 (comment)
https://blogs.msdn.microsoft.com/heaths/2017/04/21/vswhere-is-now-installed-with-visual-studio-2017/

Where: microsoft/vswhere#41 (comment)

%ProgramFiles(x86)%\Microsoft Visual Studio\Installer (Win-x64)
%ProgramFiles%\Microsoft Visual Studio\Installer (Win-x32)

a7, a8, a9 - is not recognized as an internal or external command

appveyor
a7, a8, a9 - is not recognized as an internal or external command,
diffversions Tests: 1,4,5,8,9,11
https://ci.appveyor.com/project/3Fs/hmsbuild/build/build-18

all ok for my env -_-

Possible problems with special characters in paths

Here's review of the bug: 3F/DllExport#88 (comment)

We need to check this project.

Add filter or priorities for searching MSBuild together with specific workload components

We need to provide some priorities in search result when user's machine contains 2 or more VS2017+ installed instances with different components.

The basic example is for C++ projects and several versions of installed VS2017:

The one of these contains only - [.NET desktop development]
Other, only - [Desktop development with C++]

C:\Program Files (x86)\VS\2017\Professional\MSbuild\
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\

Current version may return path for what is not needed:

error MSB4019: 
The imported project "C:\Program Files (x86)\VS\2017\Professional\Common7\IDE\VC\VCTargets\Microsoft.Cpp.Default.props" was not found. 
Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.

So we need to specify some priorities for searching via IDs.

The priority means only trying with these in first attempts. But, I think also about -force key for more strong behaviour.

Non-zero exit code when compilation fails

I love your script, but I always end up modifying line 231 (v1.2.1) to return %ERRORLEVEL% instead of zero, so that hMSBuild.bat returns a non-zero exit code when MSBuild.exe fails.

Is there any reason why you decided to always return zero, even when MSBuild.exe encounters an error?

Control of the priority for MSBuild versions

Mentioned by @odalet from #13 (comment)

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

So what's going on if we're talking about VS2017+

This is so, because of this:

hMSBuild/frontend.bat

Lines 469 to 471 in 4b368c9

    
           if defined vspath if defined vsver ( 
        
               call :vswmsb vspath vsver msbf 
        
               if defined msbf goto _vswbinReturn

But in general, it depends on installation order in your machine and current ISetupConfiguration2.EnumAllInstances / IEnumSetupInstances.Next implementation. Which may sort the available products by something.

vswhere will just enumerate it 'as is' (see installation API):

just installed 2017 & 2019 on clean VM:

:: "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community "
:: "15.9.28307.770 "
:: "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community "
:: "16.1.29102.190 "

that is:

instanceId: 2d0578b0
installDate: 7/19/2019 5:49:56 AM
installationName: VisualStudio/15.9.14+28307.770
installationPath: C:\Program Files (x86)\Microsoft Visual Studio\2017\Community
installationVersion: 15.9.28307.770
productId: Microsoft.VisualStudio.Product.Community
productPath: C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\devenv.exe
state: 4294967295
isComplete: 1
isLaunchable: 1
isPrerelease: 0
isRebootRequired: 0
displayName: Visual Studio Community 2017
description: Free, fully-featured IDE for students, open-source and individual developers
channelId: VisualStudio.15.Release
channelUri: https://aka.ms/vs/15/release/channel
enginePath: C:\Program Files (x86)\Microsoft Visual Studio\Installer\resources\app\ServiceHub\Services\Microsoft.VisualStudio.Setup.Service
releaseNotes: https://go.microsoft.com/fwlink/?LinkId=660692#15.9.14
thirdPartyNotices: https://go.microsoft.com/fwlink/?LinkId=660708
updateDate: 2019-07-19T12:49:56.4989618Z
catalog_buildBranch: d15.9
catalog_buildVersion: 15.9.28307.770
catalog_id: VisualStudio/15.9.14+28307.770
catalog_localBuild: build-lab
catalog_manifestName: VisualStudio
catalog_manifestType: installer
catalog_productDisplayVersion: 15.9.14
catalog_productLine: Dev15
catalog_productLineVersion: 2017
catalog_productMilestone: RTW
catalog_productMilestoneIsPreRelease: False
catalog_productName: Visual Studio
catalog_productPatchVersion: 14
catalog_productPreReleaseMilestoneSuffix: 1.0
catalog_productRelease: RTW
catalog_productSemanticVersion: 15.9.14+28307.770
catalog_requiredEngineVersion: 1.18.1049.33485
properties_campaignId: 112003091.1563535912
properties_channelManifestId: VisualStudio.15.Release/15.9.14+28307.770
properties_nickname:
properties_setupEngineFilePath: C:\Program Files (x86)\Microsoft Visual Studio\Installer\vs_installershell.exe

instanceId: bcc9b5bf
installDate: 7/19/2019 5:00:06 AM
installationName: VisualStudio/16.1.6+29102.190
installationPath: C:\Program Files (x86)\Microsoft Visual Studio\2019\Community
installationVersion: 16.1.29102.190
productId: Microsoft.VisualStudio.Product.Community
productPath: C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\devenv.exe
state: 4294967295
isComplete: 1
isLaunchable: 1
isPrerelease: 0
isRebootRequired: 0
displayName: Visual Studio Community 2019
description: Free, fully-featured IDE for students, open-source and individual developers
channelId: VisualStudio.16.Release
channelUri: https://aka.ms/vs/16/release/channel
enginePath: C:\Program Files (x86)\Microsoft Visual Studio\Installer\resources\app\ServiceHub\Services\Microsoft.VisualStudio.Setup.Service
releaseNotes: https://go.microsoft.com/fwlink/?LinkId=660893#16.1.6
thirdPartyNotices: https://go.microsoft.com/fwlink/?LinkId=660909
updateDate: 2019-07-19T12:00:06.2984029Z
catalog_buildBranch: d16.1
catalog_buildVersion: 16.1.29102.190
catalog_id: VisualStudio/16.1.6+29102.190
catalog_localBuild: build-lab
catalog_manifestName: VisualStudio
catalog_manifestType: installer
catalog_productDisplayVersion: 16.1.6
catalog_productLine: Dev16
catalog_productLineVersion: 2019
catalog_productMilestone: RTW
catalog_productMilestoneIsPreRelease: False
catalog_productName: Visual Studio
catalog_productPatchVersion: 6
catalog_productPreReleaseMilestoneSuffix: 1.0
catalog_productSemanticVersion: 16.1.6+29102.190
catalog_requiredEngineVersion: 2.1.3096.46871
properties_campaignId: 112003091.1563535912
properties_channelManifestId: VisualStudio.16.Release/16.1.6+29102.190
properties_nickname: 2
properties_setupEngineFilePath: C:\Program Files (x86)\Microsoft Visual Studio\Installer\vs_installershell.exe

legacy products: 10, 11, 12, 14

Don't forget about legacy products. The part for this here:

(from newer to older versions:)

hMSBuild/frontend.bat

Lines 548 to 577 in 4b368c9

    
           :msbvsold  {out:toolset} 
        
           call :dbgprint "Searching from Visual Studio - 2015, 2013, ..." 
        
           for %%v in (14.0, 12.0) do ( 
        
               call :rtools %%v Y & if defined Y (  
        
                   set %1=!Y! 
        
                   exit /B 0  
        
               ) 
        
           ) 
        
           call :dbgprint "-vs: not found" 
        
           set "%1=" 
        
           exit /B 0 
        
           :: :msbvsold 
        
           :: - - - 
        
           :: Tools from .NET Framework - .net 4.0, ... 
        
           :msbnetf {out:toolset} 
        
           call :dbgprint "Searching from .NET Framework - .NET 4.0, ..." 
        
           for %%v in (4.0, 3.5, 2.0) do ( 
        
               call :rtools %%v Y & if defined Y (  
        
                   set %1=!Y! 
        
                   exit /B 0  
        
               ) 
        
           ) 
        
           call :dbgprint "-netfx: not found" 
        
           set "%1=" 
        
           exit /B 0 
        
           :: :msbnetf

The Question is

Some additional processing from our side is possible for both cases above. But I don't think that's important for hMSBuild project because of minimal filter etc.

However, please comment and/or open PR for relevant changes.

Visual Studio 2017 Update 3 / MSBuild 15.3

Microsoft decided to put v15.3 of MSBuild.exe in <VS2017 install dir>\MSBuild\15.0\Bin, not <VS2017 install dir>\MSBuild\15.3\Bin.

This means that the vsver variable is set incorrectly after updating to Visual Studio 2017 Update 3.
We've fixed it locally by changing line 323 of hMSBuild.bat (v1.2.1) from set vsver=%%a.%%b to set vsver=%%a.0.

Thanks for making your script available to the public, by the way :)

1.2.x Possible False activated `-vswhere-version` key. (400) Bad Request, etc

Found this today before new DllExport release.

For example:
https://ci.appveyor.com/project/3Fs/dllexport/build/build-102

9:03:09 PM.4121 [INFO]: Result of the command: `selected new vswhere version: "MvsSln.sln"`
9:03:11 PM.4982 [INFO]: stderr: received '55'
9:03:11 PM.4982 [WARN]: The command has been executed with error: `The remote server returned an error: (400) Bad Request.`
9:03:11 PM.5672 [INFO]: stderr: received '42'
9:03:11 PM.5672 [WARN]: The command has been executed with error: `The system cannot find the path specified.`
9:03:11 PM.5792 [INFO]: stdout: received '75'
9:03:11 PM.5792 [INFO]: Result of the command: `hMSBuild: "\MSBuild\C:\projects\dllexport\tools\vswhere.0\Bin\MSBuild.exe" `
9:03:11 PM.5792 [INFO]: stderr: received '66'
9:03:11 PM.5792 [WARN]: The command has been executed with error: `The filename, directory name, or volume label syntax is incorrect.`
9:03:11 PM.5792 [INFO]: stderr: received '15'
9:03:11 PM.5792 [WARN]: The command has been executed with error: ` Build failed. `
9:03:11 PM.5792 [INFO]: [Pre] finished SBE: Custom build for dependencies ...

And this is why:

:: 1.2.2 minified version
if "!an:~0,16!"=="-vswhereVersion " set as=1
if "!an:~0,17!"=="-vswhere-version " set as=1
if defined as (            <<<<<<<<<<<<^^^^^^^ 
set "as="
call :be %1 & shift
set aj=%2
echo selected new vswhere version: !aj!
call :be %2 & shift
)

the as can be defined outside current env but we have no set "as=" before this block.

Affects for any editions from 1.2.x. However, full version less prone to errors because of more long name.

You can try to avoid this error via local scope, for example, for minified and the light edition it can be like:

setlocal & (set "as=" & cd MvsSln & build PublicRelease) & endlocal

MSBuild team is changing "{major}.0" to "Current"

MSBuild team is changing "{major}.0" to "Current" to make VS2019 and newer easier to automate in devops via vswhere.

microsoft/vswhere#162 (comment)

	if defined vspath if defined vsver (
	call :vswmsb vspath vsver msbf
	if defined msbf goto _vswbinReturn

	:msbvsold {out:toolset}
	call :dbgprint "Searching from Visual Studio - 2015, 2013, ..."

	for %%v in (14.0, 12.0) do (
	call :rtools %%v Y & if defined Y (
	set %1=!Y!
	exit /B 0
	)
	)
	call :dbgprint "-vs: not found"
	set "%1="
	exit /B 0
	:: :msbvsold

	:: - - -
	:: Tools from .NET Framework - .net 4.0, ...
	:msbnetf {out:toolset}
	call :dbgprint "Searching from .NET Framework - .NET 4.0, ..."

	for %%v in (4.0, 3.5, 2.0) do (
	call :rtools %%v Y & if defined Y (
	set %1=!Y!
	exit /B 0
	)
	)

	call :dbgprint "-netfx: not found"
	set "%1="
	exit /B 0
	:: :msbnetf