Is there a way to reduce the timeout in the Manage NuGet Packages visual studio extension? I've been waiting for it to do something for over 10 minutes now and am getting bored of waiting. I've been getting a lot of timeouts recently and ideally would like to know how to diagnose/fix those, but would settle for a shorter timeout so I don't waste so much time twiddling my thumbs waiting for it to decide it isn't working.
You can get in touch with the developers and suggest them to include in the plugin a way to set a custom timeout for some actions. Being an open-source project I'm sure they will have ears for you :) If that doesn't work... you can grab the source code and make the improvements yourself.
Related
Me and few friends are going to participate in Ludum Dare in a few hours as a team. We wonder how to effectively work with Unity and VisualStudio together on multiple computers.
The first idea was to use git/svn but it turned out to be very annoying as we need to commit/push/pull way too often even for some minor changes such as some Unity button.
The second thought is to use Dropbox or some service like that. However, when .sln file is somehow changed, the project at the otherone's computer must be completely refreshed and it usually ends with import errors.
Could you give us some tips how to collaborate on the same project together as much effectively as possible?
Well we finally figured it out! The solution is to use Visual Code instead of Visual Studio. Then you may use Dropbox but you mustn´t sync Assembly-CSharp.csproj if your team use multiple operating systems.
When placing the curser on a closing bracket in c# for instance, there is a small annoying delay before the opening bracket gets highlighted, and you have to sit and wait before you can use shortcuts such as (ctrl + shift + up/down). It feels like it is intended behaviour for reasons beyond me, so i don't think it is a bug or because my computer is slow (it's not), but it's driving me crazy.
I'm on a freshly installed PC, so i have only testet it in a few programming languages / file formats, and the behaviour only occours in some of them.
The delayed highligh behaviour occurs in .cs (c#), and .css files, but not in .js and .html files, here the code gets highlighed instantaneously exactly like i want it to in .cs files aswell.
I'm using Visual Studio 2015 Community Edition.
I have had this problem as well, since first installing. I can confirm that Update 1 CTP addresses this issue, and the delay is almost gone (maybe 1/8 second now.)
This UI delay was actually called out as a bugfix that was included with the update:
https://support.microsoft.com/en-us/kb/3025135
To the problem that there is a delay highlighting the brackets: In my opinion that has nothing to do with a bug. I think it takes a little while because your code needs to be parsed every time you change something in order to highlight the brackets. When you have many lines of code in one file it is obvious that it takes a little more time than normal.
Here are some tips that may help you:
Click the bracket and press STRG + ´ this will bring you directly to the other bracket. Or you press ALT + ´ and it will mark all your code in between your current brackets. You can look up the shortcuts of Visual Studio in Tools -> Options -> Environment -> Keyboard:
I'd recommend everybody programming in Visual Studio is to change the highlight color of the matching bracket. Have a look at this:
Here you can change all the colors and forms used for specific searchterms. I personally use Visual Assist 2015 to highlight my code (that's why I didn't change anything here). It is way more faster than VS itself and comes with a lot more functions like bracket guidelines who will show you the indent level of your brackets. Have a look, maybe you like it:
Its about 500ms in a newly created console project
500 msec is a magic number in .NET. You can get some insight from the source code for the C# Language Service, accidentally (?) exposed by a Microsoft programmer on github. Most relevant file is probably this one:
internal interface IBraceMatchingService
{
Task<BraceMatchingResult?> GetMatchingBracesAsync(Document document,
int position, CancellationToken cancellationToken = default(CancellationToken));
}
Or in other words, the brace matching service runs as a background task. Such tasks normally run on a thread-pool thread and are subject to scheduling by the threadpool manager. That's where the magic 500 ms number comes into play. The manager attempts to keep the number of executing tp threads down to the number of processor cores available on the machine, the most efficient way to run threads. However, if the existing tp threads take too long to finish their job then the manager assumes that they are bogged down by I/O and allows an extra one to run. It does this once every 500 msec.
So first-order estimate of your problem is that VS has too many active thread-pool threads and they don't complete in a timely manner. Causing the brace matching task to run too late.
Finding out exactly what specific tasks bog it down is technically possible. I can't guarantee success with the Community edition and you'd need a fair amount of insight in how to read thread call stacks to get ahead. Startup another instance of Visual Studio and use Debug > Attach to Process. Pick "devenv.exe" from the list. Let it trundle while it is attempting to find PDB files, then use Debug > Break All.
First place to look is Debug > Windows > Tasks. Pretty unlikely you'll see anything there however, normal is to see none. Next one is Debug > Windows > Threads. You ought to see about 15 active threads back in that window. Hover over their Location column to take a peek at their callstack. Making sense of what you see isn't that simple unfortunately, it will help a lot if you can compare what you see with another machine that does not have this problem.
Since you have this problem on more than one machine, another approach is to look for an environmental factor that they have in common. Things to look for are aggressive anti-malware, a network connection that is too slow or too unreliable, a poorly performing add-in that you like but runs poorly on a VS version it wasn't tested on.
And consider that VS2015 isn't exactly ready for prime-time. Of all the recent VS versions released in the past 18 years, it is probably the least stable. It has a lot of heavy internal changes and there were an unprecedented number of alpha and beta versions with critical bug fixes implemented just a few months ago. Try it again after Update 1 is released.
Seems like this will be fixed in a future Visual Studio update: https://github.com/dotnet/roslyn/issues/1906#issuecomment-145874647
I have not found a definitive solution for your problem.
This was a known bug in the VS2015 review edition.
This links discusses the delay (this link refers to c# btw, not c):
https://connect.microsoft.com/VisualStudio/feedback/details/1033540/braces-are-not-highlighted-correctly-in-c
And there are still similar problems for some VS2015 Community Edition users.
http://www.developerteacher.com/msdn/bracket-matching-highlights-not-working-like-i-had-in-2013-express-4227
Personally, I think you are stuck with a bug and if I were you I'd try the following:
Make sure I had unistalled all previous editions of VS.
Try a repair.
Completely uninstall and reinstall VS2015 if running repair doesn't work
Go back to VS2013 if it drives you cannot stand it, and wait until VS2015 is a bit more ripe on the vine.
One thing I have found with VS, is when it plays up it's painful, it takes so long to install and the worst case was when I ended up uninstalling and downloading everything that was associated with the install. It now works fine. (this was after previewing 2015 and then going back to 2013). You can also try this for VS2015 and also try a new download.
I sometimes will have a look at some previews, but after jumping in with haste too many times with the latest software releases and then repenting with leisure. I am now happy to wait for new releases to be out for a while before upgrading.
Another FYI for you to browse.
This is a link to Visual Studio 2015 RC fixed bugs and known issues. There are quite a few issues and hacks suggested. (not specific to your problem, but still there a few months ago.).
I am assuming you know how to play around with the settings. I've added the obvious, in case it's been overlooked.
I have added this screen shot from VS2013 settings.
Make sure you have automatic delimeter highlighting checked.
Sorry I could not be of more help.
I have been suffering from the all too common 'Waiting for a background operation to complete...' message in Visual Studio 2012 (Professional) for a while now but it has been fairly sporadic.
Lately though, I am really struggling to use Visual Studio as pretty much whenever i try and do anything with any Razor views (mostly clicking to move the cursor) visual studio hangs and the above message appears for about a minute at a time.
(If when its finished doing stuff i then click in the view again, the process repeats, and repeats, and repeats.....)
I have searched high and low, and read loads of articles regarding this and peoples suggestions and tried changing indentation settings, resetting settings, etc but none have worked.
Has anyone come across something else that may work as this is seriously impeding my ability to use visual studio and sadly provoking much cursing.
I also had the same issue with VS2012 and unfortunately I had to format my pc after trying all the following solutions:
Move/clean the symbols cache
Reset VS preferences
Install Upgrade 2
Uninstall/Reinstall VS
After formatting and reinstalling VS2012, it started working like a charm again (obviously).
Sorry for that.
I know I asked this question a while back, but I thought best to put up my findings as they may help others.
The exact reason for the Waiting dialog is still unknown, but I have since moved my project to a local disk and implemented Team Foundation server to perform the hosting and backup of the main project files.
Since moving to local disk and using TFS, I have not experienced any more of the VS Waiting dialog.
Check if IIS or another process (BizTalk maybe) is locking your DLLs/references
Kill/stop IIS if it is
I keep having intermittent issues with visual studio 2010: I'm working on a rather large solution (200+ projects), so the whole solution takes a long time to build even with a little change.
I often need to debug processes on remote machines.
What I noticed is that visual studio would often appear hung on detach or terminate remote process. On closer examination, it appears that immediately after debugger disconnects, VS will start to build solution, and it is not possible to cancel the build by pressing Ctrl+Break, in fact no menus work at all until the build finishes or fails, and with large solution it takes a long time. One way I found which would fix this issue is killing the MSBuild.exe processes, spawned by VS, which would fail the build.
Have anyone seen this behavior? Is there any fix? Very annoying
EDIT: This is how the process explorer looks after disconnect from debugger: http://vvcap.net/db/oz1NMoyXnWWlQp8mWaRY.htp
This would happen when you edit code while a breakpoint is active. After the debugging session ends, VS automatically rebuilds the solution to incorporate the changes into the binaries, not just in memory. This does tend to make VS a bit catatonic, I think it tries to prevent you from doing anything that would interrupt that operation. This normally doesn't take more than a couple of seconds but I have no idea what might happen in such a large solution. Disabling E+C is probably not one of the workarounds you'd contemplate if you are used to being able to edit code while debugging.
Having solutions with 200 projects does tend to test the limits of endurance. Do try to whittle it down to a core set of projects, chucking out the ones that shouldn't change because doing so would break too much code in higher layers. Or just create another solution and include only the projects you want to test. It doesn't otherwise affect the debugging session, you can still debug code from such projects as normal. Without E+C of course.
Such amount of projects in a solution file can take a LOT of time to build. I can't (myself) imagine) the worries before pressing ctrl+b (know that takes 30 seconds of my working hours).
I would tell my boss that we are in badly need of insert a 40 hour delay because of refactoring the projects into maintanable & compilable parts (sharing same dll into each library per purpose/layer). If the delays is about pure project redefining or just splitting out the solution into several projects fully depends on your work. At least the parts where I am expecting problems and are about to change,
I wanted to know if it is possible to know why a Visual Studio 2005 (MSBuild) build is taking a long time to build a project.
Suddenly we are getting 7-minute build times on some computers, while others take less, such as 4 minutes.
So I think I need to identify changes that were made to the project and are causing a longer build time.
Any ideas on how I can do that?
Take a look at MSBuild Profiler to analyze where the slow down is. Based on that information, dig into what each task is doing and factor in the things that Chris mentions in his answer.
Is it a C++ project? I had the same problem when I moved my project from Visual Studio 6.0. Turning off the Code Optimization did save a lot of time. It was almost impossible to work with activated Optimization.
It re-evaluates the references on every build. If any of your references are on network drives that could be slowing it up.
Some computers are naturally going to perform builds faster than others.. This is, in part, a function of processor, ram, and HD speeds.
Regarding why you see 7 minute build times there could be any number of reasons. Amount of code in project(s). Number of projects in solution. Amount of post / pre build steps. Speed of network in downloading anything from source control it needs. Number of other processes running on your computers. Amount of RAM and other resources available to perform the builds..
You get the idea.