Problems Upgrading Project to 3.5

Nightmare-Games · June 22, 2016, 2:58am

I’ve just downloaded the newest version of Monogame (3.5) and I’m getting myriad errors from Visual Studio (which wasn’t true before the upgrade). I’m not sure what version I had prior, but suffice it to say it’s been a few years.

The original problem immediately after upgrading was errors of type "The type or namespace ‘Xna’ does not exist in the namespace ‘Microsoft’, invalidating all my using statements.

Realizing Xna had been removed as an assembly reference, I put it back in.

The result was then a slew of errors in the style of “The type exists in both Monogame and XNA” for about five different data types. A few people on StackOverflow pointed out that I no longer need the Xna reference in the project, but that doesn’t solve the original problem.

Removing the “using Microsoft.Xna” statements results in “type or namespace not found” errors for many types.

It’s also my understanding that I should not have a “using MonoGame.Framework” statement. Apparently I should have Microsoft.Xna as my using statements, but MonoGame as my assembly reference. Confusing.

A post on a different question led me to try changing the target framework for the project from “.NET Framework 4” to “.NET Framework 4.5”. That seems to fix the problem with Microsoft.XNA not being recognized, but this only generates new errors.

Error 2 The type or namespace name ‘Graphics’ does not exist in the namespace ‘Microsoft.Xna.Framework’ (are you missing an assembly reference?)

I’m now getting this for everything under the Microsoft.Xna.Framework umbrella, including Graphics, Input, Audio, Content, GamerServices, and so on.

Should I just start a brand new project and paste my old code into it? What am I doing wrong here?

Chuck_Esterbrook · June 22, 2016, 6:53am

At the end of your post, you asked what I had started thinking:

Start a fresh MonoGame 3.5 project
Verify that it compiles
Verify that it launches
Bring over chunks of your code and assets

Given that you’re not sure what your last version of MonoGame was, this may be the easiest path forward.

Alkher · June 23, 2016, 7:21am

Which version of VisualStudio do you use ?
Remove all references from nuget if you have used this to install your older version.
Uninstall all XNA references, and do a fresh install of monogame 3.5 as @Chuck_Esterbrook suggests.

Nightmare-Games · June 30, 2016, 11:28pm

Everything works now (almost). Unfortunately, this was not a quick fix. Here’s a list of everything I did to get this working:

Project -> Properties -> Target Framework:

This must be set to “.NET Framework 4.5”. I believe mine was 4.0 previously.

Using Statements

Keep all the “using Microsoft.Xna.Framework” statements. However, “Microsoft.Xna.Framework.GamerServices” has to go. This one is apparently no longer supported (and I’m not sure what I was using it for any longer). Trying to add “Microsoft.Xna.Framework” back in is also a bad idea.

I had the wrong assembly reference to Monogame.

This one is tricky, because the reference manager shows 14 of them, none of which say more than just “MonoGame.Framework” with a version number. Apparently they are not all the same. Hovering over the name shows different file paths. I still don’t know what the difference is between Windows, Windows8, and WindowsUniversal, but the one I actually needed was not even being listed in the search results. I had to browse to the actual file, which for regular windows desktop was under:
C:\Program Files (x86)\MonoGame\v3.0\Assemblies\Windows\MonoGame.Framework.dll

FileMode.Open no longer works.

This is part of System.IO, which seems to now be causing a conflict with Monogame. The solution is to use “Content.Load”, which is how XNA used to do it.

I was using FileMode.Open to load Texture2D’s, since old Monogame didn’t support compiling content. Ironically, finding out that this is now supported was my main reason for upgrading, but I didn’t think I’d be converting almost 400 sprites to the new format all in one shot. They all need to loaded into the new pipeline tool and compiled, added to the VS project, and then the actual loading code has to change.

Switching back to Content.Load invalidated some of the classes I’d written during the interim, since Monogame doesn’t seem to appreciate trying to use the GraphicsDevice from outside the main game class. These had to be heavily refactored as well.