4

I'm building a WPF app w/ Visual Studio 2015 (Update 3), and—at least by now, I'm not sure for how long this has been the case—every time I make a change and compile, I'll get a failed build w/ the error

6>CSC : error CS2001: Source file 'C:[...]\Obj\Debug\AnyCPU\GeneratedInternalTypeHelper.g.cs' could not be found.`

If I just build a second time, though, it works just fine.

This smells to me like a dependency on another file that is generated afterwards or something like that, but I haven't been able to find out what it is, a google search didn't net anything either, and neither did a search through my project what this file is used for in the first place (the name suggests its purpose, but I don't know where exactly it is used).

It might also be that the (group-policy-mandated) Anti-Virus is holding an exclusive lock on the file or its dependency for a moment too long, and VS stumbles over that, I think I remember a problem like this at my last job, but I'm not sure that is the case (and I can't simply disable the scanner for a check, it's completely locked down and I don't want to violate company policy for trying to circumvent it).

Any ideas? It's not critical since it's easy to work around, but it's annoying and I don't really want to check in the project like this in the end.

Whiletrue
  • 551
  • 1
  • 7
  • 18
Johann Studanski
  • 1,023
  • 12
  • 19

3 Answers3

4

I had the same issue and i found why it happened (in my case).

Every project of our solution has the same output folder. The file GeneratedInternalTypeHelper.g.cs was generated at the same place for each project. The build order/dependencies were computed and Visual Studio found that some project could be build in parallel.

In Tools > Options > Project & Solutions > Build and Run you can find the option "Maximum number of parallel project builds.

After changed from 8(in my case) to 1, no more files generated at the same time :) It is a little slower to compile but really less annoying than compile multiple times... \o/

Whiletrue
  • 551
  • 1
  • 7
  • 18
  • Have had this with non-WPF projects that referenced DLLs with the same name. Good catch. – ldam Oct 26 '18 at 12:40
  • I can't check if this was the issue--I'm not even working at that company anymore--but this looks like a very good hint. *Because* I can't check if this was the root problem in my case, I'm hesitant to mark it as the answer, though. What's the common practice in these cases? – Johann Studanski Oct 31 '18 at 13:46
  • I have no clue... @Uwe do you ? By the way, there is a typo in the title : Ssolution :) – Whiletrue Nov 02 '18 at 09:58
  • @JohannStudanski : I think you can accept one of the 2 solutions, the concurrent build is the source of the error message. – Whiletrue Nov 13 '18 at 09:03
1

An alternative solution is to add project dependencies in the solution for the projects you don't want to build in parallel.

With this you can keep the parallel project build for the other projects.

Whiletrue
  • 551
  • 1
  • 7
  • 18
0

I have just chased down the same error. In my case it was caused by Git checkout inserting a "%20" into the folder name of the solution where a space was expected. Replacing "%20" with space fixed all these missing *.g.cs errors. Thought worth mentioning here.

Jerry
  • 393
  • 4
  • 8