Projects do not run if MonoGame is not present in 2.1.0

[Chris3606]

v2.1.0 introduced a bug where projects using GoRogue will not run if MonoGame is not also present in the project. This will be immediately fixed in 2.1.1.

[masonwheeler]

Are you sure this is fixed? I just checked out the latest commit, built GoRogue, then tried to build a project that depends on GoRogue, and it failed to build because MonoGame wasn't available. (It seems to error out somewhere in code related to Euclidean distance calculations, if that helps.)

[Chris3606]

I'll double check, but as of 2.1.1, it should work when the GoRogue package is installed via NuGet. When it is not, and instead the DLLs are manually referenced, there are still some issues -- I'm working on a build to account for this that should be done within a week or less. In the meantime, if the dll-specific issue is being a pain, I'll compile a quick build manually that fixes it.

If it's an issue on NuGet in 2.1.1, though, I can't seem to replicate that on my end currently, I'll try a fresh project and get back to you to double check though.

[Chris3606]

Ahh, I just realized you said "checked out the latest commit and built",meaning it was a DLL reference, so yes the problem is still present. Unfortunately, my development time is limited this weekend, so I can't implement the permanent fix (which will amount to reorganizing some project internals so it's easy to create a minimal build that doesn't have this issue, and will have all the same functionality of gorogue minus the parts that define implicit conversions/operators to monogame types). However, in the mean-time, I"ll real quick create a branch on my repository with the appropriate modifications made (which I should be able to do right now), so you can clone and build from that. I"ll likely remove this branch once I get the permanent fix in place.

Thanks!

[masonwheeler]

Awesome, thanks!

[Chris3606]

Ok, there should now be a master-minimal branch. if you check that one out, build, and add your reference, everything should work. I'll keep that branch in sync with master until I get the permanent fix in place that will create a project that can do this build automatically.

Please feel free to let me know if you encounter any other issues :D

[Chris3606]

Hey, @masonwheeler what IDE/compiler were you using when it complained at you? I'm all of a sudden having trouble replicating this, not sure why...

[masonwheeler]

I'm using the Boo compiler, and the error is coming from a line that invokes Distance.EUCLIDEAN.Calculate(Coord, Coord).

If I had to guess, I'd say that this is the first time the compiler has run across the Coord type in this compilation and it's trying to load the metadata for it, finding the MonoPoint operators, trying to load the metadata for them, and choking when the assembly can't be found.

[Chris3606]

And this is the case on 2.1.1, not 2.1.0? I would only expect this behavior on 2.1.0. The only potential issue I've been able to replicate with 2.1.1 is an issue where adding the assembly via dll produces a compile time error, and this only seems to happen on compilers that don't properly support PrivateAsset tags on projects (Unity, possibly Boo).

[Chris3606]

Reopening until we verify a solution

[masonwheeler]

Yeah, I just looked up PrivateAssets and it looks like something fairly recent. And even after reading the description I'm not really sure what it does, or how another compiler would be aware of it in dependencies; it looks like more of a NuGet package thing.

[Chris3606]

It was formally added to msbuild standard, but it is fairly recent. Even if you add a DLL manually, it seems to work in a Visual Studio project, so I think it's something the compiler just has to know how to deal with. I didn't realize it would be an issue with things like Unity and Boo when I initially added the operators, and since I've got multiple users I know use those operators, it's not something I want to remove in 2.x.

I think what I'll end up doing, is simply adding build configurations to the GoRogue.csproj that automatically disable all the problem-causing portions. It's actually just the mono stuff itself, so it doesnt' lose any functionality when you're not using monogame (and if you are, it's never a problem in the first place). Then, i'll simply distribute a DLL in the Releases section of github that's the GoRogue_Minimal.dll or something, that is this build. Similarly, if you build yourself, you could just select this build config and it would all work.

I think the proper solution will be to replace the operators with something else in 3.0. One possibility is replace them with extension methods -- replace implicit conversion to MonoPoint with a Coord extension function MonoPoint ToMonoPoint(this Coord self), similarly replace operator+(Coord c, Point p) with Coord extension function Coord Add(this Coord self, MonoPoint p).

This way, the monogame parts could be pulled out into a separate package GoRogue.MonoGame, and it's not an issue. The addition of the extension function quirks (you need the proper using statement to see them) is annoying but the functionality would be there.

[Chris3606]

Ok, so on my develop branch (above commit), I've pushed code that enables the additional build configs. Any chance you could try to compile and put the dll in your project? You should be able to use either Release Minimal Dependencies or Debug Minimal Dependencies, both should work in your Boo project.

[masonwheeler]

OK, just rebuilt it, and I can confirm that it builds properly now. Thanks!

[Chris3606]

Sweet! As soon as I release this in 2.1.2, I'll remove the master-minimal branch, and this should work as a solution (until 3.0 which will implement a different solution).