Hi all,

I have two questions in mind

1) What if say I have components of game engine, written in unmanaged C++, that is already in a DLL form. Will XNA be able to use it, some through unsafe pointers?

1b) Let further go to say that game engine has it own rendering capability. AFAIK from XNA, XNA uses non-fixed programmable function pipeline. Is there anyway to use that game engine's rendering code? (It's a moot point, anyway, but it's a theoritical question)

2) Will any .NET libraries work with XNA, as long as it does not interfere with its core update-draw framework?

2b) Must all libraries for the XNA framework be done via the Windows Library template in Visual Studio? Or would any .NET library work?

Extrakun:

1) What if say I have components of game engine, written in unmanaged C++, that is already in a DLL form. Will XNA be able to use it, some through unsafe pointers?

As long as you do not intend to run your game on the 360 you can use whatever you like as it is just normal interop. I would suggest a light C++/CLI wrapper though.

Extrakun:

1b) Let further go to say that game engine has it own rendering capability. AFAIK from XNA, XNA uses non-fixed programmable function pipeline. Is there anyway to use that game engine's rendering code? (It's a moot point, anyway, but it's a theoritical question)

I do not think so (and if it is possible it would be messy) and that would render using the XNA Framework rather inpractical.

Extrakun:

2) Will any .NET libraries work with XNA, as long as it does not interfere with its core update-draw framework?

2b) Must all libraries for the XNA framework be done via the Windows Library template in Visual Studio? Or would any .NET library work?

Yes, all will work and no, and assembly should work (with the limitation of: if you do not want to run on the 360 and if you do not want to include Content Pipeline assets in the libraries).

Björn Graf:

Yes, all will work and no, and assembly should work (with the limitation of: if you do not want to run on the 360 and if you do not want to include Content Pipeline assets in the libraries).

To clarify this last point, the issue with external assemblies on the Xbox is assembly references.  Even though mscorlib.dll and friends, as well as the XNA Framework assemblies, are named the same on Windows and Xbox, they are not the same and the CLR will not treat them as the same!  To the runtime environment, the Windows and Xbox versions of these assemblies are completely different, with the Windows versions only being available on Windows and the Xbox versions only being available on Xbox.  Imagine you have an assembly MyAssembly1.dll that you want to use in an XNA project.  Chances are this assembly comes from a Windows project and references the Windows versions of mscorlib.dll, System.dll, etc..  If you reference this assembly in an Xbox XNA project (without re-compiling), the Xbox CLR will not be able to find mscorlib.dll, System.dll, etc. for this assembly since it is referencing the Windows versions.  Chances are the compiler will also complain about duplicate references, though I cannot remember if it's the C# or C++ (for C++/CLI) compiler that complains, or both.

What does this mean for you?  As long as your have the source code for the .NET library you wish to use, you're fine.  You can create a new Xbox Game Library target for the project and re-compile.  If you only have a Windows binary, you cannot use the library on Xbox, at least not without some serious reference hacking.

Now if you are only interested in Windows, then there is no issue.  You can use whatever .NET libraries you wish.  Remember that XNA Game Studio is just a set of .NET libraries and some fancy Visual Studio integration.

This is a good opportunity to explain how .net assembly naming and binding works.  Hope you don't mind me tagging on to the thread.

An assembly "name" is actually a tuple composed of 4 different components;  Assembly Name, Public Key, Assembly Version Number, and the Assembly Culture.  All of these components are contained in the metadata of an assembly. 

When you reference a type in an assembly, the compilers actually store all 4 of these assembly name components for each type you reference in your application assembly.  This is sometimes referred to as a fully qualified type name.  The CLR will match all components of the reference in addition to the namespace+type name in order to load and bind the desired type successfully.

In the case of the Xbox 360 and Windows, the assembly names and cultures across the .NET framework and XNA framework are the same.  However, the assembly version numbers are different.  And the assemblies are signed with different private keys, giving them different public keys.  Thus, as has been stated above, the types will not match and the CLR will not load/bind them correctly.

You can use the "Reflector" or 'ILDASM' tools to examine these metadata fields.

Here are some not so well known tidbits:

• The assembly name is contained in the metadata.  This is actually different from the file name in almost all cases since the filenames add on an extension.  For example, the mscorlib.dll file actually has an assembly name of "mscorlib".  You could actually create an assembly called foo.dll, rename it to bar.dll, pre-load it with Assembly.Load() and types bound to foo will still resolve properly since you preloaded the assembly and the CLR looks at the assembly name in metadata and not the file name.
• mscorlib is "special" in that it is required for he clr to boot-up since it contains all of the base simple types (int, string, etc.)  there can only be one version of this assembly loaded.
• There is a Global Assembly Cache (GAC) that is like a global directory of assemblies.  While this is used on Windows and Windows Mobile, it is not used (nor does it exist) on the Xbox 360.  On windows, you can use the GacUtil.exe command line utility to manipulate and view the contents of the GAC.  The equivalent on windows mobile is cgacutil.
• You can set all 4 components using assembly attributes in C# (see the properties\assemblyinfo.cs in your project), via the C# compiler command line, or via visual studio project settings.