I want to execute a postbuild command after every build, no matter what project in my solution has changed.
To accomplish this in Visual Studio 2010, I made one empty project depend on every other project, so it always got built, executing its postbuild command. However, Visual Studio 2012 (RC) appears to recognize that the dependency is not real, and will not build this empty project automatically.
I do not see any way to specify a solution postbuild script in solution settings. How can I accomplish this?
I have solved this issue by making my post-build script also delete the output (bin**) of this "empty" project, forcing a rebuild of this project every time. It appears to work satisfactorily so far.
This works (for details see original post):
you may need to change security settings (at your own risk) e.g.: https://stackoverflow.com/a/60284384/2705777
Related
I have a solution called MainWindow.vs2015.sln for my Application. This has nearly 100 Projects and it builds perfectly in Visual Studio 2015. When I build the solution from the command line using devenv, it also works perfectly and there are no errors.
However, when I build from the command line, and then open Visual Studio 2015 and build it again, expecting an almost instantaneous build as I had already built from the command line, it builds the whole thing all over again and I am sat there for up to nearly 30 mins waiting for something to build all over again.
Is there some kind of difference between the devenv command and Visual Studio builds?
P.S I have also MSBuild as well as devenv and have had the same problem.
devenv MainWindow.vs2015.sln /Build "Debug ALL"
What's your project type? VB.net, C# or C++?
For .net projects:
If we create a new VS2015 C# project in command-line, build it in Debug+x64 combination. After that when open the project in IDE and build it, it will display Up-To-Date, and won't compile and build again since nothing changes.
So if you meet the build twice issue in C# projects, set the Build Output verbosity to Detailed or higher in VS to see detailed info about the build process.
After that, when you again meet this issue, trying reading the very first of the log to see the reason why VS builds it again! Check if you have some files missing or set as Copy Always like this.
For C++ projects:
If you're in a solution with many C++ projects in it. I'm afraid the answer could be negative. I test it in VS2015 C++ projects and I can reproduce same issue. I found if we create a C++ project, build it in command-line and then VS. VS will consider it not to be up-to-date and try to build it again...
Something interesting is if we build it not by command-line, instead we build it twice in VS, VS can recognize it's update-to-date and won't waste time to build it the second time.
So I suggest you could avoid building it in command-line before building in VS. Cause there's no advantage that we build the project using two ways while we don't do actual modify to the source files. Also, since there's something that can be improved about the Up-To-Date check in VS for C++ projects, you can post a feature request in DC and you can get help from the Product Team there.
In addition: Please make sure the Configuration+Platform you use to build solution in command-line are the same when you build in VS IDE.
Hope it makes some help :)
I have a question regarding the difference I have noticed when building a solution file using MSBuild from command line and when doing it inside Visual Studio 2013 Update 4. The solution file I am using contains a lot of projects.
Case: Using MSBuild
After successfully building the solution file, if I try to build it again, MSBuild notifies me that the projects are up-to-date and it doesn't try to compile any source files, which is evidently the expected behavior. Nevertheless, it actually tries to execute or goes through the targets in the Build step trying to determine whether the Output files are out-of-date and this occurs for every project that is existent in the solution. Even though it doesn't build the solution again, the process of checking time stamps of files for each project actually takes quite a long time.
Case: Using Visual Studio
When doing it inside Visual Studio, after a successful build, if I try to build the solution again, then it automatically notifies me that the projects are up-to-date. It actually takes few seconds to return this output. Looking at the build output, I noticed Visual Studio doesn't really execute targets in the Build step to conclude that the projects are up-to-date. So I figured it must be using something different to check the statuses of the projects.
I really want to bridge the performance gap between these two "worlds". I would appreciate any help or hints in regards to how Visual Studio is performing this check or ways I could implement something similar in MSBuild.
Cheers!
I have recently converted a mid-sized Visual Studio 2005 solution to Visual Studio 2010.
One of the projects contains files which are not C/C++ files and are compiled using a batch file running a custom build tool. The output of the custom build step is some C++ files, which must be compiled after that.
The output of the custom build step in the properties for the relevant files is correctly set to the generated C++ files.
The problem is that sometimes VS2010 tries to compile the generated C++ files before the files with the custom build step, which means in a clean build it fails to find the C++ files and fails. If I try building several times eventually it would compile the custom files and then the build will succeed, but this is obviously not a good solution for automated build.
In VS2005 there is no problem building this project, but VS2010 fails to determine the correct compile order from the outputs of the custom build step. Is there another way to force correct compile order in VS2010?
Visual Studio supports parallel builds, it can build more than one project at the same time. This will not work properly if it cannot properly see the dependencies between projects. A custom build can certainly be a troublemaker here. The number of parallel builds is configurable, setting it to 1 would be a very crude but effective workaround. Tools + Options, Projects and Solutions, Build and Run, "maximum number of parallel project builds" setting.
But don't do that, parallel builds can be a huge time saver. You fix this kind of problem by setting project dependencies explicitly. Right-click the project that uses the generated C++ files in the Solution Explorer window and click Project Dependencies. Tick the check box for the project that produces the C++ files. In case it is relevant to other readers, check this answer for a way to create a project that only does the custom build step and nothing else.
Visual Studio 2008 by default executes custom build tools first. The order can be changed via right click menu on project with command "Tool Build Order". This facility is not available in Visual Studio 2010. I do not know of a work-around.
Consider using Visual Studio 2010's "Properties >> Configuration Properties >> Build Events >> Pre-Build Event" as the place where you should issue command(s) to build source files that must be compiled first. In the Command Line field, call upon the cl.exe compiler or use a small external makefile to compile those files. Visual Studio will then compile the rest of your project following this initial step.
I resolved my problem when I noticed that my custom build step runs for only one file at a time. It runs for the next file on the next build etc.
The reason apparently is that my custom build steps are calling a batch file and VS2010 creates one temporary batch file to execute all custom build files.
The solution was pointed in this discussion:
http://social.msdn.microsoft.com/Forums/en-HK/msbuild/thread/ca392036-ebdb-4812-930e-f90aa445cca5
It is simply to prefix all calls to batch files with a "call" statement, thus not terminating the execution of the master batch file prematurely.
I'm a solo developer running Visual Studio 2008 and looking into MSBuild to improve my build process.
Almost all of the tutorials I've found so far have plenty of information about writing a build file. However I'm having a lot of trouble finding out how to integrate MSBuild into Visual Studio. Maybe MSBuild is only used with something like CruiseControl but that's overkill for me as a single developer.
Where should the build file live in a Visual Studio project and how can I run it from within the IDE?
Visual Studio executes MSBuild automatically for projects it supports.
If you right click on a project and unload it, you can then edit it in Visual Studio. Reload (right click on project again), force a (re)build to test your changes. An alternative is to edit the project file in an external editor and Visual Studio will detect saves and offer to reload the project for you.
Sounds like you're on the right track, and if you are considering writing Targets or custom MSBuild Tasks, take the time to separate them from your current project so that you can re-use them. Don't re-invent the wheel though, the two main complementary MSBuild projects are MSBuild Community Tasks and MSBuild Extension Pack.
Update: Judging from your comment on Mitch's answer, you might also want to consider adding a new Configuration element or custom properties to a project. A new MSBuild Configuration (something other than the default Debug/Release) could run unit tests, build documentation, or whatever you want automated. A custom MSBuild property would allow you to use normal Debug/Release Configuration and extend it to automate more of your build process, just depends on what you want. Either approach could also be driven from the command line.
As others have noted, MSBuild is already available when you install Visual Studio.
If you want to integrate into VS2008: Running MSBuild from Visual Studio
MSBuild is the build engine used by Visual Studio to process the files included in a project.The Visual Studio project files themselves (**.csproj* for C#, and .vbproj for VB, for example) are in fact MSBuild scripts that are run every time you build a project.
Your .csproj file is a MSBuild file. So you are actually using it already.
You may of course wish to create a separate build file to have more control, especially within a continuous integration or nightly build say.
If you simply wish to edit your project build file then you can use the IDE to edit some settings such as pre and post build actions or edit the Xml itself by unloading project and right click and editing.
You can use your current .vcproj files to build your project with MSBuild. However, as MSBuild is not directly supported (at least for vc++) vcbuild is used instead (internally).
In VS2010 all project files are MSBuild based...
This is an older article about some simple extension points from the msbuild team
How To: Insert Custom Process at Specific Points During Build
Also, don't forget you can use the MSBuild SideKick for developing and debugging your (local) msbuilds, available for free at http://www.attrice.info/msbuild/
I'd suggest you call msbuild as a post build step. Then you can put your build script somewhere in your solution and call it.
<windowsdir>\Microsoft.NET\Framework\v3.5\MSBuild.exe c:\temp\MyProject\mybuildfile.proj
The easiest way is probably to invoke your custom build script using a post-build step. Right click project, choose "Build Events" and call msbuild with your custom msbuild file from there.
I use the msbuild template to intergrate with visual studio
http://msbuildtemplate.codeplex.com/
Will Visual Studio choke on customized .csproj files?
For example, I wanted to add a Target to update the version number in all AssemblyInfo.cs files. I plan to invoke this from the command line with MSbuild.
As another example, I would like to include the build timestamp into the compile, like so. This would be a pre-compile step (I guess), and unlike the example above, this one would run from within a build inside Visual Studio.
Will VS be ok with this?
As long as the code is a valid MSBuild extension, Visual Studio should be able to handle it. Under the hood the project files are really just MSBuild files and MSBuild does the dirty work of the VS build system. So as long as the file remains a valid MSBuild file it should be just fine.
Yes it does allow customizations. We integrated FxCop with our release-mode builds this way.
It will complain when you first load the project file after it's been edited, saying "it's been tampered with, do you wish to continue loading?" Just hit yes and continue on your merry way. It also lets you check a box to ignore the rest of the projects in the solution for the same warning.