brutaldev/StrongNameSigner

Long pause on build

programatix opened this issue · 19 comments

programatix commented

I'm using VS 2019 16.4.1 with StrongNameSigner 2.6.0. Whenever I build the project which is installed with StrongNameSigner nuget, it will pause at the following phase,

1>------ Build started: Project: <project name>, Configuration: Debug Any CPU ------

When this happens, MSBuild.exe CPU usage would be quite high. It can take from 1 minutes to 5 minutes. Then it would continue with the following phase where it would build normally until the end,

1>The "Configuration" property is a global property, and cannot be modified.
1>The "Platform" property is a global property, and cannot be modified.
1>The "SolutionDir" property is a global property, and cannot be modified.
1>Search paths being used for $(MSBuildExtensionsPath) are C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild;$(MSBuildProgramFiles32)\MSBuild
...
...

The log above is generated with "diagnostics" setting. In between the two log above (where the pause happens), there's nothing logged.

I tried several different projects and several different solutions and the result is the same. A very long pause will be introduced. Also, after I added StrongNameSigner in nuget manager, adding/removing other nuget packages will also have this pause issue. Everything will go back to normal if StongNameSigner package is removed.

brutaldev commented

How many references and sub-dependencies do these several solutions have? How slow is the disk that these files reside on...?

programatix commented

There's quite a number of sub-dependencies. I think more than 10. The disk is a SSD with around 400 MB/s read and write. The the pause occurred, the disk usage is at 2%-3% (Task Manager). MSBuild.exe is using around 0.1MB/s

brutaldev commented

Not even sure where to start looking. This is tested on a solution with over 1000 package references totaling 1.3GB in assemblies, still finishes in 5-6 seconds. Maybe you have an anti-virus installed that is blocking the scanner since it will open and read the files to determine the strong-name.

programatix commented

I'm using TortoiseSVN and Symantec Endpoint Protection 14. I tried disabling them and excluding the solution path. Problem remains. Weird.

programatix commented

I attached a test solution. It's actually an empty netstandard2.0 project with the following nuget packages

  • Brutal.Dev.StrongNameSigner
  • CSJ2K
  • SixLabors.ImageSharp
  • SixLabors.ImageSharp.Drawing

On my PC, it takes more than 1 minute to build, pausing at
1>------ Build started: Project: test2, Configuration: Debug Any CPU ------

It will also pause for a long time if I try to add more nuget packages, such as Portable.BouncyCastle. If StrongNameSigner is removed using nuget package manager, everything will be fast again.

test2.zip

programatix commented

Sorry if the frequent posts are annoying. I've came back from work and tested on my own PC which is of higher spec than my work PC. The disk is SanDisk Extreme II. It has no antivirus installed except for the built-in Windows 10's Windows Defender. The Visual Studio 2019 version is 16.3.10 (older than my work PC).

The long pause is during build is there. Similarly, non-responding (long pause) issue is also when

  • Installing/removing nuget packages
  • Closing the solution (if there are many projects and one of the project is similar to test2 above)
  • Opening the solution (if there are many projects and one of the project is similar to test2 above)

I recorded a video at work just now and uploaded it to https://photos.google.com/share/AF1QipMhQ1uRcJdpVVYJhVxUIrHT0lupxPI3K3MV-patYBhwsr8G6DHt7LqV1CykI1HPaA?key=WVlWSFYxWE5jbEZ4VzUwb3dPb0hrTTJkRGY2S0pn.

Please note that the sample in test2 takes around 1 minute to build with StrongNameSigner package installed. In my work solution (there are around 10 projects in it), it paused for around 1 to 5 minutes when building the project (the main project) which has StrongNameSigner installed.

jzabroski commented
programatix commented

Attached zip file with a new solution with several projects in it. On my home machine, it paused for around 1.5 minutes while building WpfApp1. After building the solution, close Visual Studio 2019 and re-open the solution, you may experience a long pause when Visual Studio 2019 tries to open the solution.

Also in the zip file, the MSBuild binary log.

test2 v2.zip

jzabroski commented

@programatix One thought - did you try deleting all your bin and obj files and rebuilding?

I've run into weird issues with the new dotnet tool chain due to the MSBuild targets written by Microsoft referencing the obj directory to discover the "state" of things.

I imagine since you said "new solution", this is already true and you've done it - but just thinking.

programatix commented

Yes, I deleted all bin and obj folders for the solution to test a rebuild. The long pause is there. Using the "rebuild" command in VS2019 is also the same.

Deleting the obj folders will cause msbuild test2.sln /bl to fail because somehow the nuget packages info is inside obj. So, I have to go into VS2019 and restore the nuget packages. Then re-execute the msbuild command.

jzabroski commented
programatix commented

The V2.zip is just to simulate my actual solution but it still my actual solution is slower.

For simplicity sake, just use the first zip in the thread. It only has 1 netstandard2.0 project. It takes around 1 minute to start building.

jzabroski commented

The problem seems to be that your WpfApp1 is using PackageReference despite being an old school project type. Can you try using packages.config in that project instead? It's clear Visual Studio is mind boggled by this, as the references dont show up in Solution Explorer as they would if this was a .NET SDK csproj

brutaldev commented

@jzabroski It's definitely because of package references. When using this the target signing directory is your package cache folder (C:\Users\user_name.nuget\packages). My directory has 715 packages with tens of thousands of files in it that would need to be recursively checked. Looking into a way to workaround this but that's going to get tricky finding the packages a project uses and it's underlying dependencies in order to make a smaller list of directories/probing paths to scan.

For now I would say package reference is not supported. This was identified some time back but only really shows this problem if you use it often and have built a huge directory of packages (Issue #33).

jzabroski commented

Interesting. So it's not because he is using new-style PackageReference with old-style csproj format?

Edit: You have a very cool GItHub Avatar. \x/

brutaldev commented

I've implemented a really rudimentary fix to just ignore any framework files which will always be signed. Now it takes it down from about 2 mins to 11 seconds. Gonna tidy it up and then I'll release a new version.

Thanks @jzabroski, might need a bit of a refresh, made it years ago.

programatix commented

I tested version 2.7.0 and found that the issue is still there. Attached in this post is the msbuild binary log.
msbuild snsv2.7.0.zip

From it, I see a long list of check statements,
Fixing references to 'C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.8\Facades\....

image

So I tried changing the target to NETFramework 4.72 and I get a long list of check statements,
Fixing references to 'C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.2\Facades\......

Using test2.sln as a test solution, it took 1 minute and 17 seconds.

brutaldev commented

Added additional paths to ignore, there was actually a bug using the AND which @programatix highlighted in the pull request, all paths should be OR to be ignored.

Release: https://github.com/brutaldev/StrongNameSigner/releases/tag/2.7.1
NuGet: https://www.nuget.org/packages/Brutal.Dev.StrongNameSigner/2.7.1
Download: https://github.com/brutaldev/StrongNameSigner/releases/download/2.7.1/StrongNameSigner_Setup.exe

  • 👍1