[GH-ISSUE #57] Long pause on build

kerem commented

2026-02-25 21:30:33 +03:00

Owner

Originally created by @programatix on GitHub (Dec 11, 2019).
Original GitHub issue: https://github.com/brutaldev/StrongNameSigner/issues/57

Originally assigned to: @brutaldev on GitHub.

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.

Originally created by @programatix on GitHub (Dec 11, 2019). Original GitHub issue: https://github.com/brutaldev/StrongNameSigner/issues/57 Originally assigned to: @brutaldev on GitHub. 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.

kerem closed this issue

2026-02-25 21:30:33 +03:00

kerem commented

2026-02-25 21:30:33 +03:00

Author

Owner

@brutaldev commented on GitHub (Dec 11, 2019):

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

@brutaldev commented on GitHub (Dec 11, 2019): How many references and sub-dependencies do these several solutions have? How slow is the disk that these files reside on...?

kerem commented

2026-02-25 21:30:33 +03:00

Author

Owner

@programatix commented on GitHub (Dec 11, 2019):

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

@programatix commented on GitHub (Dec 11, 2019): 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

kerem commented

2026-02-25 21:30:33 +03:00

Author

Owner

@brutaldev commented on GitHub (Dec 11, 2019):

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.

@brutaldev commented on GitHub (Dec 11, 2019): 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.

kerem commented

2026-02-25 21:30:33 +03:00

Author

Owner

@programatix commented on GitHub (Dec 11, 2019):

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

@programatix commented on GitHub (Dec 11, 2019): I'm using TortoiseSVN and Symantec Endpoint Protection 14. I tried disabling them and excluding the solution path. Problem remains. Weird.

kerem commented

2026-02-25 21:30:33 +03:00

Author

Owner

@programatix commented on GitHub (Dec 11, 2019):

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 on GitHub (Dec 11, 2019): 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](https://github.com/brutaldev/StrongNameSigner/files/3950686/test2.zip)

kerem commented

2026-02-25 21:30:33 +03:00

Author

Owner

@programatix commented on GitHub (Dec 11, 2019):

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.

@programatix commented on GitHub (Dec 11, 2019): 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.

kerem commented

2026-02-25 21:30:33 +03:00

Author

Owner

@jzabroski commented on GitHub (Dec 11, 2019):

@programatix can you try sending @brutaldev the binary MSBuild log file?
http://msbuildlog.com/#advantages

On Wed, Dec 11, 2019 at 10:38 AM programatix notifications@github.com
wrote:

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. 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.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/brutaldev/StrongNameSigner/issues/57?email_source=notifications&email_token=AADNH7M525KXZZAZVUME4N3QYECN5A5CNFSM4JZNSP62YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGTSAFI#issuecomment-564600853,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AADNH7J66GTT7GNFMJ73NQLQYECN5ANCNFSM4JZNSP6Q
.

@jzabroski commented on GitHub (Dec 11, 2019): @programatix can you try sending @brutaldev the binary MSBuild log file? http://msbuildlog.com/#advantages On Wed, Dec 11, 2019 at 10:38 AM programatix <notifications@github.com> wrote: > 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. 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. > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <https://github.com/brutaldev/StrongNameSigner/issues/57?email_source=notifications&email_token=AADNH7M525KXZZAZVUME4N3QYECN5A5CNFSM4JZNSP62YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGTSAFI#issuecomment-564600853>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AADNH7J66GTT7GNFMJ73NQLQYECN5ANCNFSM4JZNSP6Q> > . >

kerem commented

2026-02-25 21:30:33 +03:00

Author

Owner

@programatix commented on GitHub (Dec 11, 2019):

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

@programatix commented on GitHub (Dec 11, 2019): 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](https://github.com/brutaldev/StrongNameSigner/files/3951667/test2.v2.zip)

kerem commented

2026-02-25 21:30:33 +03:00

Author

Owner

@jzabroski commented on GitHub (Dec 11, 2019):

@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.

@jzabroski commented on GitHub (Dec 11, 2019): @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.

kerem commented

2026-02-25 21:30:33 +03:00

Author

Owner

@programatix commented on GitHub (Dec 11, 2019):

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.

@programatix commented on GitHub (Dec 11, 2019): 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.

kerem commented

2026-02-25 21:30:33 +03:00

Author

Owner

@jzabroski commented on GitHub (Dec 11, 2019):

So, your build is really weird. WpfApp1.csproj should not build IMHO but
it does - where are you referencing MahApps? My mind is blown.

[image: image.png]

On Wed, Dec 11, 2019 at 12:34 PM programatix notifications@github.com
wrote:

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.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/brutaldev/StrongNameSigner/issues/57?email_source=notifications&email_token=AADNH7I4TLNKNBGGA2VZAPLQYEQB3A5CNFSM4JZNSP62YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGT6OLQ#issuecomment-564651822,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AADNH7MACRQWZUY4FUAU7BLQYEQB3ANCNFSM4JZNSP6Q
.

@jzabroski commented on GitHub (Dec 11, 2019): So, your build is really weird. WpfApp1.csproj should not build IMHO but it does - where are you referencing MahApps? My mind is blown. [image: image.png] On Wed, Dec 11, 2019 at 12:34 PM programatix <notifications@github.com> wrote: > 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. > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <https://github.com/brutaldev/StrongNameSigner/issues/57?email_source=notifications&email_token=AADNH7I4TLNKNBGGA2VZAPLQYEQB3A5CNFSM4JZNSP62YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGT6OLQ#issuecomment-564651822>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AADNH7MACRQWZUY4FUAU7BLQYEQB3ANCNFSM4JZNSP6Q> > . >

kerem commented

2026-02-25 21:30:33 +03:00

Author

Owner

@programatix commented on GitHub (Dec 11, 2019):

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.

@programatix commented on GitHub (Dec 11, 2019): 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.

kerem commented

2026-02-25 21:30:33 +03:00

Author

Owner

@jzabroski commented on GitHub (Dec 11, 2019):

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

@jzabroski commented on GitHub (Dec 11, 2019): 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

kerem commented

2026-02-25 21:30:33 +03:00

Author

Owner

@brutaldev commented on GitHub (Dec 11, 2019):

@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).

