https://pact.io logo
Join Slack
Powered by
Hi crew. Great work on 4.0.0. I’m having some trou...
# pact-net
m
Hi crew. Great work on 4.0.0. I’m having some trouble getting verification results to output to console. I know that output is occurring because pointing the verifier to a bad pact file location spits out a bunch of output. Has anyone reported this? I’ve tried xunit and nunit. Same results. Makes it very hard to know where verification fails.
👋 1
m
A colleague of mine was putting together an example yesterday, and I noticed the consumer logging seemed to be missing some items. I’m going to take a little look now
(I’m on a Mac though - what OS are you running Mick?)
I don’t know .NET all that well, but I can see in the examples Adam has added an 
XUnitOutput
added to the 
Outputters
attribute. If I leave that in, I’m assuming the output is redirected to the xunit tool (which I don’t use, so in the terminal it’s empty)
Copy code
Outputters = new List<IOutput>
                {
                    new XUnitOutput(this.output),
                    new ConsoleOutput()
                }
Presumably will write to both stdout and xunit
a
Yeah if you use both outputs then you'll get the logging twice
As in, once on the console and once inside xUnit. However, xUnit 'steals' the console, so generally speaking that won't work inside an IDE or with 
dotnet test
. In that case just using the xUnit output is enough though
I'm gonna release a 
PactNet.Output.Xunit
package I think, because it's just something you always need. It's annoying that it's literally one class with one line of code though
👍 2
@Michael Fagan it's worth making sure you're on beta 2 as well, just to be sure. I think logging worked fine in beta 1 as well though
m
I’m on windows and have beta 2. I’ve followed the example and still can’t get any output. Definitely used to work in an earlier build
a
The output definitely works in the samples. Could you maybe clone the repo and try to run those?
👍 1
m
How are you running the tests, via 
dotnet test
in the terminal or clicky in VS (or VS code)? Just gave the clicky clicky a go in VS code, and pretty impressed it “just worked”
That being said, the verifier logs being dumped out after the verifier output seems strange. I’d mostly ignore those logs I think, unless something went wrong.
I think it makes more sense swapped around, what do you think? Or do most people not using the terminal and therefore that would be hidden?
a
Yeah I put the output first since that generally tells you what went wrong, then included the logs just in case you want further detail. I can't really do much other than that because those are two separate FFI calls. Output and logs are collected separately in the Rust core
For example, the logs contain the full message (at debug level) whereas the output just tells you about mismatches
m
oh yeah, I was more thinking the Verifier Output is what most people want to see, and having to scroll up (above the noise) is not ideal
My point being, that a terminal is LIFO in terms of consuming the information, so you probably want the most pertinent information at the bottom
a
Iirc, in VS the test output window (either the one built into VS or the R# one) starts at the top though 😂 That's probably the primary platform for .Net instead of a terminal. You've also got the actual logs from PactNet above all of that as well. That's just the downside of the shared core approach. You can't interleave any of the output in a consistent and satisfying way, you just need to ask the core for the output after it's finished.
🤯 1
m
I'm running the tests via the terminal with dotnet test. Here's a gist of what I see when I force an error by providing a bad pact file. https://gist.github.com/mkzer0/480ee0fa6bc3e7abc5a8da04b6cb398f Would this suggest that my Xunit output is indeed configured and setup correctly? I'll try the samples too.
a
Yeah that's working. It's telling you the file you've specified wasn't found
👍 1
m
I get a very similar error running the ReadMe Provider tests to what I see in my own project. https://gist.github.com/mkzer0/60a31fdff3e1dc0eeb7669a1691c0c7c Some notes: I'm using visual studio 2022 Was prompted to install framework 4.6.1 replicated from clicky vs command line build On windows 10 I'm not a .net guy
a
Those tests are all working locally for me and in CI, so it does appear to be something on your machine. That's telling you a directory wasn't found
m
Ok. I'll keep digging. Thanks!
Pulled out another machine, works as expected. Something about the setup of the other machine. Anyway, thanks for the help and keep up the great work on PactNet!
🤔 1
m
Would love to know what the difference is
🤷‍♂️ 1
a
It could be the certificate issue that I have on my work laptop. It causes a panic that crashes the entire thing with no logging
That's definitely a blocker to a full release
I think I made a little app that can detect the problem, but it was in Rust, not C#
m
I debugged it as far as the rust native lib call. I could send you some logs if you tell me what you need?
We’re champing at the bit to get 4.0.0 , so if we can help.
m
That’d be great, thanks Michael
Sounds like it might be a seg fault.
a
It'll be the certs panic no doubt. @Michael Fagan could you run my little sample app I've shared above? That'll indicate if it's the invalid certs issue: https://github.com/pact-foundation/pact-reference/issues/156
👍 1
m
Ran the cert checking tool. It reports an error:
Copy code
[2022-02-22T20:12:57Z ERROR rustls_native_test] Failed to parse cert
[2022-02-22T20:12:57Z ERROR rustls_native_test]     Subject: CN=127.0.0.1
[2022-02-22T20:12:57Z ERROR rustls_native_test]     Error: MissingOrMalformedExtensions
👍 1
m
Thanks for confirming!
There is an upstream issue in an HTTP lib we use that tracks this. I'll see where it's at today as I believe it was fixed. if released I'll get a new release out
👍 1
a
Problem is that rustls was fixed but we've not had a reqwest release to upgrade to that version yet
That cert is a localhost development cert, likely the one that ASP.Net Core installs by default. Given we're expecting pretty much all our users to have a cert like that, that makes this a huge issue 😲
m
As always, Windows users causing problems for us *nix folks 😛
Confirmed, latest version is 
0.11.9
which doesn’t have the fix
m
Haha. You don’t want things to be easy, where’s the fun in that?
m
Bring back the good old days - write everything yourself. The problem with that, is you can’t point the blame at somebody else 😛 I’ll follow up the maintainer to get an idea as to when the next release is likely to go out
👍 1
m
Sounds great. Let me know if you testing done. I’ll monitor this group
m
thanks Mick - much appreciated
did you manage to find the certificate at fault? Removing/moving it out of the way (whilst not ideal) would be a workaround for the time being
m
I’ll give that a go. Happy with a workaround tbh
👍 1
a
If it's an ASP.Net Core dev cert (which it looks like to me) then it'll just get reinstalled if you remove it
I still don't really get why we're not just using the native certs support in reqwest instead of the rustls version. I compiled it locally with the default TLS feature and it worked absolutely fine, even with the 'invalid' cert
m
I still don’t really get why we’re not just using the native certs support in reqwest instead of the rustls version. I compiled it locally with the default TLS feature and it worked absolutely fine, even with the ‘invalid’ cert
If you look at the PR that removed it, you’ll see why. Essentially, it doesn’t support the standard open ssl environment variables that everybody is used to on the current version.
Whilst openssl isn’t the only implementation, it’s essentially a standard
also, from memory, it properly discovered certificates x-platform that the native one didn’t
7 Views
Open in Slack
PreviousNext
Powered by