This project cannot build given the current state of the project.

I’ve been cleaning up a continuous integration build system for my cloud gaming client’s server system. The codebase is pretty big, and my build system on Windows is pretty rubbish but works… It has been getting slower and slower due to how I build the system, and I wanted to make it faster. Whilst doing this, I ran into a Visual Studio error message that I hadn’t seen before, and it took me a while to work out what was going on…

The first step in speeding things up was to realise that having the build system load and build the various projects separately was far slower than building everything in one solution. I like building the projects separately as it proves that they haven’t been broken, but building a solution which contains all the projects is far faster. The design I ended up with is that I first do a rebuild of all the code using an “all.sln” solution which includes all the projects. This is done at the start of the CI build. The rest of the build then continues as normal. It ‘builds’ rather than ‘rebuilds’ each of the projects in isolation, as this is (a) fast, and (b) proves that the projects work in isolation as well as in the “all.sln” build. Once each project builds, the associated unit-test project is built and the tests are run.

When creating the “all.sln” file, I realised that I’d been a bit lazy in creating some projects. I tend to simply copy an existing project and change the names and whatever as this keeps all my normal structure the same. I should really write a tool to create these projects, but… Anyway, copying a project is fine as long as you remember to change the project GUID to something new. In fact, and here’s the root of the problem, it’s fine even if you DO NOT remember to change the project GUID. The GUID only has to be unique within the set of projects that are loaded in a single solution and so you can get along just fine with all your unit test projects having the same GUID as long as each project is only ever loaded into the library specific solution that builds the library and the test harness… Once you add multiple projects with the same project GUID into a solution, Visual Studio starts down a path of madness that was obviously designed to be ‘convenient’ for someone…

If you add two projects with the same GUID to a Visual Studio solution, it will likely “fix” one of the GUIDs for you without telling you. This can result in files being changed when you don’t expect them to be, and this only really shows up when you have to check in files you didn’t think you’d changed…

If you only have a single solution loading a project, then this doesn’t really matter, the solution and the project are silently updated with a new GUID and everything just works. If, however, you have other solutions that reference the project with the old GUID, these now fail. I’m pretty sure how these projects fail has “evolved” over the years. I seem to remember that the various solutions would fight to set the GUID as they wanted it in the project file, which resulted in the project file changing back and forth as various solutions were loaded… Anyway, with Visual Studio 2022, you end up with one solution with the correct GUID for the project and one with the old duplicated GUID. The old solution file then doesn’t build and gives the error “This project cannot build given the current state of the project.” Which doesn’t really tell you what’s going on. Another warning suggests that turning on design time tracing with the environment variable “TRACEDESIGNTIME.” This produces copious MSBuild logs which didn’t really help.

So… If you have a project that fails to build and Visual Studio displays, “This project cannot build given the current state of the project.” You need to check the solution file and the project file and make sure that the project GUID matches…