Trouble with the MockHttpService

[steve-westwood]

I'm having a bit of trouble getting my first v2 consumer test running. Keep getting this error message:

Please install the relevant platform and architecture specific PactNet dependency from Nuget. Based on your current setup you should install 'PactNet-Windows'.

.NET45 using 2.0.13-beta on Win7

Any ideas?

[neilcampbell]

Hi @steve-westwood To confirm, you do have PactNet-Windows nuget package installed in your project? What version of nuget are you running on your machine?

[steve-westwood]

Yes the PactNet-Windows prerelease 2.0.13-beta nuget package.

[steve-westwood]

I can see in a the code it fails because it's looking for a directory called pact-win32 in the build output, and it does seem to be there when I look for it myself.

[neilcampbell]

Are you using VS2015? What version of Nuget are you running? In your csproj file is there a target include for PactNet-Windows.targets?

[neilcampbell]

Yeah that is correct the target will copy the relevant files into your output directory. If you run Directory.GetCurrentDirectory() from within your tests, do you get the same path as the output location (where pact-win32 is copied to)?

[steve-westwood]

Ah, might be getting somewhere.. in my csproj there's only a reference to PactNet:

<Reference Include="PactNet, Version=1.0.0.0, Culture=neutral, processorArchitecture=MSIL">

I'm away from my laptop but I'm pretty sure I'm using nuget v3.

[neilcampbell]

That's to be expected, PactNet-Windows is a tools only nuget package. If you are getting the files in pact-win32 in your output path, nuget is likely doing everything correctly. My guess is that Directory.GetCurrentDirectory() isn't resolving to your output directory. How about running System.IO.Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssembly().CodeBase)?

What test runner are you using to run the test?

[steve-westwood]

My test runner is nunit v3 and the System.IO.Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssembly().CodeBase) comes back with:

file:\C:\Work\SolutionName\TestProjectName\bin\Debug

and if I look in there I see pact-win32 as expected :/

[neilcampbell]

Currently it uses Directory.GetCurrentDirectory(), so I need to know what that returns. I may move to the other method depending on your results.

[steve-westwood]

Yikes, I get this from Directory.GetCurrentDirectory()

C:\Users\username\AppData\Local\JetBrains\Installations\ReSharperPlatformVs14

[neilcampbell]

Interesting. That will be the issue. I will change the way that works and publish an update.

[steve-westwood]

Thanks Neil

[neilcampbell]

No problems, thanks for reporting it.

Update has been pushed and will be released in 2.0.14-beta after this build has completed https://ci.appveyor.com/project/SEEKJobs/pact-net/build/281.

Can you please update the nuget package once available, and confirm everything is working as expected?

[neilcampbell]

@steve-westwood and 2.0.14-beta is published. Keep me posted.

[steve-westwood]

Thanks, I can confirm the update has fixed this issue.

Still haven't quite got it working but I think this is my implementation.

[steve-westwood]

Sorry guys, just got a similar issue to the first whereby the pacts seems to be getting stored to C:\Users\user\AppData\Local\pacts rather than the desired directory? PactBuilder = new PactBuilder(new PactConfig { SpecificationVersion = "2.0.0", LogDir = $"..{Path.DirectorySeparatorChar}..{Path.DirectorySeparatorChar}..{Path.DirectorySeparatorChar}logs{Path.DirectorySeparatorChar}", PactDir = $"..{Path.DirectorySeparatorChar}..{Path.DirectorySeparatorChar}..{Path.DirectorySeparatorChar}pacts{Path.DirectorySeparatorChar}" }).ServiceConsumer("ConsumerService") .HasPactWith("ProviderApi");

[neilcampbell]

@steve-westwood Woops forgot to update the defaults in the PactConfig. Just pushed the change, which will be available in the 2.0.15-beta. You should be able to just use the default log and pact directory, and it should work.

[steve-westwood]

I can confirm the config defaults work, but the problem still persists if you enter any relative paths. I'll use the defaults for now. Thanks!

[neilcampbell]

@steve-westwood Yeah that is correct. The issue is with your test runner, it's using your AppData for it's build directory. All we can safely do is provide a sensible default that works, if that get overridden then it's up to user to make sure it goes where they want it.