I have a C# project which includes one exe and 11 library files. The exe references all the libraries, and lib1 may reference lib2, lib3, lib4, etc.
If I make a change to a class in lib1 and built the solution, I assumed that only lib1 and the exe would need to be changed. However, all dll's and the exe are being built if I want to run the solution.
Is there a way that I can stop the dependencies from being built if they have not been changed?
Is the key this phrase? "However, all dll's and the exe are being built if I want to run the solution"
Visual Studio will always try to build everything when you run a single project, even if that project doesn't depend on everything. This choice can be changed, however. Go to Tools|Options|Projects and Solutions|Build and Run and check the box "Only build startup projects and dependencies on Run". Then when you hit F5, VS will only build your startup project and the DLLs it depends on.
I just "fixed" the same problem with my VS project. Visual Studio did always a rebuild, even if didn't change anything. My Solution: One cs-File had a future timestamp (Year 2015, this was my fault). I opened the file, saved it and my problem was solved!!!
I am not sure if there is a way to avoid dependencies from being built. You can find some info here like setting copylocal to false and putting the dlls in a common directory.
Optimizing Visual Studio solution build - where to put DLL files?
We had a similar problem at work. In post-build events we were manually embedding manifests into the outputs in the bin directory. Visual Studio was copying project references from the obj dir (which weren't modified). The timestamp difference triggered unnecessary rebuilds.
If your post-build events modify project outputs then either modify the outputs in the bin and obj dir OR copy the modified outputs in the bin dir on top of those in the obj dir.
You can uncheck the build option for specified projects in your Solution configuration:
(source: microsoft.com)
You can can create your own solution configurations to build specific project configurations...
(source: microsoft.com)
We actually had this problem on my current project, in our scenario even running unit tests (without any code changes) was causing a recompile. Check your build configuration's "Platform".
If you are using "Any CPU" then for some reason it rebuilds all projects regardless of changes. Try using processor specific builds, i.e. x86 or x64 (use the platform which is specific to the machine architecture of your machine). Worked for us for x86 builds.
(source: episerver.com)
Now, after I say this, some propeller-head is going to come along and contradict me, but there is no way to do what you want to do from Visual Studio. There is a way of doing it outside of VS, but first, I have a question:
Why on earth would you want to do this? Maybe you're trying to save CPU cycles, or save compile time, but if you do what you're suggesting you will suddenly find yourself in a marvelous position to shoot yourself in the foot. If you have a library 1 that depends upon library 2, and only library 2 changes, you may think you're OK to only build the changed library, but one of these days you are going to make a change to library 2 that will break library 1, and without a build of library 2 you will not catch it in the compilation. So in my humble opinion, DON'T DO IT.
The reason this won't work in VS2005 and 2008 is because VS uses MSBuild. MSBuild runs against project files, and it will examine the project's references and build all referenced projects first, if their source has changed, before building the target project. You can test this yourself by running MSBuild from the command line against one project that has not changed but with a referenced project that has changed. Example:
msbuild ClassLibrary4.csproj
where ClassLibrary4 has not changed, but it references ClassLibrary5, which has changed. MSBuild will build lib 5 first, before it builds 4, even though you didn't mention 5.
The only way to get around all these failsafes is to use the compiler directly instead of going through MSBuild. Ugly, ugly, but that's it. You will basically be reduced to re-implementing MSBuild in some form in order to do what you want to do.
It isn't worth it.
Check out the following site for more detailed information on when a project is built as well as the differences between build and rebuild.
I had this problem too, and noticed these warning messages when building on Windows 7 x64, VS2008 SP1:
cl : Command line warning D9038 : /ZI is not supported on this platform; enabling /Zi instead
cl : Command line warning D9007 : '/Gm' requires '/Zi'; option ignored
I changed my project properties to:
C/C++ -> General -> Debug Information Format = /Zi
C/C++ -> Code Generation -> Enable Minimal Build = No
After rebuilding I switched them both back and dependencies work fine again. But prior to that no amount of cleaning, rebuilding, or completely deleting the output directory would fix it.
I don't think there's away for you to do it out of the box in VS. You need this add-in
http://workspacewhiz.com/
It's not free but you can evaluate it before you buy.
Yes, exclude the non-changing bits from the solution. I say this with a caveat, as you can compile in a way where a change in build number for the changed lib can cause the non built pieces to break. This should not be the case, as long as you do not break interface, but it is quite common because most devs do not understand interface in the .NET world. It comes from not having to write IDL. :-)
As for X projcts in a solution, NO, you can't stop them from building, as the system sees a dependency has changed.
BTW, you should look at your project and figure out why your UI project (assume it is UI) references the same library as everything else. A good Dependency Model will show the class(es) that should be broken out as data objects or domain objects (I have made an assumption that the common dependency is some sort of data object or domain object, of course, but that is quite common). If the common dependency is not a domain/data object, then I would rethink my architecture in most cases. In general, you should be able to create a path from UI to data without common dependencies other than non-behavioral objects.
Not sure of an awesome way to handle this, but in the past if I had a project or two that kept getting rebuilt, and assuming I wouldn't be working in them, I would turn the build process off for them.
Right click on the sln, select configuration manager and uncheck the check boxes. Not perfect, but works when Visual Studio isn't behaving.
If you continue to experience this problem, it may be due to a missing or out of date calculated dependency (like a header) that is listed in your project, but does not exist.
This happens to me especially common after migrating to a new version (for example: from 2012 to 2013) because VS may have recalculated dependencies in the conversion, or you are migrating to a new location.
A quick check is to double-click every file in offending project from solution explorer. If you discover a file does not exist, that is your problem.
Failing a simple missing file: You may have a more complicated build date relationship between source and target. You can use a utility to find out what front-end test is triggering the build. To get that information you can enable verbose CPS logging. See: Andrew Arnott - Enable C++ and Javascript project system tracing (http://blogs.msdn.com/b/vsproject/archive/2009/07/21/enable-c-project-system-logging.aspx). I use the DebugView option. Invaluable tool when you need it.
(this is a C# specific question, but a different post was merged as identical)
Related
This happens sometimes when I make small changes to the source code, like removing a line of code or changing some value.
case A
change player.y = 100; to player.y = 250;
compile code with CTRL+F5
player still appear at y: 100
change player.symbol = "O"; to player.symbol = "P";
compile code with CTRL+F5
player now appear at the correct location y: 250
So far I've tried
Clean Solution - this works, but I'd rather not have to rely on this whenever I make a change
Build is checked for the project under Build > Configuration Manager...
CTRL-SHIFT-B still compiles the wrong code.
running VS as administrator - still compiles the wrong code.
I've looked at the executable's creation date. It doesn't update when I compile.
deleting the executable before compiling re-creates the same executable without the changes.
I had the same issue on another visual studio installation on the same computer
The project is located on a local hard drive.
edit:
I found this link. The problem seem to be very similar, although when testing right now it extends to more than just editing float numbers. I'm using Visual Studio Community Version 15.7.1, but had this problem prior to patching as well.
This doesn't seem to occur (so far) while building for debug.
It may seem like a pain, but after making any significant changes it is usually a good idea to clean the solution and rebuild the project. You may think that recompiling a single translation unit will work and in some cases that may be true, but if other object files rely on the translation unit you just updated they need to be recompiled as well otherwise visual studio will use the older object files that have previously been built.
As for CTRL+F5 whether you are in debug or release mode just tells Visual Studio that you want to run without debugging as it has nothing to do with the compilation and building of the project or solution. Are you sure you are not confusing CTRL+F5 with CTRL+F7 as user SoronelHateir has mentioned in the commmets? After you make any changes to source code it is good to first recompile that individual file to make sure there are no compilation errors. Then it is good to rebuild that current project within the solution.
On the other hand if your solution has multiple projects for example: one project is a library that is statically linked and the other project is your main executable project and the changes you made are in your library and depending on how the main project depends on the library project you will probably have to more than likely at the least rebuild the library project and in some cases you may even have to rebuild the main startup project. Most of the times just rebuilding the statically linked library should suffice; it is rare that the main program that is linking the library would have to be rebuilt to see the new changes, but there are some rare cases that both will have to be rebuilt.
I'll say it again; yes it may seem like a pain to have to do a clean solution and complete rebuild, but after a while this is the safest path to travel to ensure that all of the object files are up to date. What you are seeing in your own solution is a side effect of running the program with updated code but the output matches that of the older object files. This is a result of the IDE using the older or stale object files that already exist since you did not rebuild the solution. Cleaning the solution clears out all of the old object files as well as any intermediate files that are used to compile the source code into translation units to make the appropriate object files.
There are settings within the IDE that others have mentioned above such as user: Bo Persson has stated from their answer that you can change the behavior of how Visual Studio will recompile, rebuild a project or solution.
In visual studio, after making changes, I always click(in the menu bar):
Build -- Rebuild Solution
Note that this is different from "CTRL+F5" and "CTRL-SHIFT-B"
And it will always pick up all the changes and recompile your program
I tried everything mentioned in the current solutions and it didn't work for me. However after a lot of frustration I realized I was running my debugger. Try going to the Debug tab then press Stop Debugging. Finally make sure to select Release from this dropdown box(Mine was on Debug).
I have a build process (let's call it the "engine") that has been using a command line call to Visual Studio's devenv.exe to build a project. I have known for some time that VS is just building with MSBuild, so I finally got around to updating the engine to use MSBuild directly. However, I'm finding a strange anomaly with MSBuild.
For the sake of discussion, there's projects A, B, C, and D. Project A is the main project I'm building, a web app, that depends (through project references) on the other 3 projects. When built manually in VS, A\bin is populated with assemblies. When built in the engine with devenv.exe A\bin is again populated with the expected binaries. When built in the engine use MSBuild, A\bin contains nothing. However, B\Release\bin, C\Release\bin and D\Release\bin contain their binaries as they did using the former 2 build methods.
This happens with just a single project as well. The problem doesn't appear to be related to dependent projects.
I have attempted to explicitly set the MSBuild OutDir property, but it doesn't appear to have any affect.
I have run builds with diagnostic output on and can't see anything obvious (granted, there is a LOT there so it's possible I have yet to find something significant).
I've also been trying to figure out how to see the command line call to MSBuild that VS is making when run from devenv.exe but I can't seem to find it.
I have looked at several other SO posts (here and here) but they aren't the same problem.
Anyone have an idea of what this could be or where else I could look for an answer or more diagnostic information?
EDIT 1: The arguments pattern used for the call to MSBuild looks like this:
/nologo /target:Compile /property:Configuration=%%BUILDCONFIG%% /maxcpucount
/property:OutDir=%%OUTDIR%%\bin\ /verbosity:diag /detailedsummary "%%PROJPATH%%"
The lower half of that shows my attempt to force the output directory as well as the enhanced output to show more details of the process. Build engine code replaces with "%%TOKEN%%" items with the appropriate replacement values for the project being built.
EDIT 2: After more research and looking into suggested provided, I've decided to abandon the effort to use msbuild instead of devenv. It seems there is a lot more going on under the hood of devenv in preparation its own call to msbuild and I could likely break something else going on if I don't fully understand the entrance in msbuild. I did try to see if the call to msbuild from devenv is logged, but it doesn't seem to be. I've considered building a dummy msbuild app to just dump the command going into it and temporarily swap out the actual msbuild to generate this diagnostic information, but that's more effort than it's worth at this point. The performance gain isn't so great that it's worth pursuing further for now.
I would look at the Output path on the build tab of your project properties. There are more than few differences when using MSBuild and when using Visual Studio (Even from the command line). It could be you have A configured differently than B,C,D and synching A to the rest will make it work. Also, if you plan to build the projects individually, not as a solution make sure you don't use Solution Level macros that won't be available to the project file on it own.
You are supposed to set OutputPath instead of OutputDir.
Since you already used /verbosity:diag, why not redirect the output to a text file and carefully analyze where csc.exe (or another compiler in use) stores the binaries? That's quite simple and informative for you to learn how MSBuild works under the hood.
The title is fairly straightforward. If I hit the build button, it acts like the "Rebuild All" button. If I have two projects, lets call them PARENT and CHILD, and I make a change to Parent and click the "Build" button. The default behavior in VS is to rebuild PARENT AND CHILD, when it should only rebuild PARENT.
I was wondering if this is an option in Visual Studio and how I can change it.
Thanks.
There seems to be some inconsistencies in your question, so I'm going to define the terms I'm using, for clarity.
Build: Compile & link everything required for the application/project
Clean: Delete all files produced as part of a build.
Rebuild: Perform a clean, then a build.
My Visual Studio doesn't have a '(Re)build All' button, it does however have a '(Re)build Solution' button, so I'm going to assume you mean that. I'm also going to assume that where you've said rebuild PARENT and CHILD, you meant build PARENT and CHILD, and that it's not recompiling each and every file in the project.
The Build and Build Solution options are not the same.
Performing a Build will evaluate the current project (and its dependencies), compiling anything required.
Performing a Build Solution will evaluate all projects in the solution, compiling anything required.
So, if you have a solution with 3 projects:
Child
Service (Dependent on Child)
FrontEnd
Then, assuming the currently selected project is Service:
Build: Would evaluate/compile: Child & Service
Build Solution: Would evaluate/compile: Child, Service & FrontEnd
Now, I believe what you are seeing is that when you perform a build on Parent, VS is performing a build on Child as well, even though it hasn't changed. I would expect that it is evaluating Child, because it needs to know if it has changed. Without performing the evaluation, there's no way it can know, which is why in your output window you'll see that it has done something with the Child project. This is usually fairly quick, although it does add up if you have a lot of dependencies.
If you don't want VS to evaluate your dependencies when you build the parent, then there are approaches you can follow but you're choosing to step away from the tools protection so unless you're careful you may get binary mismatches etc...
Some options:
Unload child projects that you're not changing (right click in solution explorer and select unload). This hides the dependency so it doesn't get compiled).
Stop letting visual studio manage your dependencies. The safest way to do this is to remove the Project Based references and instead use Binary Based references (point at the compiled output from each dependency). But this can be a non-trivial undertaking, since you have to manage your project builds yourself.
I'd suggest you think twice about what it is you're asking and evaluate whether or not the time saving (there can be some) is worth the risk that now and again you might not build everything you needed to and so end up spending time chasing your tail.
Right click on the Solution from Solution Explorer, choose Properties.
From Configuration Properties > Configuration you could exclude particular project from the build process
From Common Properties > Project Dependansies you could create and remove project dependencies
Hope this helps...
Muse Extensions
I had a similar issue with about 40 projects in one solution. For me, the following setup felt a lot less hazardous than the other answers.
In Visual Studio, open up the Configuration Manager from the Build menu.
Select <New...> from the Active solution configuration drop down.
Enter a Name (e.g. Debug Interface) and either copy settings or create an empty configuration. You should be safe to deselect Also create new project configuration(s), especially if you only want to reduce the build time.
Select or deselect the projects you want to build with your new configuration and then close the Configuration Manager.
Enjoy the shorter build time using Ctrl + Shift + B or by just building the parent project. But don't forget to change to another build configuration if you want all projects to build again. Other projects that you've deselected can still be built if you right-click on them and select Build.
More information about the Configuration Manager can be found on MSDN: Configuration Manager Dialog Box.
Please review this article:
http://blogs.msdn.com/b/kirillosenkov/archive/2014/08/04/how-to-investigate-rebuilding-in-visual-studio-when-nothing-has-changed.aspx
[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\12.0\General]
"U2DCheckVerbosity"=dword:00000001
When setting the registry key (I had to add it), just use the visual studio version that's applicable to you. E.g. 14.0 == VS2015
The diagnostic that's presented can help you determine why msbuild thinks things are out of date.
I also had this problem with C++. Dependent projects would completely recompile even when I did not change their source code or header files.
I turned off "Whole Program Optimization" for all of the dependent projects. Now my projects only rebuild if I change the source code. This option for C++ projects can be found in Properties->Configuration Properties->General.
Good Luck
I have just seen a situation like that in a solution with a couple of hundred projects. Whenever you clicked "build", VS would go and rebuild most of the projects, even if you just made a full build a second ago. Same problem if you only wanted to build a single project.
It turned out the problem was a circular dependency between projects.
Normally VS does not let you create a reference from one project to another if this would cause a loop.
This only concerns "Project references", however. VS does not prevent you from adding, say ../Debug/bin/OtherSubProject.dll as a DLL reference.
Now suppose we have a solution with 100 projects, most of them, say, dependent on CoreLibrary.dll. Suppose someone adds a reference from CoreLibrary.dll to ProjectX.dll (ignoring the fact that ProjectX already depends on CoreLibrary).
If we run the build now, then first CoreLibrary.dll is built, then ProjectX.dll and all other projects.
Now suppose we run the build again, without changing anything. VS sees that one of the dependencies of CoreLibrary.dll, namely ProjectX.dll is newer than CoreLibrary.dll, and hence CoreLibrary.dll needs to be rebuilt. But of course, rebuilding the core library forces the rebuilding of all other projects, including ProjectX.dll (which will again be newer than CoreLibrary.dll).
The way to resolve this problem is to get rid of all the circular dependencies which, in particular, means that you should not reference your other subprojects via DLL references. A temporary solution while you do it would be to go to Solution Properties -> Configuration and simply disable building for one of the projects in the loop (either CoreLibrary.dll or ProjectX.dll in the example above).
There is another common reason why VS may rebuild projects which were not changed: static files with "Copy to output directory: Always" set in their properties. Avoid those.
Finally, to debug all that and figure out what is causing the rebuilds, go to Tools->Options->Projects and Solutions->Build and Run, and enable "Diagnostic" output for MSBuild. Then search for the words "not up to date" in the output window while the solution builds.
Alt + B, U will build just your current project. Good shortcut if you don't want build all projects in solution.
I've got a solution containing multiple projects. I'm only changing the code in one of them, but every time I hit Ctrl+Shift+B, Visual Studio rebuilds all of the others.
I want it to build the other projects, so this is good. What's not good is that, normally, it would see that there was nothing to do. I have a wonky dependency somewhere, so this isn't working.
Is there a tool or macro (or switch) that'll explore the dependency tree and tell me which files are missing or out-of-date, so that I can get it to stop?
I know that I can solve this specific case, by (e.g.) touching all of the project files.
Unfortunately, I've often seen this situation when a file is configured to produce an output file (e.g. an IDL file is configured to output a typelibrary, but doesn't contain a 'library' block, so it'll never create a TLB).
This wouldn't be resolved by touching all of the project files, so I'm looking for something more general to add to my personal toolbox that'll easily tell me why a file is being rebuilt, whether it be because it's older than a dependency, or because the project is misconfigured to expect an output file that will never be produced.
In Options / Projects and Solutions / Build and Run turn up the MSBuild project build output verbosity to Detailed. It should give you an idea of why it is rebuilding all the projects.
If I understand you right, you might solve this by touching all your project's files. It may be caused by a source-file having a last-modified-time that's in the future.
Edit:
I know that I can solve this specific case, by (e.g.) touching all of the project files, but I'd like to add something to my personal box of tricks that I can use in the future, in the general case.
I'm confused - what's the 'general case' of this problem?
Not that I've found. If you know that a project is not going to change often, you can tell the Configuration Manager not to build it. (Right-click on the Solution, and select Configuration Management)
As far as I know ctrl + shift + b is by default bound to BuildSolution, so that would be why all your projects are being build. i'm not really sure what else you could use except for rightclicking the project and pressing build :)
You might want to check in Tools>Option>Projects and Solutions and check if your option is set to Only Build startup project and dependencies instead of all the solution.
Or instead of using ctrl+shirt+b you should simply press F6 on the project you want to build :)
You can use shift+F6 to build just the current project.
While not directly answering my question: "is there a tool that'll work this out for me?", I found the specific problem by using SysInternals Process Monitor:
The project was configured with /analyze, which requires Visual Studio Team Edition, but the version on this PC is Visual Studio Professional, which doesn't support it. Unfortunately, there appears to be a bug in Visual Studio, where it thinks that the .pchast file should be created, even though it has no way to do so. I've raised this on Connect.
I think I might write a macro for Visual Studio Professional that, if /analyze is turned on, simply creates an empty .pchast file at the end of the build...
I have experienced an annoying issue with Visual Studio 2005... sometimes when I rebuild, and even if I do a Rebuild Solution, it will come back with no errors or warnings, but then when I later edit another code file, even without changing it, and rebuild, it will find an error or warning in that other file. Clearly, the earlier Rebuild Solution did not recompile that file! How can I force VS to completely recompile every file?
I've seen this happen before when you have multiple projects in your solution and the references get mixed up.
Say you have four projects in your solution, Common, Business, Data, and UI. Assume that Common is referenced by the other three projects.
What we want is for Common to be a "project reference" from the other three projects - they'll then pick up their copy from the build output directory of Common.
But, sometimes, one of the projects will get it's reference mixed up. Say, in this case, that UI starts referencing the copy of Common in the build output directory of Data. Now, any change that compiles "UI" without also compiling "Data" will result in two, possibly incompatible, versions of "Common" being a dependency of UI.
Another scenario is where the reference is to a binary, such as from a "lib" directory. Then, one of the projects ends up referring to a build output location instead of lib.
I don't know what causes this - but I see it all the time, unfortunately.
The fix is to go through the references of each project and find the one (or more) that point to the wrong place.
It might help to clean the solution prior to rebuilding -- right click on the solution in the Solution Explorer and choose "clean solution" -- this deletes temporary files and is supposed to clear out the bin and obj folders, so everything is rebuilt.
I'm with Guy Starbuck here, but would add that Rebuild Solution is supposed to do a Clean Solution followed by Build Solution, which should, then, have solved your issue to begin with. But VS 2005 can be terrible in this regard. Sometimes it just starts working after several rebuilds. If upgrading to 2008 isn't an option, consider manually clearing the bin folder.
Is this related to the Configuration Manager? There you can select which projects in your solution build. Not sure if this helps.
Depending on the types of warnings it is not possible if I recall correctly.
For example, warning messages for XHTML compliance are ONLY displayed when the file is open. You might check the tolerance settings inside VS to see if you can change it.
This sounds strange - Rebuild should build everything regardless of changes and Build should only build things that have changed.
The behaviour you've described should only happen if you have modified something that is referenced by the unchanged file so that it is now incorrect.