@brutaldev commented on GitHub (Dec 11, 2019): @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).

kerem commented

2026-02-25 21:30:33 +03:00

Author

Owner

@jzabroski commented on GitHub (Dec 11, 2019):

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/

@jzabroski commented on GitHub (Dec 11, 2019): 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/

kerem commented

2026-02-25 21:30:33 +03:00

Author

Owner

@brutaldev commented on GitHub (Dec 11, 2019):

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.

@brutaldev commented on GitHub (Dec 11, 2019): 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.

kerem commented

2026-02-25 21:30:34 +03:00

Author

Owner

@brutaldev commented on GitHub (Dec 11, 2019):

Fixed up, got it down to 2 seconds so not going to push it any more than that.
Release: https://github.com/brutaldev/StrongNameSigner/releases/tag/2.7.0
NuGet: https://www.nuget.org/packages/Brutal.Dev.StrongNameSigner/2.7.0
Download: https://github.com/brutaldev/StrongNameSigner/releases/download/2.7.0/StrongNameSigner_Setup.exe

@brutaldev commented on GitHub (Dec 11, 2019): Fixed up, got it down to 2 seconds so not going to push it any more than that. Release: https://github.com/brutaldev/StrongNameSigner/releases/tag/2.7.0 NuGet: https://www.nuget.org/packages/Brutal.Dev.StrongNameSigner/2.7.0 Download: https://github.com/brutaldev/StrongNameSigner/releases/download/2.7.0/StrongNameSigner_Setup.exe

kerem commented

2026-02-25 21:30:34 +03:00

Author

Owner

@programatix commented on GitHub (Dec 12, 2019):

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\....

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.

@programatix commented on GitHub (Dec 12, 2019): 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](https://github.com/brutaldev/StrongNameSigner/files/3953453/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](https://user-images.githubusercontent.com/3293865/70676208-5564e780-1cc6-11ea-80da-d0cc5e9c0c64.png) 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.

kerem commented

2026-02-25 21:30:34 +03:00

Author

Owner

@brutaldev commented on GitHub (Dec 12, 2019):

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

@brutaldev commented on GitHub (Dec 12, 2019): 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

Rows
Columns

[GH-ISSUE #57] Long pause on build #50