Monogame: Generate PCL Assemblies using Piranha

[tomspilman]

We want to generate the following PCL assemblies for MonoGame:

• MonoGame.Framework.Portable
• MonoGame.Framework.Content.Pipeline.Portable

This involves the following tasks:

• Add the latest Piranha executable to the dependencies submodule.
• Modify the default.build script to generate the PCL assemblies.
• Add NuGet packages for each.
• Add the new PCL assemblies to the Windows/Mac/Linux installers.

As long as the new PCL assemblies are placed into the MonoGame.Framework\bin\Portable and MonoGame.Framework.Content.Pipeline\bin\Portable folders the build server will automatically gather it into the build artifacts and copy them around for the various build steps.

[dsaf]

Thank you!

What about MonoGame.Framework.Core.dll?

https://github.com/mono/MonoGame/issues/3405#issuecomment-119281380

The next logical step if we wanted a pure true PCL would be a MonoGame.Framework.Core.dll which contains only types that are 100% PCL compatible and have no #ifdef junk. This should include all the core math types, all the enums, pure interfaces, etc. The more we put in there the better.

The MonoGame.Framework.dll would remain as platform specific stuff. If we want to support a bait-and-switch PCL there we still could.

https://github.com/mono/MonoGame/pull/4339

[hach-que]

A better way of doing this would be to use AdditionalProjectTransforms so that it occurs for developers as well, and so there isn't more build server only stuff which causes PRs to fail.

There's an example here: https://protobuild.readthedocs.org/en/latest/customizing_protobuild.html#specifying-additional-transforms

[tomspilman]

What about MonoGame.Framework.Core.dll ?

That is a separate issue... lets discuss that somewhere else. There are a dozen different issues that cover it that can be re-opened.

[tomspilman]

so that it occurs for developers as well

I'll consider it... depends on how the Piranha processing works.

so there isn't more build server only stuff which causes PRs to fail

None of this would require build server changes at all.

[craftworkgames]

Great :+1: This will make it a little easier to build MonoGame.Extended. We are currently building the PCL manually and storing it in our repo. It's not a _huge_ issue since we only need to build it every so often but it would be nice to just reference an official NuGet package source.

The real benefit could be that it will open up more opportunities for other 3rd party libraries like ours. Building against a PCL makes a lot of things easier and figuring out how to do that is not trivial.

[tomspilman]

Working on this now... will have it committed by tomorrow if things go well.

[tomspilman]

@craftworkgames - The new PCL for framework and pipeline are now on our development nuget feed. It would be good for you to test it and be sure it works for you.

The next step is including the PCL in the installers for people that don't use NuGet.

[craftworkgames]

@tomspilman Is this the package feed you're talking about?

http://teamcity.monogame.net/guestAuth/app/nuget/v1/FeedService.svc/

I finally got around to testing this and I realized I wasn't sure what development nuget feed you're talking about. As far as I can tell there's no packages on the above feed.

Get-Package -ListAvailable -Source http://teamcity.monogame.net/guestAuth/app/nuget/v1/FeedService.svc/
No packages found in the current package source.

[tomspilman]

@craftworkgames - Looks like I inadvertently broke the permissions which kept the packages out of the feed. Try it now... it should work.

[craftworkgames]

Still not working. I'm running the Get-Package command as above from the Packager Manager Console in Visual Studio and it returns with "No packages found".

Have I missed something? What happens at your end if you run that command?

[dsaf]

https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard

[eatdrinksleepcode]

What is the current status of this effort? Really wanting to use a PCL for sharing my presentation code between mobile apps.

[SimonDarksideJ]

There is a NuGet for the PCL on the development NuGet, although I haven't tested myself as I'm busy with other tasks at the mo.

[SimonDarksideJ]

Don't forget to use the "Include Pre-Release" option when looking at the dev NuGet source @craftworkgames or you won't see anything (nearly tripped me up as well that 💃 )

[tomspilman]

There is a NuGet for the PCL on the development NuGet,

There is... specifically a PCL bait-and-switch assembly. We've used it on a few projects and it seems to work great.

[craftworkgames]

MonoGame.Extended relies heavily on the PCL bait-and-switch assembly. It's pretty much the foundation of the library. We've been using it for ages with no issues.

[SimonDarksideJ]

So @craftworkgames is the PCL enough, or do you feel there is still a need for the "Core" style solution?
Which splits off all the "true" multiple platform code out of the MonoGame platforms in to one library (mostly containing all the structs and core libraries)

[dsaf]

IMHO a temporary workaround is not a proper solution even if it works. Unless of course a rock-solid absolute feature parity across all supported platforms is the long-term strategy. Though I am not shipping anything real at the moment, so who am I to judge :).

[SimonDarksideJ]

Not sure I'd call a "Bait and switch" solution a temporary work-around. It's simply A pattern that can be used. Are more needed?
The question, is it enough?

[dsaf]

I guess "temporary work-around" is not the best term, apologies. You are right about patterns.

How likely is it that at some stage there will be a piece of official MonoGame functionality that will only be available to a specific few platforms?

[SimonDarksideJ]

We already have this. Most platforms have certain parts of the framework that only work on that platform. Mostly in the graphics area.
This causes a large amount of #IF's in the project. PCL's break through this, either via "Bait and Switch" or having a "Core" true PCL and just having platform variants.

[dsaf]

Does it mean a choice between NotImplementedException and compile-time errors?

[SimonDarksideJ]

Depends on your implementation, again, what is preferred.
A better approach is what MS have done with UWP. You have one API layout, each "platform" implements stubs for all capabilities and true implementations where those functions actually do something.

You also have a test to validate / tell the developer which platform capabilities are available so they can decide. Ultimately though, no code should "fail" or "Crash" it just won't do anything if a certain platform doesn't support it (e.g. Gamepads on a mobile phone :D)

[dsaf]

@DDReaper well both iOS and Android have gamepads :), but I get your point - there is no touch on PS4. Your explanation makes sense - thank you very much.

[craftworkgames]

So @craftworkgames is the PCL enough, or do you feel there is still a need for the "Core" style solution? Which splits off all the "true" multiple platform code out of the MonoGame platforms in to one library (mostly containing all the structs and core libraries)

Do you mean, is the bait-and-switch PCL enough? For MonoGame.Extended it's fine. Once people understand how it works there's no problem.

The "core" style solution could come in handy when building 3rd party libraries that _only_ need a few of the low level data types (e.g. Vector2, Vector3) but _don't_ need anything else.

A good example of this is the Farseer Physics engine. What they do is provide a small set of common data types. When they compile against MonoGame, the "real" MonoGame types are used instead. Referencing the full MonoGame bait-and-switch PCL is kind of overkill in this case, although, technically it doesn't really hurt anything.

That said, it's been a while since I've thought about this stuff and the bait-and-switch PCL works pretty well these days. I remember running into some issues around the MonoGame 3.4 => 3.5 release with strange version incompatibilities, but since then things have been pretty stable.

So in conclusion, I think the bait-and-switch PCL is fine.