Package manager in Visual Studio 2015 "407 (Proxy Authentication Required)" - visual-studio

I understand this is an often asked question, however after days of research I've not found an answer to this particular problem.
I have a new ASP.NET 5 (Core 1.0) MVC template that I'm trying to add a package to however each and every time I get in the Package Manager output:
Response status code does not indicate success: 407 (Proxy Authentication Required).
and the following at the top of solution explorer:
my settings look fine and I am able to browse packages in the 'Manage Packages for Solution' screen.
I understand I'm being requested to supply credentials so where do I enter them? On the other hand all other applications on my machine have validated internet access, so why should I?
Any ideas / pointers are very welcome.
Visual Studio 2015 - 14.0.24720.00 Update 1
NuGet Package Manager for Visual Studio 2015 - 3.3.0.167
Top section of Package Manager output:
Installing NuGet package AutoMapper.4.2.1.
Successfully installed 'AutoMapper 4.2.1' to CustomerPortal
========== Finished ==========
PATH=.\node_modules.bin;%PATH%;C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\Microsoft\Web Tools\External;C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\Microsoft\Web Tools\External\git
C:\Users\medmondson.dnx\runtimes\dnx-clr-win-x86.1.0.0-rc1-update1\bin\dnx.exe "C:\Users\medmondson.dnx\runtimes\dnx-clr-win-x86.1.0.0-rc1-update1\bin\lib\Microsoft.Dnx.Tooling\Microsoft.Dnx.Tooling.dll" restore "M:\visual studio 2015\Projects\CustomerPortal\src\CustomerPortal" -f "C:\Program Files (x86)\Microsoft Web Tools\DNU"
Microsoft .NET Development Utility Clr-x86-1.0.0-rc1-16231
GET https://www.nuget.org/api/v2/
GET http://packages.nuget.org/v1/FeedService.svc/
GET https://www.postsharp.net/nuget/packages/
Restoring packages for M:\visual studio 2015\Projects\CustomerPortal\src\CustomerPortal\project.json
GET https://www.nuget.org/api/v2/FindPackagesById()?id='AutoMapper'
GET http://packages.nuget.org/v1/FeedService.svc/FindPackagesById()?id='AutoMapper'
GET https://www.postsharp.net/nuget/packages/FindPackagesById()?id='AutoMapper'
Warning: FindPackagesById: AutoMapper
An error occurred while sending the request.
GET https://www.nuget.org/api/v2/FindPackagesById()?id='AutoMapper'
GET https://www.nuget.org/api/v2/FindPackagesById()?id='System.Collections.Immutable'
GET http://packages.nuget.org/v1/FeedService.svc/FindPackagesById()?id='System.Collections.Immutable'
GET https://www.postsharp.net/nuget/packages/FindPackagesById()?id='System.Collections.Immutable'
Warning: FindPackagesById: AutoMapper
An error occurred while sending the request.
GET https://www.postsharp.net/nuget/packages/FindPackagesById()?id='AutoMapper'
Warning: FindPackagesById: AutoMapper
Response status code does not indicate success: 407 (Proxy Authentication Required).
Update
I've managed to capture a non-working request (returning 407) and a working request with the only difference being the content of the Proxy-Authorization header which is longer. This would suggest the proxy authentication does exist but it's using a different protocol.

I had the same problem a few weeks ago. For me it has helped to put in the the following in the machine.config (Windows/Microsoft.NET/Framework64/v4.0.30319/Config)
<system.net>
<settings>
<ipv6 enabled="True"/>
</settings>
<defaultProxy useDefaultCredentials="True" enabled="True">
<proxy proxyaddress="http://your.proxyserver.ip:port"/>
</defaultProxy>
</system.net>

I had to modify the 32 bit machine.config (assumption being VS runs in 32 bit) to add the <system.net> section but omitting anything within the <defaultProxy> tag:
<system.net>
<defaultProxy useDefaultCredentials="True" enabled="True" />
</system.net>
According to MSDN:
If the defaultProxy element is empty, the proxy settings from Internet Explorer will be used.
This is perfect for me as every other application on my machine works - including IE.
manchine.config location (Win 7): %SYSTEMROOT%\Microsoft.NET\Framework\v4.0.30319\Config\machine.config
Note
I resolved this thanks to #user3063127 pointing me in the right direction (you have an upvote). As far as I can tell this only affects package restore on DNX projects and may well be fixed when RC2 is released.

