2

I've a Visual Studio 2013 solution with about 50 C# projects. Normally if I select build (F6) it just builds the projects which have changed. But sometimes after a I shut down and restart my PC it rebuilds all when I select build (F6). Why?

This doesn't happen all the time when I restart my PC. Most of the times it says that all projects are up to date after a reboot. But sometimes it rebuilds all.

I took a look at the following question Visual Studio Rebuilds unmodified projects and its answers.

The next step I did was to set the build output verbosity to diagnostic.

I'm getting the following output when Visual Studio rebuilds all after a PC restart:

1>Project 'Project1' is not up to date. Missing input file
...

There much more lines (more than 1000). I took a look at them but I still don't understand why Visual Studio rebuilds the project.

Update

Why does Visual Studio needs the following file?

1>Project 'Project1' is not up to date. Missing input file
'c:\users\wo\appdata\local\temp\.netframework,version=v4.5.assemblyattributes.cs'.
...
Wollmich
  • 1,616
  • 1
  • 18
  • 46
  • 1
    Could be many things. What is the input file Project1 depends on? Are there external dependencies? Are your projects building to a folder that gets cleared after reboot? A temporary folder? RAM drive? –  Sep 06 '18 at 06:10
  • @MickyD Project1 depends on two cs-files and two native dll files which are not changed. The folder is not cleared after a reboot. I'm working with Subversion and the build folder is in the ignored list. – Wollmich Sep 06 '18 at 06:15
  • Take a look at the project's **Pre-build** event. _"Missing input file"_ has me worried –  Sep 06 '18 at 06:22
  • @MickyD There is no pre-build event. – Wollmich Sep 06 '18 at 06:24
  • @MickyD I've edited my question. The comment about the temp folder helped me to understand it better. – Wollmich Sep 06 '18 at 06:38

2 Answers2

4

For future travelers, I think it's also just a bug in current versions of Visual Studio 2019, 16.6 and newer.

This problem happens for me with Visual Studio 2019 versions 16.6.0 and 16.6.1. I have cross-version aware C# projects that do not have this issue for 2010, 2015, 2017, or 2019 16.5 and older, on the same machine and same user, with the same project in the same folder and solution.

With the recent 2019 versions (in the last month or so, May and June 1st 2020) I get similar message:

1>Project 'Banana' is not up to date. Missing input file 'c:\users\banana\appdata\local\temp.netframework,version=v4.7.2.assemblyattributes.cs'.

If I clean then build, then its normal. If I run a successive build I get the error.

This happens with or without reboot, and after cleaning temp folders even, or if I run Visual Studio with admin or not. The path its trying to find really exists, and pops up if paste in explorer.

I've completely cleaned all but the code files with fresh folders and have the same issue. For me it's only with C# projects. So I think it's a 16.6 bug.

See recent changes:

KirillOsenkov commented on Jan 4 2020

@livarcocc would it be possible to prioritize this? This is an impactful issue that's very easy to fix and has been open for three years now. Seems like low-hanging fruit.

bording commented on Feb 12 2020

With the fix for this being merged into master now, which release will it be a part of? I see that this issue is on the 16.5 milestone, so does that mean it will be in that release, or does the fix also need to be ported to another branch?

tmat commented on Feb 12 2020

@bording I updated the milestone to 16.6 as I believe master is 16.6.

https://github.com/microsoft/msbuild/issues/1479

Beeeaaar
  • 1,010
  • 9
  • 19
  • 3
    I think you're correct that it's related. I started seeing this problem after updating VS2019 to version 16.6.2. I found that changing the `ToolsVersion` attribute in each *.csproj file's `` tag to `15.0` (VS2017) or `16.0` (VS2019) if it was previously set to an older version fixed the problem for me. It appears that there is some sort of bug between the ToolsVersion (which _should_ be defaulting to `Current`) and the changes referenced in that GitHub issue. – Nick Jun 24 '20 at 23:22
  • 2
    To add to @Nick 's comment: I've noticed the same bug using VS2019 16.6.5, and fixed it as well by setting `ToolsVersion="16.0"` in every *.csproj file. VS didn't rebuild every project then between two builds. What's interesting is that reverting `ToolsVersion` on every *.csproj did not make the bug reappear, so I didn't have to commit this change which would not have been compliant with other team members (still using VS2017). – Otiel Aug 19 '20 at 10:08
1

Visual Studio Rebuilds unmodified projects sometimes after a PC reboot

One possibility that caused this issue is that the building account lost permission to the temp folder. To resolve this issue, you can try to grant permissions read/write/execute to the temp folder, or maybe try running visual studio as administrator to see if it is permissions related.

As we know, if we Open/Build a project in visual studio, .NETFramework,Version=v4.x.AssemblyAttributes.cs appears in temp folder automatically. If you lost permission to the temp folder after restart PC or not running visual studio as administrator, we could not access the temp folder, then Visual Studio will report that it can not find the file version=v4.5.assemblyattributes.cs in the temp folder.

Alternatively, you can also generate this file into the Intermediate directory (usually called obj) by adding following property to the project file:

  <PropertyGroup>
    <TargetFrameworkMonikerAssemblyAttributesPath>$([System.IO.Path]::Combine('$(IntermediateOutputPath)','$(TargetFrameworkMoniker).AssemblyAttributes$(DefaultLanguageSourceExtension)'))</TargetFrameworkMonikerAssemblyAttributesPath>
  </PropertyGroup>

Credentials: MSBuild: unnecessary rebuilds because of generated AssemblyAttributes.cs

Hope this helps.

Leo Liu
  • 71,098
  • 10
  • 114
  • 135
  • I'm not running Visual Studio as administrator, but the missing file is in the temp folder `c:\users\wo\appdata\local\temp` of the current user `wo`. – Wollmich Sep 06 '18 at 07:59
  • Have you tried to run it as administrator? I know the file is there, but if you do not have permission to `read/write/execute` after restart, then you will get that issue. – Leo Liu Sep 06 '18 at 08:02
  • @Wollmich, If grant permissions read/write/execute to the temp folder or running Visual Studio as administrator not works for you, you can try the another method in my updated answer. Let me to know if it works for you for free :). – Leo Liu Sep 06 '18 at 10:01
  • Specifying the `` worked for me. Running Visual Studio as administrator is not an option for me. My temp folder `c:\users\wo\appdata\local\temp` has `read/write/execute` permissions. So I don't know why this is not working. – Wollmich Sep 06 '18 at 12:11
  • Why would OP need to set explicit permissions on a folder under his Windows profile particularly when that folder should be inheriting parent permissions by default? Also, VS and VBCSCompiler run as current user again no explicit permission required I would not have thought –  Sep 06 '18 at 17:00
  • I have started getting this error all the DLLs in my VSIX project. It rebuilds, because the file is not present in the temp project, but it generates the file in the obj\Debug project. The diagnostic output shows `TargetFrameworkMonikerAssemblyAttributesPath = obj\Debug\.NETFramework,Version=v4.7.2.AssemblyAttributes.cs`. Explicitly setting the property `TargetFrameworkMonikerAssemblyAttributesPath` as suggested by Leo Liu fixes the problem. I very recently installed VS 16.6. I don't know if there is a connection. – Phil Jollans May 23 '20 at 16:09
  • @phil-jollans I have code that builds with 2010 and 2015 and does not have this issue, and didn't with 16.5. With 16.6.0 and 16.6.1 I have this same issue. I've completely cleaned all but the code files with fresh folders and has the same issue. For me it's only with C# projects. I think it's a 16.6 bug. – Beeeaaar Jun 02 '20 at 06:17