How do I debug a custom test adapter in Visual Studio - 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

Related

how to check visual c++ 2013 is installed or not in bootstrapper(wix)?

I am trying to install visual c++ 2013 with bootstrapper, so inside the bundle tag i am using following code to install visual c++ 2013 as follows
<ExePackage Id="VC2013" Cache="no" Compressed="no" PerMachine="yes" Permanent="yes" Vital="no" InstallCommand="/q" SourceFile=".\vcredist_x862013.exe" />
currently it will install always, irrespective of whether it is installed or not, how can i put check for whether it is installed or not?
In your bundle, add the following lines:
<util:RegistrySearch Id="VCRedistTest64" Root="HKLM" Key="SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{GUID_HERE}" Result="exists" Variable="VCR64Present" Win64="yes"/>
<util:RegistrySearch Id="VCRedistTest32" Root="HKLM" Key="SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{GUID_HERE}" Result="exists" Variable="VCR32Present" Win64="no"/>
Replace the {GUID_HERE} tags with the correct GUID for Visual C++ 2013. To find this, on a machine with Visual C++ already installer, open your registry and navigate to:
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\
In this key there will be several subkeys, where each subkey corresponds to one software package currently installed. Find the key which corresponds to the Visual C++ 2013, and copy the key name, which is the GUID you need to insert into the above code.
Finally, change your Exepackage element to:
<ExePackage Id="VC2013" Cache="no" Compressed="no" PerMachine="yes" Permanent="yes" Vital="no" InstallCommand="/q" SourceFile=".\vcredist_x862013.exe" DetectCondition="(VCR32Present OR VCR64Present)/>
This will allow Windows to detect if Visual C++ is already installed, and will prevent your installer from re-installing it.
Also, add the following to the top level "Wix" tag:
xmlns:util="http://schemas.microsoft.com/wix/UtilExtension"

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

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

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.

Cannot get powershell script to import module via msbuild

I have a post build step in an msbuild config which executes a powershell script. The powershell script works perfectly if I call it directly from Powershell but fails via msbuild.
It seems it fails after it tries to use classes from the import:
Import-Module WebAdministration
I get the error "Error : Retrieving the COM class factory for component with CLSID {688EEEE5-6A7E-422F-B2E1-6AF00DC944A6} failed due to the following error : 80040154 Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG))"
I've tried changing the version of powershell loaded by msbuild from 64bit to 32bit but it makes no difference.
Here is the msbuild step:
<Target Name="DevPostBuild">
<PropertyGroup>
<PowerShellExe Condition=" '$(PowerShellExe)'=='' ">%SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe</PowerShellExe>
<ScriptLocation Condition=" '$(ScriptLocation)'=='' ">$(ProjectDir)DevPostBuild.ps1</ScriptLocation>
</PropertyGroup>
<Message Text="$(ScriptLocation)" />
<Exec Condition="Exists($(ScriptLocation))" Command="$(PowerShellExe) -NonInteractive -executionpolicy Unrestricted -command "& { &'$(ScriptLocation)' } "" />
I'm using VS2010 on a 64bit machine.
Thanks!
Visual Studio 2010 is a 32bit process. Powershell will then run as a 32bit process. The WebAdministration module is 64bit only. Try using %SystemRoot%\syswow64\WindowsPowerShell\v1.0\powershell.exe for PowerShellExe.
Same in Visual Studio 2017, using syswow64's powershell.exe gives no difference. I had similar challenge while controlling IIS from within MSBuild XML and go same error messages about clases not registered. The Stop-WebAppPool and Stop-Website are useless therefore in MSBuild XML, as all from WebAdministration module, not mentioning Stop-IISSite from IISAdministration module.
In my case I had to utilize old good AppCmd executable from IIS. Works smooth, no issues. I also had the case when application pools and web sites are already stopped so be aware I ignore any error codes.
<Exec Command="$(WinDir)\SysWOW64\inetsrv\appcmd.exe stop apppool /apppool.name:"My Application Pool"" IgnoreExitCode="true" />
<Exec Command="$(WinDir)\SysWOW64\inetsrv\appcmd.exe stop site /site.name:"My Web Site"" IgnoreExitCode="true" />

Resources