20

I have a sln with > 50 projects, and recently, when I moved to VS2013, every time I press F5 for a build, it will rebuild all the projects, even though I have just performed a build. The diagnostics show, that each project is marked as not up to date with the following error:

Project <PROJECT NAME> is not up to date. Missing input file 'c:\users\USER\appdata\local\temp\2\.netframework,version=v4.0,profile=client.assemblyattributes.cs

I have read these threads:

but the suggestion there is to add the following line to the proj file:

  <Target Name="GenerateTargetFrameworkMonikerAttribute" />

I did and it did not work. Suppressing the warning as MS suggestion will also not work as the project will remain "not up to date".

I am using VS2013, C# and VB projects. With the very same project and VS2012, such error is not raised and the projects are up to date.

Any suggestions?

UPDATE Perhaps it is worth mentioning that I do have a few build definitions in the solution, where all of the projects are building for AnyCPU except one: http://screencast.com/t/fuw9k4IubN

Community
  • 1
  • 1
checho
  • 3,092
  • 3
  • 18
  • 30
  • 2 Questions, Are all the projects set up to build in your configuration manager settings (R Click solution->Configuration Manager)? and are you using any third party lib or DLL files that were compiled under a previous version of .NET? and by third party I mean any libs that are not being compiled in your solution even if they are from other projects at your company? I had a the same problem a while back and it turned out that the culprit was a static library we were using that had been compiled under a previous version of VS. – Semicolons and Duct Tape Jul 24 '15 at 18:02
  • 1. Yes, all of the projects are setup to build. 2. I don't think I have external libs that are not building in the project. – checho Jul 27 '15 at 07:53

5 Answers5

19

I had the same problem and solved it by upgrading the ToolsVersion attribute in *.csproj files:
ToolsVersion="4.0" replaced with ToolsVersion="16.0"
(I’m using Visual Studio 2019, which is v16.x internally).

picrap
  • 1,236
  • 1
  • 13
  • 35
  • Strangely enough, worked for me. I'll try to find the time to use the [this project converter tool](https://github.com/hvanbakel/CsprojToVs2017). – sebkraemer Jun 08 '20 at 09:15
  • 2
    You are a life saver. I just ran into this problem myself. My ToolsVersion was 15.0. Changing it to 16.0 worked great. I had to do this to all 21 of my projects. I think this started happening to me when I upgraded to Visual Studio 2019 v16.6.1. I think I skipped v16.6 – Greg Veres Jun 09 '20 at 15:00
  • 1
    My Tools version was 12.0 and changing it to 16.0 in all my projects just knocked it on the head. Great tip that will save me at least 20 mins a day. – jon morgan Aug 06 '20 at 20:01
  • This solution worked on a VS2015 solution also. Thank you! – Danimal111 Nov 16 '21 at 15:12
6
<Target Name="GenerateTargetFrameworkMonikerAttribute" />

Well, not a good idea, that accomplishes the exact opposite of the problem you are trying to solve. It forces MSBuild to create the AssemblyAttributes.cs file, inevitably your project needs to be rebuilt since the file is new. The Q+A you found addresses a completely different issue, these were C++ programmers that were trying to come to grips with a new linker warning in VS2010. They hate warnings that appear from nowhere from files that are not part of their project. Well, don't we all. The marked answer on that SO question is quite evil btw, that other guy posted a much better answer :)

Missing input file 'c:\users\USER\appdata\local\temp\2\.netframework...

There's a signal in this message, note the presence of the \2 subdirectory in that path name. That is a Big Red Flag, it is not normal. This auto-generated .cs file normally lives inside the TEMP directory, not a subdirectory of that folder. Surely this has something to do with your real problem.

MSBuild doesn't do anything special and simply uses System.IO.Path.GetTempPath() to generate the folder name. That method isn't special either, it simply delegates the job to the GetTempPath() winapi function. The diagnostic therefore is that on this build machine, that OS function sometimes generates an odd-ball path, picking a subdirectory of the TEMP folder. And that it doesn't always generate the same one, thus causing your projects to getting rebuilt.

There is at least one good theory for this behavior, mentioned by commenter @Darran Rowe to this blog post:

No, this is Terminal Services at work. When you log in over remote desktop, Windows will set the temp directory for the logon session to %LOCALAPPDATA%\Temp\<session id>

Rings a bell?

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • Thank you for your input I do find this post useful, hence my upvote. I am pretty confident I have tested this flag before and it didn't work. I was with VS2015 Enterprise and now I am with Professional, which is the only difference I can think of, but this shouldn't matter. Not sure why today it worked. On the question about terminal services, I do quite often log it to my machine remotely and sometimes I build this particular solution, so this might be the reason, but the solution suggested on this page to recreate the deleted folder did not help. – checho Jul 27 '15 at 14:13
  • "I do quite often log it to my machine remotely" is a slamdunk explanation. It however sounds like you are missing the point, a side-effect of using Remote Desktop is that it is entirely *normal* for the entire solution to be rebuilt. Because the TEMP directory is not the same. And this is likely to happen every time you reconnect since you'll get a different session ID on the host machine. A hacky workaround is to start a command prompt, override the TEMP environment variable and start devenv.exe. Dangerous since it might interfere with other people connecting to the machine. – Hans Passant Jul 27 '15 at 14:36
  • From what I understood, the TEMP dir is different only during the remote session. So if I ever used the project during a remote session, as it is using a sub dir for the session, the project will constantly rebuild. However, when I am locally on the machine, the TEMP dir is the correct one, so if I start the project from my machine, it should not interfere with the sub folder in TEMP but should use the correct one, but it doesn't. Also, manually creating the \1 folder did not help. – checho Jul 28 '15 at 05:14
  • Similar things happen when running VS2013 as administrator: %LOCALAPPDATA%\Temp\1 folder is used and projects are always rebuilt. Without elevation everything works fine. – Aleksandr Nov 20 '17 at 10:41
  • [This](https://devblogs.microsoft.com/oldnewthing/?p=11673) also sheds some insight on it. – Jimenemex Jul 25 '19 at 15:02
1

Try deleting the hidden .vs directry which is in the same folder than the solution file.

Lumo
  • 627
  • 6
  • 21
1

This worked for me

Close visual studio and Deleted the .sou files from the projects

Dongolo Jeno
  • 414
  • 6
  • 8
0

I was getting the same error and I solved it by removing the project from my solution and re-adding it. It is a pain because then you have to add the inter project references back in.

user2882190
  • 81
  • 6