6

MonoGame (a framework which basically brings XNA to Windows Phone 8) has all it's namespaces prefixed with Microsoft.Xna.Framework I believe to minimise the amount of code changes required when porting your XNA app to MonoGame.

My issue is, I wish to access the Microphone class, which, because has not been created in MonoGame yet, I have to utilize it from within in the official Microsoft XNA class, this requires taking out the explicit forced removal of the standard Microsoft.XNA.Framework.dll references within the .csproj that my MonoGame template has setup to avoid conflicts, which works great and now Microphone is accessible, but in doing so I have created ambiguity between a few key classes which both exist in Microsoft standard issue and MonoGame.

The errors I am receiving are:

Ambiguous reference:
Microsoft.Xna.Framework.Color
Microsoft.Xna.Framework.Color

This has obviously occurred because alongside the standard Microsoft-issued XNA library, I have a reference to MonoGame.Framework.dll which commandeers the namespace, creating this ambiguity. However, in all instances, I wish to access the MonoGame version.

Any ideas how I can explicitly tell the compiler to use the MonoGame version of the Color and Vector2 class and not the official Microsoft one?

Any attempt in a using Color = Microsoft.Xna.Framework obviously won't work because they are both labelled the same in the compiled dlls!

GONeale
  • 26,302
  • 21
  • 106
  • 149
  • If the namespaces are identical then it seems you will have to recompile MonoGame to use a different namespace. The only other alternative is to create a wrapper for the few methods you do want to use. Be sure you are explicit in which reference you actually want to use in this new class. I also would caution you with regards to using XNA since Microsoft has basically discontinued its development. – Security Hound Mar 05 '13 at 13:33
  • Thanks, I'll consider a wrapper.. just hoping for something more elegant. – GONeale Mar 05 '13 at 13:34
  • You want to use both references and they both share the exact same namespace the problem is with MonoGame there isn't an elegant solution. Of course I seriously doubt the full namespace is `Microsoft.Xna.Framework.Color` you would have to look to the code to determine what it actually is. – Security Hound Mar 05 '13 at 13:35
  • @Ramhound Uh... There's a much better solution - see my answer. Also XNA/MonoGame is a reasonable technology choice. And `Microsoft.Xna.Framework.Color` really *is* the full namespace and class name for `Color`. – Andrew Russell Mar 05 '13 at 13:42
  • @AndrewRussell - If the full namespace is an exactly the same then that is a poor design choice on the part of MonoGamee. While its a reasonable choice today because XBOX 360 and Windows 8 currently supports it, going forward in the very near future, it might not be a reasonable solution. I only brought it up because it needed to be said. – Security Hound Mar 05 '13 at 13:45
  • 2
    Re MonoGame: It's a deliberate and sound choice. It's designed to be source-code compatible with XNA. You take your XNA source, switch out the assembly references, and it should "just work". (Of course, until they actually *finish* it - `Microphone` and all - it doesn't always work like that.) Conditionally changing `using` statements is a nightmare - that's what you had to do in the very early days, and they changed it. (Re XNA: Maybe true, but MonoGame+XNA is a different choice to "just" XNA.) – Andrew Russell Mar 05 '13 at 13:52
  • Funny to stir up some debate \*grabs some popcorn\* Thanks all for your answers, I'd love to contribute and add `Microphone` but I wouldn't really know where to start especially talking interfacing to a WP8 microphone component, or if it's a matter of just simply porting the same code from XNA decompiled into the MonoGame sources.. – GONeale Mar 06 '13 at 00:49
  • @GONeale You can't "copy" the copyright code from XNA ;) – Andrew Russell Mar 06 '13 at 06:05
  • Ok, well there we have it ;) – GONeale Mar 07 '13 at 04:01

1 Answers1

8

The way to solve this specific problem is by using an extern alias (MSDN, tutorial).

That way you can alias the Microsoft XNA DLL and specify an appropriate using statement just for the Microphone class. Continue using MonoGame as normal.

Possibly a better solution might be to make your own wrapper class called Microphone in the namespace Microsoft.Xna.Framework.Audio using this technique. Put it in a separate assembly so you don't have to pollute your main source code with the extern alias stuff.

The ideal way, of course, is to actually implement Microphone for MonoGame and contribute it ;)

(Of course, this answer says nothing about how successful you might be at mixing MonoGame and XNA in this way, functionality-wise. Hopefully it works.)

Andrew Russell
  • 26,924
  • 7
  • 58
  • 104
  • Hey Andrew, thanks for your answer and greetings from the G/C :) Only about an hour from you.... ;) Will give the `extern alias` a go when I return home, thanks. – GONeale Mar 06 '13 at 00:46
  • Ahh.. you were the author of "Dark" sweet :) I thought your name sounded familiar... – GONeale Mar 06 '13 at 00:52
  • Excellent! I found the extern alias the best way to go, I now have the following declared, while verbose, I much prefer than upkeeping a wrapper library: `MonoGameFramework::Microsoft.Xna.Framework.GraphicsDeviceManager graphics; MonoGameFramework::Microsoft.Xna.Framework.Graphics.SpriteBatch spriteBatch; private MonoGameFramework::Microsoft.Xna.Framework.Graphics.SpriteFont spriteFont; private Microphone mic = Microphone.Default;` This has allowed me to utilise both the standard Microsoft.XNA.Framework classes provided by WP8 and the MonoGame ones, thanks again for the suggestion! – GONeale Mar 08 '13 at 11:38