Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dot net framework 4.7.2 project is never up to date when using NuGet package System.IO #6360

Closed
vsfeedback opened this issue Jul 10, 2020 · 5 comments
Assignees
Labels
Feature-Up-to-date Build up-to-date check that avoids shelling out to MSBuild unless necessary. Legacy Issues against the legacy project system. Triage-Investigate Reviewed and investigation needed by dev team
Milestone

Comments

@vsfeedback
Copy link

vsfeedback commented Jul 10, 2020

This issue has a corresponding ticket on Developer Community. Please vote and comment there to make sure your voice is heard.


When building dot net framework 4.7.2 projects (without any changes), we never see the following line:

========== Build: 0 succeeded, 0 failed, 1 up-to-date, 0 skipped ==========

The projects always Builds. We expect the project only builds after changing anything, or after issuing a 'Clean' command.

The reason from the detailed logs is:

1>Project 'Project1' is not up to date. CopyLocal reference 'C:\VSTS\Project1\bin\Debug\System.IO.dll' is missing from output location.
1> Encountered conflict between 'Reference:System.IO, Version=4.1.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL' and 'Platform:System.IO.dll'. Choosing 'Platform:System.IO.dll' because AssemblyVersion '4.1.2.0' is greater than '4.1.1.0'. (TaskId:14)

It seems like the build process decides to not copy the System.IO to the output directory; because a platform System.IO.dll exists with a greater version number.

The check for any changes in the project does not recognize this situation; so it comes to the wrong conclusion (the project is not up to date).

The check for any changes in the project should recognize the situation when a NuGet dll is not copied because a platform dll exists.

This problem costs our team a lot of valuable time. Our solution includes over 75 projects; and it takes several minutes to start a debugging session; even when nothing has changed.

To reproduce the issue:

  • Create a Dot Net Framework 4.7.2 class library.
  • Add System.IO NuGet package.
  • Build the project.
  • Change nothing and Build the project again. The expected behaviour is: the project is not build because it is up to date. But the project builds anyway.
@ocallesp ocallesp self-assigned this Jul 10, 2020
@jjmew jjmew added the Triage-Investigate Reviewed and investigation needed by dev team label Jul 16, 2020
@jjmew jjmew added this to the 16.x milestone Jul 16, 2020
@jjmew jjmew added the Feature-Up-to-date Build up-to-date check that avoids shelling out to MSBuild unless necessary. label Jul 16, 2020
@sixeyes
Copy link

sixeyes commented Mar 29, 2021

I'm using VS v16.9.1 and it's still not fixed.

@drewnoakes drewnoakes added the Legacy Issues against the legacy project system. label Jul 4, 2021
@drewnoakes
Copy link
Member

This does not reproduce for SDK-style projects.

@drewnoakes drewnoakes modified the milestones: 16.x, 17.x Oct 6, 2021
@drewnoakes
Copy link
Member

This applies to legacy projects that use Packages.config, as described in the linked feedback ticket. To workaround this issue, use PackageReference for package references instead.

@sixeyes
Copy link

sixeyes commented Dec 6, 2021

According to this link https://docs.microsoft.com/en-us/nuget/consume-packages/package-references-in-project-files

PackageReference support is limited for ASP.NET projects

@drewnoakes
Copy link
Member

My understanding is that PackageReference should work well provided the packages you install don't have install/uninstall scripts. Such scripts are not supported in PackageReference.

You can use a package that has such scripts, but you would need to manually apply whatever steps they were performing (such as modifying config files).

This comment seems to summarise the situation well: NuGet/Home#5877 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature-Up-to-date Build up-to-date check that avoids shelling out to MSBuild unless necessary. Legacy Issues against the legacy project system. Triage-Investigate Reviewed and investigation needed by dev team
Projects
None yet
Development

No branches or pull requests

5 participants