Bogged down CPU with Visual Studio 2017 and a C++ project

[trueqbit]

Hi,

After loading a C++ project, even just a simple one, the CPU keeps running constantly at around 70%. How should I go about to help find out the cause? I've created a minidump if that helps.

In regards to the selected features of the Visual Studio installation, I have chosen only a small subset for C++ desktop development, if that information is of interest.

[ceztko]

Hello. Yes, I noticed but I'm not using this extension actively on C++ projects anymore. I discovered the old method I used to set the global property is now causing a some loop inside VisualStudio and it's probably bugged/not supported anymore. The old method was clean in a sense and dirty in another. I will end setting the macro as a per project property: this should also handle the invalidation of the single projects better, without the tricks I was using (which are not the cause of the loops).

[trueqbit]

Ok... so I am unsure how to understand your answer: do you plan to fix it by not setting the macro as a per-project property or file it under 'not gonna fix for C++ projects'?

[ceztko]

I'm gonna fix it. Please have a little patience

[ceztko]

Can you test the attached release on VS2017? Can you also test a sample project on VS2013 or VS2015?

SolutionConfigurationName.zip

[ceztko]

A sample test project is the extension source[1]. Read the txt in the folder. https://github.com/ceztko/SolutionConfigurationName/tree/master/Resources/Test

[trueqbit]

I tested the .zip with VS2017 and VS2015:

• the CPU runs normal
• the test projects compile/link (though the one for VS17 crashes on my side due to the VS17 installation being C++ only)
• however: the $(SolutionConfiguration) macro is gone - is this expected?

[ceztko]

How do you test that the macro is gone? Can you make a simple script and test for it? The macro should still be there even if you don't see it in the macro editor. Unfortunately, I had to remove the macro from the global properties for c++ projects because that was causing issues, so it's possible that it's no more reported in the macro editor. Which is not so good. I think it's time to proper request the feature to Microsoft. https://visualstudio.uservoice.com/

[ceztko]

1) Please vote https://visualstudio.uservoice.com/forums/121579-visual-studio-ide/suggestions/19819036-make-available-solutionplatform-and-solutionc

2) Please vote https://developercommunity.visualstudio.com/content/problem/75339/extensions-setting-global-property-on-c-projectcol.html

3) Uninstall the previous test extenstion on VS2015/VS2017 (menu Tools -> Extension and Updates). Install the new extension attached to this post

4) Please test on VS2015 the attached extension with test project: should compile correctly, Release/Debug bin directories should be full, $(SolutionConfiguration) should be visible in the macro editor;

5) Please test on VS2017 the attached extension with test project (you can remove the C# projects with a text editor): should compile correctly, Release/Debug bin directories should be full, $(SolutionConfiguration) should be not visible in the macro editor, but should be still usable on settings and scripts.

This is the best I can do, for now. If everything is ok, I will release this version. SolutionConfigurationName.zip

[trueqbit]

I test it the following ways:

1. verify whether macro is visible/available when defining project properties (like the output directory and include paths)
2. set output directory of the .exe to $(SolutionDir)$(Platform)\$(SolutionConfiguration)\,
   1. verify whether VS's property evaluator shows the expected path
   2. verify files are really placed there

Now I noticed the following interesting behavior:

• VS2015
  1. macro isn't visible in the property editor
  2. macro actually works
• VS2017
  1. macro isn't visible in the property editor
  2. macro works sometimes, but not always, especially when switching between solution configurations and platform (x86, x64) - though I couldn't find a real pattern yet

While it is kind of unfortunate the property editor/evaluator doesn't pick the macro up, it's something one could live with). But I am surprised the final evaluation doesn't always work - seems like a refresh issue

[ceztko]

1) VS2015: macro isn't visible in the property editor Ok, my conjecture about visibility of the property editor was wrong, and I only have VS2017 installed atm. Sorry, there's nothing I can do about it without intense exploring of VS internals with memory debuggers, which I already did in the past just to support VS2013 and later. It is not worth the effort for this visual feature. 2) VS2017: macro works sometimes, but not always I got it once, me neither I found a pattern to reproduce it yet. I may have to find a different logic to invalidate the projects after.

[ceztko]

