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!
Related
TLDR
When one of my applications executes _CrtDbgBreak() it just writes a .dmp file and exits. On any other application _CrtDbgBreak() causes the app.exe has stopped working -dialog where I can chose to break into my debugger (VS 2013).
This is my desired behavior.
Background
A few weeks ago I experimented with Windows Error Reporting to find out if/how the WER Dialog could be suppressed. Apparently I succeeded for my application and unfortunately I haven't found the way how to undo this.
In the meantime I have had to deal with a number of other things so that I no longer remember which steps I exactly took at the time. (Should have taken notes, I know.) Since it works for other applications, I am guessing a setting specific to my app needs to be reset.
I turned to the usual suspects on my machine but so far I haven't found anything:
HKCU\Software\Microsoft\Windows\Windows Error Reporting
HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting
Policy Editor: Computer Configuration\Administrative Templates\Windows Components\Windows Error Reporting
Policy Editor: User Configuration\Administrative Templates\Windows Components\Windows Error Reporting
WER Service is running
I have even removed all occurrences of my executable's name from my entire registry but this hasn't made any difference. What else am I missing?
One possible reason is your app/exe is added to the WER's exclusion list. See 'ExcludedApplications' at https://learn.microsoft.com/en-us/windows/desktop/wer/wer-settings.
https://learn.microsoft.com/en-us/windows/desktop/api/Werapi/nf-werapi-weraddexcludedapplication
Check registry at: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\ExcludedApplications
If your app/exe name is found there, remove it.
Maybe you'd set the process error mode, like so
SetErrorMode(SEM_NOGPFAULTERRORBOX);
(see https://learn.microsoft.com/en-us/windows/win32/api/errhandlingapi/nf-errhandlingapi-seterrormode)
[yes - the question is dated, but it's not marked as answered, and this alternative solution may help future readers]
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.
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
We're using OLEDragDrop Event in one of our bigger products and have stumbled upon a strange issue. On my machine, if I build the application and run the exe-file, the application sees a drag-drop-event and I can drag a file from the desktop to the program and it saves it and does what it should do. However, when I go into debug-mode, this same function does not work. All I get is an icon-switch to the icon that indicates that I can't release the file "on top" of this program.
My co-worker has the same code, the exact same code from the same revision, and every other project-related setting is exactly the same. But he gets the expected behaviour from the application when debugging. The only reasonable guess we do have is that he hasn't applied the ~300mb security update for visual studio 2010 sp1. I'm right now setting up a virtual machine to check this out and will update when I know if it does indeed work without that update.
Has anyone else had a problem related to this one? Anything that could lead me on the right track I would be eternally grateful for.
Thanks for reading.
You won't be able to drag onto the application if Visual Studio is running as an administrator.
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.