I get the following error sometimes when deploying a SharePoint 2010 solution via Visual Studio 2010:
Error occurred in deployment step 'Activate Features': A timeout has occurred while invoking commands in SharePoint host process.
It's true -- it's taking a long time because we do a lot of work in the feature receiver. But This is not an error; I would just like Visual Studio to wait longer. Is there a place I can configure the amount of time to wait before timing out?
ChannelOperationTimeout
http://msdn.microsoft.com/en-us/library/ee471440.aspx
Do not forget to restart Visual Studio
Related
I am running into a frustrating issue with Visual Studio in which every time I open or refresh a solution, Visual Studio locks up for about 30 seconds and then I am met with this error
This happens about 10 times, so it takes about five minutes to get a working instance of Visual Studio.
I eventually traced this to entries in Server Explorer to which I don't have access. These seem to be auto-populated from connection string entries in various Web.config files throughout the solution. If I comment out the connection strings, the solution loads fine. But this is not an ideal solution because I don't want to commit these changes to source control.
Is there a way to stop this auto-population of Server Explorer? I don't remember this ever happening in previous version of Visual Studio, so maybe it's new in 2015?
I have recently installed Windows 10 in my DELL laptop. I see quite often Visual Studio 2015 not responding.
Is there a log that I can turn on to see what's happening in the Visual Studio while loading a project, to see any add-on delaying the load? Or something like that in the Task Monitor to see which resource is causing the slowness like disk read or memory?
UPDATE:
As per IInspectable's comment, I created a dump file from the Task Manager.
I don't see any thread information in this file. I tried to debug (by clicking debug from the actions menu) after loading the data in VS 2015 again. That takes a while to load the symbols, but at the end I see Source Not Available screen and stop there.
11/18/2015: Asp.net tools team is working on this performance issue.
You could try enabling logging via the /Log command line option of the devenv.exe. See the Microsoft reference. (devenv.exe being the Visual Studio IDE)
I'm getting a frustrating error when debugging in Visual Studio 2010.
I'm fairly certain that its something to do with a setting on IIS but no idea what it is!
here is the error:-
'The Web server process that was being debugged has been terminated by IIS.'
The time-out happens every time I debug, on any of the various workspaces we have at work
takes about 90 seconds of inactivity on the debugger for the error to show
IVE FOUND THE SOLUTION
In the advanced application pool settings in IIS you can change the maximum ping response time on the process model to stop the debugger timing out.
VS 2010 becomes unresponsive randomly. A look into process monitor shows it waits in a loop on RegQueryValue operation on HKLM\SOFTWARE\Microsoft\Cryptography\Defaults\Provider Types\Type 001\Name key. Why does Visual Studio need to do this? Is there a way to get around this?
Have tried resetting devenv and stopping Windows Cryptography Services.
I'm trying to build a setup project in Visual Studio 2005, and it is failing every time, after opening a dialog box labeled Microsoft SQL Server 2005 Tools and configuring for a few minutes. The Microsoft SQL Server 2005 Tools dialog then launches a dialog with the text Failure creating local group SQLServer2005NotificationServices$COMPUTER_NAME. I suspect this failure is because I'm not currently local admin on my machine (a situation I hope will be rectified rapidly), but I don't see why I need to configure MS SQL 2005, as my project does not use it, and in fact has no DB connectivity. How can I get past this step to a successful build?
Related:
Visual studio configures SQL 2008 on every build
Visual Studio Setup and Deployment build fails with no errors
Update: Got my admin back, but this is still taking up time to run, and I'd still like to be rid of it.
I found something about it on Microsoft Connect. Seems like it's a bug. In the reply they linked to a knowledge base article with some workarounds.