I am using VS 2015 and I created a new “Unit Test App (Windows Universal)”.
If the Default Processor Architecture is set to x64 (under “Test -> Test Settings -> Default Processor Architecture”), the build works fine and the test is also discovered successfully and displayed by the Test Explorer
However, if I change the Default Processor Architecture to x86, the build still succeeds, but VS does not discover any tests.
Thoughts?
P.S. I have looked at some of the similar problems that have been asked here. If you think this is a duplicate, please confirm with me before flagging the question. thanks.
For the larger audience: It seems like there was something that I was missing while installing Visual Studio that resulted in this issue. I reinstalled VS from scratch, and everything works as expected.
I just hit this too.
For me the root cause was that the Build target must match the Test Settings Default Processor Architecture.
New Projects (even Universal Windows projects) always default to Any CPU.
If you are running on x64 machine then your Test Settings Default Processor Architecture has to be x64 too.
In my opinion Universal Windows projects should never have an "Any CPU" config.
Universal always has to build native now so stop the "Any CPU" option and make the user pick the target!
Related
I have a visual studio 2019 project that requires a 64 bit build due to dependence on some nuget packages.
As you can see, I have changed the build targets to 64-bit but it doesn't seem to be able to move past the same complaint.
What am I missing here? Is this a bug in Visual Studio 2019 or am I doing something wrong?
Changed all built targets to 64 bit.
While you're looking at the specific build options for a Configuration called "All Configurations", where the Platform is set to "X64". But note your settings in your IDE's toolbar. You're currently targeting/building the "Debug" Configuration for "Any CPU".
To better understand what's going on here, right click on your Solution node in the Solution Explorer and select the "Configuration Manager..." menu item.
Given you require X64, you can/should remove the configurations that allow you to target x86 or ANY CPU. I suspect you are just building the wrong configuration here. That "All Configurations", is probably being brought along by one or more C++ projects in your solution.
Sincerely,
I have a Visual Studio solution where i use MSTest for my Unit-Testing, and would like to use the ReSharper Testrunner as i think the Visual Studio Test Explorer is really painful to work with. My whole solution is built for x64, because i have some dependent assemblies that are specifically compiled for x64 and not available for x86.
My unit-tests run fine in the VS Test Explorer, but they fail in the ReSharper Testrunner.
The following exception is being thrown, right before it hits the first line of the unit-test:
Unable to get type xxx.xxx.xxx. Error: System.BadImageFormatException: Die Datei oder Assembly "file:///D:\path\to\unit\test\project\bin\Debug\xxx.xxx.xxx.dll" oder eine Abhängigkeit davon wurde nicht gefunden. Es wurde versucht, eine Datei mit einem falschen Format zu laden.
Sorry for the exception being in german. It's just a 'typical' BadImageFormatException where xxx.xxx.xxx is the type of my unit-test project.
The Stacktrace indicates that the exception is being thrown from
Microsoft.VisualStudio.TestPlatform.MSTestFramework.TypeCache.LoadType(String typeName, String assemblyName)
I know that there are already many similar questions on stackoverflow, but i already tried every possible solution i found (without any effect), and therefore i assume my problem lies somewhere else.
What i tried and checked so far:
I double checked every project in my solutions to be compiled to x64 (even in release mode) -- everyhting seems fine
Default processor architecture for MSTest is explicitly set to x64 (Probably that's why it's working with the built-in Test Explorer)
Though it should be decided based on the platform of the project, i explicitly set the platform in ReSharper Testrunner to x64
I even modified the Unit Testing settings for ReSharper to force the execution of the unit-tests in a 64-bit process
Disabled Shadow-Copy of the assemblies in ReSharper settings (Just because i'm pretty frustrated right now, and switched to trial & error mode just before i started creating this question)
It's irritating that the tests run fine with Test Explorer, but not with ReSharper, though both have been set to x64. Am i missing a specific setting i need to modify? Or are they some known problems when using ReSharper in combination with MSTest? I might also consider using nUnit instead, but i'd need to modify all tests, so preferably i'd stay with MSTest.
Additionaly some information about versions and stuff (don't know if it might be helpful):
Visual Studio Premium 2013 v12.0.30110.00 Update 1
.NET Framework 4.5 on every project in the solution
ReSharper 8.2 C# Edition, Build 8.2.0.2160
After some additional research i found a similar post in the ReSharper Community, that indicates that ReSharper is configured to create and use a testsettings file in MetaData of the application per default, which is not configured to use the x64 architecture. I had to create a custom TestSettings file on my solution (which is placed under Solution Items), set it to force running in x64 and then edit the ReSharper setting to use this custom TestSettings file instead of the default one. I still do not know why ReSharper isn't using the default processor architecture specified for MSTest and also ignoring the settings i specified explicitly in the ReSharper settings.
But anyway it's working now.
In one project's Properties | Build tab, only x86 is available for Platform. The x64 build option is missing. This is occurring in one project of a solution. The other projects are all still using x64. I tried creating an entirely new and separate solution/project and it is also only displays x86. Also, in the General section x64 is available and selected for Platform Target.
Can anyone explain why this is happening and how to fix it?
Trying to debug an NUnit test in VS2010 and is not stopping on the breakpoint. It was working the last time I tried need to debug the test (maybe 1 yr ago) but now it doesn't work.
I've tried the following:
How to debug with vs.net 2008 and nunit?
http://erraticdev.blogspot.com/2012/01/running-or-debugging-nunit-tests-from.html
I've tried attaching, rechecking my installation, updated the config file so it's using the 4.0 runtime, still doesn't hit the breakpoint.
What am I missing?
You can debug nunit tests in VS studio community version only. For this you need to install Nunit3testAdpter. You can add this in Tools -> Extension and updates. or from Nuget packages.
This is a long overdue question but I haven't seen the solution to debug NUnit tests directly within Visual Studio. This is quite easily possible and without any third party tools. All you have to do is configure your test project (which is just a plain old Class library project) so it will start NUnit test runner whenever you hit F5 or Ctrl-F5 (just run, no debugging).
Particularly you will have to configure your project properties to start an external program:
Step by step configuration is very well described in this blog post. It advises you to use NuGet to obtain NUnit test runner and configure project to execute the runner when you try running your library project. As simple as that. Using no specific tools which are usually not free.
There are multiple reasons why this may happen. If your application's target framework is different from NUnit's, then you won't be able to debug, because the tests are actually being run by nunit-agent.exe.
For me, my application was using 4.5, but NUnit's was using 3.5. (You can find this from one of the NUnit GUI applications -> Help -> About)
To fix this, change the nunit.exe.config file to include the following, inside the configuration section:
<startup>
<requiredRuntime version="4.0.30319" />
</startup>
This can also happen when your PDB generation is set to embedded. Switching it to full will allow the nunit test adapter to start with the debugger attached. At that point it can be switched back to embedded and it will debug again.
The setting is on the project properties pages, in the Build tab, then click the Advanced button. I always choose "All Configurations" at the top, so I make sure I'm emitting a useful PDB (or embedding the info) when building Release configuration assemblies too.
The other day I failed to hit a breakpoint in my NUnit debugging. It took me a while to realize that someone had copy/pasted the test into a different file and I was running a different test than the one that the breakpoint was in.
I recently had a similar problem. Changing the project's platform to AnyCPU solved it for me. Also worth checking:
1) Check NUnit's latest version (I was using 2.5.7, updated to 2.6.2)
2) The Target Framework for your test project. I was using .NET 4.0 (you can find it under Properties -> Application, on VS2010)
At least up to vs2010 the debugger can only debug 32 bit apps but not 64 bit apps.
With vs2010 I am using a 32bit nunit.exe version and use "attach to debugger". This workes well for me.
Please upgrade NUnit Test Extension and close the Visual studio so Visx (probably spell) will run and update NUnit tool.
After this you can open your project and run NUnit test project.
It will run.
I tested accurately.
Try changing the test to x64. From the menu do
Test -> Test Settings -> Default Processor Architecture -> x64.
i think u cant debug with Visual studio. better u install TestDriven.NET.
then
Put the BreakPoint on the test method
Right click on the test
method.
select TestWith->Debugger
What's the difference between different Build Configuration settings e.g. Any CPU, Mixed Platform, WIN32 etc in Visual Studio.
As other platforms are already explained (i.e. X86 for 32 bit, x64 is for 64bit only, and 'Any CPU' can run in Both) I'll concentrate on Mixed Platform and how this is different from Any CPU.
The Any CPU is at the project level setting, whereas in the real world solution we have a number of projects under one solution, and there's a chance that some of my project use Any CPU but other uses the x86 or x64 build platform.
So at solution level automatically Mixed Platform will be selected. This indicates that during Build/Rebuild solution each project builds based on its selected platform.
Here's a link that helps explain the build configuration setting found in Visual Studio and its build files:
http://web.archive.org/web/20151215192101/http://visualstudiohacks.com/articles/visual-studio-net-platform-target-explained/
Basically the setting states what platform the assembly is able to run on. When AnyCPU is selected, the resultant DLL is marked as able to run anywhere; when x86 is selected, the resultant DLL is marked as only being able to run on 32-bit systems and will not run in 64-bit applications or processes (but will run in 64-bit Windows;) and so on and so forth.
This just sets flags on the compiled DLL - it does not change other aspects of compilation process at all.
The build configuration names don't mean very much - they proliferate if you have C++ and C# projects in the same solution (and even worse if you have mobile projects too), because the various types of projects use different configuration names, so you end up with lots of them.
We try to keep deleting all the configurations we're not using, but that's hard work sometimes as often when you add a new project, unwanted configurations will be added back to the solution.
My recommendations is to decide on what configurations you need (by looking at the actual settings within them), and then remove everything else.
From: this post.
https://social.msdn.microsoft.com/forums/vstudio/en-US/81c72e8b-6335-4bf4-b7c0-b5c322edcaee/mixed-platforms-vs-any-cpu
When all of the projects in a solution are of the same type (e.g.
C#/VB projects) the solution configurations will match up exactly with
the project configurations. Once you have projects in a solution that
have mismatched configurations/platforms, Visual Studio creates the
solution level configuration(s) "Mixed Platforms/Debug" and possibly
"Mixed Platforms/Release". These configurations are just mappings to
individual project level configurations.
For example, if you have a C# project and a C++ project, typically
"Mixed Platforms/Debug" will map to "Any CPU/Debug" for the C# project
and "Win32/Debug" for the C++ project.