73

In the past week or so, I've noticed that Visual Studio 2010 is not recompiling code unless I force it to. This is a C# 4.0 project with WPF. I hit F5, which seems like it used rebuild, if the code had changed, and then launch the app. Instead, it now says in the bottom left status bar "Build Successful" and launches the application. It doesn't actually rebuild the app, though. I can tell because:

  1. even if I make a large number of changes, it "compiles" very quickly and
  2. if I try to set a breakpoint, it gives the warning that the code has changed and doesn't set the breakpoint.

This happens regardless of whether there are errors in the code or not, so I don't believe it's the thing where it launches an older version if the build fails.

If I instead select from the menu to rebuild the project, it then works. This kind of impedes my usual workflow, however. I semi-frequently forget to do this, and then spend 10 minutes trying to figure out what the hell is wrong with my changes. Even worse, sometimes there are build errors that I don't notice right away.

Pressing F6 to "rebuild" the solution does not do anything either. What settings might I have mucked with that would cause this behavior?

davidtbernal
  • 13,434
  • 9
  • 44
  • 60
  • Check to make sure that your project references are indeed project references, and not references to the outputted assemblies from other projects. – Dave Markle Aug 16 '10 at 00:07
  • Hmmm... I don't think this is related to my references, because it happens even when I change code in the project I'm actually launching. – davidtbernal Aug 16 '10 at 00:15

3 Answers3

138

Gah, I figured this out. It was naturally something stupid I did when messing around with build settings after a too-late night. Here are the things to check:

  1. Tools >> Options >> Project and Solution >> Build and Run >> Check that "On run, when projects are out of date" is set to "Always build" or "Prompt to build"
  2. Build >> Configuration Manager >> Check that "Build" is checked for all of the projects you want to build for each of the configurations you need to use.
davidtbernal
  • 13,434
  • 9
  • 44
  • 60
  • 8
    I think Visual Studio somehow periodically corrupts this file, because throughout my time working with it, this exact thing would happen every now and then. – davidtbernal Jan 30 '12 at 20:00
  • 1
    This was very helpful. I noticed this after a Windows Update. – evanb Apr 10 '13 at 21:13
  • Same problem affected me with Visual C# 2010 Express. It seems like by default, if a project in the Configuration Manager says "Any CPU" as its platform, "Build" will default to not being checked. – Brian A. Henning Mar 23 '14 at 01:14
  • Thanks you very much! I forget about "Build >> Configuration Manager >> Check that "Build"" option and manually rebuild projects. After you guide all works as expected! – Maks Jul 28 '15 at 09:01
  • Also see this answer http://stackoverflow.com/questions/1334774/how-do-i-force-a-rebuild-when-the-project-configuration-changes – userSteve Jan 20 '16 at 12:53
  • I set "Active solution configuration" in "Configuraton manager" from "release" to "debug" and my problem is solved – Majid Basirati Apr 03 '16 at 04:40
6

Also if multiple projects in solution, check configuration manager. If you have some projects "Any CPU" and some "x86", will be builded only projects of same arhitecture. Same with "Debug" and "Realese" config.

user3585447
  • 121
  • 2
  • 2
  • 1
    This is not accurate. To be precise, A solution has "configurations". One configuration is the "Active" one; this controls what is built. Each project also has "configurations". A SOLUTION configuration can contain ANY combination/settings of project configurations. By convention, you usually will name the project configurations the same as the solution configurations, but this is not required, nor does Visual Studio care whether these configuration names match. What you **do** need to verify, is that you have selected the project configurations and platforms **that you intended** to build. – ToolmakerSteve Mar 26 '18 at 18:35
  • 1
    ... That is, VS will build **only one** version of each project - the one you have selected for that project, in the "active" configuration. These might all be the same (e.g. "Debug" + "x64"), but they might be different. For example, you might have an "x64" solution configuration that builds "Any CPU" for some class libraries, but "x64" for other class libraries, and for the main .exe. – ToolmakerSteve Mar 26 '18 at 18:41
  • @ToolmakerSteve Thanks for the info. Some examples would help. – Pierre Nov 12 '18 at 18:03
  • 1
    @Pierre - See [Walkthrough: Build an application](https://learn.microsoft.com/en-us/visualstudio/ide/walkthrough-building-an-application?view=vs-2017), after `6. Choose the OK button`, is a screenshot of configuration manager window. In upper right, "Active solution platforms" is `x64`. In middle, `ExpenseItIntro`s "Platform" is `x64`. This is the default. But it doesn't have to be; you *could* build `ExpenseItIntro` as "Any CPU" (as part of your `x64` configuration), by changing "Platform" dropdown to "Any CPU". See https://stackoverflow.com/a/5229805/199364 for explanation. – ToolmakerSteve Nov 12 '18 at 23:57
  • 1
    @Pierre ... actually the stackoverflow link I gave explains what happens if your entire app is "Any CPU". Having a single project "Any CPU", bound into an X64 app is different. In that case, the meaning is that the CLR code of that project can be JIT as either 32-bit or 64-bit without any problem. So you can build *that* project once, and use it in both 32-bit and 64-bit apps. [This is an unusual scenario; usually you will set all projects to x64 when building for x64. I was just commenting that user3585447 is wrong about what happens if some projects are "Any CPU".] – ToolmakerSteve Nov 13 '18 at 00:08
2

Had similar issue in 2020 with VS 2019 (Community Edition) and WPF project not being rebuilt (deemed as "up-to-date") even though the referenced project was rebuilt. The above advice (Tools->Options and Configuration Manager) is met in many places, though didn't work for me.

Eventually changing .csproj file and adding the following line (under ProertyGroup) worked for me:

<DisableFastUpToDateCheck>true</DisableFastUpToDateCheck>
Maxim Saplin
  • 4,115
  • 38
  • 29