To quote the how-to (which is quite not easy to find):
The first step in generating a PCL is to install the required tools. They should come by default with Visual Studio
That’s not correct, on windows at least, with VS2013 Express (this may comes from there), building it doesn’t work, I’ve go error with the ‘=>’ operator, VS is unable to process them and report syntax errors, missing the semi-colon at the end of the line where the operator is.
Example: DefaultViewportAdapter source:
line: public override int VirtualWidth => _graphicsDevice.Viewport.Width;
The build target I’ve got are .net 4 (weird) set by default, and Silverlight 5.
I’ve also tried with .net 4.5.1 just in case, same errors (total: 106 errors reported for the MG.Ex project alone)
Tried with provided MG reference and my own build from dev snapshot, probably not with/for WindowsGL (but I don’t get missing/unknown namespace error).
I don’t remember seeing anything regarding C# 6.0 used there in the build wiki page.
By the way, I would like to ask what is the benefits of creating a PCL ? It looks like to be more complicated than a regular library and for which benefit ? Only compile it once ? Is there any performance cost (as it is made for game, it’s quite a critical concern) ?
As MG itself is platform specific, why not doing the same, kind of “hooking” the build process with MG for easier building after all ?
We only just updated the project to C# 6.0 fairly recently.
The main benefit of using a PCL is that it’s exactly the same code running on ALL platforms. This has some advantages that shouldn’t be underestimated. It also makes the library a LOT easier to develop. We can write code and be 99% confident it will work on all supported platforms out of the box.
There was an initial learning curve to properly setup the PCL code structure but other than that it hasn’t been complicated at all. PCL’s are officially supported by the latest versions of Visual Studio and they also work with Xamarin Studio and other popular C# IDE’s. There really hasn’t been any issues.
Not that I’m aware of.
MonoGame has it’s reason’s for having multiple platform specific DLL’s. None of which apply to MonoGame.Extended. You can reference the one MonoGame.Extended PCL with any of the platform specific MG DLL’s and everything just works.
I don’t really know what you mean by “hooking” the build process but trying to follow MG’s release process would drive me insane. I don’t have the capability or desire to produce and test different platform specific DLL’s for no good reason.
I believe the only reason you’re seeing anything complicated is because you’re trying to use VS2013.
Upgrade to VS2015 and everything will just work. You don’t need to follow any instructions. Just grab the source and it will compile out of the box. I promise.
ends up too long for the Package Manager to actually install - my build folder is sitting in the default Visual Studio 2015/Projects folder. I’ve had to move it to somewhere else to actually build it.
Yeah. It’s unfortunate the default folder is in such an inconvenient place. It always surprised me that Microsoft did this knowing they have a fairly short path length limitation. I guess the other issue is the way NuGet names the folders when it downloads packages.
I don’t think there’s much we can do about this. Moving your project to a shorter path seems like the most sensible thing to do.
Well as a result of a suggestion here, I ended up downloading the latest development build (I was on 3.4) just as 3.5 was released so I actually have Version 3.6.02 of the Pipeline - are you saying I should uninstall and revert back?
I’ve uninstalled 3.6 and installed 3.5. I also removed the NuGet MonoGame references from the Samples project and added in the installed 3.5 version. I then rebuilt the project - which complained as it was targeting vanilla .NET 4 rather than 4.5.x. It now builds and runs.
It’s too late in the evening here and I’ve consumed a little too much Vino Tinto to work out the actual issue but never mind…