c#
namespace MyTestProject
{
[TestClass]
public class MyTesterClass
{
[TestMethod]
[HostType("ASP.NET")]
[AspNetDevelopmentServerHost("$(SolutionDir)\\MyWebProject", "/MyWebProject")]
[UrlToTest("http://localhost:29633/")] // FIXUP for your port
public void MyTestMethod()
{
Console.Out.WriteLine("BEFORE");
Assert.IsTrue(System.Diagnostics.Debugger.IsAttached); // always fails
System.Diagnostics.Debugger.Break();
Console.Out.WriteLine("AFTER");
}
}
`
IDE: VS2015 update 1 (on Win10), no extra 3rd party addons installed
Target: .net 4.5
Using IISExpress to test as a non-Administrator user (which is 32bit even on 64bit system for me)
Have 2 binds setup in IISExpress the "localhost:29633" and one to IP "192.168.0.2:29633" to allow across network testing and usage. This is all working just fine. This is setup in .vs\config\applicationhost.config with 2 entires bindingInformation=":29633:*" and bindingInformation=":29633:192.168.0.2"
I can get my unit tests to pass successfully, but I can not get execution to stop at any breakpoint that is setup, either in code Break() or the IDE breakpoint window.
So I provide a target test class to get working in your IDE to prove it should work for someone else as-is.
You'll need to create a dummy/empty ASP.NET project called "MyWebProject" and have this test case in its own project.
Things I have tried:
Resetting all settings
Ensuring both projects (MyTestProject and MyWebProject are rebuild and setup for Debug build types)
Ensuring the ASP.NET debugging is enabled on that project.
Modifying Test menu -> Test Settings -> Default Process Architecture from 32bit to 64bit.
Modifying Test menu -> Test Settings -> Keep Test Execution Running
Settings for debug symbols, disabling Just My Code,
Settings for Common Properties -> Startup Project -> Multiple startup projects
Tried this (but all my code in project is rebuilt, I do not need to debug any DLLs): Use Managed Compatibility Mode
Lots of other things tried that I have simply forgotten now. Have "Reset all settings" since.
If I try to attach to process (existing IISExpress.exe that runs in background between tests), then I can not start my tests at all, option "Run/Debug All Tests" greyed out.
If I try to start any other app, like running ASP.NET webapp on its own, again I can not start the tests the options are greyed out.
So it has to work from "Test [menu] -> Debug -> All Tests" and letting VS2015 start up all processes as needed, with debugger attached (ideally to both IISExpress.exe and TE.processhost.managed.exe).
What I find painful is that if something went wrong during the setup why didn't the unit test fail on the basis that VS2015 could not attach to process and then confirm correct setup of process so it was executing the expected copy of the project, etc.. Surly it should ALWAYS suspend execution at the start to allow VS to setup and communicate to inferior process being debugger, then execution resumed. It should just fail unit test run and not even start the testing if the environment if not all setup as expected.
I notice what looks like 2 te.processhost.managed.exe (one is persistent across tests and one spawns during the current test run). The breakpoint dialog indicates this process is the location of the test case breakpoints (but not ASP.NET ones)
But of course the ASP.NET runs in iisexpress.exe which is another process.
So is debugger attaching to both ok? How can I see this while it should be the case? How can I stop debugger cleaning up on termination, as this resets UI to many options in Debug -> Window -> ... are not available (if you are not quick enough).
If I set an ASP.NET breakpoint in code for example in Application_BeginRequest() from Global.asax/aspx execution does not stop in here either.
I am after a working project ZIP file and settings of the simplest test case project that proves the debugger is attached from VS so I can run-step though the code.
Related
This seems to be a similar problem like Visual Studio "Debug Unit Test" fails to hit breakpoints
But his fixes didn't work for me.
VS2019 Professional, XUnit:
I'm programming a server backend with controllers, I setup a new project for the test file and used one of the xunit templates, i got some intergration tests with a fake client for my server tests.
All worked fine at the beginning and at the point i set up a client, my debugger started to refuse to hit my breakpoints.
So, you press debug tests, it seems to debug, and after it ran through your tests(successful), it quits debugging. But my breakpoints in every testfile, in every constructor and mehod, were not hit.
they aren't white with red outline, they're normal full red circles
repairing vs didn't change anything
cleaning and rebuilding didn't change anything
my normal project is working and is able to be debugged correctly
I deleted my whole code in the project and had an empty constructor, which breakpoint wasn't hit (no connection to the main file)
Its Debug Version, not release version
updating all nuget packages isn't helping
restarting vs and the pc is not helping
no warnings or anything
setting the testproject to be the startproject didn't change anything
same problem on other devices
If you add more tests, you debug without hitting any breakpoints longer, because yor tests take longer & your tests give the correct result. Therefore I'm quite sure, it's really going past your breakpoints, because I mean, you got the results of the methods you trying to debug.
Add a reference to the nuget package xunit.runner.visualstudio to your test project and try again.
As of today I can no longer debug any c# code using Visual Studio. If I use the debugger, breakpoints can be hit, but as soon as execution has paused the trouble begins. Pressing Step Into, or Continue will normally generate an AccessViolationException saying the memory is corrupt and kill the current request. If I then run a further web request I will instead get an SEHException (occurred in Unknown Module).
It gets even more odd, in that if the AccessViolationException doesn't trigger, the program counter that shows the next statement jumps randomly. Code is then executed in random order! (until it crashes).
If no breakpoints are hit then the app will run in debug mode just fine (even with the debugger attached).
I am confident it's not a code issue. I can actually reproduce the access violations with a new project and the following code:
class Program
{
static void Main(string[] args)
{
Console.WriteLine("Hello world");
Console.WriteLine("Access violation"); // This will throw if breakpoint set
}
}
Have deleted VS cache, deleted .suo, cleaned, and tried safe mode. The one possible suspect is that this is on a Windows 10 preview machine, and there was an update last week. I am not really sure where else to go with this to confirm it, or fix it without reimaging the machine.
Changing from Any CPU to just x64 resolved this for me on my "Hello World" test project.
To get working on my original project, which was actually a web project, I had to take a few extra steps.
Update all libraries in the project to x64, not just the web project.
Enable 64 bit IIS express in VS2013 Tools > Options > Projects & Solutions > Web Projects > Use 64 Bit IIS ...
Install Internet Information Services Hostable Web Core through Control Panel (Turn Windows Features On or Off). Before I did this I would get an error when launching 64 bit web projects in the form HttpException (0x80004005): Specified argument was out of the range of valid values. Installing HWC fixed it.
Still none the wiser why any of this is happening, but at least I can debug projects again.
This exception appeared to start out of nowhere and certainly caused me some headache, but I was able to resolve my issue by doing the following:
Go into the properties of the affected Projects
Go to the Debug Tab
Uncheck "Enable native code debugging"
I am trying to run a code snippet multiple numbers of times in C#.Project name is test.Initial number of times it's running properly but after that i am getting the following build error."Error 1 Unable to copy file "obj\x86\Debug\test.exe" to "bin\Debug\test.exe". The process cannot access the file 'bin\Debug\test.exe' because it is being used by another process.test".
How can I get rid of this error.
It happens because sometime Test.exe keeps running even after you finish executing test.
One solution is to kill Test.exe once your run is finished.
There could be some side effects because of this. You might see some Test run Errors in next runs
Better way is to disable Test Execution Running between runs
Go to Tools > Options > Test Tools > Test Execution
Unselect "Keep test execution engine running between test runs"
Can take this Referance.
That's because a protected version of you application is being run in memory by VS. You have to shut it down. You have many ways to solve this problem. The simplest one is:
in solution explorer, right click on you Test project, click Properties. in Test properties, go to Debug tab. Uncheck "Enable Visual Studio hosting process". You may need to restart VS.
By the way, if it's critical for you, upload you entire solution and I will take care of it.
I am writing tests for an application using Outlook Redemption that absolutely must run 64-bit (it connects to windows MAPI and Outlook x64). Unfortunately, I cannot for the life of me make it run the test in 64-bit. I have tried using a .runsettings file (edited to indicate 64-bit) and a .testsettings file (also edited), and finally I have selected Test>TestSettings>Default Processor Architecture>64-bit, to no avail.
Every time, System.Environment.Is64BitProcess is false, and when I load the dll to connect to Outlook and MAPI I get the dreaded COM Exception: Wrong OS or OS version for application (Exception from HRESULT: 0x800401FA (CO_E_WRONGOSFORAPP)) which indicates that 64-bit Outlook is installed and the process trying to access it is 32-bit.
I have restarted VS 2012 after making settings changes as I have read somewhere that a restart may be necessary. Does anyone have any other suggestions? I could just write this as a console app that runs informal tests and reports their status, but my next step is to get these tests integrated into the automated build. Any help would be greatly appreciated.
Edit
Screenshot of Host Settings page in .testsettings
Experiment
Interestingly, I did a little experiment. I created a new solution with a single console app project. I put a public method in there that just returned true. When I ran the console app, and paused execution, I looked and indeed it is running 64-bit; no problem there. I then added a test project, created a single test which called the method. I also added var is64 = Environment.Is64bitProcess and put a breakpoint after it.
Predictably, without changing any options, is64 was false. I chose the 64-bit default architecture from the dropdown under test, then cleaned the solution, and ran the test again, same result, running 32-bit. I restarted VS2012, cleaned, built, same result. I created a testsettings file and referenced it in the Test menu, clean build, same, restart,clean, build same. I created a runsettings file, set <TargetPlatform>x64</TargetPlatform> , referenced that in the test menu, ran through it all again, and came up with the same results. QTAgent32.exe continues to run the process, and absolutely refuses to heed my demands that it run 64 bit.
I swear, if I have to delete QTAgent32.exe and rename QTAgent to that name, I will. I am not above cramming my wishes down the computers throat when it wants to be obstinate. Please, if you dont want to see me mistreat a workstation, someone show me what is going wrong. Think of the computers.
If you use VS2012, then you will be able to select your platform x64 through test settings as below;
In this example I am referring to .runsettings file.
the settings are
But if wish to run your test through command line you need to use vstest.console.exe instead of MSTEST as it doesn't support for x64 test.dlls
you will find vstest.console.exe at "C:\Program Files (x86)\Common7\IDE\CommonExtensions\Microsoft\TestWindow\"
Please note below steps
Open CMD
Navigate to "C:\Program Files (x86)\Common7\IDE\CommonExtensions\Microsoft\TestWindow\"
execute vstest.console.exe "C:\Projects\Test\Test.Automation.Specs.dll" /InIsolation /platform:x64
Note : Test.Automation.Specs.dll is your test project and you need to define full path
I hope this help
I ran into the same issue just now. Here are the steps you can follow to fix the problem.
Switch default processor architecture for unit tests from x86 to x64: Go to Test->Test Settings->Default Processor Architecture->x64.
Change the Build settings for the unit test project to x64.
Clean the solution then rebuild the solution. Your unit tests should now show up in the test explorer, and you should not run into this issue anymore.
References
Link to MSDN reference which explains how to resolve the issue.
This is a bit out of my scope, but the configuration settings for both projects are set correctly, right? You have them set to build for AnyCPU or x64?
Just trying to Occam's Razor it out... I know I've been frustrated too many times by configuration settings that VS just magically decides to change on me.
I have a problem debugging an NUnit test from VisualStudio. I created an empty project (Console Application), then I added references to the NUnit library and wrote a simple test.
namespace ReimplementingLinq.Tests
{
[TestFixture]
public class WhereTest
{
[Test]
public void SimpleFiltering()
{
int[] source = { 1, 2, 3, 4, 2, 8, 1 };
var result = source.Where(val => val < 4);
int[] expected = {1,2,3,4};
CollectionAssert.AreEqual(expected, result);
}
}
}
Next I followed the advice given in this link
How do I run NUnit in debug mode from Visual Studio? but none of the solutions in that topic work for me. None of my breakpoints are hit while performing the test. I tried testing the solution by attaching to the process and also by running the project with an external program with arguments.
What can I do to debug my unit test?
Running or debugging NUnit tests directly with Visual Studio
Look ma' no extensions!
Simply configure your test project so that when you hit F5 (Start debugging) or Ctrl-F5 (Start without debugging) it will automatically start NUnit GUI and execute all tests within it. If any breakpoints get hit, you will also be able to simply debug your test code.
A step-by-step guide with images shows you exactly how to do it.
Laziness is the mother of all invention :-)
Assuming you're using a version of Visual Studio other than Express Edition then TestDriven.NET might be of use.
After installing it
Set a breakpoint within your test method
Right click and choose Debugger from the Test With menu
The debugger should launch and hit your breakpoint
Unfortunately you can't use this method with Express editions of visual studio because TestDriven.NET is a plugin for visual studio and the Express editions do not support the use of plugins
Running a test within a console app
You can also run a test in the debugger via a console application:
Create a new console application
Reference your unit tests project
Inside the Main method of the console application create a new instance of your test fixuture and then call one of the test methods. For example if I have a fixture named MyTests and a test named Test1 I'd write:
var myTests = new MyTests();
myTests.Test1();
Set a breakpoint at the line where you create an instance of the MyTests class and press F5
The debugger will hit your breakpoint and then you can use F11 to step into your TestFixture's constructor, or step over that into the test itself
If you are using NUnit 2.4 you can put the following code in your SetUpFixture class. (You can do this with older versions but you will need to do whatever equivalent that has to the SetUpFixture, or copy it in to the test itself.)
[SetUpFixture]
public class SetupFixtureClass
{
[SetUp]
public void StartTesting()
{
System.Diagnostics.Debugger.Launch();
}
}
What Debugger.Launch() does is cause the following dialog to show up when you click Run inside NUnit.
You then choose your running instance of visual studio with your project open (the 2nd one in my screenshot) then the debugger will be attached and any breakpoints or exceptions will show up in Visual Studio.
Have a look at NHarness on CodePlex.
It's a very simple, reflection based, test runner library, that recognises NUnit attributes, and can be run from a project within Visual Studio Express, allowing debug testing.
It currently has a test class level granularity, but method level calls are, supposedly, going to be added soon.
Had the same problem with NUnit 2.5.3, and eventually found a different solution. See if this works for you:
Open NUnit GUI and go into Tools menu Settings... dialog. Select Assembly Isolation subsection of Test Loader section in Settings tree. Set the Default Process Model to Run tests dierctly in the NUnit process.
I had it set to Run tests in a single seperate process, which is why the debugger could not link my dll under test to the symbols for debugging it. I am still using Use a sperate AppDomain per Assembly for my Default Domain Usage.