You can't realistically ask people to download the entire XNA development framework just to run your game. And I'm pretty sure Microsoft won't allow you to just distribute the Content Pipeline DLLs willy nilly.

What you do to accomplish your goals depends on your answers to a couple of questions:

1. Do you need to be able to serialize data to XML at runtime, or is this purely so you can make a level editor and plug a bunch of data into XML files that are to be read by your game at runtime (your XMLHandler.FindSkillsForLevel suggests that the latter is your case).

2. Is it necessary for you to stream any data from a server that is meant to be deserialized, or can you assume it's all packaged in the game?

3. If you do indeed need runtime serialization, is it absolutely required that you use XML? You may find it easier to map your data to JSON, which is easier to read and a little faster to emit and parse for many cases.

If you are only using the XML for defining your game data (and making level editors for you to use, you should split your solution up into 4 projects: Engine, Game, Editor, Content. Don't think of Engine as this fancy thing, it's just the common code shared between Game and Editor (see my answer here). Game contains game-specific code, all the presentation and special handling of level data and end-user UI. Engine can contain most of the code (AI, level logic, etc.) since you'll probably want to use the editor project as a catch-all for editing all sorts of data related to your game.

If you intend to stream XNB files to a desktop game, you may have to experiment with instantiating a ContentManager object using the constructor that takes a string. I haven't done this, so I don't know what the limitations are.

If you require runtime serialization/deserialization for playing your game outside of typical content pipeline use, you must handle your own serialization instead of relying on the content pipeline. The reflection API isn't too hard to use and understand, it's just tedious. And if you have to serialize your own stuff anyway, you may want to consider looking into JSON. It usually maps more intuitively to classes. A couple libraries to check out would be LitJSON for something lightweight, and JSON.Net for something more featureful and robust.

You can't realistically ask people to download the entire XNA development framework just to run your game. And I'm pretty sure Microsoft won't allow you to just distribute the Content Pipeline DLLs willy nilly.

What you do to accomplish your goals depends on your answers to a couple of questions:

1. Do you need to be able to serialize data to XML at runtime, or is this purely so you can make a level editor and plug a bunch of data into XML files that are to be read by your game at runtime (your XMLHandler.FindSkillsForLevel suggests that the latter is your case).

2. Is it necessary for you to stream any data from a server that is meant to be deserialized, or can you assume it's all packaged in the game?

3. If you do indeed need runtime serialization, is it absolutely required that you use XML? You may find it easier to map your data to JSON, which is easier to read and a little faster to emit and parse for many cases.

If you are only using the XML for defining your game data (and making level editors for you to use, you should split your solution up into 4 projects: Engine, Game, Editor, Content. Don't think of Engine as this fancy thing, it's just the common code shared between Game and Editor (see my answer here). Game contains game-specific code, all the presentation and special handling of level data and end-user UI. Engine can contain most of the code (AI, level logic, etc.) since you'll probably want to use the editor project as a catch-all for editing all sorts of data related to your game.

If you intend to stream XNB files to a desktop game, you may have to experiment with instantiating a ContentManager object using the constructor that takes a string. I haven't done this, so I don't know what the limitations are.

If you require runtime serialization/deserialization for playing your game outside of typical content pipeline use, you must handle your own serialization instead of relying on the content pipeline. The reflection API isn't too hard to use and understand, it's just tedious. And if you have to serialize your own stuff anyway, you may want to consider looking into JSON. It usually maps more intuitively to classes. A couple libraries to check out would be LitJSON for something lightweight, and JSON.Net for something more featureful and robust.