Unfortunately VS is destroying the per project macros I'm adding in a unpredictable way. Actually, the way I was using for all VS versions, that is setting a global property in the VC++ ProjectCollection[1] was avoiding this problem nicely, but this is causing the high cpu usage and I can't do anything about it. Possible solutions would be: 1) Wait for MS to fix the bug with global properties on C++ projects ProjectCollection; 2) Find the new location of the global properties for C++ projects and have a way to access it/add values; 3) Find the proper moment before adding per-project global properties, after being reset by VS but before build.

I spent a lot of time in 3) without results and I don't have time for further investigations now so I am officially pulling support for C++ projects in the extension running in VS2017.

[1] https://msdn.microsoft.com/en-us/library/microsoft.build.evaluation.projectcollection.aspx

[trueqbit]

Hi Francesco,

thank you so much for investigating this!

That's of course very unfortunate, as I am relying on this little macro - as VS allows one to set solution and project configuration independently it's IMHO actually the only proper way to e.g. set the output and include directories to the solution configuration.

But let's see how it goes, a solution to this specific problem might come along, and I'm gonna (re)open a feature request as well.

[ceztko]

Can you test the update extension attached? With VS2017 first. SolutionConfigurationName.zip

[trueqbit]

I tested it on VS2017 and VS2015 and it is working!

The only thing I noticed with VS2017: sometimes (though not really reproducible) when quickly rebuilding after switching configuration/platform following output would appear:

Build started ... Build Failure. Error: Cannot begin a transaction while already in a transaction. ========== Build: 0 succeeded, 0 failed, 0 up-to-date, 0 skipped ========== Calculating project dependencies...

Are the changes being tested in the vs15mef branch?

[ceztko]

Yes, changes are tested in the vs15mef branch. The old code path for previous VS versions is fully preserved. About your "transaction" issue with VS2017: I can't reproduce, but can you test the attached version? I just put a lock that should ensure projects are updated with the macros before starting a new build. SolutionConfigurationName.zip

[trueqbit]

It's hard to tell the difference whether the lock you put in has some effect. I think we'll see how it's going.

The bigger issue now is that VS15 works with a simple solution, but crashes with a 'system argument exception' after loading one of my solutions - which is still very simple, but contains e.g. unit test and installer projects...

[ceztko]

Are you able to provide a full call stack?

[ceztko]

If there is none, this is a good guide to get one by debugging an external devenv.exe with VS itself. https://www.devexpress.com/Support/Center/Question/Details/KA18588/collecting-a-call-stack-to-track-down-the-cause-of-vs-crash-or-freeze-issues

[trueqbit]

I am able to produce two useful callstacks and dump files and I have a simple solution to reproduce the crash. What's the best way to share them with you?

It's basically very simple: SolutionConfigurationName can't deal with projects grouped under a solution folder (i.e. one can add solution folders and move projects, but when reopening the solution VS crashes). Steps to reproduce:

• Create a solution with a C++ project
• Add a solution folder
• Add an empty C++ project to the solution folder
• Reopen the solution

[ceztko]

I was able to reproduce. The fix was to not invalidate the project with a save operation during loading. It works for me. Can you test the attached version? SolutionConfigurationName.zip

[ceztko]

Do you have any feedback on the latest test release?

[trueqbit]

I have it in use since a week and it's working great! The only issue I experienced is that the extension doesn't recognize when a solution configuration gets renamed, but that's probably an entire other thing/feature?

[ceztko]

Solution configuration renamed: yes, this is not handled and it's a new feature. As far as I know there's no easy hook for that, but at some point I may investigate the matter better. I would like to officially release 1.0.8 with C++ support reenabled in VS2017 but I don't have VS2013/VS2015 at hand for testing. Are you able to briefly test the sample project with the attached release candidate? Previous VS are running exactly the same code as before, I thin you already tested it. In this release I also removed the dependency on .NET sdk. Thanks SolutionConfigurationName.zip

[trueqbit]

I tested the extension again on VS2015 with your test solution plus one of my production ones, and it is working as expected. Also, the dependency on MSBuild instead of CoreEditor/.NET was a perfect idea, and apparently solved the installation issue - it's presenting the installation dialog instantaneously!

[ceztko]

Thank you, I deployed 1.0.8. It's the same package attached here, it shouldn't pop new updates on VS if you have it installed. Thanks for the testing.