Developers use the Visual Studio (VS) GUI to develop their solutions and get their projects all building using a solution file (.SLN). The build teams using vNext then have to automate those builds using MSBuild instead of devenv.exe (the Visual Studio executable file). This is a serious and chronic problem because not only is MSBuild incapable of building several project types, but the build order is defined in a completely different, and complex, way.
Some Microsoft advice (https://learn.microsoft.com/en-us/archive/blogs/msbuild/incorrect-solution-build-ordering-when-using-msbuild-exe) is to switch to explicit dependencies in each .*proj file and remove all dependency specifications in the .SLN file. This sounds like a person who has never worked in a relatively powerless build team trying to get development teams to:
do a lot of what they perceive as time-wasting extra work and to
change how they do things
What build teams need is a way to automate whatever VS allows dev teams to build. If VS is given a SLN to build, then a vNext build needs to be able to use that same SLN in the same way. Instead vNext currently only offers MSBuild as the build tool. MSBuild has many more options than devenv, so that would be great, IF it could be made to use the SLN to govern dependencies in the same way as VS, and would be upgraded to build all the same project types.
There have been prospective efforts, referenced by PatrickLu-MSFT at Build project using devenv.exe in TFS 15RC1 Build Server, to enhance a vNext build step to allow devenv to be used instead of MSBuild, but those efforts seem to have been dropped.
Maybe someone has developed a custom vNext build step to build using devenv?
Here is an existing extension you can reference, which provides a build task in your TFS/VSTS instance that will allow you to build your projects using DevEnv.com (Visual Studio):
https://marketplace.visualstudio.com/items?itemName=mmajcica.devenv-build
If you want to automatically use TFS/DevOps build whatever solution files our development teams get working using Visual Studio, you could set CI trigger in build pipeline, when the solution build successfully on local, you can check in/commit the changes, and trigger TFS/DevOps builds.
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 large solution of dozens of projects. Since yesterday (and for no good reason that I can find) the projects are refusing to build, with Visual Studio's build output window simply stating (eg)
1>------ Skipped Rebuild All: Project: Api.Models.Common ------
There are already a few similar q/a's here about the reasons why VS may decide to skip a build (Configuration not set to build, or set to build wrong target). I'm not interested in guesses as to why this isn't building. I'd really like answers to help me diagnose this, and have Visual Studio tell me why it thinks it can skip the build.
Is there a way to have VS generate anything more detailed than Skipped rebuild for example? It must be calling msbuild under the covers right? So can I have Visual Studio pass additional parameters to msbuild so that it generates diagnostic log output?
(For what it's worth - calling msbuild from the command line builds the projects as expected, so it seems like my issue is something quirky that VS is doing).
I'm using VS 2017 - 15.9.4
If you have any unload projects, you must load it or you remove it in solution.
Note: My unloaded project was the result of a permission issue. VS warned that a project was configured to use IIS. To run the project with IIS required launching VS as an administrator.
This was happening in my solution with Visual Studio 2019. I just migrated my applications from .Net Framework 4.6 to .NET5, almost all the projects were not building, it gets always skipped. The reason was that after the migration the tool upgrade assistant was not setting the Target Framwework as in the preceding image (Right-click on the project and then click on Properties).
After setting it to the right framework, in my case, it was .NET 5.0, the project started to build.
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/
I am debugging someone else's work and the solution is quite large. When I try to build the entire thing, several projects within the solution don't build and just skip. Viewing the output window during the build process says:
1>------ Skipped Rebuild All: Project: pr1lib ------
How can I determine why these builds were skipped? I am unable to find additional output.
This is with VS2008 and the solution is comprised of c# and c++ code.
Right click the solution, choose Properties and then Configuration Properties. Here you can choose which projects to build.
[edit]:
See Kdt's comment: ... when I looked in configuration properties ... the project build target was configured for "Mixed Platforms" while the solution was set to build "Any CPU".
*When this problem happened to me, The main project only had 'Any CPU' and it set the child dll to 'any CPU' too, however, I'd deleted that profile and left only 'x86'. Picking x86 for just the dll make it start working
[/edit]
Build, rebuild, and clean operations were being skipped. Unloading and reloading didn't help, and neither did restarting Visual Studio.
Once I removed the project from the solution and added it back, it is no longer skipped. To remove it, in Solution Explorer, right-click the project > Remove > OK. To add it back, in Solution Explorer, right-click the solution > Add > Existing Project and select your project
I just had the same problem- "unload project" and "reload project" solved the issue !
Restarting Visual Studio did the trick
If the confixguration is x64 and the x64 compiler isn't installed it will skip the project.
My solution is the same as mentioned previously: Delete -> Add existing project
But this solution implies that references between projects get gone
To avoid re-adding references: and in case if you use version-control system like GIT or TFS or whatever, it is possible to acheve goal with the following steps:
Make shure that all the changes are commited / checked-in before the operation
Go through all projects deletting them from solution and adding-existing them
Notice that the .sln file has changed
Keep the new .sln file, but undo the changes to all the .cspoj files with the version-control system
I had a weird one that may be worth documenting amongst the other possibilities here..
I'd added a Shared Project to my solution, with code that was used in two or three of the other projects. As you're aware - Shared Projects are just code, and not really a project in the traditional sense.. You can't 'build' a shared project, it's just code that is embedded into the other projects, and then built there.
But somehow my solution file had been updated as if the shared project was it's own thing that needed building. I'm guessing then that any time I was trying to build and I hadn't changed the code in the shared project, then it figured 'nothing has changed, skip those builds'
I found the shared project in the solution.sln file like:
Project("{D954291E-2A0B-460D-934E-DC6B0785DB48}") = "Api.Common", "Api.Common\Api.Common.shproj", "{EC580471-D78A-4509-AC46-BD565553AD60}"
..which is fine. What isn't fine is that this project also appeared in the GlobalSection(ProjectConfigurationPlatforms) = postSolution like:
{EC580471-D78A-4509-AC46-BD565553AD60}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
{EC580471-D78A-4509-AC46-BD565553AD60}.Debug|Any CPU.Build.0 = Debug|Any CPU
{EC580471-D78A-4509-AC46-BD565553AD60}.Release|Any CPU.ActiveCfg = Release|Any CPU
{EC580471-D78A-4509-AC46-BD565553AD60}.Release|Any CPU.Build.0 = Release|Any CPU
I removed those four lines from my .sln file, and now things seem happy again
The visual studio 2008 , it can be because 64 bit compiler wouldn't have installed.
Control Panel --> Programs and Features -> Microsoft Visual Studio 2008 professional --> [double click]
On Visual Studio Dialog
Next --> Add/ remove Features --> (Under) Visual C++ --> (select) x64 compiler and Tools
The first thing you need to do is diagnose why the build is skipping projects. So to get a detailed build output change the verbosity to detailed in the following place in Visual Studio.
Problem exists in VS 2010 as well; of the proposed solutions: editing build config, cleaning, changing/re-changing target framework, do NOT work. But unloading and reloading the project does.
I've just had this issue, and was able to resolve it by removing the hidden .vs folder in the topmost folder. After restarting Visual Studio everything worked again.
Hey, just fixed this one. Thought it might help. You most likely didn't install corresponding compilers along with the visual studio. This happened to me today - by default, VS 2008 installer doesn't install x64 C++ compiler.
If you have SP1, uninstall it before changing VS installation. When done, install SP1 again.
Close visual studio
Open the sln file with notepad
delete all of the things like this :
{B546C55D-9321-4FC0-B25C-46844222BEBE}.Debug with
Fakes|x86.ActiveCfg = Debug with Fakes|x86 (there will be a bunch of
them)
4.save the file
5.open visual studio and all better
Go to the build menu and choose "configuration manager". This will show which projects are configured to build in your selected configuration.
I had a similar thing just happen to me. I'm not sure what the problem was, but it would not Clean, Build, Rebuild, etc. I am operating in Visual Studio 2017 and wanted a netstandard2.0 assembly. The issue for me was that somehow the project type was incorrect, maybe I started from a netcoreapp class library, something like that, stuck in the Solution file, I do not recall. Anyway, I backed up the project, created a new netstandard class library project, and factored in the backed up bits, and that fixed it for me. HTH someone.
i updated to 15.9.11 , ... after some builds, same problem:most projects are skipped (which build a second ago without problems). Unloading/reloading the solution helps always in my case, but it will happen again soon.
I have no idea why... except a big bug in VS2017
I checked configuration manager , all checkmarks are set to build.
Maybe, it has something to do with nuget packages, but that is just a guess
The solution has only c++/vcxproj, no csproj. 64 and 32 are installed both
This happened to me in VS 2019, and the solution was to simply restart visual studio.
My build configuration was never modified.
I checked-in my project to source control from one computer and downloaded it to another and it will not build properly there. It will skip building projects and didn't even create the master \Debug folder for outputs.
The solution (VS2019) is to right click on solution and select Configuration Manager.
I saw the build checkbox was not checked for two projects that I was building (shown below). I don't know why they were unchecked but checking them and building project worked!
Right click on solution ->Remove then Add the existing project, this worked for me.
Had the same problem, found out that the project setting was for Itanium CPU, changing it to Intel fixed it.
Was running into the same problem with VS2005, all the configurations were correct .
It was even skipping the Clean project command.
Finally Unloading /Reloading did the magic.
Right click on Solution at at your solution explorer, then, click on Property at bottom of the menu. In the property windows, click on Configuration Properties -> Configuration on the left pane, you will see the list of projects on right pane, make sure Build check box is checked in the popup window.
If your solution contains a NuGet project (*.nuproj) file, try unloading it and then rebuilding your solution.
This worked for me after none of the above worked.
I had similar problem, I had one project which could not load in solution explorer due to some reason. When I loaded that project it worked like a charm.
I find that sometimes when you have target platform as set to lets say x86 in your solution and in your projects the project does not actually always had it selected.
To double check go to the project properties and see if you can select that platform in the Build->Platform setting if you can not then you will need to go to the configuration manager and create that configuration.
I had this problem with some Windows CE projects on a new PC. "Unload project" and "Reload project" appeared to fix the problem, but actually Visual Studio had simply switched to a different platform and built that.
It turned out that although my WinCE platform was shown as the active platform, Visual Studio didn't "really" see it. The solution was to reinstall the WinCE SDK with administrator priveleges:
Make sure Visual Studio 2008 is not running.
Open a “Visual Studio 2008 Command Prompt” as Administrator. On Windows 7 just right click the short cut and pick the “Run as administrator” option.
Enter the following command: msiexec /log SDKInstallLog.txt /package <the path to your .msi file>
When asked if you wish to do a custom or complete install pick custom, and instruct the installer to omit the installation of the documentation (this step was not necessary in my case; in fact I just asked it to "repair" the existing installation.)
Install
VS 2008 will skip x64 targets if you don't have the x64 compiler installed. VS 2008 does not by default. Kind of a duh, thing.
I had a very similar issue after generating a project from a decompiler from Telerik, then trying to recompile it. The project was skipped whenever I tried to rebuild it. Tried a lot of the suggestions above, but for me, it was the .NET Framework selected in the project properties.
Right-click project in solution file, select properties, application tab, change target framework from 4.0 to 3.5.
Then, rebuild, and I got a bunch of assembly reference missing errors, which makes sense since I haven't added references to them yet.
I update one small update of Visual Studio 2017 and then the installer reminds me to restart my computer,but I did not restart.When I build my project or solution in Visual Studio 2017,I meet the same above problem.I guess the update maybe the key,so I restart my computer,I did it.:>
I had this problem in Visual Studio 2017 15.9.4 and after some searching and putting some time I found out that in my solution the .csproj file of one of projects got corrupted after merging in TFS. (I could build other projects by unloading the problematic project from solution).
How I resolved my problem was that I compared the .csproj file before and after the merge and do fix that. And by fix I mean since my own project's type was .netStandard I removed unnecessary lines including Configuration PropertyGroup, all and others in the new .csproj file to make it similar to previous .netstandard-style version.