The ci.yml could benefit from having separate jobs for windows and linux. Add windows specific tools for windows build such as Visual Studio Tests which may help with cross-compatibility. Currently testing a modified workflow.

Attempting the following:

• Add another job specifically for windows
• Add vstest.exe to run unit tests and results should upload as artifact.
• Test and verify.

Related to #629

Also could be linked to the following:
#666
#689
#684

Related to #629

See if architecture x64 vs x86 should be conditionally targeted for .net45

What do you mean by this? I think we only really need tests for x64 these days...

Add nuget statement --> nuget restore KRPC.sln

In my experience, it is best to avoid having automated builds/tests rely on external services/websites. If nuget was temporarily down, then our workflows would fail. This can be avoided by having the dependencies cached.

For example, the Linux build and test uses a docker image (hosted by the GitHub container registry) that already has all the dependencies embedded in it.

Only more of a fail safe and not observed to be an issue. It was based on a suggestion I read in documentation. It likely does not apply for our purposes. Can remove that. I was tweaking and testing capabilities of the workflow. Maybe not appropriate to add an issue for that? For the building portion I found that to be unreliable and troublesome. I had not updated this yet. I think I should just add some of these as project actions for tracking and not use the issue feature until I have gathered more information.

I've removed the old Travis CI scripts. It included this script which seems relevant to this:
https://github.com/krpc/krpc/blob/4687066a28a65b22820463b897ef96b4eba2fe36/tools/travis-ci/script-windows.sh

That's how we used to do C++ client builds for Windows.

That Travis script was very "new" and not necessarily the best way to do things. It was just added to do a Windows build of the C++ client library. It didn't build any of the C#. So I wouldn't necessarily copy the way it works. Just thought it was relevant.

Travis is now completely gone. The #689 pull request has been merged which transitions us to proper GitHub actions workflows.

I think you're actually good to go for adding windows build/test jobs to it, if you want? Or I'm happy to do it if you like. Quite familiar with the GitHub actions stuff now!

Did you mention you had some work in progress changes?

I had not taken the time to look at the Travis scripts and I see that it was doing all the heavy lifting. That would make sense if the issues arose from removing Travis CI. So I would think then we need to focus on transferring that to GitHub CI before anything else. It should have no issue doing the same. On that note, I should probably not bother with the csproj stuff until Travis/GitHub transition is complete. I will hold off. Also, the Travis script does look like it addresses both 32 and 64 bit architecture.

Hopefully this clears up some of the confusion between the various tools/services:

• bazel is the build system that the project uses to coordinate everything
  • It's a bit like cmake, if you've heard of that.
  • I chose it because it can build any language. Which we need because we don't just have C# code!
  • Internally, it uses the actual compilers for the various languages (e.g. msbuild for C#, gcc for C++, javac for java etc.)
  • Currently only tested on Linux.
• Travis CI is the old testing service that we used
  • It's now replaced by GitHub actions. (GitHub actions didn't exist when I started the project).
• GitHub actions is now set up to:
  • Run the build and tests whenever a pull request is submitted.
  • Launch separate jobs for each part of the project, to do builds and run tests
  • Uses a docker image to set up its build environment
  • Does the actual building and testing using bazel (just like you would on a local linux machine)

And yes, bazel is a very very deep rabbit hole... Ideally we should get bazel working on Windows at some point in the future, but I think this is low priority at the moment. For now, we just want to allow people to build the C# part of the project (using the solution file) on Windows (which we can do with a batch script + VisualStudio/vscode/whatever IDE).

Being able to build the C# code on Windows is all you need to be able to update the code running in the game.

The OS check seemed the best way to trigger which script to run, not sure exactly what happens if it is set to run both before the solution can build. Stuff I have never really worried about before.

Just let the programmer choose which script to run. It's not a difficult choice ;) Automating OS detection sounds like a headache that we don't want to deal with... So on windows, you run setup.bat then open the solution file. Simple.

Oh I see. So it was not handling C# portion. Sorry for the confusion. A little confused between exactly what bazel and what travis was handling. I read that you can also build in windows with bazel and I played with it a little. Did not get very far. I don't want to get too hung up on all of that. My interest was piqued. And gotcha on the .bat script. I can leave bash to you if you want you because you can test it directly in your dev environment. The OS check seemed the best way to trigger which script to run, not sure exactly what happens if it is set to run both before the solution can build. Stuff I have never really worried about before.

Thanks for taking the time to break that down. It was helpful! I'm getting there.

Note: Windows and Linux build and tests are set up in the krpc2 repository. I will set up the same for this repository at some point.