Visual Studio 2008 not responding when dealing with large number of tests - c#

We are working with Visual Studio 2008 in a solution with 128 projects, almost half of them are unit test projects which make a total number of more than 5000 unit tests. For that reason we usually leave all unit test projects unloaded except those ones we are working with. Nevertheless, we often suffer from having Visual Studio 2008 blocked whenever we try to launch a single unit test or load/unload a different unit test project. In Task Manager we see that devenv.exe process takes constantly 25% of CPU and through Process Explorer we have seen that devenv.exe is in a loop of CreateFile, QueryBasicInformationFile and CloseFile for each project file loaded in the solution, iterating through all project files over and over again.
We have tried to set in the registry the key HKLM\Software\Microsoft\VisualStudio\9.0\EnterpriseTools\QualityTools\EnableCMI to 0 as it is stated in some forums where we have searched for a solution or workaround, but with no luck.
As a workaround, we are working with solutions that contain only a small subset of projects, but we don´t see it as a definite solution as we don´t consider very 'developer-friendly' to be switching between different solutions and different instances of VS2008 all the time.
Anyone who had experienced this same behavior could give us any clue on how to prevent Visual Studio 2008 from being unresponsive for so much time when dealing with unit tests? It makes developing unit tests almost impossible.
Many thanks in advance.
Jose Antonio

Consider upgrading Visual Studio. 2008 is ancient and it had serious performance issues in large solutions. 2012 was better, but IIRC a lot of work was done in 2013 to make it workable with a lot of projects.
128 projects in one solution in 2008 times is - ah - challenging it. Not to say totally over the top by factors.
With 2013 it should actually work
There is not a lot you can do here in fact - the problems with a significant number of projects in older versions of Visual Studio are simply documented and were fixed a long time ago - in newer versions.

Related

Maximum amount of projects in visual studio 2019 solution

at the moment I‘m very frustrated while developing at work. We‘re working in a visual studio 2019 solution file with 290 projects in it. Our software is written in C# using .NET code.
I‘m getting even more frustrated every time when I change a branch of the git repository, because the visual studio then starts a whole reload of the solution which takes up to 5 or 10 minutes.
Do you know if there is a limit for the amount of projects in a visual studio solution? Or did you work within solution with a higher amount than 300 projects?
While there is no enforced limit (in theory you can have thousands of projects in a solution file and visual studio will try to load them) there are some, as you can see here: Recommended number of projects in Visual Studio Solution
Machine limits. After a certain number, non powerful machines take to much to load or even crash.
Older vs version have been reported to crash after a certain number (even lower than yours)
Manageability is also a concern. Too many projects sometimes mean that there should be a better separation of concerns. Having them all in one solution sometimes brings unneeded coupling between unrelated codebases.
If number 3 is not the case, I'd advise you to create multiple solutions, each a subset of the projects per domain area.
If it is, try to refactor and decouple. Each decoupled dll should be moved outside the solution, packaged into a nuget and consumed independently.

Visual Studio have many delay before start to building and some time be stop again

We have a moderately sized solution, with about 20 projects. In one of them I have my business entities. On compiling any project, visual studio waits and hangs about one and a half minutes on this BusinessEntities project.
I tried our solution in SharpDevelop and it compiles our complete solution, in 18 seconds. Similar timing with MSBuild.
My guess is that VS is trying to find out if the project needs a compile, but this process is about 15 times slower than actually performing the compile!!
I can't switch to the great sharpdevelop, it lacks some small, but essential requirements for our debugging scenarios.
Can I prevent VS from checking this project, And have it compile the projects without such a check, just like sharpdevelop?
I already know about unchecking projects in configuration management to prevent building some projects, but my developers will forget they need to compile this project after updating to latest sources and they face problems that seem strange to them.
Edit: Interesting results of an investigation: The delay happens to one of the projects only. In configuration manager I unchecked all projects, then compiled each of them individually. All projects compile in a few seconds!! The point is this: if that special project is built directly, compiles in a few seconds, if it is being built (or skipped, because it is up-to-date) as a result of building another project that depends on it, VS hangs for about a minute and half, and then decides to compile it (or skip it). My conclusion: Visual studio is checking to know if any files are changed, but for some reasons, for this special project it is extremely inefficient!!

