My project has 15 projects and 1 solution file
If my source code has not been modified, Visual Studio prompts me if I want to build the 15 project files?
There is a box to say not to display it again, I'm not sure why Visual Studio thinks the code is out of date?
Thanks for the feedback
If my source code has not been modified, Visual Studio prompts me if I
want to build the 15 project files?
No. If your code has not been changed, it will always show up-to-date, not build. VS has the feature of incremental build.
Note: you should click Build button rather than Rebuild. Rebuild will execute clean and then build, so it will always execute the whole build process.
Once you do not modify the resource files, MSBuild will detect that the project has not changed and does not need to be built again, turns out to up-to-date.
Therefore, under normal circumstances, MSBuild will not build again without changing the project.
There is a box to say not to display it again, I'm not sure why Visual
Studio thinks the code is out of date?
In fact, it should not happen.
If you have not made any changes to the project but the build still displays out-of-date, you have to check the diagnostic build log and find it out.
Enter Tools-->Options-->Projects and Solutions-->Build and Run--> set MSBuild project build output verbosity to Diagnostic . And then build your project to find the cause out.
Maybe you have set Copy To Output Directories of some files to Copy always or you have lost the files for inputs and ouputs, .... so on.
Related
Lately we (the team I work with and myself) have been seeing something strange between the build results of MS-build and Visual Studio (2015).
The situation
The team I work with has been tasked with refactoring an older and rather large c# project that contains many (150+) projects all bundled into a single sln file. As to be expected merge conflicts occur in the sln file during our work and one of the team members resolved this conflict incorrectly. Leaving the sln file with a missing project reference.
From here on out the behavior of the project is different on 3 location. They are described below
Visual studio of the developer that origionally made the mistake
(note that I assume that this developer has not cleaned his solution)
This programmer has already build and run the project (using visual studio 2015 professional). So all compiled dll files are in the prorammers output folder. This means that Visual studio does not notice that a reference is missing. The programmer can build, run and test the application without any problems.
The build server
The build server (Jenkins) does not run Visual studio, but it uses MS-build 14 to compile the source code. The Jenkins server is configured to run with pipelines, described in groovy. We call ms build by invoking a bat script that runs MS-build over the command line. An example:
"C:\Program Files (x86)\MSBuild\14.0\Bin\amd64\msbuild.exe" "TheSolutionFile.sln" /property:Configuration="Debug" /property:Platform="Any CPU"
Somehow the build will succeed even with the incorrect sln file. I suspect that ms build resolves its own dependencies as the workspace on the buildserver is clean (completely empty) so no leftover dll's can fool the system. (am I correct in assuming this?)
The other team members
The other team members will eventually pull the changes of the broken sln file and they will be in for some 'fun'. When you do not have the dll files in your output folder Visual studio will attempt to rebuild the missing dependencies. But since the references cannot be resolved it will fail and start stacking errors about missing meta data. In the team we all use Visual studio 2015. But we also tried it with 2017 and ran into the same result. The person who originally made the mistake can also end up in this group of he cleans the solution.
The Question
Obviously we are not happy with the fact that the build server accepts the build with a broken sln file (a developer pulling the latest version cannot compile or run the program). Is there a way to get the last two situations in sync (so ms build not accepting a 'broken' sln file to compile)
Is there a way to get the last two situations in sync (so ms build not accepting a 'broken' sln file to compile
That is because MSBuild.exe from command line does not have the same build environment as Visual Studio. You can call MSBuild.exe from VS command promt which has the same biuld environment as Visual Studio.
If you want call ms build by invoking a bat script that runs MS-build over the command line, you can use devenv.exe to build the solution/project from command line:
C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE>devenv "D:\TestSample\TestProject\TestProject\TestProject.sln" /build Debug /project "TestProject\TestProject.csproj" /projectconfig Debug
For the detail information about devenv.exe you can refer to Devenv Command Line.
Hope this can help you.
My advice:
The .sln file is just a collection of project files. Create a brand new one, and add in your proj files one by one. Forget the code-merge-conflict-resolution drama.
The voodoo in the .sln file is too much voodoo. Let VS do it for you...as you add each project in, one by one.
File / New / Project ::: Installed / Templates / Other Project Types / Visual Studio Solution ::: Blank
Solution.
One other hint. If you still have issues, then open up each proj, and any "by project" references, delete them and re-add them. Sometimes the GUID's get mixed up, especially over a long code-merge history.
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 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
I've written a VS addin which intercepts Visual Studio's build command and uses another build system to do a build. I've got my build showing errors in the right format so that you can click on them in VS but the one step remaining for completely seamless integration is to prevent VS's "run" or "debug" commands from whining the it doesn't think the project is built (when of course it is) does anyone know how I can trick VS into thinking the project is built?
Shortly, MSBuild / Visual Studio checks what is output of defined targets in configuration of particular project. Next it compares timestamp of file(s) specified as target output with timestamps of all files specified as input for that particular target. If input is more up-to-date than output, then it requests to regenerate output (re-compile source code or re-link object files, etc.)
How I can trick VS into thinking the project is built?
Update timestamp of input files, namely source files (.cpp, .cs) or binary files like .obj used as input for linker and other files that are of your interest.
Sometimes I do it manually issuing the following command using touch utility from GnuWIn32
touch myfile.obj
Visual Studio uses the date/time stamp of the source files. If the source file is more up-to-date then the compiled binary located in bin\debug or bin\release, Visual Studio will rebuild the solution.
Sometimes, the rebuild process can fail, the quick solution is to delete the intermediate debug files *.pdb within the solution's bin\debug or bin\release folder. Then issue a build on the solution.
Hope this helps,
Best regards,
Tom.