Features/6 dnx compatibility

[smudge202]

Backed out some changes to ReadMe as per feedback on #5.
Backed out solution structure changes as per feedback on #5.

Switched TFM to net40 to support dnx451 as per #6. This gives us much a much wider compatibility than is required, but I don't believe that will be an issue.

[smudge202]

Note, I switched the version in the project.json to alpha9 in order to test this locally. Let me know if you want the version reverted.

Also, it isn't necessary (or a particularly good idea) to have project.lock.json in source control. It's as likely to cause conflicts as a csproj when collaborating so I dropped it out and appended a gitignore entry for it. Again, let me know if it should be backed out.

[stajs]

Sorry, looks like I did conflict you when manually backing out those changes 😞

Looks good (yes to alpha9 and removing lock file). I'll get the new version up on NuGet for testing, and check that the existing sample still works. Once that's up, do you mind adding a sample for dnx451?

[stajs]

I mean, once you've fixed the conflict (sorry).

[smudge202]

Sure. So, for reference, I did the following to test this local (incase it helps you).

First, build the solution including the PR changes to produce output (or quickly replicate the change to project.json if that's easier).

In any solution that currently references SpecFlow.Dnx version 1.0.0-alpha8:

1. Add a Nuget.config add the root level of the solution.
2. Add the following configuration to the file:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <add key="local" value="D:\\\\Projects\\Resources\SpecFlow.Dnx\\src\\artifacts\\bin\\SpecFlow.Dnx\\Debug\\" />
    <add key="api.nuget.org" value="https://api.nuget.org/v3/index.json" />
  </packageSources>
</configuration>

Note, replace the long path in there to point to wherever you store SpecFlow.Dnx but making sure to keep the escaped backslashes.

1. Simply reference 1.0.0-alpha9 in the project consuming SpecFlow.Dnx.

The above sounds longwinded but in practice takes less than a minute to achieve and is very handy for testing packages pre-publication and without running a full private NuGet repo.

Anyway, I'll see about these merge conflicts and takes yours for the most part. I can add a complete example to the samples directory if you want, but would it be easier to simply add the dnx451 targets to the existing projects? The TFM's would actually make one another redundant but it does prove that SpecFlow.Dnx works in both cases?

[smudge202]

I've merged those changes, just sorting samples now.

[stajs]

Good idea on the Nuget.config. I was manually doing an Add > Existing Project... in VS.

Hmm, regarding the samples... my original thoughts process was it would be better to have explicit examples per framework, but can be convinced otherwise if you think it's easier.

[smudge202]

I'll create a new PR for samples. The difficulty of course (without using aforementioned nuget.config trick) is that I won't be able to reference alpha9 until it's published without it. I'll see if I can get relative local paths working so that I could add a samples nuget.config that looks at the build output? It would assume that the core project was built before running samples or that the local build is available on nuget.

[stajs]

Gah, I'm suffering some problems with local testing against my consuming solution :/

I'm not sure net40 is working for me.

I'm about to go incommunicado for a while, sorry, work calls and then weekend plans. I'll look to pick up in a couple of days (unless I can squeeze in some time in the weekend).

[smudge202]

Try out the samples PR. Should work and show it off for you?

[stajs]

Okay, I've got a little bit of time before the weekend, I'll see if I can get this out. I'm on a different machine now and not experiencing the same problem that I had before when testing (whatever it was), so I'll assume it's all good and push out a new NuGet. (Feel like there should be a 💩 joke there...)

I'll continue the discussion in the open issue/PR.