[Dev] 0.1 "Babylon" Progress Thread

It needs msbuild and maybe some of the tooling, not the CLR. I'm a bit confused about what exactly the "Godot SDK" is, too, but I know we don't import the Godot namespace, and although the SDK is gettable with nuget I have been so far unsuccessful in trying to use any of Godot from outside Godot. Not that we need to, really...I just occasionally try to figure out if using xUnit is even possible Godot Mono code.

I'm not getting that. I'm wondering if that has to do with whatever you mean by going back and forth between dotnet and mono.

dotnet 5 has System.Text.Json "built in" whereas in mono 472 it needs to be added as a nuget package, but that's already in the csproj file, so I am not clear on why you would be seeing those errors.

Building with Godot should be performing a `nuget restore` before building which should fetch the needed nuget packages. I guess you can try that manually. The mono and dotnet tools put their build objects in different places I think, so if you are switching back and forth you'd need to "dotnet restore" for dotnet or "nuget restore" for mono, but I think the Godot build should be doing that for you.

Maybe try hitting that "build" button instead of build project? Quintillus found that it seems to do something extra over the build project or build scene buttons.

 

I tried doing the restore manually but that didn't work. I also tried adding the System.Text.Json package to the C7 project but that didn't work either. I was hoping adding the package manually (with "dotnet add...") would download a DLL or something but it all it did was add a line to the csproj file.

I guess the problem is that the Mono runtime that's part of Godot can't find packages that are part of .NET Core. I don't know why it can't install the missing package automatically, maybe it relies on the build tool to do that but that's not happening since the build tool thinks the package is already available as a built-in. I'll try installing System.Text.Json inside Godot's bundled Mono runtime (the "Godot SDK" ?). I searched the GodotSharp folder and as expected there's no System.Text.Json.dll, though there are Newtonsoft.Json, System.Runtime.Serialization.Json, System.Json, and System.Json.Microsoft DLLs.

Edit: Another thing I'll try is pointing Godot to the .NET Core libraries, after all System.Text.Json.dll must be somewhere on my system. Hopefully they're all compatible.

Tried it, no change.

 

Ok I haven't been paying very close attention lately and didn't realize C7.csproj went to netstandard2.0 . I'm a bit surprised that works, but I guess it kinda makes sense. I thought our ideal was to converge on net472 for everything, though, and the netstandard2.0 was my own personal kludge because I didn't know how to make utility console apps with mono. (Which I think I finally have figured out and have a PR #65 to make _Console/BuildDevSave use mono on the console.)

Oh, and I just remembered that xUnit does NOT work with netstandard2.0 . Which meshes with my next point that I have yet to figure out how code with `using Godot` can be unit tested, but the non-Godot-tied libraries should be testable with xUnit if we change them to net472 (or anything but one of the netstandards). And the load/save functions should be testable this way right now.

 

Incidentally, I should be sure to point out I am pretty convinced that Flintlock's System.Text.Json errors and the rest of us crashing on loading the json save are two entirely different issues, even if they seem to present in a similar way. Maybe the VS changes are causing both, but they are two different problem paths.

I'm poking in an `xUnit` branch now (not yet pushed) where I put everything as net472 (except Blast, the external library), and I'll see if the save read crashes without Godot which at this moment I'm presuming it will.

 

Ok, that's not what I expected, but I'll take it: Changing all (except Blast which is not ours) netstandard2.0 to net472 makes "new game" work for me. I just pushed the xUnit branch. Try the all-net472 tag for the actual commit as I might poke at actual unit testing later.

Tagging @Quintillus and @Flintlock as you may be looking at this now.

 

I just checkout Development again and changed *only* C7.csproj to net472. That also works for me. (I'm not going to push that or make a branch; just letting you know.)

The main project shouldn't be netstandard, but libraries can be to share between other projects, generally speaking. I don't really understand what's going on here, but it sort of meshes with my vague understanding of .NET so it makes enough sense to me that the main project should not be a netstandard.

I am personally ready to fully commit to making everything net472, and I feel like I caused all this confusion in the first place. But I don't have full VS and don't know what will work with it and what won't.

Edit: As a testing note, I think it would have taken an integration test and not just a unit test to catch this issue. On the other hand, having C7GameData, C7Engine, and the other libraries unit tested would have at least narrowed down the scope of the problem.

Edit 2: Oh, changing the C7 target framework is exactly what Quintillus' PR does. I reviewed/approved the PR but do not have VS to test against it.

 

When you make a new Godot Mono 3.4 project, it makes it net472, and I don't know what the impact of changing that would be. I figure our target version is tied to our Godot version which is providing the runtime.

Actually I guess I need to double-check that assertion as we created this project with a pre-3.4 Godot.... Yep, it still makes a new project with net472.

 

Surprisingly that FixC7SAVLoading branch fixes "new game" for me too. I didn't expect that, I thought the problem was due to differences between the Mono and .NET SDKs. Speaking of which, you guys never replied to my question about which one you are using. Am I correct in assuming you're all using the Mono SDK?



Edit:

This is good to know. I was planning to merge the PR in any day now, figuring you guys had had a chance to see it even though you never commented on it specifically.

 

I have both installed. I don't know what Godot is using. VSCode seems to be using external Mono for Intellisense.

I don't think the version installed matters; I think Godot just needs one of them for msbuild and maybe another tool or two. ... Huh, actually it seems to specifically reqire ".NET Core" which should be styled dotnetcore but is just dotnet as of v5.

https://docs.godotengine.org/en/stable/getting_started/scripting/c_sharp/c_sharp_basics.html

Edit: This adds a lot of possible confusion back into the console utility platform question. Whee.

Edit 2: If I'm reading this right, we're using dotnetcore v3.1 or dotnet v5 to compile code that is run by Mono emulating .NET Framework 4.7.2. Oh, and the csproj specifies Godot SDK. WTF Microsoft?

Edit 3: Ok, apparently ".NET Core" is the correct styling after all. Not sure if that changed or if I've always been wrong.

 

You can check which one Godot is set to use if you go into the editor settings then look at the "Builds" section, which is under "Mono" at the bottom of the list. "dotnet CLI" means it's using .NET Core and "MSBuild (Mono)" means it's using Mono SDK.

 

Mine says "MSBuild (Mono)" which conflicts with what the site I linked earlier says.

But the msbuild on my path does say it's for Mono which at least comforts me a little. So I guess I'm using Mono?

 

I just installed Visual Studio 2019 on Windows to see what's up. I'm not sure what @Lanzelot is doing with it, but if I choose build it succeeds with 11 warnings. If I go into Godot and build from there it still works. This is with the latest merge of PR#66 a few minutes ago with net472 in the csproj file.

This is a new install of VS 2019 community with a bunch of the .NET stuff checked for install including the .NET 4.7.2 SDK.