In Visual Studio 2017, you can select Tools > Options > Environment > Startup > At startup: Show empty environment. This prevents the Start Page from displaying when you launch Visual Studio, and in previous versions it prevented the Start Page from appearing when closing a solution.
In Visual Studio 2017, though, it seems the designers chose to show the Start Page after closing a solution, even if the option was for an empty environment on startup.
Are there any creative ways to get around this until the Visual Studio team decides to provide a reasonable option?
I came across this after running into the same thing. Here is a potential work around from the developer community page from Oleg Savelyev & Bill Menees answers. Work around later added on that page by Praveen Sethuraman.
Here's a workaround you can use to disable the Start Page from
reopening after a solution closes.
The steps to follow are:
1.Close all instances of VS & Run Regedit
2.Select HKEY_LOCAL_MACHINE
3.File -> Load Hive…
4.Open %LOCALAPPDATA%\Microsoft\VisualStudio\15.0_\privateregistry.bin
5.Enter a name like “MyVSHive”
6.Navigate to HKEY_LOCAL_MACHINE\MyVSHive\Software\Microsoft\VisualStudio\15.0_\StartPage
7.Create a new dword with a non-zero value like so:
"DisableOpenOnCloseSolution"=dword:00000001
8.Select “MyVSHive” and then go to File->Unload Hive…
9.Restart VS
Now, on closing a solution, the Start Page will not autopen.
Please note that resetting your settings will cause this setting to be
reset and you will have to run through these steps again.
Thanks,
Praveen [MSFT]
Worked for me. Copying over in case it helps someone else.
I disliked this behavior so much that I added an "Auto-close Start Page" option to my free Menees VS Tools 2017 extension for VS 2017. It defaults to false (since I didn't want to change VS's default behavior for everyone using my extension), but I set it to true manually on all my VS installs.
I and others discussed this with Andrew Arnott from Microsoft on the MS Developer Community, but he didn't seem to care much. MS telemetry data says that those of us that don't want to see the Start Page are in the minority, so MS is just going to force it on us now. :-(
Fixed in Visual Studio 2017 v.15.5, 4 December 2017:
https://www.visualstudio.com/en-us/news/releasenotes/vs2017-relnotes
https://developercommunity.visualstudio.com/content/problem/20817/disabled-startpage-is-opened-when-project-is-close.html
Thank you for your feedback! We have fixed this issue and it's
available in Visual Studio 15.5.
It's great that Microsoft listened to the request in developercommunity, but I think the requesters missed the main point:
The problem is not the 4 seconds that it takes to close an extra window, it's the break in the programmer's concentration while looking at and resisting unnecessary link-bait.
Seems that this behavior is by design https://developercommunity.visualstudio.com/content/problem/20817/disabled-startpage-is-opened-when-project-is-close.html
One approach is to create own extension. See more
https://social.msdn.microsoft.com/Forums/vstudio/en-US/4f59de7c-715e-4f42-93d4-5e13efd626e3/visual-studio-2017-disable-start-page?forum=visualstudiogeneral
Related
Is there a way to disable to constant "Provide feedback" notifications in Visual Studio 2017. I keep hitting "Always Ignore" but they persist.
Edit: Tried Help --> Send Feedback --> Settings. Changed setting to "No, I would not like to participate" but continue to receive "Provide feedback" notifications.
Edit 2: For my situation this may be due to Resharper (link) which was reported on the MS Developer Community site (link). I'll update the question again once I've confirmed.
Edit 3: Disabled Resharper and no notifications ... yet. Re-enabled Resharper 2017.2 and instantly reappeared after relaunching VS. Seems to be 1 notification for each instance of VS running.
Edit 4: Posted answer below. Was caused by using Resharper 2017.2 in evaluation mode.
In my case it was 100% caused by Resharper (version 2017.2) when using in "Evaluation" mode. Once I entered license info (via a JB account) the notifications went away. To confirm this I logged out, restarted the evaluation, closed/reopened VS and notifications were instantly back. Logged back in via a JB account, restarted and notifications went away.
It seems that #MachinusX is receiving notifications for a different reason so they should post a new question with their details since my issue has been resolved.
Taking suggestion of #KornMuffin and adding my comment as an answer:
I resolved this temporarily by fully uninstalling and cleaning VS files, then installing a prior release of VS 2017. I used the following URL: VS 2017 Releases and selected Enterprise 15.0 (not 15.3 even though the release dates suggest 15.3 is older than 15.0 -- they are misleading/mislabeled). This has worked for me for now, until MS releases a fix. If trying the same, you will need to be logged into your MSDN account to download the prior release.
Instead of opting for "non participation", click on "Don't show again" link on the pop-up. This seems to have solved the issue as mentioned at https://developercommunity.visualstudio.com/content/problem/63752/vs2017-requests-feedback-then-tells-me-ive-already.html
Normally that kind of option, when marked, is saved somewhere in Regedit so whenever the popup is about to appear again it will check first what options you have marked.
If it's not remembering them, maybe it's an issue saving your preferences?
Somtimes it can be just as simple as running visual with administrator priviledges. I say this because mine kept forgetting my account and I had to sign in every single time I opened it. Switched to running it with administrator priviledges and it no longer forgets me which is so much better than having to put my credentials every single time!
This Debugger message pops up randomly while i am attempting to examine a variable while a breakpoint has hit in Visual Studio 2017.
Shortly thereafter, a larger message box appears that shows the following: "Evaluating the function 'System.Reflection.Assembly.LoadForm' timed out."
After enabling option Tools / Options / Debugging / General / Only managed code, the second message box have disappeared. But first message is still showing.
The problem is that first popup window appears for a relatively long time, that makes debugging process very noncomfortable. What else Visual Studio debugger options could I set to disable this popup?
(1)Tools->Options, uncheck the setting Debugging / General / Enable property evaluation and other implicit function call, and enable the Use Managed Compatibility Mode.
(2)Deleted all the .suo/obj/Bin/.user files in your project, and then re-open your project, clean and build your solution, debug it again.
This solution works fine for me:
Uncheck the new langage JavasScript Language Service in Options -> Editor -> JavaScript -> Language Service.
Option capture
I'm having this same issue and there doesn't appear to be a solution. It's extremely frustrating because when the "Getting DataTip text..." does popup and eventually goes away, my breakpoints no longer work.
The solutions listed here have not solved the problem, I've tried them ALL ... even a wipe and re-install of OS and VS 2015.
Debugging without ability to do property evaluation and other implicit function calls is basically NOT debugging and defeats the purpose.
Microsoft seem to be aware of the problem but keep closing the tickets as "unable to replicate" ... yet, a simple Google Search will show many many thousands of hits of developers running into this problem. I keep opening tickets with Microsoft, but they just keep getting closed or merged with no solution.
Cheers, Rob.
The ONLY solution that worked for me:
CMD window (Run As Admin)
type SFC /SCANNOW and wait for it to complete and hopefully fix any errors
Reboot
Bring up VS 2015 or 2017 without loading any project
In VS select Tools | Import and Export Settings | Reset all Setting ... now pick the template you use (i.e. VB, C, Web)
Exit VS
Load VS project and debug
Cheers, Rob.
Old post, but maybe it will help someone anyway ;)
In my case I got this every time I examined the first variable while debugging.
Annoying as hell as I due to the nature of the work restart the debugger often.
This was cause by that the location where my Visual Studio 2017 files were saved, was a cloud drive and it actually had to sync the files before showing the data.
The solution was to mark that whole folder "Always keep on this device".
Cheers,
Here is one possible solution:
I had this error never seen - then my graphics card (Nvidia) was gone and I removed the graphics card and worked with the integrated Intel. Then I got this error in after 3-4 steps. I installed a Nvidia again and now the "getting data" text message was never shown again.
Btw: this was the fix for the error
"64 bit debugging operation is taking longer than expected"
I had the same issue when I wanted to evaluate variables while debugging in my Unit tests and couldn't find any solution.
This is the solution that helped me: Tools -> Options / Debugging / General. Uncheck "Call string-conversion function on objects in variables windows".
This might only work for some people.
I've experienced this with every version of Visual Studio starting from 2012 (2012, 2013, 2015 Preview), on multiple computers and multiple projects, but I haven't figured out how to fix it:
Whenever I'm debugging a 64-bit(?) C++ console program, after a few minutes and seemingly completely randomly (when I'm not clicking or typing anything), the console window for the program spontaneously closes and I can no longer debug or step through the program with Visual Studio. When I press Stop and attempt to restart debugging, I usually get ERROR_NETWORK_UNREACHABLE:
// MessageId: ERROR_NETWORK_UNREACHABLE
// MessageText:
// The network location cannot be reached. For information about network troubleshooting, see Windows Help.
#define ERROR_NETWORK_UNREACHABLE 1231L
If I try to attach to the process manually I get the error:
Unable to attach to the process.
The only fix I've found for this is to restart Visual Studio. I can't find any other way to fix it, and I've tried running Process Monitor but haven't found anything.
What causes this problem and how can I fix it?
(?) Upon further checking it seems that this only happens in 64-bit mode, but I'm not 100% sure.
Ok, this is just so wrong
I also have issues with this bug, and in my case it occurred every other debug session. Which meant debug -> stop -> debug -> bug -> restart visual studio -> go to start (repeat every minute during the whole day).
Needless to say I was driven to find a solution. So yesterday I tried procmon, spend hours looking at API monitor differences, looked at plugins, netstat, etc, etc, etc. And found nothing. I gave up.
Today
Until today.
To track down a stupid bug in my program today, I launched appverifier. For my application, I ran the 'basics' tests and clicked save. After a few hours this led me to the bug in my program, which was something like this (extremely simplified version):
void* dst = _aligned_malloc(4096, 32);
memcpy(dst, src, 8192);
Obviously this is a bug and obviously it needed fixing. I noticed the error after putting a breakpoint on the memcpy line, which was not executed.
After a stop and 'debug' again I was surprised to find that I could actually debug the program for the second time. And now, several hours later, this annoying bug here hasn't re-emerged.
So what appears to be going on
So... apparently data from my program is bleeding through into the data or execution space of the debugger, which in turn appears to generate the bug.
I see you thinking: No, this shouldn't happen... you're right; but apparently it does.
So how to fix it? Basically fixing your program (more particular: heap corruption issues) seems to make the VS debugger bug go away. Using appverifier.exe (It's in Debugging tools for Windows) will give you a head start.
Why this works
Since VS2012, VC++ uses a different way to manage the heap. Hans Passant explains it here: Does msvcrt uses a different heap for allocations since (vs2012/2010/2013) .
What basically happens is that heap corruption will break your debugger. The AppVerifier basic settings will ensure that a breakpoint is triggered just before the application does something to corrupt the heap.
So, what happens now is that before the process will break the heap, a breakpoint will trigger instead, which usually means you will terminate the process. The net effect is that the heap will still be in-tact before you terminate your program, which means that your debugger will still function.
"Test"
Before using appverifier -- bug triggered every 2 minutes
While using appverifier -- VS debugger has been stable for 5 days (and counting)
This is an environmental problem of course. Always hard to troubleshoot, SysInternals' utilities like Process Monitor and Process Explorer are your primary weapons of choice. Some non-intuitive ways that a network error can be generated while debugging:
Starting with VS2012, the C runtime library had a pretty drastic modification that can cause very hard to diagnose mis-behavior if your program corrupts the heap. Much like #atlaste describes. Since time memorial, the CRT always created its own heap, underlying call was HeapCreate(). No more, it now uses GetProcessHeap(). This is very convenient, much easier now to deal with DLLs that were built with /MT. But with a pretty sharp edge, you can now easily corrupt the memory owned by Microsoft code. Not strongly indicated if you can't reattach a 64-bit program, you'd have to kill msvsmon.exe to clear up the corruption.
The Microsoft Symbol Server supplies PDBs for Microsoft executables. They normally have their source+line-number info stripped, but not all of them. Notably not for the CRT for example. Those PDBs were built on a build server owned by DevDiv in Redmond that had the source code on the F: drive. A few around that were built from the E: drive, Patterns+Practices uses that (unlikely in a C++ program). Your debugger will go look there to try to find source code. That usually ends well, it gives up quickly, but not if your machine uses those drive letters as well. Diagnose by clearing the symbol cache and disabling the symbol server with Tools + Options, Debugging, Symbols.
The winapi suffers from two nasty viral infections it inherited from another OS that add global state to any process. The PATH environmental variable and the default working directory. Use Control Panel + System + Advanced + Environment to have a look at PATH, copy/paste the content of the intentionally small textboxes into a text editor. Make sure it is squeaky clean, some paralysis at the usual mess is normal btw. Take no prisoners. Having trouble with the default directory is much harder to troubleshoot. Both should pop out when you use Process Monitor.
No slamdunk explanations, it is a tough problem, but dark corners you can look in.
I have the same problem. Thought it was related to 64 bit console apps, where it is very easily triggered with almost any debug session. But, it also happens on 64 bit windows apps too. Now I am seeing it on 32 bit windows apps. I am running Windows 8.1 pro on a single desktop with the latest version of vs 2013 and no remote debugging. My (added) extensions are Visual Assist, Advanced Installer, ClangFormat, Code Alignment, Code Compare, Duplicate Selection, Productivity Power Tools 2013, and Visual SVN.
I discovered that the "Visual Studio 2013\Settings\CurrentSettings.vssettings" file gets corrupted. You can delete this file and recreate it by restarting VS or you can try to edit the XML. I then keep a copy of a good settings file that I use to replace when it gets corrupted again.
In my case, the corrupted line begins with
</ToolsOptionsSubCategory><ToolsOptionsSubCategory name="XAML" RegisteredName="XAML"
... and it is extremely long (I think this is why it is prone to corruption).
I just disabled in the Menu
Tools > Options
Debugging > Edit and Continue
Native-only options > Enable native Edit and Continue
and now it does not give the that stupid error which was preventing the starting of the debuggee application.
I also had the same problem with VS2015. It was so frustrating that a simple Hello World program gave this error when I ran debugger for the second time. Tried uninstall and reinstall and didn't work.
Finally, the solution mentioned in https://social.msdn.microsoft.com/Forums/vstudio/en-US/8dce0952-234f-4c18-a71a-1d614b44f256/visual-studios-2012-cannot-findlaunch-project-exe?forum=vsdebug
worked. Reset all visual studio settings using Tools->Import and Export settings. Now the issue is not occurring.
Every time I view my XAML file, Visual Studio hangs for several minutes (the UI is blocked completely). I'm working with a DirectX/C++ project with a XAML wrapper (using SwapChainBackgroundPanel).
What I've tried:
Using the Windows::ApplicationModel::DesignMode::DesignModeEnabled condition in the code behind
Using XAML mode only (not split view or design mode)
Lighting myself on fire
The hanging persists. I'm so desperate that I've resorted to using Notepad++ to edit this one file, but then I don't have Visual Studio to catch my dumb typos.
Is there any imaginable way around this?
first of all try this.
Also I recommend to disable design view default for XAML files in options:
Tools -> Options... -> Text Editor -> XAML -> Misc -> Always open documents in full XAML view.
FYI: this recommendations made my VS2012 faster.
Well, I don't know what was causing this, but subsequent experiences with VS2012 have taught me a likely culprit. (And Michael alluded to this in his answer.) The XAML designer spawns multiple processes, each of which are unfathomable memory hogs. I have taken to offing these so-called "XDesProc.exe" via the Task Manager, with extreme prejudice.
Is there a way to change the poll interval for the Build Notification tray application for TFS 2010?
It case someone else searches for this;
The e-mail notificaiton delay does not affect the build notification tray
Check out this blog post: http://blogs.msdn.com/b/ukvsts/archive/2010/10/08/team-build-notification-polling-interval.aspx
Basically
There is a registry setting that controls this, and you can find it under:
HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0\TeamFoundation\Build\BuildNotification\Subscriptions
Default is 2:30
Ironically, the code for the Build Notifcation tray application does support changing the poll interval by means of a parameterable constructor, but the root code which starts the polling off hard codes the value.
If you really want to change the poll interval, then you could theoretically create a replacement Main() procedure, and re write the launch of the form and polling timer in order to be able to pass in your own configurable poll interval, but I think that that would probably not be worth the time & investment.
EDIT: The upcoming 1.3.0 build of Jim Liddel's Team Build Screen on Codeplex now features support for TFS 2010, and also a desktop app rather than just a screensaver! This is far better than the team build screen. http://teambuildscreen.codeplex.com/
You can do this in a quick Powershell one-liner:
sp HKCU:\Software\Microsoft\VisualStudio\12.0\TeamFoundation\build\BuildNotification\Subscriptions PollingInterval 00:00:05
The "12.0" in the middle refers to VS 2013. Change it to "10.0" for 2010, "11.0" for VS 2012, and "14.0" for Visual Studio "14".
Be aware that you have to restart the tool afterwards. If you don't want to log out and back in, closing the tray app then running something like this from a Run prompt: "%vs120comntools%..\ide\BuildNotificationApp.exe" (with the double-quotes) ought to do the trick.
For those not so familiar with Powershell, "sp" is an alias for Set-ItemProperty, which can work with many types of objects, including registry keys.