I have this error when TeamCity Build Step compile with obfuscating a Visual Studio dll Project with MSBuild:
EXEC: error: Error occurred during processing of input file '.dll' -> Cannot load file or assembly 'zx_2cba06c4237a413ea1e8116e71ad61dc, PublicKeyToken = 6205972ab2f0fc68' or one of its dependencies. The system cannot find the specified file. C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets (5473,5): error MSB3073: The command "if /I "Release" == "Release" "C:\Program Files (x86)\Eazfuscator.NET\Eazfuscator.NET.exe" "E:\Builds\MyDll\bin\Release\MyDll.dll" --msbuild-project-path "E:\Builds\MyDll\MyDll.csproj" --msbuild-project-configuration "Release" --msbuild-project-platform "AnyCPU" --msbuild-solution-path "*Undefined*" -n --newline-flush -v 2018.2" exit with code 1.
Eazfuscator-.NET-2018.2.2 is not compatible with MSBuild 2019, the solution is use Eazfuscator-.NET-2019.1 as minimun version.
Related
I am trying to build Tensorflow 1.14.0 dll. I am using bazel 0.24.1 to do it. I also use cuDNN 7.1.4 and CUDA 9.0.I want it to use Visual C++ Build Tools 2015, but when running bazel to build dll:
bazel build --config=cuda tensorflow:tensorflow.dll,
by default in LIB and INCLUDE variables path C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\VC\Tools\MSVC\14.16.27023 is set. I then get bunch of errors like C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\VC\Tools\MSVC\14.16.27023\include\xutility(796): error: expression must have a constant value. Build failes with error: nvcc error : 'cicc' died with status 0xC0000005 (ACCESS_VIOLATION).
I tried to set:
set BAZEL_VS=C:\Program Files (x86)\Microsoft Visual Studio 14.0
set BAZEL_VC=C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC
but error still occurs. Any ideas?
I finally got a solution. You can force correct paths by setting following environment variables:
CPU_COMPILER = ('C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/cl.exe')
GCC_HOST_COMPILER_PATH = ('C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/cl.exe')
just before running
bazel build --config=cuda tensorflow:tensorflow.dll
in commandline. It's best to do it in Powershell, as there is a problem with spaces/apostrophes in paths when using Windows commandline.
I have two Visual Studio installed on my system: VS 2015 and VS 2017.
I run msbuild explicitly from the VS 2017 location:
"C:\Program Files (x86)\Microsoft Visual Studio"\2017\WDExpress\MSBuild\15.0\Bin\amd64\msbuild.exe build/binding.sln /p:Configuration=Release;Platform=x64
Since I call msbuild from the VS 2017 I expect it to take the tools from VS 2017 as well, but it does not work!
The "normal" Verbosity level shows that msbuild calls C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\x86_amd64\cl.exe and C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\x86_amd64\link.exe, so it takes them from the older VS 2015 that is wrong.
If I use even more verbose level (/clp:Verbosity=diagnostic) I see that msbuild takes the properties file from the wrong location as well. The message is:
Property reassignment: $(VCInstallDir_140)="C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\" (previous value: "") at C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.Cpp.Common.props (55,5)
The indeed properties file is located at C:\Program Files (x86)\Microsoft Visual Studio\2017\WDExpress\MSBuild\15.0\Microsoft.Cpp.Common.props.
The PATH variable is correct and does not contain anything that points to the older VS 2015. The variable VS140COMNTOOLS is unset.
Is it the expected behaviour and how can I tell msbuild to use the tools from VS 2017?
MSBuild.exe 15.0 calls cl.exe and link.exe from wrong Visual Studio directory
Please try to call the MSBuild from:
C:\Program Files (x86)\Microsoft Visual Studio\2017\WDExpress\MSBuild\15.0\Bin
and add the parameter /p:VisualStudioVersion=15.0 in the command line, like:
msbuild.exe build/binding.sln /p:Configuration=Release;Platform=x64 /p:VisualStudioVersion=15.0
I have tried the option /p:VisualStudioVersion=15.0, but it did not take effect.
Later I found what was the reason of that behaviour: my *.vcxproj file has the tag
<PlatformToolset>v140</PlatformToolset>
Once I changed it to v141 the msbuild started to take compiler and linker properly. So, it turned that msbuild first of all respects this parameter and only then probably command line options or/and PATH variable.
We are currently having problems while compiling a solution with MSBuild. The build fails randomly on the resource linking step inside the task "AL" which executes the "AL.exe" linker.
ALINK : error AL1019: Metadata failure while creating assembly -- The volume for a file has been externally altered so that the opened file is no longer valid.
The build log shows the following execution flow.
4>Target "GenerateSatelliteAssemblies" in file "C:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets" from project "C:\source\MyProject.csproj" (target "CreateSatelliteAssemblies" depends on it):
4>Building target "GenerateSatelliteAssemblies" completely.
4>Output file "obj\Debug\de\MyProject.dll" does not exist.
4>Task "MakeDir"
4>Done executing task "MakeDir".
4>Task "AL"
4> C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools\AL.exe /culture:de /out:obj\Debug\de\MyProject.resources.dll /template:obj\Debug\MyProject.dll /embed:obj\Debug\MyProject.SomeResource.de.resources
4> Microsoft (R) Assembly Linker version 14.0.0081.0
4> Copyright (C) Microsoft Corporation. All rights reserved.
4>
4>Done executing task "AL".
4>Done building target "GenerateSatelliteAssemblies" in project "MyProject.csproj".
4>Target "GenerateSatelliteAssemblies" in file "C:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets" from project "C:\source\MyProject.csproj" (target "CreateSatelliteAssemblies" depends on it):
4>Building target "GenerateSatelliteAssemblies" completely.
4>Output file "obj\Debug\en\MyProject.resources.dll" does not exist.
4>Task "MakeDir"
4>Done executing task "MakeDir".
4>Task "AL"
4> C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools\AL.exe /culture:en /out:obj\Debug\en\MyProject.resources.dll /template:obj\Debug\MyProject.dll /embed:obj\Debug\MyProject.SomeResource.en.resources
4> Microsoft (R) Assembly Linker version 14.0.0081.0
4> Copyright (C) Microsoft Corporation. All rights reserved.
4>
4>ALINK : error AL1019: Metadata failure while creating assembly -- The volume for a file has been externally altered so that the opened file is no longer valid.
4> The command exited with code 1.
4>Done executing task "AL" -- FAILED.
4>Done building target "GenerateSatelliteAssemblies" in project "MyProject.csproj" -- FAILED.
To me it is completely unclear what is meant by the error code AL1019. The MSDN error code listing didn't help either.
I recently installed Visual Studio 2017, shouldn't MSBuild.exe come with it? One of bash scripts is calling it, but can't find anything.
Here is the part of build.bat that yields error (you can see the whole file here)
MSBuild.exe mpc-hc.sln %MSBUILD_SWITCHES%^
/target:%BUILDTYPE% /property:Configuration="%BUILDCFG% Filter";Platform=%1^
/flp1:LogFile=%LOG_DIR%\filters_errors_%BUILDCFG%_%1.log;errorsonly;Verbosity=diagnostic^
/flp2:LogFile=%LOG_DIR%\filters_warnings_%BUILDCFG%_%1.log;warningsonly;Verbosity=diagnostic
IF %ERRORLEVEL% NEQ 0 (
CALL "%COMMON%" :SubMsg "ERROR" "mpc-hc.sln %BUILDCFG% Filter %1 - Compilation failed!"
EXIT /B
) ELSE (
CALL "%COMMON%" :SubMsg "INFO" "mpc-hc.sln %BUILDCFG% Filter %1 compiled successfully"
)
You can use vswhere 1 which comes with Visual Studio 2017.
It is located in "%ProgramFiles(x86)%\Microsoft Visual Studio\Installer\vswhere.exe".
The part of the path to MSBuild.exe is then retrived by vswhere -nologo -latest -property installationPath, which results e.g., in C:\Program Files (x86)\Microsoft Visual Studio\2017\Community.
Based on the msbuild Version you want to use you can now guess the rest of the path:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\VERSION\Bin\MSBuild.exe
where VERSION is e.g., 15.0 for Version installationVersion: 15.3.26730.12as ouputed by "%ProgramFiles(x86)%\Microsoft Visual Studio\Installer\vswhere.exe" -property installationVersion.
1 See GitHub
I've stumbled upon problems installing clang/LLVM on my Win 7 64-bit machine for setting up Emscripten in my Visual Studio 2010 Setup. I was following the official howto from Emscripten at https://github.com/kripken/emscripten/wiki/Using-Emscripten-on-Windows and stumbled into problems regarding the needed compilation of clang/LLVM.
svn co http://llvm.org/svn/llvm-project/llvm/tags/RELEASE_32/final llvm
cd llvm\tools
svn co http://llvm.org/svn/llvm-project/cfe/tags/RELEASE_32/final clang
cd ..\\..
mkdir build
cmake -G "Visual Studio 10" ..\llvm
msbuild LLVM.sln /p:Configuration=Release
The result is alot of errors similiar to this one:
CUSTOMBUILD : error : error reading '10.0\VC\bin\llvm\tools\clang\test\Index\
pch-opaque-value.cpp' [c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\b
in\build\tools\clang\test\check-clang.vcxproj]
CUSTOMBUILD : error : error reading '10.0\VC\bin\llvm\tools\clang\test\Index\
pch-with-errors.m' [c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\
build\tools\clang\test\check-clang.vcxproj]
Obviously, a path starting at
'10.0\VC...' is totally invalid.. its missing the 'C:\Program Files (x86)\Microsoft Visual Studio ' in front.. (I've checked there is a file like that in test\Index\ - it is!
My question is: how do I fix that ?
a) Can I setup an additional include path that is like 'C:\folder\MS Visual ' (including space) ?
What I have tried so far:
a) Doing it from Visual Studio Prompt and normal Prompt. Using default and custom location.
b) Running MSBUILD like
msbuild LLVM.sln /p:Configuration=Release /p:"VCBuildAdditionalOptions= C:\Program Files (x86)\Microsoft Visual Studio "
c) Trying to change PATH/Systemroot.. Destroyed my systemroot in the meantime for unknown reasons (It complaimed about a wrong path like "C:\Program " and erased it obviously).
I am seriously stuck and dont know any further than these steps. Setting up an include path does not seem to help - though I'm wondering if the CMAKE stuff had problems with space's or what is going on.
Since the authors of Emscripten and probably LLVM call their windows support "experimental", I'm not the only one having troubles trying to set up LLVM/clang for later use with Visual Studio 2010 (not 2012..). I'm sorry for the bad formatting, for some reason SO won't allow me neat formatting today.. I'm using a nightly browser build though.
If you just need a build of LLVM, you can generate NMake Makefiles and build with nmake instead of msbuild. It seems that there is a quoting issue somewhere (might be CMake, CmakeLists.txt, msbuild, who knows).
On second thought, this might be a problem with environment variables. How did you set up PATH? Try from a new "Visual Studio Developer Command Prompt".