I'm in the process of resurrecting a friend's toy game project. It ran on Windows using XNA, and I set out to port it to Linux using MonoGame. After a long series of bumps in the road (most of which turned out to be bugs in .NET that my friend's code "canceled out") I ended up with a working Linux port with several additional features. I had, along the way, carefully made sure that what little Windows- or Linux-specific behavior there was got cordoned off behind a runtime platform check.

Now, I want to deploy both a Windows and a Linux version, but I find that the MonoGame dependency is tied to the specific platform; MonoGame.Framework.Linux on Linux and MonoGame.Framework.Windows on Windows. The obvious solution is to have two projects, one for the Windows version and one for the Linux version... but this strikes me as silly and inelegant, as both assemblies will be bit-for-bit identical except for the MonoGame.Framework.* reference. Is there a better way to do this?

(There's going to be a Mac version as well, but I'm crossing one bridge at a time here.)

It has been suggested to remove the platform from the assembly names for other reasons...  we will probably do that.

Still I don't recommend that path.

Moving forward MonoGame will support even more platform specific content formats than it does now.  For example right now content built for Windows 8 Store apps is incompatible with Linux or iOS.

Maybe you get lucky and Linux and Windows support all the same formats...  but i wouldn't count on it.  The idea that one build will work everywhere is not where MonoGame is heading.

  - Tom

The idea is that you write your code once, but you compile and build for each platform to get the best out of it.

Now theoretically in your own fork, you could just using 1 set of assemblies for all *desktop* platforms, but that does mean using a common denominator between them. As long as you are happy with that, go for it.

D.