Updated to latest nuget.exe 1st
nuget update self
Added proxy details to the config file:
nuget config -Set http_proxy=http://username:password#proxyserver.company.com:port

You need to modify file 2 .config files:
for Visual Studio 2015
C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\vsn.exe.config
C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\devenv.exe.config
for Visual Studio 2017
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\vsn.exe.config
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\devenv.exe.config
<system.net>
<defaultProxy enabled="true" useDefaultCredentials="true">
<proxy usesystemdefault="True" bypassonlocal="True" proxyaddress="http://yourproxy:proxyport" />
<bypasslist>
<add address="(.*\.)?anyotherdomain\.com?(.*)" />
<add address="(.*\.)?nuget\.org?(.*)" />
<add address="192\.168\.\d{1,3}\.\d{1,3}" />
</bypasslist>
</defaultProxy>
<settings>
<ipv6 enabled="false"/>
<servicePointManager expect100Continue="false"/>
</settings>
</system.net>
The bypass for nuget.org will work if, without the proxy, you still can get it's IP from DNS server and nothing else is blocking it.
Also need this to install nuget
Open the file C:\Users\[YOUR_USER_NAME]\AppData\Roaming\NuGet\NuGet.Config and add inside the <configuration> <\configuration> tag the following:
<config>
<add key="http_proxy" value="http://yourproxy:proxyport" />
</config>
Taken from Marco Mengoli's Blog

If you have Fiddler installed, tick the option 'Automatically Authenticate' under the Rules option, should fix the above issue.
Selecting the Automatically Authenticate
Got this from the following post
Configuring Fiddler to use company network's proxy?

If you don't know the proxy server details, you can go with other workaround to overcome this error "407 (Proxy Authorisation Required.)"
Workaround:
1. Download/Install Fiddler
2. Click Menu Rules -> Automatically Authenticate
Without closing Fiddler, now try to do restore package in Visual Studio. It should now restore the packages without any proxy error.
This is not a neat solution, but still an alternate workaround to resolve this issue. This solution tries to utilise Fiddler as Proxy.

Maybe you have wrong proxy credentials in Credential Manager. Try to remove it.
Control Panel -> User Account -> Credential Manager.
Remove proxy credentials resolved my problem.

Adding proxy username, password fixed my 407 authentication issue.
Place the following snippet in NuGet.config file located at C:\Users\myUserName\AppData\Roaming
<configuration>
<config>
<add key="http_proxy" value="http://my.proxy.address:port" />
<add key="http_proxy.user" value="mydomain\myUserName" />
<add key="http_proxy.password" value="[base64 encoded Password]" />
</config>
</configuration>
Ref: https://forums.asp.net/t/2096179.aspx?Proxy+407+Access+Denied

Related

How do I debug a custom test adapter in Visual Studio

I am working on a custom test adapter for Visual Studio 2017. How can I configure Visual Studio to debug the test adapter without having to use a hack such as adding Debugger.Launch() in my adapter code?
Microsoft Child Process Debugging Power Tool
Install the Microsoft Child Process Debugging Power Tool which was created by an employee at Microsoft. This allows you to configure the Visual Studio debugger to attach to child processes (which is how vstest.console.exe executes tests)
Once installed, open your solution and enable child process debugging:
1) Go to the child process debug settings at the following Visual Studio Menu location: Debug -> Other Debug Targets -> Child Process Debugging Settings...
2) Enable child process debugging: true and Save
3) Optionally persist the settings using the dropdown so that this setting can be checked into source control
If you choose to persist the settings, your settings file might look something like this:
<?xml version="1.0" encoding="utf-8"?>
<!-- EngineFilter Guid was found here: https://blogs.msdn.microsoft.com/martintracy/2006/05/16/debug-engine-guids/ -->
<ChildProcessDebuggingSettings IsEnabled="true" xmlns="http://schemas.microsoft.com/vstudio/ChildProcessDebuggingSettings/2014">
<DefaultRule Attach="false" />
<Rule IsEnabled="true" ProcessName="TE.ProcessHost.Managed.exe" EngineFilter="{92ef0900-2251-11d2-b72e-0000f87572ef}" />
<Rule IsEnabled="true" ProcessName="vstest.discoveryengine.exe" EngineFilter="{92ef0900-2251-11d2-b72e-0000f87572ef}" />
<Rule IsEnabled="true" ProcessName="vstest.discoveryengine.x86.exe" EngineFilter="{92ef0900-2251-11d2-b72e-0000f87572ef}" />
<Rule IsEnabled="true" ProcessName="vstest.executionengine.exe" EngineFilter="{92ef0900-2251-11d2-b72e-0000f87572ef}" />
<Rule IsEnabled="true" ProcessName="vstest.executionengine.x86.exe" EngineFilter="{92ef0900-2251-11d2-b72e-0000f87572ef}" />
</ChildProcessDebuggingSettings>
Once this has been setup, you then just need to make sure your project is setup to debug with vstest.console.exe. The key point here is making sure that you enable native/unmanaged debugging, otherwise the child process debugging tool wont work.
New csproj System
Edit or create a launchSettings.json file to look similar to this:
{
"profiles": {
"DebugTestAdapter": {
"commandName": "Executable",
"executablePath": "C:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\Enterprise\\Common7\\IDE\\Extensions\\TestPlatform\\vstest.console.exe",
"commandLineArgs": "Tests.dll --ListTests --TestAdapterPath:.",
"workingDirectory": "C:\\Projects\\TestAdapter\\Tests\\bin\\Debug\\net46"
}
}
}
Modify your csproj file to contain the following property, which enabled native debugging:
<PropertyGroup>
<EnableUnmanagedDebugging>true</EnableUnmanagedDebugging>
</PropertyGroup>
Old csproj System
In the debug properties page of your project, set the following settings:
Start external program:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\Extensions\TestPlatform\vstest.console.exe
Command line arguments:
Tests.dll --ListTests --TestAdapterPath:.
Working directory:
C:\Projects\TestAdapter\Tests\bin\Debug
Enable native code debugging:
Set this value to true

