mpekurny
commented
4 days ago After digging a bit more on how Java works, I was incorrect on how the Java works and I am not sure this is the best route for the .NET so I am going to close this for now, while I continue to look into it
Not really an issue, but a suggestion.
In comparing the .NET plugin with Java, Java has a single executable written in Go that launches the Java app and the plugin includes a set of jar files that is included in the Java app when built that provides the app with the framework to run the Gauge tests. For .NET, the plugin launches the actual .NET application from the plugin and then dynamically loads the user's library to pull in the steps and code to run. This relies on a library between that manages the communication between the app and the user's code and often causes problems if the library in the plugin doesn't match the library in the user's code. I am hoping this isn't news to anyone, but wanted to make sure we were on the same page.
I am suggesting that we move the .NET app to be more like the Java app. Actually eventually exactly like the Java app. Unfortunately, with the Nuget package manager the library will still need to be a separate build/deployable, but to move the plugin code to the library and replace the plugin with a simple Go executable that builds the user's code, including the library that sets up the grpc server and then runs it. This would eliminate the problems associated with the the sync issues between the plugin and library. It would remove a lot of the clunkiness in dealing with data objects that somewhat straddle both the user's code and the server code.
I am certainly willing to work on this, in chunks to avoid ultra huge PRs like the one for supporting async, but long term, I think this change would make the .NET plugin far more stable and less prone to blowing up randomly.
@chadlwilson @sriv