Is it possible to take this aprroach with latest tooling 1.0.0-preview3-004056

[richardjharding]

Hi,

I'm trying to get Specflow working with VS Code and .Net core targeting net461 hoping you might have tried this already!

But I'm struggling to get the feature code behind .cs to generate?

I've added in the specflow targets but was not sure your approach could be adapted?

After importing the targets I get the error below - assuming this must be .net core mismatch?

   "C:\temp\canopyTest\canopyTest.csproj" (Build target) (1) ->
   (UpdateFeatureFilesInProject target) ->
     C:\Users\richard\.nuget\packages\SpecFlow\2.2.0-preview20161020\tools\TechTalk.SpecFlow.targets(47,5): error MSB4061: The "GenerateAll" task could not be instantiated from "C:\Users\richard\.nuget\packages\SpecFlow\2.2.0-preview20161020\tools\specflow.exe". \r [C:\temp\canopyTest\canopyTest.csproj]
   C:\Users\richard\.nuget\packages\SpecFlow\2.2.0-preview20161020\tools\TechTalk.SpecFlow.targets(47,5): error MSB4061: System.TypeLoadException: Could not load type 'System.MarshalByRefObject' from assembly 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e'.\r [C:\temp\canopyTest\canopyTest.csproj]
   C:\Users\richard\.nuget\packages\SpecFlow\2.2.0-preview20161020\tools\TechTalk.SpecFlow.targets(47,5): error MSB4061:    at Microsoft.Build.Utilities.Task..ctor()\r [C:\temp\canopyTest\canopyTest.csproj]
   C:\Users\richard\.nuget\packages\SpecFlow\2.2.0-preview20161020\tools\TechTalk.SpecFlow.targets(47,5): error MSB4061:    at TechTalk.SpecFlow.Tools.MsBuild.GenerateAll..ctor() [C:\temp\canopyTest\canopyTest.csproj]
     C:\Users\richard\.nuget\packages\SpecFlow\2.2.0-preview20161020\tools\TechTalk.SpecFlow.targets(47,5): error MSB4060: The "GenerateAll" task has been declared or used incorrectly, or failed during construction. Check the spelling of the task name and the assembly name. [C:\temp\canopyTest\canopyTest.csproj]

[richardjharding]

ok so I now see that this is not compatible with the latest tooling as Fixer.cs is built to look for .xproj which no longer exists

My goal is to get feature code behind generating for a core 461 project using Vs Code

But before I tried this package I had tried importing the specflow targets into the new csproj but this results in the error I posted above - sorry for the confusion

Any ideas on how I could get this working - do you think this package has a very short lifetime now the new msbuild tooling is out or will it still be needed going forward?

[erik-inkapool]

Hey Richard, thanks for reporting this.

I believe you're correct in that this is related to the different tooling and lack of xproj in the new variant.

A basic fix would be to switch xproj with csproj as I believe it's only used for it's file name. Finding out the test runner will also be different as project.json no longer exists.

Documentation will also need an overhaul.

I will very likely have some time to look into this next week. How do we feel about abandoning project.json as Microsoft have done? Should we have different branches for different tooling?

[richardjharding]

I thought I would try and make that change but I cant get this to build -in preparation I ran
dotnet migrate to convert to csproj
dotnet restore
but dotnet build fails with

error : RuntimeIdentifier must be set for .NETFramework executables

even adding win7-x86 to csproj as runtime identifier didn't fix so a bit stuck

If I can get it to build then I'll try and make the change and test

As to whether another branch not sure - depends how long this project will survive I guess that now msbuild type project is out then it might not be long before specflow supports core and the msbuild targets could be used to generate the feature code behind files

[erik-inkapool]

Great that you want to help with this!

We have no global.json in this solution what I can find. Perhaps that is the issue as dotnet will try to build with latest tooling if installed.

Since I am on vacation I can't actually test this but I found an article on global.json while googling, perhaps that may help.

Stajs have stated that this project isn't really supposed to stick around so you're right in that tooling branches may not be important. Old releases are still functioning fine for tooling that won't be updated so in my opinion we can probably stick to master. Stajs will decide that anyways.

Looking forward to a pull request if you get it building, that would be so awesome!

[stajs]

Thanks for the report. I haven't tried the latest tooling yet, but I'm happy to take a PR for it. I'm okay with not branching. People who don't have the latest tooling (including myself) can stick on the current version in the meantime.

I probably won't have a chance to have a look until the tooling settles down a bit and we upgrade our work solutions, so if you want to have a crack at it yourself, feel free.

Good point about the lack of global.json. There is one in the sample, but not for the main solution.