How to overcome "Could not load type 'Microsoft.Cct.Services.Sqm.IWatSqmService'" without updating?

I'm getting the same error message as in this question: Could not load type 'Microsoft.Cct.Services.Sqm.IWatSqmService' Unfortunately, I cannot upgrade to Azure SDK 2.9, as the top answer there suggests.
Specifically, I get this error in a message box whenever I try to package my Azure Cloud Service project:
What's interesting is that I can start the same project in the emulator, which I would assume involves packaging it.
Things I've tried:
Ensuring that I only have version 2.8.2 of the emulator installed (I may have had 2.9 installed initially)
Reinstalling version 2.8.2 of the SDK
Manually copying the Windows Azure Tools from C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0 to the v14.0 equivalent.
Ensuring that C:\Program Files\Microsoft SDKs\Azure\.NET SDK\v2.8 exists
Reinstalling Visual Studio (so you know I'm desperate!)
And I've no idea what to try next. I can't work out which DLL is supposed to hold the Microsoft.VisualStudio.WindowsAzure.Services assembly, I can't find any references in any config files, and all the Google hits seem to point back to the SO question linked above.
What's going on? And how can I fix it?
In case I'm being an idiot, here's all the Azure-related things I've got installed:
Also (just in case it's relevant) I'm on Windows 7 SP1.
Update 17/01/16
Following some advice from the excellent Rest Azured Slack channel, I've tried using ProcMon and Fusion Log to diagnose this (spoiler: without success)
ProcMon filtered to that assembly returns nothing:
Fusion log (set to log everything) yields lots of entries like this:
* Assembly Binder Log Entry (17/01/2017 # 11:52:02) *
The operation was successful. Bind result: hr = 0x0. The operation
completed successfully.
Assembly manager loaded from:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll Running under
executable C:\Program Files (x86)\Microsoft Visual Studio
14.0\Common7\IDE\devenv.exe
--- A detailed error log follows.
=== Pre-bind state information === LOG: DisplayName = Microsoft.VisualStudio.WindowsAzure.Services, Version=1.1.0.0,
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a (Fully-specified)
LOG: Appbase = file:///C:/Program Files (x86)/Microsoft Visual Studio
14.0/Common7/IDE/ LOG: Initial PrivatePath = NULL LOG: Dynamic Base = NULL LOG: Cache Base = NULL LOG: AppName = devenv.exe Calling assembly
: Microsoft.VisualStudio.WindowsAzure, Version=2.9.0.0,
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a.
=== WRN: Native image will not be probed in LoadFrom context. Native image will only be probed in default load context, like with
Assembly.Load(). WRN: No matching native image found. LOG: IL assembly
loaded from C:\Program Files (x86)\Microsoft Visual Studio
14.0\Common7\IDE\Extensions\Microsoft\Windows Azure Tools\Microsoft.VisualStudio.WindowsAzure.Services.dll.
When I explore the DLL mentioned, I can find Microsoft.Cct.Services.Sqm, but it doesn't contain a type IWatSqlService:
This feels like it's the crux of the issue, but I've no idea what to do next. Presumably I'd need to replace the DLL with a version that does define IWatSqlService, but I'm not sure where I'd get one. Or, for that matter, why it would even be necessary.
Next stop is probably a full wipe of the machine.
I've had the same problem, and solved it by not using the Web Platform Installer.
Download all parts (Microsoft Azure SDK for .NET - 2.8.2) from the Microsoft site: https://www.microsoft.com/en-us/download/details.aspx?id=50041 and follow the instructions how to install them.
For anyone else with this problem. I ended up resolving this by nuking it from orbit. Fresh install of Windows, reinstall VS and the SDK.
Confusingly, you can also see this error when you add a new
<setting name="TODO" />
element to your *.csdef file but either:
forget to add the corresponding <setting name="TODO" value="TODO" /> element to every *.cscfg file, or
accidentally add a duplicate <setting name="TODO" value="TODO" /> element to any of the *.cscfg files.

Configuring IIS Express fails with configuration file error

I got this error when I created a website in Visual Studio 2013:
File name: redirection.config
Error: Cannot read configuration file
I had the similar issue could not even start a web project in vs 2013
So i tried the following
Unable to create a new web project in Visual Studio 2013
Had same issue in visual-studio 2015. Tried many solutions, used Process Monitor to identify a missing directory structure, copied the 'config' folder -
C:\Program Files (x86)\IIS Express\ -> C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\
Also using the change iis express user home fix -
eg. C:\Program Files (x86)\IIS Express\iisexpress.exe /userhome:c:\temp\iisexpress
Need to delete existing iisexpress folder, usually in [home]\documents folder.
I had the same problem. I looked in the file, and it was corrupted, only filled with NUL.
Fortunately I was able to recover the same file from my old PC:
<configuration>
<configSections>
<section name="configurationRedirection" />
</configSections>
<configProtectedData>
<providers>
<add name="IISRsaProvider" type="" description="Uses RsaCryptoServiceProvider to encrypt and decrypt" keyContainerName="iisConfigurationKey" cspProviderName="" useMachineContainer="true" useOAEP="false" />
</providers>
</configProtectedData>
<configurationRedirection />
</configuration>
Probably you can even leave the providers tag empty.

DataDriven Unit Test using Excel in VS2013

I am creating Datadriven Unit(MS Unit Test) Test using Excel(*.xlsx) file as data source.
it is erroring out with the following error
Result Message: The unit test adapter failed to connect to the data
source or to read the data. For more information on troubleshooting
this error, see "Troubleshooting Data-Driven Unit Tests"
(http://go.microsoft.com/fwlink/?LinkId=62412) in the MSDN Library.
Error details: ERROR [IM014] [Microsoft][ODBC Driver Manager] The
specified DSN contains an architecture mismatch between the Driver and
Application
I have set the Copy to Output directory : always for the DateRangeTest.xlsx
I also tried defaultdir=.\;, defaultdir=.;, and defaultdir=c:\projectName\bin\debug\;
Here is the section from app.config
<configSections>
<section
name="microsoft.visualstudio.testtools"
type="Microsoft.VisualStudio.TestTools.UnitTesting.TestConfigurationSection, Microsoft.VisualStudio.QualityTools.UnitTestFramework, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
/>
</configSections>
<connectionStrings>
<add name="DateRangeConstr"
connectionString="Dsn=Excel Files;dbq=DateRangeTest.xlsx;defaultdir=.\; driverid=790;maxbuffersize=2048;pagetimeout=5"
providerName="System.Data.Odbc" />
</connectionStrings>
<microsoft.visualstudio.testtools>
<dataSources>
<add name="DateRangeTestDataSource"
connectionString="DateRangeConstr"
dataTableName="Sheet1$"
dataAccessMethod="Sequential"/>
</dataSources>
</microsoft.visualstudio.testtools>
There are (2) options here - you can either remove the DSN requirement or install the opposite Excel/Access runtime bitness of the Office product you have installed.
Option 1 - remove DSN from Connection String
Change from this:
<add name="DateRangeConstr"
connectionString="Dsn=Excel Files;dbq=DateRangeTest.xlsx;defaultdir=.\; driverid=790;maxbuffersize=2048;pagetimeout=5"
providerName="System.Data.Odbc" />
To this:
<add name="DateRangeConstr"
connectionString="dbq=DateRangeTest.xlsx;defaultdir=.\; driverid=790;maxbuffersize=2048;pagetimeout=5"
providerName="System.Data.Odbc" />
Option 2 - Install ODBC Drivers for Opposite Bitness
For Office x64, install Microsoft Access Database Engine 2010 Redistributable for x86 (AccessDatabaseEngine.exe)
For Office x64, install Microsoft Access Database Engine 2010 Redistributable for x64 (AccessDatabaseEngine_x64.exe).
This fix should be the same whether you have Office 2010 or Office 2013.
To test this change - you should be able to configure the Excel Files DSN for both x86 and x64 once installed.
32-bit ODBC: %WINDIR%\SysWOW64\odbcad32.exe
64-bit ODBC: %WINDIR%\System32\odbcad32.exe
Click on "Excel Files" and then click "Configure" and you should see a dialog. If an error occurs when you click "Configure" - you don't have the proper office driver installed for that bitness.
We need not to install anything to our system to run the external excel data driven unit tests.
We need to simply run the Data Source Wizard present under Visual Studio Data Source Explorer.
Watch this video. This Tutorial tells how to run Data Driven (Parameters) unit tests using Visual Studio Testing Tools.

Visual Studio keeps crashing: Application Error

VS keeps crashing, usually when I want to click on some text I want to edit.
When I look in the event log I get;
Log Name: Application
Source: Application Error
Date: 26/03/2013 15:18:30
Event ID: 1000
Task Category: (100)
Level: Error
Keywords: Classic
User: N/A
Computer: (removed)
Description:
Faulting application name: devenv.exe, version: 10.0.40219.1, time stamp: 0x4d5f2a73
Faulting module name: clr.dll, version: 4.0.30319.269, time stamp: 0x4ee9ae83
Exception code: 0xc00000fd
Fault offset: 0x00194a5d
Faulting process id: 0x47c
Faulting application start time: 0x01ce2a3396f0faf2
Faulting application path: c:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe
Faulting module path: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
Report Id: 69d0daee-9628-11e2-aeba-005056c00008
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Application Error" />
<EventID Qualifiers="0">1000</EventID>
<Level>2</Level>
<Task>100</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2013-03-26T15:18:30.000000000Z" />
<EventRecordID>23553</EventRecordID>
<Channel>Application</Channel>
<Computer>(removed)</Computer>
<Security />
</System>
<EventData>
<Data>devenv.exe</Data>
<Data>10.0.40219.1</Data>
<Data>4d5f2a73</Data>
<Data>clr.dll</Data>
<Data>4.0.30319.269</Data>
<Data>4ee9ae83</Data>
<Data>c00000fd</Data>
<Data>00194a5d</Data>
<Data>47c</Data>
<Data>01ce2a3396f0faf2</Data>
<Data>c:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe</Data>
<Data>C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll</Data>
<Data>69d0daee-9628-11e2-aeba-005056c00008</Data>
</EventData>
</Event>
also I get this;
Log Name: Application
Source: Windows Error Reporting
Date: 26/03/2013 15:21:01
Event ID: 1001
Task Category: None
Level: Information
Keywords: Classic
User: N/A
Computer: (removed)
Description:
Fault bucket 2985755835, type 1
Event Name: APPCRASH
Response: Not available
Cab Id: -721041670
Problem signature:
P1: devenv.exe
P2: 10.0.40219.1
P3: 4d5f2a73
P4: clr.dll
P5: 4.0.30319.269
P6: 4ee9ae83
P7: c00000fd
P8: 00194a5d
P9:
P10:
Attached files:
C:\Users\xxx\AppData\Local\Temp\WERE350.tmp.WERInternalMetadata.xml
C:\Users\xxx\AppData\Local\Temp\WERF0C9.tmp.appcompat.txt
C:\Users\xxx\AppData\Local\Temp\WERF108.tmp.mdmp
These files may be available here:
C:\Users\xxx\AppData\Local\Microsoft\Windows\WER\ReportArchive\AppCrash_devenv.exe_3f453f47c0d86c534010e7cf6788bb8f42fbcd_cab_144e2fda
Analysis symbol:
Rechecking for solution: 0
Report Id: 69d0daee-9628-11e2-aeba-005056c00008
Report Status: 8
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Windows Error Reporting" />
<EventID Qualifiers="0">1001</EventID>
<Level>4</Level>
<Task>0</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2013-03-26T15:21:01.000000000Z" />
<EventRecordID>23554</EventRecordID>
<Channel>Application</Channel>
<Computer>(removed)</Computer>
<Security />
</System>
<EventData>
<Data>2985755835</Data>
<Data>1</Data>
<Data>APPCRASH</Data>
<Data>Not available</Data>
<Data>-721041670</Data>
<Data>devenv.exe</Data>
<Data>10.0.40219.1</Data>
<Data>4d5f2a73</Data>
<Data>clr.dll</Data>
<Data>4.0.30319.269</Data>
<Data>4ee9ae83</Data>
<Data>c00000fd</Data>
<Data>00194a5d</Data>
<Data>
</Data>
<Data>
</Data>
<Data>
C:\Users\xxx\AppData\Local\Temp\WERE350.tmp.WERInternalMetadata.xml
C:\Users\xxx\AppData\Local\Temp\WERF0C9.tmp.appcompat.txt
C:\Users\xxx\AppData\Local\Temp\WERF108.tmp.mdmp</Data>
<Data>C:\Users\xxx\AppData\Local\Microsoft\Windows\WER\ReportArchive\AppCrash_devenv.exe_3f453f47c0d86c534010e7cf6788bb8f42fbcd_cab_144e2fda</Data>
<Data>
</Data>
<Data>0</Data>
<Data>69d0daee-9628-11e2-aeba-005056c00008</Data>
<Data>8</Data>
</EventData>
</Event>
Standard checks to resolve these types of errors:
uninstall any beta/ctp releases for Visual Studio.
look in the Windows Event Viewer and check for the following two items in the Application log: it will contain a stacktrace which may help you find the culprit.
delete any *.*user files and the solution user options file (.suo)
Run visual studio with activity logging turned on to see if the logs contain a hint to what's causing the crash. (devenv /log)
Run Visual Studio in Safe mode (devenv /safemode)
Clear the ComponentModelCache folder
Check to see if any extensions/add-ons/plugins need updates and update them first to see if that fixes your problem.
disable all add-ins and extensions (VS Commands, WebEssentials etc)
uninstall all plugins (resharper, coderush, reflector etc)
install the latest patches and service packs, you may need to re-apply these servicepacks if you've installed SQL Server or another product that installs a feature which is based on Visual Studio Shell:
2005: SP 1 & TFS 2010 Forward Compatibiltiy Patch & Visual Studio update for Windows Vista
2008: SP 1 & TFS 2012/VSO Forward Compatibiltiy Patch
2010: SP 1 & TFS 2012/VSO Forward Compatibility Patch & Visual Studio update for Windows 8 and TFS 2012.
2012: Update 5
2013: Update 5
2015: Update 3 & KB3165756
2017: Update to the latest version
reset vs settings (devenv /resetsetting /resetaddin /resetskippkgs /setup)
backup & remove the %LOCALAPPDATA%\Microsoft\VisualStudio\ folder to have Visual Studio recreate your setting folder.
Do not run Visual Studio while installing extensions, updates etc.
Try to reproduce it. If it still occurs, repair Visual Studio and reapply the latest service packs and hotfixes in order. If it then still occurs, submit a support ticket to Microsoft, or an item on connect.
If it doesn't occur turn-on/install/restore the items one by one until you can find the culprit. I know it's a lot of work, but since your error happens somewhere deep inside the CLR (you're seeing a StackOverflow Exception), it's hard to pinpoint the problem easily. When you've found the problematic item, see if there is an update for it or request their support (or update your question).
In the worst case you can perform a force-uninstall of Visual Studio using vs_setup /uninstall /force, that should work on the 2012 and newer installers.
If you're still on an old version of Visual Studio (2010 or older), really, really. really consider upgrading. These versions are past their support lifetime and were built for versions of Windows that are not even supported anymore. I know the pain these upgrades can cause in the short term, but the long-term solution is really to move away from the old versions.
A quick and dirty approach is to rename your %LOCALAPPDATA%\Microsoft\VisualStudio\ folder to VisualStudio.backup\ and restart devenv. It will recreate the folder and populate it with default settings files. You will lose any customizations of course, but many times that is ok and/or easily recreated. You always have the backup folder just in case.
If you want to take it a step further, you can move settings one-by-one from the backup back into the new folder until you can completely isolate the problem.
None of the above worked. But I saw a user settings file had appeared next to the .sln file. I deleted it, and the solution's corresponding .suo file. This fixed the problem.

Resources