-
Notifications
You must be signed in to change notification settings - Fork 153
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
Unable to run nunit-console with VSProjectLoader that has a WPF 8.0 project #1468
Comments
@WindingWinter Coincidentally, I just ran into the same error in the TestCentric GUI. As you can see, the exception is thrown by TestCentric.Metadata, a package I maintain. It is used both by my GUI and by the NUnit engine. The code of TestCentric.Metadata is rather old and it's likely that the internal structure of a managed assembly image has had some additions, which are causing this exception. I don't think it's a problem which will be resolved quickly but I'll start looking into it. @OsirisTerje FYI... this may have big implications for the adapter. |
@WindingWinter Does this crash with |
@OsirisTerje , not entirely sure what you mean, but if I run it with And the |
That means it is not related to the engine per se, as the adapter 4.6 also use the 3.18.1, but to what executables it is trying to load. It seems the console is trying to load that executable without needing to do so, probably to check if it is a test assembly or not. The filtering of assemblies happens in the Microsoft testhost (or perhaps even before that one too). |
@WindingWinter Coincidentally, I just ran into the same error in the TestCentric GUI. As you can see, the exception is thrown by TestCentric.Metadata, a package I maintain. It is used both by my GUI and by the NUnit engine. The code of TestCentric.Metadata is rather old and it's likely that the internal structure of a managed assembly image has had some additions, which are causing this exception. I don't think it's a problem which will be resolved quickly but I'll start looking into it. @OsirisTerje FYI... this may have big implications for the adapter. |
Above comment was written before I saw @OsirisTerje 's comment. So... more info... I think what we have here is a serious bug in the BACKGROUND A long time ago we used reflection exclusively but reflection did not help us in our cross-platform scenario, i.e. we were building the runner and engine with .NET 2.0 but wanting to examine newer framework versions and the newly arrived .NET Core and .Net Standard. To solve that problem, we switched to
THIS ISSUE I think this issue would be readily solved for @WindingWinter if we didn't try to load the executable at all. That would involve looking at the package produced by the VS Project Loader extension to see if it includes the .NET Standard assembly. If so, that's a bug in the extension. If so, I'd view that as relatively low priority because there is already a simpler workaround, in this case, of simply not using the solution at all but either using the project or the single assembly itself on the command-line. We should also consider issue #25, which involves a much bigger rewrite of the project loader. BROADER PROBLEM I'm seeing the same stack trace in the TC GUI when loading a .NET 8.0 test assembly. That's where I see a potentially bigger implication. I'll try to replicate that problem for this issue and I'll create an issue for the metadata project itself. It's not clear whether this impacts the VS adapter. For that, I'll need to narrow down the particular APIs that are failing, determine where they are used in the engine and whether the adapter is likely to trigger those calls. Since the adapter only uses a subset of the engine API, there may be no immediate effect. That would take a bit of the pressure off this |
@WindingWinter If you switch to using either the |
@CharliePoole , if I run it on DLL basis then no, no such problem. It makes sense though because when I run it on DLL basis then the nunit console will have no information of the WPF 8.0 version, so no screwing up. |
Not sure what you mean by that. The console doesn't get any information from the solution or project files about the WPF version you use. Neither does the project loader extension. All information is extracted from the dll itself by the engine, including all your references. However, running from the dll vs csproj vs sln can change how the engine examines the assembly, just what calls it makes and in what order, so this information is a useful lead for me. For now, I suggest you just run the assembly on the command-line and watch this issue for a fix. |
Oh... are you saying that the WPF project is not a test project? That would be important info! |
If the WPF project is not a test project (waiting for confirmation from @WindingWinter ), then this would really be a duplicate of #1465. The question there is "why are we examining this assembly at all?" and the fact that it's .net 8.0 or .net standard isn't relevant. However the stack trace in this error indicates a failure in examining the metadata for the .net 8.0 app, which I have seen before in the TestCentric GUI, so I'll retain this issue either way. @WindingWinter You could help by running NUnit3-console against the .net 8.0 exe alone. I'm pretty sure we will see the same stack trace. |
@CharliePoole , yes you are right. The WPF project is not a test project at all. As indicated totally by the csproject file information:
|
@WindingWinter Yes, that's how I guessed. it would be unusual (but possible) to have a WinExe as a test project. :-) Even so, it's still a bug if the engine throws an exception while analyzing any assembly so I'll continue to work on that problem here, while working the "spurious error" problem under issue #1465. Further question to narrow down the problem: Is the WPF project is a self-contained executable? |
Yes it is a self contained thing with no reference to anyone. It's just a
dummy winexe project and it can already reproduce the problem
…On Thu, Sep 5, 2024, 6:26 PM CharliePoole ***@***.***> wrote:
@WindingWinter <https://github.com/WindingWinter> Yes, that's how I
guessed. it would be unusual (but possible) to have a WinExe as a test
project. :-)
Even so, it's still a bug if the engine throws an exception while
analyzing any assembly so I'll continue to work on that problem here, while
working the "spurious error" problem under issue #1465
<#1465>.
Further question to narrow down the problem: Is the WPF project is a
*self-contained* executable?
—
Reply to this email directly, view it on GitHub
<#1468 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADENIZVPUOPI6XTKHQ5N2ULZVAWWNAVCNFSM6AAAAABNRFPYN2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMZRGE3DOMRSGI>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
I thought so. I think the exception may occur because of a missing optional header, but one which we assume must be present in a test assembly. |
I have replicated this in my latest set of tests. |
It turns out that the answer is relatively simple and my worries about the long-term viability of TestCentric.Metadata were a bit premature. I forgot one thing and didn't know another...
@WindingWinter You can check this yourself. If your app is named I can resolve this in one of two ways...
In fact, I'll do both things, option 1 right now for the console runner and an internal fix in the next release of TestCentric Metadata. @jbevain I'd appreciate any thoughts you have on the above. |
@WindingWinter Fix is on myget, version 3.18.2-dev00023 if you would like to test it. @OsirisTerje I created a "test runner" for unmanaged executables. It doesn't actually execute anything, of course, but it returns a result when you call it rather than throwing an exception. This is an adhoc experimental implementation but I'll come back to it in a separate issue to create similar (non)runners for other situations. More detail on that issue when I create it. |
This issue has been resolved in version 3.18.2 The release is available on: |
If you just add a WPF Windows .net 8.0 project to a solution, such as this one:
Then when you run the code
Where
%slnFile%
is the path of your solution file, then it just won't work.This is the error message:
I've tested this with nunit console 3.18.1 standard version, and the VSProjectLoader 3.9 version.
It should be noted that the existence of WPF .net framework 4.8 version won't have any problem at all.
The text was updated successfully, but these errors were encountered: