codecadwallader / codemaid

CodeMaid is an open source Visual Studio extension to cleanup and simplify our C#, C++, F#, VB, PHP, PowerShell, JSON, XAML, XML, ASP, HTML, CSS, LESS, SCSS, JavaScript and TypeScript coding.
http://www.codemaid.net
GNU Lesser General Public License v3.0
1.88k stars 352 forks source link

Build is taking much longer after updating to VS 2019 v16.9.0 - CodeMaid v11.2.231 #795

Open iamsu007 opened 3 years ago

iamsu007 commented 3 years ago

Environment

Description

Build is taking much longer than usual after updated to v16.9.0. The VS stops responding at certain times. See the attached CodeMaid.config.

Steps to recreate

Ctrl + Shift + B to start the Build

Current behavior

In the previous VS 2019 versions like 16.8.5, the build was much faster. The same solution works faster with VS v16.8.5 rather than the new v16.9.0.

Expected behavior

The Build should not take so long to complete and should not crash the VS.

iamsu007 commented 3 years ago

CodeMaid.txt CodeMaid.config file used

ghost commented 3 years ago

Having the same problem for one project. Visual Studio hangs a log time during build. If I attach a debugger during the hang I get this exception in an endless loop

System.Runtime.InteropServices.COMException: 'Catastrophic failure (Exception from HRESULT: 0x8000FFFF (E_UNEXPECTED))'

with this call stack

Microsoft.VisualStudio.Editor.Implementation.dll!Microsoft.VisualStudio.Editor.Implementation.TextDocData.DTEDocument.get() Unknown
Microsoft.VisualStudio.Editor.Implementation.dll!Microsoft.VisualStudio.Editor.Implementation.TextDocData.EnvDTE.IExtensibleObject.GetAutomationObject(string Name, EnvDTE.IExtensibleObjectSite pParent, out object ppDisp)    Unknown
[Native to Managed Transition]  
[Managed to Native Transition]  
SteveCadwallader.CodeMaid.dll!SteveCadwallader.CodeMaid.Integration.Events.TextEditorEventListener.TextEditorEvents_LineChanged(EnvDTE.TextPoint startPoint, EnvDTE.TextPoint endPoint, int hint) Line 78   C#
EnvDTE.dll!EnvDTE._dispTextEditorEvents_SinkHelper.LineChanged(EnvDTE.TextPoint A_1, EnvDTE.TextPoint A_2, int A_3) Unknown
[Native to Managed Transition]  
[Managed to Native Transition]  
[Native to Managed Transition]  
[Managed to Native Transition]  
Microsoft.VisualStudio.Editor.Implementation.dll!Microsoft.VisualStudio.Editor.Implementation.TextDocData.ExtensibilityFireLineCommitEvent(uint dwGestureFlags, Microsoft.VisualStudio.Text.SnapshotSpan textSpan)  Unknown
Microsoft.VisualStudio.Editor.Implementation.dll!Microsoft.VisualStudio.Editor.Implementation.TextDocData.OnTextBufferChanged(object sender, Microsoft.VisualStudio.Text.TextContentChangedEventArgs e) Unknown
Microsoft.VisualStudio.Platform.VSEditor.dll!Microsoft.VisualStudio.Text.Utilities.GuardedOperations.RaiseEvent<Microsoft.VisualStudio.Text.TextContentChangedEventArgs>(object sender = {Microsoft.VisualStudio.Text.Implementation.TextBuffer}, System.EventHandler<Microsoft.VisualStudio.Text.TextContentChangedEventArgs> eventHandlers, Microsoft.VisualStudio.Text.TextContentChangedEventArgs args = {Microsoft.VisualStudio.Text.TextContentChangedEventArgs}) Unknown
Microsoft.VisualStudio.Platform.VSEditor.dll!Microsoft.VisualStudio.Text.Implementation.BaseBuffer.RawRaiseEvent(Microsoft.VisualStudio.Text.TextContentChangedEventArgs args, bool immediate)  Unknown
Microsoft.VisualStudio.Platform.VSEditor.dll!Microsoft.VisualStudio.Text.Implementation.BaseBuffer.TextContentChangedEventRaiser.RaiseEvent(Microsoft.VisualStudio.Text.Implementation.BaseBuffer baseBuffer, bool immediate)   Unknown
Microsoft.VisualStudio.Platform.VSEditor.dll!Microsoft.VisualStudio.Text.Implementation.BufferGroup.RaiseEvents()   Unknown
Microsoft.VisualStudio.Platform.VSEditor.dll!Microsoft.VisualStudio.Text.Implementation.BufferGroup.FinishEdit()    Unknown
Microsoft.VisualStudio.Platform.VSEditor.dll!Microsoft.VisualStudio.Text.Implementation.BaseBuffer.TextBufferEdit.Apply()   Unknown
Microsoft.VisualStudio.Editor.Implementation.dll!Microsoft.VisualStudio.Editor.Implementation.TextDocData.ReplaceLinesHelper.AnonymousMethod__0()   Unknown
Microsoft.VisualStudio.Editor.Implementation.dll!Microsoft.VisualStudio.Editor.Implementation.TextDocData.ReplaceLinesHelper(uint dwFlags, int iStartLine, int iStartIndex, int iEndLine, int iEndIndex, string text, Microsoft.VisualStudio.TextManager.Interop.TextSpan[] pChangedSpan)   Unknown
Microsoft.VisualStudio.Editor.Implementation.dll!Microsoft.VisualStudio.Editor.Implementation.TextDocData.ReplaceLinesEx(uint dwFlags, int iStartLine, int iStartIndex, int iEndLine, int iEndIndex, System.IntPtr pszText, int iNewLen, Microsoft.VisualStudio.TextManager.Interop.TextSpan[] pChangedSpan)    Unknown
[Native to Managed Transition]  
[Managed to Native Transition]  
Microsoft.VisualStudio.CommonIDE.dll!Microsoft.VisualStudio.Build.ComInteropWrapper.HostLogger.Write(string message)    Unknown
Microsoft.Build.dll!Microsoft.Build.BackEnd.Logging.ParallelConsoleLogger.WriteBasedOnPrefix(string nonNullMessage, bool prefixAlreadyWritten, int adjustedPrefixWidth) Unknown
Microsoft.Build.dll!Microsoft.Build.BackEnd.Logging.ParallelConsoleLogger.WriteMessageAligned(string message, bool prefixAlreadyWritten = true, int prefixAdjustment)   Unknown
Microsoft.Build.dll!Microsoft.Build.BackEnd.Logging.ParallelConsoleLogger.WarningHandler(object sender, Microsoft.Build.Framework.BuildWarningEventArgs e = {Microsoft.Build.Framework.BuildWarningEventArgs})  Unknown
Microsoft.VisualStudio.CommonIDE.dll!Microsoft.VisualStudio.Build.ComInteropWrapper.HostLogger.SendEventToConsoleLogger(Microsoft.Build.Framework.BuildEventArgs args)  Unknown
Microsoft.VisualStudio.CommonIDE.dll!Microsoft.VisualStudio.Build.ComInteropWrapper.HostLogger.SendEventToIde(Microsoft.Build.Framework.BuildEventArgs args = {Microsoft.Build.Framework.BuildWarningEventArgs})    Unknown
Microsoft.VisualStudio.CommonIDE.dll!Microsoft.VisualStudio.Build.ComInteropWrapper.HostLogger.ProcessQueueAsync()  Unknown
[Resuming Async Method] 
mscorlib.dll!System.Runtime.CompilerServices.AsyncMethodBuilderCore.MoveNextRunner.InvokeMoveNext(object stateMachine)  Unknown
mscorlib.dll!System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool preserveSyncCtx)   Unknown
mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool preserveSyncCtx)   Unknown
mscorlib.dll!System.Runtime.CompilerServices.AsyncMethodBuilderCore.MoveNextRunner.Run()    Unknown
mscorlib.dll!System.Threading.Tasks.SynchronizationContextAwaitTaskContinuation..cctor.AnonymousMethod__8_0(object state)   Unknown
Microsoft.VisualStudio.Threading.dll!Microsoft.VisualStudio.Threading.JoinableTaskFactory.SingleExecuteProtector.TryExecute()   Unknown
Microsoft.VisualStudio.Threading.dll!Microsoft.VisualStudio.Threading.JoinableTaskFactory.SingleExecuteProtector..cctor.AnonymousMethod__20_0(object state) Unknown
mscorlib.dll!System.Threading.Tasks.Task.InnerInvoke()  Unknown
mscorlib.dll!System.Threading.Tasks.Task.Execute()  Unknown
mscorlib.dll!System.Threading.Tasks.Task.ExecutionContextCallback(object obj)   Unknown
mscorlib.dll!System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool preserveSyncCtx)   Unknown
mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool preserveSyncCtx)   Unknown
mscorlib.dll!System.Threading.Tasks.Task.ExecuteWithThreadLocal(ref System.Threading.Tasks.Task currentTaskSlot = Id = 1041528, Status = Running, Method = "Void Invoke(System.Object)")    Unknown
mscorlib.dll!System.Threading.Tasks.Task.ExecuteEntry(bool bPreventDoubleExecution) Unknown
mscorlib.dll!System.Threading.Tasks.TaskScheduler.TryExecuteTask(System.Threading.Tasks.Task task)  Unknown
Microsoft.VisualStudio.Shell.UI.Internal.dll!Microsoft.VisualStudio.Services.TaskSchedulerService.VsUIThreadBlockableTaskScheduler.DoOneTask(out int dequeuedTaskCount = 1) Unknown
Microsoft.VisualStudio.Shell.UI.Internal.dll!Microsoft.VisualStudio.Services.TaskSchedulerService.VsIdleTimeScheduler.FDoIdle(uint grfidlef)    Unknown
[Async Call Stack]  
[Async] Microsoft.VisualStudio.Threading.dll!Microsoft.VisualStudio.Threading.JoinableTask.SetWrappedTask.AnonymousMethod__81_0(System.Threading.Tasks.Task t, object s)    Unknown
kaby76 commented 3 years ago

