Some issues occur widely enough that others have faced them before you. Consequently, you can solve your problem quickly, or you can add your input to an existing discussion.

Concise, meaningful titles improve the discoverability of your posts, and make it easier for other WPF forum community members to determine if they can solve your problem.

You should describe the issue and how you’ve tried to work through it. If possible, include supporting code snippets, or the simplest possible sample that demonstrates your issue. All these details help to increase the chance your question will be answered quickly.

A complete set of forum best practices can be found online.

Some issues occur widely enough that others have faced them before you. Consequently, you can solve your problem quickly, or you can add your input to an existing discussion.

Concise, meaningful titles increase the chance that your issue is directed to the most appropriate WPF team in the shortest amount of time. This is particularly important for a technology like WPF, which contains many interrelated features.

When you post about a bug, it is important to include the following where relevant:

• Provide a clear description of the bug.

• Use code snippets to support the bug description.

• Provide a list of steps that demonstrate how to reproduce the bug.

• Include the smallest possible code sample that reproduces the bug.

• Mention whether the bug is consistently reproducible or not.

• Include relevant exception information.

If the bug is install or setup related, attach the relevant install logs and snapshots (files prefixed with "dd_" that are located in your %temp% folder).

For compile or build issues, attach the build logs. The MSBuild system can be configured to supports logging with various verbosities by using the /v: switch from the command line or by configuring the appropriate level from an Integrated Development Environment (IDE) like Microsoft Visual Studio.

Background information can often be useful for adding context to your post. In particular, mention the operating system platform, processor family, and architecture, such as "Windows XP SP2, Pentium III, x86".

If the issue you are posting about is related to rendering, you should also include graphics card and driver details, if possible. This information is important because WPF is a presentation framework.

Bugs may pertain to the tools used to develop and build your applications and the types of applications you are building. Consequently, it can be useful to specify:

• The type of application you are building, such as:

  • Application (.exe) or library (.dll).

  • Extensible Application Markup Language (XAML) browser application (XBAP).

  • Loose XAML application.

  • Standalone installed applications.

  • Standalone ClickOnce-deployed applications.

• The development tool, such as:

  • MSBuild.

  • Expression Graphic Designer.

  • Expression Interactive Designer.

  • Microsoft Visual Studio.

• The solution configuration, such as:

  • A solution.

  • A single project.

  • A solution with multiple dependent projects.

• Whether your application has language-specific or language-neutral resources. For example, did you specify the UICulture project property or localizable metadata for Application, Page, and Resource types?

• Whether you used the neutral language setting in the AssemblyInfo.cs or AssemblyInfo.vb file.

Information about the scenario that manifests the bug and its impact is highly important to the WPF team when it decides if, when, and how a problem should be fixed, or whether an acceptable workaround can be used instead.

Ordinarily, crash and data loss scenarios are high impact and, therefore, the easiest to prioritize. Some bugs, however, only show up in uncommon scenarios, which may also be mainline scenarios in some cases. Providing context around scenario and impact helps the WPF team make the right decision.