ContentPipeline logging/debugging

XNA Brains;

I created some code that converts a BSP file into an XNA-renderable map file. It was on the xbox360homebrew.com site. I had everything working in the code, and then I decided to port it over to the ContentPipeline. (I'm liking the pipeline more and more now).

Long story short, I've run into a few nasty bugs introduced while trying to improve my code. I've found debugging to be a real pain because the only way I can simulate the entire Content Pipeline experience is to let GSE/XNA do the building of some actual content. I can eventually solve my bugs, but my real questions are:

1. What is the best way to debug custom Content Pipeline importers/processers/writers I am already using the three-project setup (One assembly of pipeline types, one assembly of the content types, and one platform-specific assembly for the game)

2. What is the expected usage pattern of ContentBuildLogger I am using it to spew messages, but I have no clue where they should be coming out. A file The output window At Microsoft (egad!)

I apologize if this information has been covered, but I couldn't find anything specific to new/custom importers/processors. I have to say, I love the pipeline, my only comment is that I wish the base classes were interfaces instead. (Read: I should have spoken up/voted!)

Thanks!

Answer this question

ContentPipeline logging/debugging

DanglingChap
The best way to debug content pipeline is to use Visual Studio 2005 Pro, and Attach to Process to the copy of Visual Studio Express that runs the actual content build. Then set breakpoints, build some real content, etc.

If you don't have VS Pro, you can download and install the CLR Debugger (I think it's part of the .NET SDK on MSDN), which allows you to target specific processes. The main drawback with VS Express is that it doesn't support the "Attach to Process" command (nor does it support the "Threads" window display -- gah!)

The content logger outputs the data depending on the level that you specify. At least one of the levels goes to the Output window in the IDE. At least one more of the levels goes to the build log file that gets created by the IDE, which you can open after the build using some web browser.
Raguvind
Additionally, for a quick'n'dirty way of debugging, just put the following line wherever you want to start debugging:

System.Diagnostics.Debugger.Launch();

That will pop up a message asking you if you want to launch a debugger :-)
TR Materene
You don't open the csproj in VS Pro -- you use "Attach to Process" to attach to the VC Express process, before you start building in VC Express. You can then open the individual source files (without the project) in VC Pro, and set breakpoints. Through the magic of .NET assembly debug information, it will all work out just peachy!
MA2005
Wow, thanks both of you - That is exactly what I needed. I hadn't thought of opening my csproj from VS.NET Pro.

I'll turn on the verbose logging; oddly enough I didn't have anything important to say, I was just trying to log where I was in the process. My bug is that a certain section of code gets into an infinite loop; but does not eat up memory or overflow the stack. If I had an error, I certainly would have LogImportantMessage'd it :)

I'll look for that build log as well.

Thanks!
Sergiulica1
Okay - I always have the project already loaded when I use attach-to-process. I hadn't realized that would work. I don't have VS Pro on my machine right now, just got a new laptop and wanted to see how long I could express-it. Turns out installing the .NET 2.0 SDK / CLR Debugger was super easy and allowed me to debug quite easily (When combining Joel's tip). Turning on verbose logging for the Content Pipeline was hard to find but worked perfectly.

The only problem is that I still have a bug! The interesting thing is that if I build as normal I see my ContentImporter start up but I never see my ContentProcessor start - even though the first line is to log. The entire VC# Express process hangs and has to be killed.

When I debug the process during the build, however, by stepping through the lines (not all of them, just a bunch here and there to see what it's doing) the processor finishes off completely and results in good content. I'm not sure why, and it's probably something I'm doing, but my content pipeline assemblies appear to work only if debugged.

I'll leave a message when I figure it out, most likely saying, 'Duh, I'm an idiot.'

Thanks!
jason duncan
What Jon said :-)

Regarding logging, by default C# Express will show LogImportantMessage output in the build window, but discard regular LogMessage strings.

You can change this in Tools / Options. Make sure "Show all settings" (in the bottom left) is checked, then open up Projects and Solutions / Build and Run, and change the MSBuild project build output verbosity from Minimal (the default) to Normal.
ContentPipeline logging/debugging

Answer this question