The search for the .xproj is just for generating a fake .csproj with the same name. Now it's fully .csproj my first thought is that whole code path is redundant. However you'll have to check that SpecFlow no longer needs to be using ToolsVersion for VS2013. If so, might still have to generate a fake secondary .csproj.

[smudge202]

I believe tools version 14 maps to VS2015 by the way, 15 to 2017, etc.

The issue here will be that the implicit/convention based xml reduction introduced to try and placate project.json lovers is going to leave standard SpecFlow looking for xml that no longer exists explicitly in the csproj. I suspect you may be able to get the normal SpecFlow running by making some of the implicit/hidden xml, explicit again.

I can't install the tooling to help out however. Installing 2017 will replace 2015's tooling and generally c*ck everything up for our projects.

[stajs]

I believe tools version 14 maps to VS2015 by the way, 15 to 2017, etc.

Hah, yes right you are. At some point back in the DNX days I had to use the VS2013 tools version. It looks like it was SpecFlow pre-v2.0 and since updating to v2.0 the comment wasn't changed/removed.

The issue here will be that the implicit/convention based xml reduction...

Yes. I don't want to force the addition of XML nodes in to the slimmed down implicit .csproj just for the purposes of this tool, so I'd lean towards still generating a secondary fake .csproj for this purpose.

I can't install the tooling to help out...

I'm in the same boat ATM.

[erik-am]

I bumped into the same issue today, that it could not find .xproj. Would be awesome if this worked with the latest tooling! 👍

[richardjharding]

Ok so I have the tooling and can build the Specflow.netcore project - but struggling to test I want to be able to run the command that the test projects run eg

dotnet SpecFlow.NetCore

After project migration this is traslated to

<Target Name="PrecompileScript" BeforeTargets="BeforeBuild"> <Exec Command="dotnet SpecFlow.NetCore" /> </Target>

Currently thats using the nuget in my global packages folder/cache

How do I get it to use my modified version - do I need to publish or package the Specflow.NetCore project and reference it somehow?

[erik-inkapool]

Hey Richard, nice that you've gotten this far. My method, while imperfect, is to add a nuget local package source pointing at the build dir of the specflow.netcore project. Heres how to do that. It usually allows changing package version a lot for me as nuget keeps caching the version. If you guys have a better way I'm all ears.

[richardjharding]

great I'll try that - I did publish the project which did create an rc7 version in my global nuget packages folder (for me thats at C:\Users\richa.nuget\packages\SpecFlow.NetCore\1.0.0-rc7)

In the test project the new csproj as this entry

<ItemGroup> <DotNetCliToolReference Include="SpecFlow.NetCore" Version="1.0.0-rc7" /> </ItemGroup>

after migrating the proj json it was rc6 I updated to 7 after publishing my changes - I simply changed the references to ".xproj" to ".csproj" but when I build the test project I still get an error - indicating the old version is still used - if I delete the rc6 from my packages folder its restored in build - but I can't yet see a reference to rc6 anywhere

I'll keep trying :)

[richardjharding]

ok managed to get my code to use the local modified code by following this https://github.com/dotnet/cli/issues/5189

now as expected its complaining about not being able to find project.json so I'll try and work through the issues and update here

[richardjharding]

So it looks like it was using project.json to determine which test runner was being used - this is now inferred from the package references it seems - http://www.natemcmaster.com/blog/2017/01/19/project-json-to-csproj/

[richardjharding]

So some success - after hardcoding GetProjectJsonTestRunner in AppConfig.cs I was able to build with VS2017 and VSCODE and have the specflow code behind files generate for at least the MSTest test project - I'll work on updating GetProjectJsonTestRunner to use the information in the new csproj file to determine the test framework

Incidentally I did attempt to add in the generated elements to the new core csproj but Specflow.exe complained about some namespaces and version attributes on package references so it looks like we'll still need the fake csproj file for time being

[stajs]

Sounds like some great progress! I've been away from the computer for a few days and will be for a few more but wanted to give some words of encouragement. Keep it up! On the subject of global.json, I've been meaning to revisit the sample. I've used the global.json in other solutions to reference relative paths to include projects from outside the solution folder. This works for libraries, not sure about tools.

[richardjharding]

Ok I think I have this working see pr #43

If you want to test you'll need to pack the tool nupkg to a local folder and add a nuget.config to the sample projects as per https://github.com/dotnet/cli/issues/5189

[stajs]

That PR is merged now, but I'll leave this open until such time as I can get a NuGet package up.

[richardjharding]

I can share a copy of nupkg via one drive or similar?

[stajs]

Yes, please!

[richardjharding]

No worries - have emailed link to your gmail address - hope thats ok Richard

[stajs]

Thanks @richardjharding ❤️ , your work is up on NuGet now!