We are trying to get one of our tool programs integrated into the build
process for a VS.NET C# project.

The tool we want to use is a parser generator which runs as a console-mode
Win32 application and reads a YACC-like grammar from an input file and
generates C# source code into an output file and error messages to its
standard output.

We want the input (*.y) file to be what the programmer edits in a text edit
window in the VS IDE, and also what is checked into the source control
system.

Ideally we want the generation of the C# output to occur at build time (that
is, when the user runs the "build" or "rebuild" menu commands for the
project, and we do not want the C# file to be under source control.

I want to emphasize that the tool does not interact with the user and does
not assist in the creation of the .y file. I mention this because most
searches for help on "custom build tools" seem to fall into this model,
programs which interact with the user to "edit" the "source" in some
graphical method.

Our current method for doing this integration is using an assembly written
as a C# project based on code found on the Web. The assembly has has a class
derived from BaseCodeGeneratorWithSite (ultimately derived from
IVsSingleFileGenerator and IObjectWithSite). When IVsSingleFileGenerator's
Generate method is called, our code uses System.Diagnostics.Process to run
the parser-generator app, and loops reading error messages from the
StandardOutput member of the Process object. The code parses the error
message to extract severity and source location information, and ultimately
calls the GeneratorError method of the IVsGeneratorProgress object which was
originally passed to Generate. The generated parser (which was written to a
temporary file) is read and returned via the rgbOutputFileContents argument
of Generate. The assembly is registered with COM and its class ID is
registered appropriately (I think) under
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\7.1\Generators.

This more or less does the right thing. The tool runs, the generated C# code
appears in a file, and when the assembly is built, the code is compiled and
included in the assembly.

Minor annoyances in this interface are that the tool runs when the .y file
is changed and saved, rather than when the project is built, and that the
.cs file in which the tool's output is stored is added to source control.

The main problem we are currently encountering is that, although the error
messages of the tool show up in the Task List as "build errors" and show the
correct filename and line number, double-clicking on one of these lines
opens the input (.y) file but *does not go to the line of the error*.

So we have several questions...

1 - Is this the right approach to use for this sort of tool?

2 - Is there any way to make the file management work as mentioned
("ideally...") above? Currently the .cs file is generated when the user
saves the .y file and *not* when the user builds the project, and the .cs
file is placed under source management.

3 - Is there any way that an alternative filename can be attached to the
build error that appears in the Task List? This is not a concern for this
particular tool but some other tool which supports source file inclusion
could very well report errors relating to source files other than the main
input.

4 - Is there any official documentation available on IVsSingleFileGenerator
and related interfaces and registry keys?

5 - Is there any way to generate text into the Output window of the IDE? The
parser generator produces some statistics which should not rightly be placed
in the Task List but which should be recorded somewhere the user can inspect
them, and it seems that the Output window is used in this manner by the C#
compiler.

6 - (our most immediate concern) Why does double-clicking in the Task List
not position the cursor to the correct line?