Same with v16.9.1--stalls for 1minute+ on a C# project rebuild. I have to disable the extension.

codecadwallader commented 3 years ago

Thanks for reporting the issue. I have not been able to reproduce it yet using v16.10.0 Preview compiling a standard solution like https://github.com/microsoft/vs-editor-api

I see there was a fix published by Microsoft yesterday in v16.9.2 with the message:

Fixed an issue causing a building project with fast deployment enabled to fail deployment or take additional time

https://docs.microsoft.com/en-us/visualstudio/releases/2019/release-notes#16.9.2

Can someone that is reproducing the issue try upgrading to that version and see if that helps? If you're still seeing the issue, can you please provide a minimal solution that exhibits it?

kaby76 commented 3 years ago

@codecadwallader Do you know of a switch I can throw on in VS2019 to output timings? Otherwise, I can run the perf tool over VS2019 itself. Codemaid is really a great tool--can't live without it really.

AKruimink commented 3 years ago
Visual Studio version: 2019 Community - v16.9.2
CodeMaid version: 11.2.231

Noticing the same issue, my .net core projects seem to build just fine, but my .net framework project does not. A clean ASP.NET Framework web api running .net framework 4.8 takes me anywhere from 3 to 5 minutes for the build to finish (Visual Studio compleetly freezes while doing so).

Already resetted all my Codemaid settings, but nothing changed.

@codecadwallader as i am running 16.9.2 i can confirm the issue is still persists.

AKruimink commented 3 years ago

@codecadwallader Here is a projects in which im able to replicate it (note that its a bit messy as i ripped it out of some existing stuff)

It's basicly a clean asp.net framework web api, an editor config and pipeline file are included, i tried it with disabling the .net core project that is there as well, which did not seem to make any difference for me, but decided to leave it in as it might make a difference afterall.

Edit: on that project i timed a 1 minute and 46 second build time, it contains 2 clean projects (web api using framework and .net 5 console project, although removing the .net 5 seems to make no difference on my end, so the problem seems to be with the web project)

EDIT: quick note, for reasons that are unimportant i ended up reinstalling my desktop, and the same issue now no longer occures on that project, so it seems not consistent.

codecadwallader commented 3 years ago

@AKruimink Thanks for the sample solution. Unfortunately similar to what you're seeing now, I was unable to reproduce the issue with it either. It is helpful to know though that the issue is intermittent.

@kaby76 If you search for msbuild in Tools->Options you can change the MSBuild project build output verbosity, although I wasn't getting any additional information with the sample solution.

dada051 commented 3 years ago

I have a solution with a lot of .NET Framework 4.8 projects. Handled approximatively well on 16.8.x, freezing with 16.9.3... I fixed some comments ("///") on my code and it's started to be handled better. Don't kwon if this can help.

codecadwallader commented 3 years ago

Thanks for the information @dada051 . I'm still hoping for a mechanism to reproduce the issue to chase it further.

dada051 commented 3 years ago

I reproduced the bug with another extension : Visual Studio Build Timer. But it seems that Visual Studio is not handling builds very well in the latest versions...

codecadwallader commented 3 years ago

