There is a well-known problem when unit testing managed C++ code in Visual Studio: unmanaged code calling back into managed can't cross app domains and crashes unit tests, as documented here:
http://social.msdn.microsoft.com/Forums/is/vststest/thread/fc7bc074-ff05-407b-b646-d9e5532c6998
and in more details here:
http://lambert.geek.nz/2007/05/29/unmanaged-appdomain-callback
Using /noisolation flag is one solution but it works only when running tests outside of Visual Studio, meaning you can't debug your tests in Visual Studio.
For me this is a huge thing. I have hard time understanding that Microsoft doesn't want to address this issue since at least 2006. Discovering that even Visual Studio 11 beta doesn't offer anything new here was a major disappointment.
So I turned to NUnit and started running my test with "Use a single AppDomain for all tests" selected. Disappointingly, NUnit displays the message: "An unhandled System.ArgumentException was thrown while executing this test: Cannot pass a GCHandle across AppDomains." After that it crashes.
I was hoping that I will be able to both debug and avoid GCHandle AppDomain issue. Am I misinterpreting the meaning of the single AppDomain option? Does NUnit 2.6 execute the test in the separate AppDomain and is there still no option to change that?
According to this answer by Charlie Poole at NUnit group:
https://groups.google.com/forum/?fromgroups&hl=en#!topic/nunit-discuss/elG7oyCOyBw
NUnit main (driver) program executes in the different AppDomain from the code that gets tested. Single AppDomain means single only for all the code to test.
Charlie suggested using NUnitLite, which uses a single AppDomain for "everything" and, after testing 0.7 version, I am happy that I can debug my tests of C++/CLI code which uses gcroot.
UI integration of NUnitLite in Visual Studio would be a great additional bonus, but for now I can live without it.
Related
The main software that we built is built using VB6 (old school, I know). We're having some problem for viewing a report using ActiveReports. We did many Debug DLLs and were unable to find why the problem happen. Note that restarting the server solves the issue, which brings us to think that the problem is resource related.
Is there a way I can see how much memory is being used by a DLL? I would like to see if an object in that dll might not be released correctly.
I tried using the performance monitor, but this is not as precise as needed.
Is there anything i could use to monitor a Dll's usage?
We are just doing it the hard way and monitoring a server running multiple instances of the DLL.
I have written automation tests in Specflow 2.0, nUnit 3.X, TeamCity and Visual Studio 2013. I am trying to run the tests in parallel but they are failing because the code uses static classes/object.
On the Specflow website the recommendation is to run thread safe tests (if architecture depends upon static state) using PARALLEL EXECUTION WITH MEMORY (APPDOMAIN) ISOLATION
http://www.specflow.org/documentation/Parallel-Execution/
But there is no information as to how to do this and even googling I couldn't find any relevant article.
I am really appreciate if anyone can help me understand how do we do this.
Thanks for your help,
Satty
How to configure the isolation depends on the test runner you are using.
I am not 100% sure that NUnit does support appdomain isolation, but a good start to find out would be the Parallelizable attribute documentation: https://github.com/nunit/docs/wiki/Parallelizable-Attribute
AppDomain or Process separation is possible if you are using the SpecFlow+Runner (http://www.specflow.org/plus/).
Here is a blogpost of the different modes in the SpecFlow+Runner: https://the-engineers.net/2016/04/08/using-specflowrunners-parallelization-features/
Full Disclosure: I am one of the developers of SpecFlow+Runner
That's the reason why you shouldn't be using static classes in your code
Code with static (is like globals) considered harmful and hard to test
I have this monstrous C++ application built using MFC(mainly) and COM. It links to several libraries and does a lot of scientific computing. So, now I want to add some new features to it and as an organizational policy, we are developing everything new using .NET. So, this new UI feature is going to be built using WPF and will be consumed in this existing C++ application.
I know how to use a WPF control in a C++ application, so that's not the problem. The problem is that when I try to turn on CLR on this project, it takes a lot of time (around 10 minutes) in linking stage to perform the linking and produce a mixed mode executable. In the end, it manages to do so and successfully creates the executable. But the problem is that whenever I launch this executable, it crashes. I tried to debug InitInstance but it crashes somewhere before this. I am a little stumped on what to try next.
Does anybody have any idea what might be the cause of this.
The target framework of the mixed mode assembly is 4.0 (as it should be) so THIS is not the problem here.
FYI, ILDasm fails to load this exe as well. It takes a lot of time, gives no error but it doesn't load it either. This gives me the impression that somehow managed image is not created properly.
Not sure if this is necessary, but it doesn't hurt either. New MFC projects have this in the constructor of your CWinApp-derived class:
#ifdef _MANAGED
// If the application is built using Common Language Runtime support (/clr):
// 1) This additional setting is needed for Restart Manager support to work properly.
// 2) In your project, you must add a reference to System.Windows.Forms in order to build.
System::Windows::Forms::Application::SetUnhandledExceptionMode(System::Windows::Forms::UnhandledExceptionMode::ThrowException);
#endif
I have a interesting problem: Where I work we've built a home-grown ERP system in VB6 that we are slowly moving over into vb.net. There are some projects have are in .net: we have a hand-held C# project that uses a web service to talk to our database, I've built some reporting screens using Crystal and some smaller maintenance screens.
Well as we have been plotting the conversion out, we want to have a way to separate our business logic and UI so that the UI can be a win/web form or a Smart Device project. Is this even possible? I try to reference the DLL in a test I have and it gives me this error when trying to debug using a emulator
Deployment and/or registration failed with error: 0x8973190e. Error writing file '%csidl_program_files%\smartdeviceproject1\system.windows.forms.dll'. Error 0x80070070: There is not enough space on the disk.
I'm not sure what it's doing... I take my DLL out and it works fine. Does anyone know of a way I can create a DLL that can target all of these UI without may changes?
This post here
helped me alot. Using a linked projects with conditional complation would seem to work in my case.
I have a vb.net project which sometimes, when running in the IDE, suddenly hangs. Normally this wouldn't be a problem. Just hit 'pause', look at the currently running threads, and find the deadlock (or whatever else).
But now I'm running into a situation where not only does the program hang, but trying to pause it causes visual studio itself to hang. In order to get control back, I have to kill the program-being-debugged's process, at which point visual studio comes back to life and says it was unable to pause execution. This is frustrating, because killing the process means the program state is lost (of course), so I don't know where the hang is.
So are there any common causes for this behavior? What should I be looking for?
if your program installs global hooks (which communicate with app) - this might be the case. A hook tries to communicate with your app (which is paused by debugger) and gets locked. And debugger is unable to receive its window messages: classic deadlock between hooked debugger (with hook dll) and a hooking app.
Finding a specific fix for a Visual Studio problem can be tricky: http://social.msdn.microsoft.com/Search/en-US/?query=visual%20studio%202008%20hang&ac=3
Additionally, not all hotfixes from Microsoft get released directly to the public. Some are only given out to customers whose systems are exhibiting a specific problem. So you have to contact Microsoft to the get the fix. They do this to limit the potential downside of releasing a hotfix that may break something else. So if all else fails, give them a call.
Here are some other things that I like to do when Visual Studio starts acting up:
Delete old breakpoints and watch variables.
With visual studio not running, delete the intellisense file (.ncb)
Clean the solution and then do a rebuild of all of the code.
Check hotfixes and service packs. I've seen a bug related to .net programming and debugging hangs. (VS hangs for me when debugging C++ 32-bit apps on 64-bit os:es sometimes.)
I just had a very similiar issue (VS fails to break execution), using Debug -> Delete all breakpoints solved the issue.
I'd check the code of the program being debugged, I'm thinking there may be an infinite loop or race condition in the code you're trying to debug. This has been the case for me in the past, especially on a single-core laptop I used to have. Can you give any information about where in the program you think execution is when you try to pause?