Visual Studio 2017 Enterprise won't stop running all tests on build

I have a project, composed of a 3 C#/.NET Core class libraries, targeting .NET Standard 2.0. In addition, I have a XUnit test project, where I use FluentAssertions.
When working on the project, I use Visual Studio 2017 Enterprise, with Resharper Ultimate installed.
When running the full suite of tests, my SQL Server 2016 Express database is hit around 8100 times.
If I leave my profiler running while working in Visual Studio, I can see that the full suite of tests is executed, whenever I change code and do a build.
It's a bit of a nuisance, since it takes a good 1-1½ minute for the tests to finish, and often, I will only want to run a specific subset of the tests, when making incremental changes.
My problem: I can't seem to stop the tests running from running on build.
What puzzles me the most is, that I can't cancel the tests from Test explorer or Resharpers Test window, as they appear not to be running at all.
Also, the Test pane of the output window does not show anything except "....Discovering unittests" without progressing any further.
My impressions is, that from Visual Studios perspective, the tests are not running at all.
Getting the primary suspects out of the way:
The "Run tests after build" button in test explorer is not toggled
on.
Live unit testing appears to be disabled (The only option from the
menu is "Start")
I've spent hours browsing the net trying to figure out what is going on, with no luck. I'm hoping someone here can help me find out why the tests are running, and how to stop them.
This is my first ever StackOverflow question. I hope my questions meets the requirements for asking. If not, please let me know what to do better.
First I would advise you update VS. There was an issue in test discovery taking long time that was fixed in update 15.7 (See here)
If that doesn't do the trick I advise you try disabling this option in Tools > Options > Test:
As this might be attempting to analyse all assemblies in build output folder to discover tests.

How to identify what causes Visual Studio to use to much memory?

we are using Visual Studio 2013 with latest updates installed. Our solution(s) contains about 20 to 30 C# library and asp.net projects. We also have some extensions installed such as Resharper, VSCommands and NCrunch (all latest versions as well).
After working a couple of minutes on a solution the memory of Visual studio increases to more than 2GB of RAM. The IDE is becoming very unresponsive.
Usually i have to close a solution after working with it after 1 or 2 hours.
When not closing VS myself the RAM usage goes up to 3GB+ and VS crashes (probably because VS is still a 32bit application)
How can i identify what causes Visual Studio to use so much memory?
Thanks
(I realized that ncrunch is also using a lot of RAM when executing our tests. Therefor i have disabled it. It takes a couple of minutes longer for VS to use so much ram when ncrunch is disabled but the problem remains)
Ran into a similar scenario on my end. But mine was purely resharper.
I had personally used the following things to optimize the performance.
http://confluence.jetbrains.com/display/NETCOM/Ultimate+Guide+to+Speeding+Up+ReSharper+(and+Visual+Studio)
For huge projects, I usually turn off the solution wide analysis for it.
We identified that the latest perforce plugin for visual studio (p4vs: p4vs11_2014.2.93.1619.vsix) was the cause for VS to grow in memory usage.
We downgraded to p4vs11_2013.3.78.1524.vsix. This fixed the problem.
(Also it seems that p4vs11_2014.1.85.4506.vsix is still working)

Should or can Visual Studio run inside App-V and what are the repurcussions?

There is a debate going in our department to virtualize Visual Studio into App-V, Microsofts Application Virtualization. In the back of my mind, I think doing this will cause problems when trying to debug or run other tasks in Visual Studio but I can't put my finger on any one thing to support my argument.
Has anyone had any experience with Visual Studio 2010 running inside App-V?
I am open to the idea if there are no issues but I am afraid that if this is put in place, we will have issues.
What do you think?
Based on the description of App-V here I'd be shocked if the performance was good enough for Visual Studio to be usable. VS is a very processor and IO intensive application. Virtualizing its entire operation over the wire is likely drag performance down to unacceptable levels.
I have seen VS perform acceptably on local VMs running VirtualBox, that might be another option for you if platform standardization is your goal.
I know this is an ancient question, but I found it in a Google search. Just wanted to mention that we've been running Visual Studio 2010 this way for a couple of years, and it's fine. We use it in both a classroom setting and on developer desktops.

Categories