Nunit console doesnt find selenium-manager.exe , works fine from visual studio #1488
Comments
|
Moving this to the console repo. |
|
is there any command that I can tell nunit console to refer project dll path, as of now it appears that nunit takes nunit3-console.exe path as base |
|
@saiparth You are running the console runner out of a It will also be helpful to know if you are referencing the vs adapter in the same runs where you use the console and, if so, which verson. |
|
Hi @CharliePoole
|
|
Uploading Bug.zip… |
|
Selenium uses |
|
@saiparth What happens if you use the .NET 6.0 runner from the zip file? Does error change? @nvborisenko Thanks for that info. The question seems to be "Whose AppContext?" From the symptoms, I would guess it's using the context of the NUnit runner itself. This might be a way to simplify the issue. I'll write some tests to see what the value of |
|
@CharliePoole Runtime Environment Test Files Errors, Failures and Warnings
|
|
I'm running a small test project that simply checks the value of Of course, the .NET Framework builds use an ApplicationDomain, which is where the basepath is set. I'll do some research about whether there is any downside to setting the basepath directly in the runner. |
|
In .NET 8.0 I'm able to use I'm posting my code here, from class Note that @nunit @OsirisTerje All I'd appreciate ideas and comments from anyone who knows more than me about this, esp. about any pitfalls to watch out for. I have a suspicion that this may possibly allow us to simplify the current code we use to find dependencies and if we put it in I'll experiment with that further. |
|
@CharliePoole We have said earlier that we will support LTS for approx 6 months after end of MS support. It may also be longer, as we have seen before. But I wonder if we could accept that this works for .net 8 and above only, even if other parts of NUnit also support net 6. |
|
@OsirisTerje Ha ha! Have you met me? I'm still a strong believer in backward compatibility. But "support" needs to be defined by any team creating software. I think we did that in the Platform Support document. That document distinguishes what tests we will run from what specific runner agents we provide. We didn't deal with the .NET Core runner at the time we approved it, so that will require some extra thought. AFAIR the @nunit team as a whole (absent an engine team) never reviewed that document. Would that be useful at this point? |
|
@CharliePoole Yes, I did, and .net 8 is to be supported 6 months after MS EoS. Which is May 2025. |
|
@OsirisTerje Sorry, I dont' understand "I did." Can you clarify? Also, I assume you meant .NET 6.0. I'll clarify as well. I agree completely with your suggestion "But I wonder if we could accept that this works for .net 8 and above only, even if other parts of NUnit also support net 6." That's exactly what I was implying in my own initial comment. I re-commented for two reasons:
BTW, the linked document says nothing about the .NET Core runner. We limited ourselves to the standard runner and agents when we wrote it. I'm hoping to come up with some ideas about the .NET Core runner as a result of working on various issues like this one and I'll make some suggestions when I do. FWIW here is what I mean when I just use the word "support" by itself... We state that we do not support tests targeting .NET Standard. What that means is we actively examine the assembly and if it targets .NET Standard, we refuse to run the test. We could do the same for any platform. In fact, there are others where we do that, e.g. Silverlight, Compact Framework. We could refuse to run .NET Core 2.1 tests as well, but we do not. So, by that definition, we still "support" .NET Core 2.1, typically running the tests using a .NET Core 3.1 agent. |
|
@nunit In spite of the policy/personal digression, still looking for technical insights on whether setting the BaseDirectory directly is a good idea. |
|
@CharliePoole Sorry, I wasn't clear :-) I am very grateful for what you're doing! Just so that is said. I just meant I was aware of that document, and I thought it matches what the team discussed earlier on this. I do seem to remember (but may be mistaken) that we actually read it at that time. Hard to remember everything, but all in all, we are in complete agreement here - THAT was what I was trying to express! When it comes to "support", we seems to mean that it actually will not work with the newer version, and we will not do fixes in earlier versions. E.g. in the framework we do support both the 3.X and the 4.X series, and then the latest version of each. That said, we have actually done support on an earlier version when there has been pressing needs from someone that really really want it very badly, and they seem nice of course! I have also experienced that the different parts we have do support frameworks differently. So if you run using the adapter, either VS or dotnet cmd line, you will have one (or even two) experience(s) (add to that the engine of possibly not the latest version is embedded). Using the console, another experience. Using NUnitLite, a third experience, and using Rider and their own runner, which relies on not the latest engine version, yet another experience. Also, in the first case, VS, the experience will also depends on which version of VS you're using, and it also seems to have a certain dependency not only on which version you run, but also on which has been installed on your machine. There are so many dimensions to this, I don't think we're able to set up a complete documented matrix for this, unfortunately. About AppContext.BaseDirectory, I have understood it is meant to be a read-only property, and should not be changed. I do not have enough knowledge to understand potentially side effects on this, also when you have the custom AssemblyLoadContext. But I do get a kind of yellow flag here. Feels like that is what you also get, since you're asking. |
|
Regarding
Reading it further https://learn.microsoft.com/en-us/dotnet/framework/app-domains/how-to-configure-an-application-domain:
I hope this might help. EDIT: It is not relevant for .net core, please ignore me. |
|
@nvborisenko The first citation is relevant to .net core but the second is framework only. .NET Core contains a kind of skeleton implementation of AppDomain, but many methods throw exceptions, including creating a new AppDomain. |
|
Yes, although it's possible to set On support... I feel like we have clarified it between ourselves but nobody else was involved in the discussion with me and of course any team discussions are private, which is why I asked. |
|
I have found 28 GitHub projects using I can see that this could be a dangerous thing to do in the default context or in any context that had already built up a dictionary of loaded assemblies but I'm confident enough about this usage to create a PR for it. @saiparth I have only tested that this leaves the BaseDirectory set correctly. You'll need to verify the result of using it with your own code after the PR is created and merged. |
|
@CharliePoole |
|
@saiparth You can try this using 3.18.3-dev00002. I predict it will work if you are using an agent via the standard runner but not if you are using the .NET Core runner. :-) |
|
It dint work for . net core runner, could you please tell me how to check via the standard runner |
|
You'll find the standard runner in the net462 directory in the zip if that's what you are using. Or get it from nuget or chocolatey as NUnit.ConsoleRunner. It will run under .NET Framework but launch an agent to execute your tests. Note that the zip file only exists for 3.18.1 and earlier. |
|
@CharliePoole Runtime Environment Test Files Run Settings Test Run Summary |
|
@saiparth |
|
Our MyGet feed now contains a new package, The package itself is experimental at this time and feedback on it will help us decide what to do in the coming 3.19 release. |
|
I tried |
|
This issue has been resolved in version 3.18.3 The release is available on: |
I downloaded nunit3-console.exe zip file and running from my local machine. Problem is seems nunit-console sets some path for execution and wont find already downloaded selenium-manager.
steps
Create nunit project in .net8 or .netcore3.1
add selenium dependency and add basic step to lunch browser like
var driver=new ChromeDriver();Run from visual studio and verify it works fine
Open cmd and run dotnet test and observe it works fine
dotnet test "LoggerDemo/bin/debug/net8.0/LoggerDemo.dll""Now run below command and see it throws exception
C:\softi\nunit-console\bin\net8.0\nunit3-console.exe "LoggerDemo/bin/debug/net8.0/LoggerDemo.dll"System.TypeInitializationException : The type initializer for 'OpenQA.Selenium.SeleniumManager' threw an exception. ----> OpenQA.Selenium.WebDriverException : Unable to locate or obtain Selenium Manager binary at C:\softi\nunit-console\bin\net8.0\selenium-manager\windows\selenium-manager.exe at OpenQA.Selenium.SeleniumManager.BinaryPaths(String arguments) at OpenQA.Selenium.DriverFinder.BinaryPaths() at OpenQA.Selenium.DriverFinder.GetDriverPath() at OpenQA.Selenium.Chromium.ChromiumDriver.GenerateDriverServiceCommandExecutor(DriverService service, DriverOptions options, TimeSpan commandTimeout) at OpenQA.Selenium.Chromium.ChromiumDriver..ctor(ChromiumDriverService service, ChromiumOptions options, TimeSpan commandTimeout) at OpenQA.Selenium.Chrome.ChromeDriver..ctor(ChromeDriverService service, ChromeOptions options, TimeSpan commandTimeout) at OpenQA.Selenium.Chrome.ChromeDriver..ctor(ChromeOptions options) at OpenQA.Selenium.Chrome.ChromeDriver..ctor() at LoggerDemo.UnitTest2.Test1(String adf, String[] dsf) in C:\Repo\LoggerDemo\LoggerDemo\UnitTest2.cs:line 20 at System.RuntimeMethodHandle.InvokeMethod(Object target, Void** arguments, Signature sig, Boolean isConstructor) at System.Reflection.MethodBaseInvoker.InvokeDirectByRefWithFewArgs(Object obj, Span1 copyOfArgs, BindingFlags invokeAttr)--WebDriverException
at OpenQA.Selenium.SeleniumManager..cctor()`
I have tried setting below still its not working
$env:SE_MANAGER_PATH="LoggerDemo\bin\Debug\net8.0\selenium-manager\windows"The text was updated successfully, but these errors were encountered: