After consecutive builds of a solution without making any changes to an assembly's code or any of its referenced assemblies' code, I've noticed that new DLLs are not compiled in the build folder (ie, the DLLs still have the old date and time). However, if I make any code changes and then do a build of the solution, new DLLs are written.
I've also discovered that doing a rebui开发者_开发技巧ld (as opposed to a standard build) does force VS to compile new DLLs. Cleaning the solution and doing a standard build also causes this.
About my initial issue of new DLLs not being compiled on a standard rebuild: is this by design? It's not a problem as I can just create a macro that does a rebuild and assign it to CTRL+SHIFT+ALT+B, but I would like to know for peace of mind due to some issues that have occurred with past deployments that have pointed the correct DLLs potentially not being properly copied over to the production servers.
It's behaving correctly. A "build" (as opposed to a "rebuild") only builds the things that have changed since the last build.
You're seeing by-design behaviour. A Build command will only trigger a build of those projects in your solution whose source/settings have changed. Obviously used more often and saves time for the developer.
MSDN's How to Prepare and Manage Builds for Visual Studio 2005
Choose Build or Build Solution to compile only those project files and components that have changed since the last build.
More on Rebuild: Difference between Rebuild and Clean + Build in Visual Studio
精彩评论