New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can't run requring a 32-bit process #181
Comments
Blocked until nunit/nunit#1548 is fixed. Probably won't require any changes in the adapter. |
Hi Charlie This issue appears to have roadblocked my own use of this adapter. It was working fine on 64bit but because I have to release as 32bit I'm having to switch back and forth between 64/32 bit. As a result I cannot get it to discover my tests anymore. I get one of two responses when I try: Either some message that flashes away too fast to see OR:
This is despite cleaning, deleting bin*, obj* files and rebuilding in the respective 32/64bit. I'm not sure if there's a better place to put this query! Warmest regards |
@SoulFireMage Note that this issue is closed and marked for release in 3.4, which will come out in the next few days. However, the issue I wrote is about NUnit erroneously giving an error message about requiring a 32-bit process when a 32-bit process is already running. If your problem relates to something else, this one won't solve it. However, I guess you have to wait and see. :-) Note that the adapter does not start any new processes so being in the right type of 32- or 64-bit process is dependent on VS settings, not on NUnit. |
Is there any current workaround for this issue? All my tests cannot be discovered! |
There is no workaround until we release the next version of the adapter using NUnit 3.4. I expect hat will be in the next week. |
Ok fine. How did this bug appear? Is it because of a recent update? Last week it was working fine for me! |
@disklosr I would need more info about your problem to answer. Read my comment to @SoulFireMage. The original issue description has to do with nunit not realizing that a 32-bit process is already running. The message will still appear if you need a 32-bit process but are not running one. In that situation, it is correct. In NUnit 3.4, the erroneous message no longer appears. However, the NUnit 3 Test Adapter has not been updated to use NUnit 3.4, so it's hard to see how anything on our side may have changed for you in the past week. Perhaps you should describe exactly what your situation is, how you are running tests and what symptoms appear. |
@CharliePoole My situation is that I can't run unit tests because no tests are discovered and the output window shows this error: "Cannot run tests in process - a 32 bit process is required". Last week everything was working fine. I didn't change any configuration in my project or build that could affect running unit tests yet I'm not able to run them today. |
And did you - or someone on your team - update NUnit in the past week? Are you using 3.4? |
No no updates recently. Just checked and I'm using NUnit 3.2.1 NUnit.Engine.NUnitEngineException, Exception thrown discovering tests in path/to/dll Maybe this is a problem with NUnit and not the test adapter. |
It may be the issue I mentioned, which is fixed in 3.4. I can't tell you why things would have changed for you in the past week unless something changed in the environment. Is VS running your tests in a 32- or a 64-bit process currently? Could that have changed? |
You will know for sure when the 3.4 release of the test adapter is released. |
Vs is configured to run tests in a 32 bit process. I'll try updating NUnit and see if it works. Thanks. |
That won't help. The NUnit3 adapter uses the version of NUnit that's bundled with it. Now that NUnit 3.4 is out, I'm working on v3.4 of the adapter. |
Just to clarify... When using the adapter, you can choose what version of the nunit framework you want to test with. The adapter chooses the version of the nunit engine that is used to run those tests. The problem you are seeing is in the engine. |
Thanks for handling this Charlie - experiencing the same issue myself. I wish I knew what changed on this end that results in tests not being discovered, but certainly hoping the NUnit 3 Test Adapter 3.4 update fixes it once it gets released! |
I have the same problem. It first appeared after I last updated the test adapter to the latest official version 3.2.0(; nUnit 3.4 wasn't even released at that time). So for me the problem appeared with updating the test adapter, not the engine. Probably this occurred because the latest nUnit test adapter used a version of the engine that contain the bug. I'm still having this problem, now that I'm using nUnit 3.4.1 along with test adapter 3.2.0. Anyway I'm going to wait for the next nUnit test adapter release that'll use nUnit 3.4 to see if it's fixed. |
@CharliePoole I've opened a new issue here: #230 Basically it has stymied my using this at all as I've spent the last hour today trying to find any way I can to make it run. I get that the problem is the test adapter but I thought this was fixed in the latest version? I'm definitely in x86 mode, setup the default architecture to be 32 bit, I've removed all of the previous versions of nunit and reinstalled the latest of both Nunit and the test adapter to 3.4.1. Despite this, still roadblocked on it. Definitely very grateful if anyone can show me how to force the test adapter to work! :) |
I've already commented on #230. Let's not start new discussion on this closed issue, but it's clear from the output you show there that you have not succeeded in upgrading to 3.4.1 - the messages are coming from the 3.2 adapter, which is the one that has this problem. |
When a test must be run in a 32-bit process, the engine throws an exception with the message "Cannot run tests in process - a 32 bit process is required."
It's particularly confusing because the message only occurs when the process is already 32-bit. That's because the engine is assuming that it's running in a 64-bit process unless it's on a 32-bit machine. The assumption slipped in because it's actually true wrt NUnit's console runner, but not with the VS adapter.
This was originally incorrectly reported against the NUnit 2 Test adapter at nunit/nunit-vs-adapter#112
This will eventually require a fix to the engine, but it may be possible to fix it temporarily by controlling the package settings passed to the engine.
The text was updated successfully, but these errors were encountered: