I am trying to build a solution via devenv.com and I get errors. The command I use:
set devenvCom=C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\devenv.com
"%devenvCom%" "C:\...\mySolution.sln" /Build "Release|AnyCPU"
I get an error: "The operation could not be completed"
But if I run it without a platform configuration:
set devenvCom=C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\devenv.com
"%devenvCom%" "C:\...\mySolution.sln" /Build "Release"
This works fine.
But in their documentation they say that you can use the format: /Build "Release|AnyCPU"
And it doesn't matter if Irun the command using devenv.exe or devenv.com they both fail.
How can I run the command successfuly?
The syntax you have in both of your commands - with and without platform - is correct for devenv.com in Visual Studio 2017, according to Microsoft documentation at https://learn.microsoft.com/en-us/visualstudio/ide/reference/build-devenv-exe?view=vs-2017.
I run similar commands with devenv.com in VS2019 without any difficulty, via a batch file run as part of a Jenkins job.
The following notes may assist in resolving this issue:
When defining environment variables for file or folder paths, I suggest using double quotes as follows:
set "devenvCom=C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\devenv.com"
These double quotes make it easier to ensure you have not added any trailing whitespace to the environment variable value by mistake. The double quotes also ensure that any parentheses or ampersands in the path will not be misinterpreted by the cmd.exe shell.
It is fine to double quote the parameter which follows /Build, e.g. /Build "Release". These double quotes are REQUIRED when specifying the platform such as /Build "Release|AnyCPU", to ensure the vertical bar is not misinterpreted by the cmd.exe shell, or when the build configuration name contains a space.
I recommend /Rebuild rather than /Build when performing automated builds. Only the former is guaranteed to perform a complete build from scratch.
Microsoft documentation states "Insert one space character between switches and arguments on the same line", i.e. put ONE SPACE between the /Build parameter and the value which follows it, e.g. "Release|AnyCPU".
The name of the build configuration and platform, e.g. "Release|AnyCPU", is expected to be found in the specified solution file. These solution build configurations names and platforms do not have to correspond to the project build configuration names and platforms (though they should whenever possible).
If you wish to build a single project only, I have been successful with the following syntax in VS2019:
"%devenvCom%" "C:\...\myProject.vcxproj" /Build "Release|AnyCPU" /Project "myProject"
Note that the first parameter in the above example is a project file, rather than a solution file. I believe that the specified build configuration and platform refer to the project rather than the unspecified solution (note: Visual Studio may create a temporary solution when performing single project builds if it cannot find a solution that corresponds to the specified project).
For single project builds, I previously had success specifying the solution file first, and the project file after /Project, but this previous syntax does not consistently succeed in VS2019 build 16.11.2 - it can lead to devenv.exe remaining running indefinitely after the project builds successfully (devenv.exe gets launched by devenv.com).
Your VS2017 installation may be corrupt, or you may have an extension that is interfering with VS2017.
Related
I have a solution that contains both C++ and C# projects that is built in a nightly CI build on a remote machine. The build script checks out a clean copy of the source and builds both debug and release configurations of the solution using MSBuild and runs the test suite on each configuration.
About every other build, the release configuration fails to build properly. An analysis of the build log reveals that C++ Project Q, which depends on C++ Project D, tries to link before Project D is done. This error only happens for the release configuration on this particular build machine - the debug configuration builds without error. I have a separate nightly build process that runs on a separate machine where the release configuration is built with a similar script that uses MSBuild (it just does not run the test suite), and it builds the same source revision without issue. Multiple team members build the solution without issue either from update or clean checkout with one or both configurations, always from the Visual Studio 2019 IDE, on various operating systems.
Project Q is configured with Project D as a project reference and Project D is also listed as a hard-dependency for Project Q. As I mentioned, the build script is using MSBuild.
An additional item of interest from analysis of the release and debug build logs: The build of Project D is initiated differently between the two configuration builds. It is started by its own metaproject in the release configuration (as item 60, for instance), but started earlier (as item 44, for instance), by a different project in the debug configuration. Not sure why the dependency algorithm would run with such different results in the two cases since the solution and working source being built are the same.
Any ideas or suggestions would be appreciated.
Update: Inspection of differences between the release and debug build logs reveals some interesting facts. In the failure case I did a search for ") is building" in each log - should be an indication of how many projects were built, including metaproj entries. For the failure case, debug had 282 occurrences, whereas release had 175. For the success case, debug had 280 occurrences and release had a whopping 559! A similar search for "Done Building Project" yields similar results, only off by 1 or 2. That might partly explain the differences in build order between the solutions. I also need to check for conditional build entries.
Visual Studio 2019 Reference Project Not Built Before Dependent
Project Tries To Link in Release Configuration using MSBuild
It seems that project buid order was broken and Project D built later than Project Q which need the output content of Project D, so the whole build failed.
Not sure that if you use Project Dependency(Right-click on project-->Build Dependencies-->Project Dependencies), if so, only VS IDE Build Will recognize their build order while MSBuild command line will lose the relationship about them.
Besides, I wonder if your main project under Release mode references a dependency project under Release mode. If you did these, the build will definitely go wrong.
All of these above is that I think you made some changes to your project.
You could follow these steps:
1) I suggest you could try to use Project Reference and it will add these xml node in ProjectQ.csproj file to strongly specify build relationship:
<ItemGroup>
<ProjectReference Include="..\ProjectD\ProjectD.csproj">
<Project>{26c26cdd-a5e0-40c7-b0c9-4563f969424f}</Project>
<Name>ProjectD</Name>
</ProjectReference>
</ItemGroup>
Also, check if there are any conditions that distinguish between Debug or Release mode when referring to a project like this:
<ProjectReference Include="..\ProjectD\ProjectD.csproj" Condition="'$(Configuration)'=='Debug'">
If so, please remove that condition Condition="'$(Configuration)'=='Debug'" to make sure it is the same between Debug and Release mode.
2) close VS Instance, delete .vs hidden folder under solution folder.
3) check your CI Build and cloud build server and ensure that cloud parameters are consistent with other servers. And examine any of your xxx.csproj files to check if you have any other operations which causes this bahavior.
In addition, if necessary, you can share your xxx.csproj file and the build script with us to troubleshoot it.
I have mixed C#/C++ solution in VS2013. One of the C++ projects is getting rebuilt every time I run build even when nothing is changed. In the diagnostic output it says:
1> Project not up to date because the following 1 build inputs were missing:
1> up to date is missing: 'PROJECT_OUTPUT_PATH\TMP_RANDOMGUID.RSP'
When I run MSBuild.exe from cmd line, I get following output:
"…\TMP_RANDOMGUID.RSP" does not exist; source compilation required.
Note that random guid changes every time I run build.
This .rsp file is listed as input file for the task "LIB" among other .obj files.
A lot of projects are dependent on this one, so this triggers a rebuild of almost entire solution.
I found out on MSDN that .rsp is MSBuild response file which contains MSBuild.exe command line switches. It looks like the project is configured so that every compile is through a generated .rsp file, can this be turned off in Visual Studio?
Perform this steps if as apply to your environment:
Delete every single output folder of your solution and projects (typically called "Debug", "Release", "x86" and "x64")
Delete every precompiled output folders of your solution and projects (typically called "ipch")
Delete files *.filters, *.user, *.sdf, *.suo
Invoke msbuild with clean target: msbuild /t:clean
Invoke msbuild: msbuild
It is done. Now you should be able to recompile only the based on file changes.
I want the commandline for building a particular project of a solution using msbuild like we do with devenv.com.In devenv.com we can specify a project of a solution using following commandline
devenv.com /Build Release|x86 test.sln /project "testproject"
Using the above commandline i can build the testproject in the test.sln using devenv.com.What is the commandline for msbuild for the same solution.
Thanks
msbuild test.sln /t:project /p:Configuration="Release" /p:Platform="x86" /p:BuildProjectReferences=false
Notice that what is assigned to /t is the project name in the solution, it can be different from the project file name.
Also, as stated in How to: Build specific targets in solutions by using MSBuild.exe:
If the project name contains any of the characters %, $, #, ;, ., (, ), or ', replace them with an _ in the specified target name.
You can also build multiple projects at once:
msbuild test.sln /t:project;project2 /p:Configuration="Release" /p:Platform="x86" /p:BuildProjectReferences=false
To rebuild or clean, change /t:project to /t:project:clean or /t:project:rebuild
MSBuild actually works through the use of projects not the solution. The solution is only used to parse it into a temporary project file in MSBuild internally. You should be able to just build the project of interest directly through MSBuild by executing the following command.
"msbuild testproject /p:Configuration=Release /p:Platform=x86"
There is one major issue I know you could run into using the project directly instead of the solution: if you use the solution to express dependencies between the projects, instead of adding the references to the project and letting the build system work out the dependencies automatically.
If you are enforcing a build order using the sln file, I recommend working those dependencies directly into the proj files and removing them from the sln. This will allow you to invoke any proj file from MSBuild directly and the projects will all build independently without any additional work. You really should treat the sln file as a group of projects to make working in Visual Studio easier and not as a build input.
Posting as information to future seekers
Add the following to the build script and run it once. This will generate the exact targets and other information that msbuild will actually use.
Ex: If you have . in the project name or folders msbuild will expect _ in place of the ..
set MSBuildEmitSolution=1
After getting the information update the build script with the required details.
In order to do this, you need to know what the project's target-name is, not necessarily the project name.
One way to find this out is to use MSBuild against your SLN with intended parameters after setting a special environment variable called MSBuildEmitSolution to the value of 1.
set MSBuildEmitSolution=1
msbuild my_stuff.sln /t:rebuild /p:Configuration=Release /p:Platform=x64
I recently had to do this due to a very specific name for a target in nested directories. So from my generated file, my_stuff.sln.metaproj I found this line:
<Target Name="Utils\Firewall\FirewallUtils:Rebuild">
That means the command-line to use ends up being,
msbuild my_stuff.sln /t:Utils\Firewall\FirewallUtils:Rebuild /p:Configuration=Release /p:Platform=x64
Just to add additional information, executing msbuild in the project folder will by default build the project file since its the only one there.
>msbuild
There are many variations of using msbuild this way. You can specify the proj file directly.
>msbuild helloworld.csproj -t:Build.
Review the msbuild documentation for usage, proj file requirements, as well and the benefits of building the project instead of the solution.
MS MSBuild Documentation
There are benefits to building this way as mentioned by mark-smith above.
I'm currently working on a console application that will pass a vcxproj file and compile it using GCC. Unfortunately, I've come up against a whole load of problems pretty much instantly.
I notice a bunch of directory shortcuts such as:
VCTargetsPath
VCInstallDir
SolutionDir
ProjectDir
UserRootDir
and so on.
Where does MSBuild get these values from? I assumed they were environment variables set up for the MSBuild process (afterall known environment variables are addressed the same way, ie "$(...)"). This was a bad assumption so I'm left wondering exactly how I get at these. Has anyone any idea on this?
Any info would be much appreciated :)
The MSBuild executable (and dependent DLLs) processes those properties the same way it processes any other property in the build file. In this case, they're simply predefined properties that it looks for explicitly.
If you really want to dig into it, open up the Microsoft.Build.dll in Reflector and look for the Microsoft.Build.Construction.SolutionProjectGenerator.AddGlobalProperties(...) method to get an idea of how it's handling some of the well known properties.
As an additional note, make sure you fully navigate down Import directives and handle overwriting of property and item values with each Import. There's a number of properties and items that are part of a Visual Studio build that are not always necessary for your code to compile correctly.
I believe that these are tied to Visual Studio macros: MSDN
Some of them are defined by the location of your files
SolutionDir - the directory containing the solution (.sln) file including this project
ProjectDir - the directory containing the project file (.vcproj, .vcxproj)
Others are defined by the location of the MSVC install
VCInstallDir - where the Visual C portion of Visual Studio is installed. ie. C:\Program Files\Microsoft Visual Studio 8\VC
and so on, and would be internal to msbuild based on what you loaded.
I'd like to build all the configurations of a VS 2008 C++ project on the command line. Something like:
devenv TheProject.vcproj /build /nologo
But this doesn't work because the /build command insists on having a configuration following it like this:
devenv TheProject.vcproj /build "Release|Win32" /nologo
Is there a way to get a command line build of all configurations within the vcproj file?
I was thinking you can do what you want with MSBUILD, but it appears that it isn't much better for this than DEVENV.
You still have to specify each configuration on the command line, although it would be easy to write a batch file to accomplish this with either MSBUILD or DEVENV.
It looks like previous versions of the development environment may have supported an "ALL" option, but VS 2008 does not.
http://social.msdn.microsoft.com/Forums/en-US/msbuild/thread/8701b3d0-d5c9-45fb-8dd4-e7700c8caca6/
Not directly, but you can have projects depend on other projects - so you could have an 'all' or 'install' project with a dependacy of everything else.
Haven't used VS in a long time. But the project properties panel used to show the command line generated for linking and compiling a project for a particular configuration. It used to be under the Advanced tab. Will using that directly from the command line serve your purpose? This method will not use the VS IDE at all.
Alternatively,
Steps:
Create a project which has a dependency on all other projects.
Write a script which builds this project with different configurations sequentially. You cannot create a single configuration which encapsulates all other configurations.