attachment - a base64 encoded version of the file to be attached. Typically, an image.
attachment_content_type - for example "image/jpeg"
attachment_filename - for example, "screenshot.jpg"
attachment_desc

See the insert_bug.aspx itself for more complete and up-to-date info. Don't just trust this documentation.

Neither the screen capture nor btnet_service.exe can use IIS's Windows security, but there's a workaround if you use Windows security:
You can change the website so that insert_bug.aspx ONLY is configured not to use windows security.
That is, you can set the security at the level of a page, not just at the level of a virtual directory.

You have the source code to BugTracker.NET, so you can edit that source code however you want.
But editing the BugTracker.NET source code might make it harder for you to upgrade to new and improved versions of BugTracker.NET.

The file App_Code\Workflow.cs is an isolated place where you can centralize your customizations so that when you upgrade, you don't lose them.
The page edit_bug.aspx calls custom_adjust_controls() before a page is displayed to give you a chance to modify the controls on the page.
For example, you could limit the list of statuses a particular user is allowed to select. Later, edit_bug.aspx calls custom_validations()
to give you a chance to add your own validation logic and error messages.

There is sample code in the file itself that you can use to get started.

The only tool you need to make changes to most of BugTracker.NET is...Notepad. I personally do most of my work using Textpad, Notepad++, and the free Visual Web Developer Express Edition.

If you work with the code, you'll notice it doesn't use "code-behind". Here's the story:

I started BugTracker.NET in 2002 as a learning project, to teach myself .NET and C#, to get those technologies on my resume. At the time I didn't own Visual Studio, so I went about
learning .NET the same way I had learned Java in its early days: I downloaded the SDK, edited files using a text editor, and compiled
using the command line.

If you work with the SDK and the documentation of for the .NET libraries, you won't even come across the term "code-behind". Code-behind
is a Visual Studio concept, not a .NET concept. I didn't know about code-behind when I created BugTracker.NET and so BugTracker.NET does
not use that technique. Some folks who are very attached to the Visual Studio way of doing things have been very disappointed.

Even today (Nov 2008), I still usually just edit the files using a text editor. I just edit, save, and refresh the browser.