Thanks for the context @dada051 I looked but it doesn't appear their code is available to see if there's a particular API that we're both using. Presumably we're both listening to build events (see https://github.com/codecadwallader/codemaid/blob/dev/CodeMaid/Integration/Events/BuildProgressEventListener.cs)

Do you see the same bug whether you have just CodeMaid or just Visual Studio Build Timer enabled?

dada051 commented 3 years ago

As I remember, I have the same bug with the 2 extensions, using only one at the same time.

dada051 commented 3 years ago

Other information maybe. It seems freezing VS even if I uncheck builds related checkboxes in CodeMaid configuration.

I will try to check all these informations today or tomorrow.

codecadwallader commented 3 years ago

Thanks @dada051 đź‘Ť

To confirm you disabled the build option at CodeMaid->Options->General->Features->Tool Windows->Build Progress? I believe this is what registers the event listeners that hook into build events.

image

dada051 commented 3 years ago

In features, I unchecked "Build Progress" and "Spade" (in your screenshot). and I also unchecked all in Progressing image

Without CodeMaid, 42sec to build. With CodeMaid configured as explained, 4 min of freeze (and I killed VS)

mindofbeholder commented 3 years ago

I have no extensions enabled other than CodeMaid and experience the same issues. I do have a ton of stylecop warnings (inherited codebase) that fly by during the build process. Not sure if that's contributing in any way.

osoviejo commented 3 years ago

No previous experience with CodeMaid, installed it a couple of days ago on VS Community 16.9.4. Targeting Net Framework 4.8, with a single-project solution that ordinarily take less than 10 seconds to build. With CodeMaid enabled it's about 70 seconds. As others have mentioned, it doesn't matter what my settings are, although I do disable all build-related options.

With a non-CodeMaid build, the Output window shows build progress continuously to conclusion. With CodeMaid enabled, the Output window (and indeed, all of VS) freezes immediately upon commencing a build, and only after it is completed does the build progress get displayed all at once in the Output window.

codecadwallader commented 3 years ago

Thanks for the additional information, that is very helpful in figuring out trends/commonality.

I am still unable to reproduce the issue. I created a new Windows Forms application targeting .NET Framework 4.8 and it builds in a single second as expected. If anyone has a solution that can consistently reproduce the issue and is able to share it I would really appreciate it.

I am using VS 2019 Community 16.10 Preview 2.0. I use the preview track of VS to try and get ahead of compatibility issues. It's possible it has been fixed and that's why I can't reproduce it, but there's nothing in the changelog indicating that https://docs.microsoft.com/en-us/visualstudio/releases/2019/release-notes-preview

dada051 commented 3 years ago

My solution contains only class libraries and ASP.NET projects. It uses the packages.config, not the packagereference, for managing Nuget. Maybe it’s linked to the migration from .NET Framework 4.6 to 4.8 that cause the bug, not .NET Framework 4.8 from scratch ?

Hope it can help

De : Steve @.> Envoyé le :vendredi 30 avril 2021 14:00 À : @.> Cc : @.>; @.> Objet :Re: [codecadwallader/codemaid] Build is taking much longer after updating to VS 2019 v16.9.0 - CodeMaid v11.2.231 (#795)

Thanks for the additional information, that is very helpful in figuring out trends/commonality.

I am still unable to reproduce the issue. I created a new Windows Forms application targeting .NET Framework 4.8 and it builds in a single second as expected. If anyone has a solution that can consistently reproduce the issue and is able to share it I would really appreciate it.

I am using VS 2019 Community 16.10 Preview 2.0. I use the preview track of VS to try and get ahead of compatibility issues. It's possible it has been fixed and that's why I can't reproduce it, but there's nothing in the changelog indicating that https://docs.microsoft.com/en-us/visualstudio/releases/2019/release-notes-previewhttps://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fvisualstudio%2Freleases%2F2019%2Frelease-notes-preview&data=04%7C01%7C%7Cee1714f8b5a8414c166b08d90bcf8fcc%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637553808354566496%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=cWkeMdmd4qac4DDkBBvGiRi3as3lJ8JcnvjHDZV6FJY%3D&reserved=0

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcodecadwallader%2Fcodemaid%2Fissues%2F795%23issuecomment-830044905&data=04%7C01%7C%7Cee1714f8b5a8414c166b08d90bcf8fcc%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637553808354576490%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=wfA4OY4wLP%2BkpeIo%2Brv45ikAE0TjElJIHBgrKn698VA%3D&reserved=0, or unsubscribehttps://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FACEO3U7Y6YXPWBVMJK7NTPDTLKLWFANCNFSM4YZERKNQ&data=04%7C01%7C%7Cee1714f8b5a8414c166b08d90bcf8fcc%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637553808354576490%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=wx1j7rI5Ld4aIROCm0%2F0d%2FEQNhotNY0ajXpdknHtpts%3D&reserved=0.

osoviejo commented 3 years ago

This feels decidedly unhelpful, but I've spent the last day or two (with CodeMaid disabled) installing Roslyn analyzers, setting all rules to "error" via .editorconfig and working through configuring them. So with about 12,000 errors on my build, tried reenabling CodeMaid, and it zipped right through in about 11 seconds (compared to seven or eight seconds without CodeMaid and no errors) and otherwise behaved normally and as expected.

So...I've got nothing. Not a clue. It's an MVC 5/EF 6 project, if that helps. Sorry it couldn't be more.

Kesmy commented 3 years ago

Just want to add a comment to the pile, I have the same issue, and it is consistent across anything I attempt to build. Disabling/uninstalling Codemaid immediately resolves the issue, reinstalling it causes the same issue.

It only appears to be a problem with building, and changing the Codemaid build options has no effect.

codecadwallader commented 3 years ago

Thanks @Kesmy for the context. Can you share the solution you have that consistently reproduces the issue, or strip it down / make a new one that you can share? So far attempts to make a new one have been unsuccessful and I haven't been able to reproduce the issue yet.

Kesmy commented 3 years ago

@codecadwallader It happens on every single solution/project, even just default project templates with no changes.

osoviejo commented 3 years ago

After appearing to be solved (for no apparent reason), I'm again experiencing the same issues previously described. Since we don't really have anything to go on, I will contribute as much (possibly) relevant information I can in the hopes that commonalities with other users can be found.

I'm sure most of this info is irrelevant, but perhaps some of it will align with others having this problem and help get us to a repro. I'd add that since two people building the same (template) solution on different machines have different experiences with this issue, it suggests that environment outside the solution may be a factor.

vsconfig.txt vsext.txt CodeMaid.config.txt

codecadwallader commented 3 years ago

I'm able to consistently reproduce the issue right now. I can see it both with an ASP.NET WebAPI proejct and a Console project, both using .NET Framework v4.8. As far as I know nobody has seen the issue with .NET Core, only .NET Framework. Unfortunately the issue it isn't reproducible in the experimental (debugging) instance for extensions so it's slow going re-compiling, uninstalling and reinstalling the extension to test different ideas.

I'm fairly confident that I've tied it into the build events API as a build with the EnvDTE event listeners commented out seemed to consistently work as expected (i.e. no freeze ups or delays). This makes sense with the builds themselves being affected, and other VS extensions that work with the build events API encountering the same issue.

I have an experimental build available that may help. It simply comments out interaction with the build events API entirely, which breaks the build progress functionality but also should(tm) bypass the issue since it is avoiding that API. If you want to test it out it is available here as v11.2.247: https://www.vsixgallery.com/extension/4c82e17d-927e-42d2-8460-b473ac7df316 I would appreciate some help confirming if this bypass indeed avoids the issue.

osoviejo commented 3 years ago

The behavior with the update is unchanged for me, although it's great you've got a repro for it now:

I have never used CM's Build Progress feature.

Kesmy commented 3 years ago

@codecadwallader For me, at least, this version appears to solve the issue.

I'll note that building does take longer, but is within my expectations for adding complex extensions. With this update it takes me like a minute to build vs. 30 seconds, where previously it could take an hour or more.

codecadwallader commented 3 years ago

Thanks both for testing it out and the feedback. It seems like we haven't found the extent of the issue yet since at best it's still slower than before but at worst it's not any better. However maybe we're looking in the right place if it improved things in some scenarios.

jmanumc commented 3 years ago

Hello

Visual Studio 16.9.6 Code Maid 11.2

I have noticed my VS fails, only when I activate any of the options:

Hope I can help you find the problem. Greetings.

codecadwallader commented 3 years ago

Thanks for the suggestions @jmanumc . I tried disabling all three of those but I was still able to reproduce the issue.

I disabled all event registration and that seemed to further isolate the issue, but breaks quite a lot of functionality.

My suspicion is that the API has changed and is less tolerant of certain actions that can require the UI thread (e.g. accessing the active document). These started spitting out some warnings in VS2019 but didn't previously have an impact. It's just a theory though, I haven't been able to prove/disprove it yet.

osoviejo commented 2 years ago

The latest update to VS 2019 (16.11.3), had an item in the changelog that caught my eye: "Visual Studio UI unresponsive when too much build log output during build." I don't know if that actually resolves this CM problem or not, but I can report I haven't had it happen since upgrading VS (dozens of builds).

https://developercommunity.visualstudio.com/t/Visual-Studio-UI-unresponsive-when-too-m/1359069

ghost commented 2 years ago

I can confirm that this is fixed 16.11.3.