I installed powershell 7, which set itself as the default shell. It messed up some apps, and I removed it. However, it's still registered as the default shell in some places. One of them is VS2022. When I build my project:
2>Target PostBuildEvent:
2> The system cannot find the path specified.
2> C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(155,5): error MSB3073: The command "setlocal
2> C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(155,5): error MSB3073: "C:\Program Files\PowerShell\7\pwsh.exe" -noprofile -executionpolicy Bypass -file C:/prj-external-libs/vcpkg/scripts/buildsystems/msbuild/applocal.ps1 -targetBinary C:/8/_tmp/cpp/build/src/Debug/proj.exe -installedDir C:/prj-external-libs/vcpkg/installed/x64-windows/debug/bin -OutVariable out
2> C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(155,5): error MSB3073: if %errorlevel% neq 0 goto :cmEnd
2> C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(155,5): error MSB3073: :cmEnd
2> C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(155,5): error MSB3073: endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone
2> C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(155,5): error MSB3073: :cmErrorLevel
2> C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(155,5): error MSB3073: exit /b %1
2> C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(155,5): error MSB3073: :cmDone
2> C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(155,5): error MSB3073: if %errorlevel% neq 0 goto :VCEnd
2> C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(155,5): error MSB3073: :VCEnd" exited with code 3.
2>Done building target "PostBuildEvent" in project "proj.vcxproj" -- FAILED.
2>
2>Done building project "proj.vcxproj" -- FAILED.
I think in general it's done via: options> environment> terminal> restore default.
However, in my case, the issue was with cmake vcpkg, which created a post build event using power shell 7. Need to delete (or just ignore) this event, or rebuild a fresh cmake.
Using CMake (version 3.13.2) to build a shared C library on Windows with MSVC compiler (version 19.16.27025.1).
I get the following error:
Erreur MSB3073 La commande "setlocal
cd "\\vmware-host\Shared Folders\Documents\funnel\build\getopt"
if %errorlevel% neq 0 goto :cmEnd
"C:\Program Files\CMake\bin\cmake.exe" -E __create_def "//vmware-
host/Shared
Folders/Documents/funnel/build/getopt/getopt.dir/Debug/exports.def"
"//vmware-host/Shared
Folders/Documents/funnel/build/getopt/getopt.dir/Debug//objects.txt"
if %errorlevel% neq 0 goto :cmEnd
:cmEnd
endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone
:cmErrorLevel
exit /b %1
:cmDone
if %errorlevel% neq 0 goto :VCEnd
:VCEnd" s'est arrêtée avec le code 1.
Some excerpts of the CMakeLists.txt files defining the build options:
# CMakeLists.txt in root
add_compile_options(/Wall /c)
set(CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS ON)
add_subdirectory(getopt)
# CMakeLists.txt in root/getopt
set(src_files getopt.c getopt1.c)
set(hdr_files ansidecl.h getopt.h)
add_library(getopt SHARED "${src_files}" "${hdr_files}")
(Building STATIC library on Windows is OK. Building SHARED library on Linux with gcc is OK.)
-- EDIT (answering vre's comment) --
Running set_target_properties before call to add_library yields the following error.
set_target_properties Can not find target to add properties to: getopt
Running cmake with the proposed generator yields the following (probably because the compiler is not installed on my system though it is proposed in the list returned by cmake -H: installing this version would help?).
-- Selecting Windows SDK version to target Windows 10.0.17763.
CMake Error at CMakeLists.txt:6 (project):
Failed to run MSBuild command:
MSBuild.exe
to get the value of VCTargetsPath:
Le fichier spécifié est introuvable
Running cmake --build [...] from console (having previously generated the build system with Visual Studio 15 2017) yields the following error.
"\\vmware-host\Shared Folders\Documents\funnel\build\ALL_BUILD.vcxproj" (cible par défaut) (1) ->
"\\vmware-host\Shared Folders\Documents\funnel\build\src\exe.vcxproj" (cible par défaut) (3) ->
"\\vmware-host\Shared Folders\Documents\funnel\build\getopt\getopt.vcxproj" (cible par défaut) (4) ->
(PreLinkEvent cible) ->
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets(13
3,5): error MSB3073: La commande "setlocal [\\vmware-host\Shared Folders\Documents\funnel\build\getopt\getopt.vcxproj]
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets(133,
5): error MSB3073: cd "\\vmware-host\Shared Folders\Documents\funnel\build\getopt" [\\vmware-host\Shared Folders\Docume
nts\funnel\build\getopt\getopt.vcxproj]
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets(133,
5): error MSB3073: if %errorlevel% neq 0 goto :cmEnd [\\vmware-host\Shared Folders\Documents\funnel\build\getopt\getopt
.vcxproj]
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets(133,
5): error MSB3073: "C:\Program Files\CMake\bin\cmake.exe" -E __create_def "//vmware-host/Shared Folders/Documents/funne
l/build/getopt/getopt.dir/Release/exports.def" "//vmware-host/Shared Folders/Documents/funnel/build/getopt/getopt.dir/R
elease//objects.txt" [\\vmware-host\Shared Folders\Documents\funnel\build\getopt\getopt.vcxproj]
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets(133,
5): error MSB3073: if %errorlevel% neq 0 goto :cmEnd [\\vmware-host\Shared Folders\Documents\funnel\build\getopt\getopt
.vcxproj]
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets(133,
5): error MSB3073: :cmEnd [\\vmware-host\Shared Folders\Documents\funnel\build\getopt\getopt.vcxproj]
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets(133,
5): error MSB3073: endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone [\\vmware-host\Shared Folders\Documents\fu
nnel\build\getopt\getopt.vcxproj]
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets(133,
5): error MSB3073: :cmErrorLevel [\\vmware-host\Shared Folders\Documents\funnel\build\getopt\getopt.vcxproj]
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets(133,
5): error MSB3073: exit /b %1 [\\vmware-host\Shared Folders\Documents\funnel\build\getopt\getopt.vcxproj]
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets(133,
5): error MSB3073: :cmDone [\\vmware-host\Shared Folders\Documents\funnel\build\getopt\getopt.vcxproj]
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets(133,
5): error MSB3073: if %errorlevel% neq 0 goto :VCEnd [\\vmware-host\Shared Folders\Documents\funnel\build\getopt\getopt
.vcxproj]
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets(133,
5): error MSB3073: :VCEnd" s'est arrêtée avec le code 1. [\\vmware-host\Shared Folders\Documents\funnel\build\getopt\ge
topt.vcxproj]
I'm tyring to copy a folder from my Visual Studio 2015 Project's root directory into the output directory (as it breaks the application without it), so I decided to add xcopy to the post-build commands.
xcopy "$(SolutionDir)Content\*.*" "$(TargetDir)Content\" /s /i /y
I'm getting the following when it runs, and right now I can't even test this application because of xcopy.
1> File not found - *.*
1> 0 File(s) copied
1>C:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets(4714,5): error MSB3073: The command "xcopy "E:\Data\Projects\Vessel\Games\TheThing\Content\*.*" "E:\Data\Projects\Vessel\Games\TheThing\TheThing\bin\DesktopGL\AnyCPU\Debug\Content\" /s /i /y" exited with code 4.
I'm also getting problems with Xcopy and postbuild events in visual studio from time to time.
My fix is generally to create a batch script which contains the xcopy.
The batch script then is called by:
call "$(SolutionDir)scripts\copyfiles.bat"
as a post script event.
I'm getting the following error when trying to build Hexchat in VisualStudio 2015. Some of those paths are wrong, so I would like to change them.
How do I change those path in Visual Studio 2015?
Error MSB3073 The command "
SET SOLUTIONDIR=C:\Users\olivi\Desktop\Hexchat\win32\..\
powershell -File "C:\Users\olivi\Desktop\Hexchat\win32\..\win32\version-template.ps1" "C:\Users\olivi\Desktop\Hexchat\win32\..\win32\installer\hexchat.iss.tt" "C:\Users\olivi\Desktop\Hexchat\win32\..\..\hexchat-build\Win32\bin\hexchat.iss"
"C:\Program Files (x86)\MSBuild\..\Inno Setup 5\iscc.exe" /dPROJECTDIR="C:\Users\olivi\Desktop\Hexchat\win32\installer\" /dAPPARCH="Win32" "C:\Users\olivi\Desktop\Hexchat\win32\..\..\hexchat-build\Win32\bin\hexchat.iss"
:VCEnd" exited with code 3. installer
I got this in the output window:
The specified path cannot be found
22>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(123,5): error MSB3073: The command "
22>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(123,5): error MSB3073: SET SOLUTIONDIR=C:\Users\olivi\Desktop\Hexchat\win32\..\
22>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(123,5): error MSB3073: powershell -File "C:\Users\olivi\Desktop\Hexchat\win32\..\win32\version-template.ps1" "C:\Users\olivi\Desktop\Hexchat\win32\..\win32\installer\hexchat.iss.tt" "C:\Users\olivi\Desktop\Hexchat\win32\..\..\hexchat-build\Win32\bin\hexchat.iss"
22>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(123,5): error MSB3073: "C:\Program Files (x86)\MSBuild\..\Inno Setup 5\iscc.exe" /dPROJECTDIR="C:\Users\olivi\Desktop\Hexchat\win32\installer\" /dAPPARCH="Win32" "C:\Users\olivi\Desktop\Hexchat\win32\..\..\hexchat-build\Win32\bin\hexchat.iss"
22>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(123,5): error MSB3073:
It's resulting from the following command:
<Exec Command="%(PreBuildEvent.Command)$(_BuildSuffix)" Condition="'%(PreBuildEvent.Command)' != ''"/>
We have a project in Visual Studio 2010 that runs a batch file in the post-build event. That batch calls to signtool.exe from Microsoft SDK to sign and timestamp the binary.
Timestamp servers (we use http://timestamp.verisign.com/scripts/timstamp.dll), however, tend to be unreliable for some reason, failing sometimes. This caused build to fail.
We implemented a more advanced batch script then (based on this code), splitting signing and timestamping, and allowing to retry the timestamp operation, if it failed.
Here is a simplified version of the batch script (signfile.bat):
#echo off
REM sign the file...
signtool.exe /f Authenticode.pfx /p PASS %1
if %errorlevel% neq 0 exit /b %errorlevel%
set timestamp_server=http://timestamp.verisign.com/scripts/timstamp.dll
for /L %%a in (1,1,10) do (
REM try to timestamp the file...
signtool.exe timestamp /t %timestamp_server% %1
if errorlevel 0 if not errorlevel 1 GOTO succeeded
REM wait 2 seconds...
ping -n 2 127.0.0.1 > nul
)
REM return an error code...
echo signfile.bat exit code is 1.
exit /b 1
:succeeded
REM return a successful code...
echo signfile.bat exit code is 0.
exit /b 0
And the post-build event code would look like:
signfile.bat "$(OutDir)$(TargetName)$(TargetExt)"
So, if the timestamping fails, it retries 10 times with 2-seconds intervals.
But, what we observed was, if the timestamping went fine from the first attempt, everything was OK. However, if the first attempt failed, then the whole post-build event failed with code -1, even though the timestamping succeeded on the next try.
1>------ Build started: Project: myproject, Configuration: NonOptimized x64 ------
1> Done Adding Additional Store
1> Successfully signed: E:\tfs\MySolution\bin\x64\NonOptimized\myproject.dll
1>
1>EXEC : SignTool error : The specified timestamp server either could not be reached
1> or returned an invalid response.
1> This may happen if you specify an RFC 3161 timestamp URL but used
1> the /t option or you specified a legacy Authenticode timestamp URL
1> but used the /tr option.
1>EXEC : SignTool error : An error occurred while attempting to timestamp: E:\tfs\MySolution\bin\x64\NonOptimized\myproject.dll
1>
1>
1> Number of errors: 1
1>
1> Successfully timestamped: E:\tfs\MySolution\bin\x64\NonOptimized\myproject.dll
1>
1> signfile.bat exit code is 0.
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: The command "signfile.bat "E:\tfs\MySolution\bin\x64\NonOptimized\myproject.dll"
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: :VCEnd" exited with code -1.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
So, as you can see, even though the error code returned from signfile.bat is 0, Visual Studio thinks it is -1 and fails the event.
All attempts to clear the error flag, like adding ver>nul here and there, or adding exit 0 in the end (certainly with adding "call" before signfile.bat) didn't help since it seemed like Visual Studio checked not just for errorlevel but also for something else. In fact, the batch as well as signfile.bat only return 0 or 1 in case of error, but not -1. And if signtool.exe returns an error once, it seems like there is no way to convince Visual Studio not to fail the post-build event.
After spending much time experimenting and searching, found an article, mentioned here in a comment. It looks like Visual Studio scans the output, searching for some special keywords. Signtool.exe outputs among the other EXEC : SignTool error : An error occurred, which seems like enough to alert Visual Studio that there was an error.
So, the solution proposed was to redirect output and error streams to nul as 2>nul 1>nul. Errorlevel will still be set, so you will be able to figure out if error occured. But you may have to print some extra messages to see the status:
REM try to timestamp the file...
signtool.exe timestamp /t %timestamp_server% %1 2>nul 1>nul
if errorlevel 0 if not errorlevel 1 (
echo Successfully timestamped: %1
GOTO succeeded
)
echo Timestamping failed for %1
Now Visual Studio is happy:
1>------ Build started: Project: myproject, Configuration: NonOptimized x64 ------
1> Done Adding Additional Store
1> Successfully signed: E:\tfs\MySolution\bin\x64\NonOptimized\myproject.dll
1>
1> Timestamping failed for "E:\tfs\MySolution\bin\x64\NonOptimized\myproject.dll"
1> Successfully timestamped: "E:\tfs\MySolution\bin\x64\NonOptimized\myproject.dll"
1> signfile.bat exit code is 0.
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
In fact, just adding 2>nul would be enough to fix it. Error stream will still be printed: Number of errors: 1, but it does not cause a problem.
I experienced a very similar problem, but with the added difficulty that rather than calling SignTool directly, our post-build step calls a PowerShell script which itself calls SignTool. I set up some retry logic in the PowerShell script (to try various timestamp servers, with delays), but found that if the first attempt failed then the whole build would fail, even though the error was being caught and handled properly and a subsequent signing attempt was succeeding.
I appreciate this isn't exactly what the original question is asking, but I wasted hours and hours on this before eventually working out a solution (having stumbled upon this Q&A - thank you!), so I'm posting this info in the hope that it will help others.
From PowerShell, the standard call to SignTool would be something like this:
$output = & $signToolPath sign `
/n $companyName `
/d $productName `
/du $productWebsite `
/t $timestampServer `
/sha1 $shaHash `
$filePath
If SignTool returns an error code, this will immediately fail the build (as shown in the TeamCity screenshot), which is not desirable if the script is capable of automatically retrying:
To prevent the build failing, the PowerShell error stream can be suppressed (similarly to the solution in the accepted answer) with the PowerShell redirect statement 2>&1 as follows:
$output = & $signToolPath sign `
<switches and args as above>
$filePath 2>&1
However, this means you can't see the error output when SignTool returns an error code, which is obviously unhelpful. You can address this by writing the output to the host like this:
$output = & $signToolPath sign `
<switches and args as above>
$filePath 2>&1
$output | Write-Host
but then Visual Studio / MSBuild will resume trying to be "clever" and fail the build again!
The only solution I have found which allows SignTool error messages to be displayed without failing the build is both to redirect the error stream and to garble the error output before writing to the host, something like this:
$output = & $signToolPath sign `
<switches and args as above>
$filePath 2>&1
$output -split "([a-z0-9])" -join " " | Write-Host
The error message is then human-readable but doesn't fail the build, as shown here:
Of course, if all the retry attempts fail then you need to return an appropriate non-zero exit code from the PowerShell script so that the build does fail.
Thanks again for the original Q&A, and I hope this extra info on PowerShell helps someone else.
(PS: one of the links in the accepted answer is broken, but the referenced article is archived here: http://web.archive.org/web/20180729111947/http://blog.robertromito.com/2010/08/ignore-error-from-visual-studio-post.html )