I'm trying to use MSBuild.exe to build my Visual Studio 2017 based VSIX. I can't just build the solution as I don't want to build other projects in there. I tried using variations of the following command but these do not produce a VSIX file:
C:/Program Files (x86)/Microsoft Visual Studio/2017/Enterprise/MSBuild/15.0/Bin/MSBuild.exe" /v:normal /p:Configuration="Release" /p:Platform=AnyCPU /p:DeployExtension=false /target:Build "C:/code/Templates/Source/Boilerplate.Vsix/Boilerplate.Vsix.csproj
The solution was to add the magic /p:VisualStudioVersion=15.0 parameter like so:
C:/Program Files (x86)/Microsoft Visual Studio/2017/Enterprise/MSBuild/15.0/Bin/MSBuild.exe /p:Configuration="Release" /p:DeployExtension=false /p:VisualStudioVersion=15.0 "C:/code/Templates/Source/Boilerplate.Vsix/Boilerplate.Vsix.csproj"
go to your configuration manager and deselect the projects you do not want to build. (Right click you solution and chose configuration manager..). You can chose between release and debug in the top left as well.
Related
I am trying to build my code with Cmake and Visual Studio 2019 Build Tools.
Note that I'm not using the IDE only the Build Tools CLI.
When I try to generate my project like this:
cmake -G "Visual Studio 16 2019" -S . -B .
CMake returns this:
Generator
Visual Studio 16 2019
could not find specified instance of Visual Studio:
C:/Program Files (x86)/Microsoft Visual Studio/2019/Community
How can I make CMake to look for the Build Tools location and not for the IDE location?
I haven't used Visual Studio in years, but according to CMake's documentation on the Visual Studio 16 2019 generator, you can use a CMake variable or an environment variable to control which instance you use.
VS 2019 supports multiple installations on the same machine. The CMAKE_GENERATOR_INSTANCE variable may be set as a cache entry containing the absolute path to a Visual Studio instance. If the value is not specified explicitly by the user or a toolchain file, CMake queries the Visual Studio Installer to locate VS instances, chooses one, and sets the variable as a cache entry to hold the value persistently.
When CMake first chooses an instance, if the VS160COMNTOOLS environment variable is set and points to the Common7/Tools directory within one of the instances, that instance will be used. Otherwise, if more than one instance is installed we do not define which one is chosen by default.
Make sure you have all of the necessary individual components selected when installing the build tools.
Make sure CMake can find the tools (e.g. add the paths to your Path variable).
As a proof of concept for my case, I added the following to my user Path variable for lib.exe, cl.exe, link.exe, etc...:
C:/Program Files (x86)/Microsoft Visual Studio/2019/BuildTools/VC/Tools/MSVC/14.27.29110/bin/Hostx64/x64
And the following path for mt.exe and rc.exe:
C:/Program Files (x86)/Windows Kits/10/bin/10.0.18362.0/x64
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.
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.
Currently we are planning to use VS2017 with a cmake project. Inside Visual Studio this works quite like a charm.
Now want to run our builds as part of CI on a dedicated build master running MSBuildTools.
Is it possible to directly run the build using the msbuild command, without creating solution files with cmake? Optimally, I would even use the CMakeSettings.json used from VS2017.
Use the build-tool-mode of CMake for this. It uses the underlying default build tool which is MSBuild for Visual Studio Generators.
From the build directory call:
cmake --build . --target ALL_BUILD --config Release -- /nologo /verbosity:minimal /maxcpucount
and you get a fast, nearly quiet build. To install use INSTALL target, for running your tests if configured use RUN_TESTS target.
Is it possible to directly run the build using the msbuild command, without creating solution files with cmake?
Is it possible to directly run the build using the msbuild command, without creating solution files with cmake?
As far as I know, CMake produces Visual Studio Projects and Solutions seamlessly. So you can produce projects/solutions.
The only tricky part is to remember to make any changes in the cmake files, rather than from within Visual Studio.
In particular, each CMake project will create a Visual Studio solution (.sln file), while all of the CMake targets belonging to that CMake project will appear as Visual Studio projects within the corresponding solution.
CMake Visual Studio
project <-> Solution (.sln)
Target <-> Project (.vcxproj)
You can check cmake-and-visual-studio for more details.
Since MSbuild can build both solution files and project files, so you could also call msbuild INSTALL.vcxproj
Is it possible to even use the CMakeSettings.json used in VS2017?
The answer is yes, check the blog for details.
If your CMake project requires additional settings to configure the
CMake cache correctly, you can customize these settings by creating a
CMakeSettings.json file in the same folder with the root
CMakeLists.txt. In this file you can specify as many CMake
configurations as you need – you will be able to switch between them
at any time.
You can create the CMakeSettings.json file by selecting the Project >
Edit Settings > path-to-CMakeLists (configuration-name) menu entry.
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".