Visual Studio 2010 is known for causing missed or unwanted rebuilds. Both are annoying. There are numerous posts on the topic.
I have observed that whenever you switch the Configuration or the Platform, the next Build will be a Rebuild. For the same reason, a Batch Build always performs a full Batch Rebuild.
So my question is specifically: is there a way to avoid that, after a switch (Configuration or Platform), the build turns to a rebuild.
As mentionned in the question comments, the problem comes from the "Intermediate Directory" pointing to same directory for every platform/configuration. The object files are then outputted in the same directory and creates conflicts when you change the configuration/platform, thus forcing a rebuild.
To avoid this problem, I recommend setting the Intermediate Directory to something like this:
$(SolutionDir)build\$(Configuration)\$(Platform)\
Related
I have (fairly large) C# solution in VS 2019, running with ReSharper. Since a few days - and I can't make out the trigger - the following happens:
I change code, add a breakpoint (not required, but makes the issue show nicely), click "Start" (triggering a build and a run) and the application runs, but using old code.
The breakpoint changes to "broken" after the build, which is quick. And the build log is unbelievably short, without any warnings, but also without errors. It lists that the project I made the change in was successfully rebuilt or at least that the build was started.
I thought I may have this issue, but the code executed is the old.
Is this a caching issue? Can I get better logs somewhere?
Is this (full re-install of VS) the only solution?
EDIT: It appears to be getting worse, by now I have to manually/explicitly rebuild my solution before running (almost) every time. And, if this is any hint: while trying to fix the issue, I deleted the hidden .vs folder (where the. suo files lives) - and it has not been re-created. Shouldn't it have been?
EDIT2: The link from dwcanillas below inspired me to search deeper in my solution folder for any nested .vs folders and, indeed, I found a few - not for every project, but for some. I deleted them all and today so far it appears to be better.
CURRENT SOLUTION (another visual studio voodoo recipe):
Clean top-level solution
Close Visual Studio
Delete all ".vs" folders (hidden, in every solution folder)
Open Visual Studio
Rebuild top-level solution
Observed side-effects: Previously unloaded projects will be loaded again. But there's probably more...
You may have to, though try rebuilding it first, and cleaning the solution as well.
There are a number of post in relation to Visual Studio building projects when not necessary. However, none seem to cover this particular issue.
I'm running Visual Studio 2012 Professional Update 4.
In my solution, I have a unit test project that has a project reference to a BizTalk Transforms project. This in-turn has a project reference to a BizTalk schemas project.
Every time I choose to run a unit test, the whole solution is built, even though no changes have been made.
The first line displayed in the build window is as follows:
Input file
'C:\Workspaces\rbowman\Branches\Current-branchRB\WareHouse\FFF.Enterprise.WareHouse.Schemas\FFF.Enterprise.WareHouse.Schemas.btproj.user'
is modified after output file
'C:\Workspaces\rbowman\Branches\Current-branchRB\WareHouse\FFF.Enterprise.WareHouse.Schemas\bin\Release\FFF.Enterprise.WareHouse.Schemas.pdb'.
Note: it seems to be the .user file that's causing the rebuild.
Does anyone know how to prevent this? Strange but I only seem to be getting the problem with BizTalk proj files. I am seeing this behavior across multiple solutions but the problem file is always identified as a btproj.user.
This screencast illustrates the problem: screencast link
You should remove the *.user file from your source control.
These files store user specific settings and should never be checked into source control.
I had the same problem. BizTalk projects insist on updating the btproj.user file on every build, resulting in a full rebuild every time.
I solved the problem with the following workaround: Set the ACL Write Flag on Deny. The build cannot update the file and the projects are only build when actually needed.
In my case build time went from 10 minutes to 2.
If you have just opened the solution, even if nothing has changed since the last time you built, if you click Run All, it will as per the description in Test Explorer do a build.
How can an incremental build using IncrediBuild detect when a source file has been deleted?
When I modify a source file it will be recompiled and the corresponding dll relinked -- but deleting the same file does nothing, even when a complete rebuild would fail. How can IncrediBuild be instructed to check for deleted files?
UPDATE
I understand that Visual Studio behaves the same way, so it is not really a bug of IncrediBuild. Nonetheless I seek to remedy this situation in a Good Way. Considering that the files being deleted are known, perhaps it is possible to implement a script that removes the corresponding object files or similar. Or perhaps there is a better way?
Modifying a source file and deleting a source file are two different things.
The scenario you are describing is a proper incremental build behavior and you will see the same behavior when building with Visual Studio (without IncrediBuild). When deleting a file and then performing an incremental build, a link step will be executed by the build system and fail whether you are using IncrediBuild or regular Visual Studio builds.
I have a solution with 40 projects in it. I've recently reconfigured output path for each of these projects to this value:
..\Output
Change was made in *.csproj files for every build configuration.
This change did what was expected (gather all compiled assemblies into one folder) but unusual side effect is - every time I hit F5 Debug, portion of the (around 40%) assemblies always gets rebuilt. I have tested this several times without any changes to the projects themselves.
Once I undid changes build behaved as before.
I need help resolving this issue.
This issue is solved by changing the project files, cleaning solution, deleting all bin folders by hand, restarting Visual studio and rebuilding everything.
I would guess that the assemblies that get rebuilt are referenced from the project you are trying to build? Check the references in one of the projects, and see if this is correct. If so, you might try to adjust the properties for each reference, such as "Copy Local", and/or "Specific Version"; maybe each project "thinks" it needs to rebuild the other projects it references in order to achieve the same version number or something like that.
I have a largeish solution in Visual Studio 2008 (around 30 projects, all C# and Script#), including some test projects.
When I start the application or run my tests, way to often Visual Studio rebuilds everything rather than just the changed parts and their dependencies.
If I don't change anything at all, it will not rebuild, but as soon as I change any file in any project, everything in the entire solution will be rebuilt, even the 90% of projects which were not affected at all.
Does anyone have an idea of what the problem can be, or provide me a hint of where I can start troubleshooting it?
Edit: To clarify, all projects in the solution are rebuilt, even those which are not directly or indirectly dependent on the project that has actually been modified. Even those which the modified project depends on, so it can't be a simple project reference issue.
The build sequence is determined by the project references (dependencies).
To avoid to build the projects depending on the project you've edited, you can use Build Current under the menu Build.
I setup CTL+B as shortcut to Build Current which saved me a lot of time than F6. Everytime I just use CTL+B after I save a file.
Hopefully this will help.
You can use the configuration manager to set up a specific config for your sln that will only build the projects you specify. You can find it under Build->Configuration Manager