To achieve this, separate your XNA solution into 4 projects:

1. Content Project

• This will contain all of your assets (like normal). Including your XML files that will be generated by your editor.

2. Engine Project

• This will contain common classes like TilemapContent and WhateverOtherContent that you want to load in-game as well as edit in the editor, as well as any utility classes common between the game and editor (or your whole engine if you want essentially a "game-with-editor-mode" project).
• Any classes you wish to instantiate, edit, and reload should have appropriated attribute flags like [ContentSerializer] (or something, look at Shawn Hargreaves' blog.

3. Game Project

• This will contain the game logic. If you want to run the game, you run this project.
• It will reference the Engine project to get access to TilemapContent, etc. for deserializing TilemapContent objects from the XML that's been compiled into the XNB files.

4. Editor Project

• This will contain your editor code. Mainly, the GUI code, and even if you'd like you can reference all the same files as the game engine project so running this project is the equivalent of running the game in editor mode.
• Use conditional compilation to allow or disallow compilation & execution of editor functionality. You can set conditional compilation symbols on a per-project basis, and you can setup separate exes for editor and game.
• This will also reference the engine project of course, but it will also reference the ContentPipeline assemblies.

A 2d XNA game framework I'm creating on and off for fun does this, so I can verify it works.

Note of course that making a level editor using the Content.Load<YourObjectType>("foo"); that's intended to run on Xbox won't work at all, and you'll have to go through the pain and misery of writing your own data format and intermediary classes. The serialization supported in XNA is designed to be part of the Content Pipeline since it uses reflection.

To achieve this, separate your XNA solution into 4 projects:

1. Content Project

• This will contain all of your assets (like normal). Including your XML files that will be generated by your editor.

2. Engine Project

• This will contain common classes like TilemapContent and WhateverOtherContent that you want to load in-game as well as edit in the editor, as well as any utility classes common between the game and editor (or your whole engine if you want essentially a "game-with-editor-mode" project).
• Any classes you wish to instantiate, edit, and reload should have appropriated attribute flags like [ContentSerializer] (or something, look at Shawn Hargreaves' blog.

3. Game Project

• This will contain the game logic. If you want to run the game, you run this project.
• It will reference the Engine project to get access to TilemapContent, etc. for deserializing TilemapContent objects from the XML that's been compiled into the XNB files.

4. Editor Project

• This will contain your editor code. Mainly, the GUI code, and even if you'd like you can reference all the same files as the game engine project so running this project is the equivalent of running the game in editor mode.
• Use conditional compilation to allow or disallow compilation & execution of editor functionality. You can set conditional compilation symbols on a per-project basis, and you can setup separate exes for editor and game.
• This will also reference the engine project of course, but it will also reference the ContentPipeline assemblies.

A 2d XNA game framework I'm creating on and off for fun does this, so I can verify it works.

Note of course that making a level editor using the Content.Load<YourObjectType>("foo"); that's intended to run on Xbox won't work at all, and you'll have to go through the pain and misery of writing your own data format and intermediary classes. The serialization supported in XNA is designed to be part of the Content Pipeline since it uses reflection.