Frequently Asked Questions

Q: When I upload my assembly, FogBugz says it is not a plugin.  What's going on?

A: Your assembly must inherit from Plugin AND have the necessary assembly attributes

Plugins assemblies are defined by two criteria.  Failing to meet either one will cause FogBugz to not recognize and install your DLL as a plugin assembly.  The criteria are:

1. You must have exactly one class that inherits from FogCreek.FogBugz.Plugins.Plugin
2. You must provide a unique ID for your plugin with the AssemblyFogCreekPluginId attribute.  

See the Quick Start Guide for more details.
 

Q: What do I do if my plugin completely breaks FogBugz?

A: Disable plugins completely via diagnostics, then disable or delete the plugin.

FogBugz should catch all plugin exceptions and present them in a friendly way, but in the unlikely event that your plugin crashes Fogbugz, you can disable all plugins in diagnostics:

[your fogbugz site]/diagnostics.asp?sStep=TestPlugins

Then you can go to Settings -> Plugins to remove your plugin or reinstall a fixed version.
 

Q: I upgraded FogBugz and now I get a Load Error in my plugin.  What should I do?

A: Recompile your plugin against the latest versin of FogBugz and fix any build errors.

Load errors result from FogBugz not being able to load the type for your Plugin class.  Typically this is because something in FogBugz changed and your plugin needs to be recompiled.

If you see a "Load Error" at the top of a FogBugz page for your plugin, the first thing you should do is update the FogBugz.dll and FogBugz.Plugins.dll references in your plugin project, recompile and install. Load Errors for a previously-working plugin are often the result of updating FogBugz but referencing old assemblies in your plugin.

If your plugin compiles without errors and you see a load error in FogBugz stating that the plugin uses a version of the FogBugz API that is not supported, update your plugin's assembly info to specify a compatible version, compile and re-install the plugin.

Q: api.Request["foo"] always returns null, even though I am sending it in the URL.

A: The Request API only allows you access to fields with your plugin's prefix on them.

A plugin accesses both GET and POST fields with the api.Request dictionary, but can only access ones with its prefix. So when constructing a URL, make sure to include your plugin prefix, and also use the prefix when accessing the values.

Use api.PluginPrefix or api.AddPluginPrefix to prefix your field names and query parameters so that you will be able to access them.  URLs constructed like this WILL NOT WORK:

string sUrl = api.Url.PluginPageUrl() + "myParam=7";

Instead use

string sParam = api.AddPluginPrefix("myParam");
string sUrl = api.Url.PluginPageUrl() + "&" + sParam + "=7";

Access the value of the parameter like this:

string sValue = Convert.ToString(api.Request[AddPluginPrefix("myParam")]);

See Passing data to Plugins from the Client for the complete story.

Q: I need an instance of FogBugz class [Foo], but its constructor is not public.  What do I do?

A: Look for an API method like api.Foo.NewFoo()

If there's no constructor for a public object, typically it's because it needs to be instantiated by FogBugz via the plugin api object. For example, to create a CFilterOption for FilterOptions(CFilter filter) method in the IPluginFilterOptions interface, you use

CFilterOption myFilterOption = api.Filter.NewFilterOption();

See Access and modify FogBugz entities for more information.
 

Q: I want to implement interface [IFoo].  How do I find the methods I need to implement?

A: If you're using Visual Studio, it can do it for you.  Otherwise, look it up in the FogBugz Class Library.

Visual Studio and Visual C# Express will do many things for you to make your life easier. One is to generate method stubs for those required when you implement an interface. For example, when implementing IPluginPageDisplay, you define your class:

public class HelloWorld : Plugin, IPluginPageDisplay

Now just hover over IPluginPageDisplay and the "I" will be underlined. Hover that and a menu appears. Click the menu and choose "Implement Interface 'IPluginPageDisplay'" and it will create the method stubs for you!
 

Q: What do I need to do in the *Foo*CommitRollback function?

A: The basic rule of thumb is: undo in CommitRollback anything you did in CommitBefore.

For many FogBugz plugins, you will implement three interfaces:

• Join to add the data from your custom table to the FogBugz object
• Commit to perform actions whenever the object is committed
• Display to show your data to the user and provide a UI for editing it.

Below are basic best practices for using Commit:

The general rule is: "Whatever you did in BeforeCommit, you need to undo in Rollback".

So, if you called

wikipage.SetPluginField("foo", "bar");

You need to call

wikipage.SetPluginField("foo", barOrig);

Best-practice is to save the orig value in a class variable before you set it in BeforeCommit, something like:

BeforeCommit:

this.barOrig = wikipage.GetPluginField("foo"); wikipage.SetPluginField("foo", "bar");

Rollback:

wikipage.SetPluginField("foo", this.barOrig);

AfterCommit:

this.barOrig = null;

 

Q: How do I know what the user is allowed to read / write?

A: For most objects, use IsReadable and IsWritable.  For more advanced permissions, use methods on the CPerson object.

object.IsReadable and object.IsWritable return true if the current user is allowed to read or write the object, respectively.

For a more complete discussion of permissions, see Entity Member Security.

 

Q: Do I need to worry about Cross-Site Scripting, Cross-Site Request forgery, and SQL Injection?

A: Yes!  If your plugin is found to have XSS, CSRF, or SQL Injection vulnerabilities it may be removed from the Plugin Gallery or On Demand servers until the issues are fixed.

See Plugin Security for more details.