In Targetprocess most plugins work as standalone services. The technology is based on Message Queuing (MSMQ) component and NServiceBus to communicate with messages between a plugin and the core Targetprocess application.
The main advantage of this solution is that new plugins work as services which do not have to be installed on the same server with TargetProcess. This improves performance, reliability and makes it easier to develop new features. Unfortunately the new architecture brings in new technical issues, so let’s see how to troubleshoot them.
Your first step
If you see that some of the plugins are missing at Settings -> Plugins, it usually means that the corresponding services are stopped. The first thing to do is to go to the standard Windows Services on the server where Targetprocess is hosted and try to start them.
With some luck, the service starts and you can see the plugin in Targetprocess UI. Happy End!
If plugin service is unable to start
Check the logs
Plugins have separate log files that can provide valuable information. You can find them at
Even if you cannot identify the problem right away, it would be most useful for the Targetprocess support team.
Hint: Plugin.txt can be quite large and difficult to read. The latest records are added to the end of the file. You can try the following trick: remove Plugin.txt from the Logs folder and then try to start the service. After that the log will contain only relevant information.
Here are some of the most common plugin issues:
Plugin configuration file points to the wrong database
This may happen if you move your database to another location. Changing TargetProcess web.config is not enough. Now each plugin has its own configuration file and these files need to be updated as well.
Database connection is configured at
c:\inetpub\wwwroot\TargetProcess\Plugins\Plugin_name\PluginSettings.config (e.g. ...\TargetProcess\Plugins\SubversionIntegration\PluginSettings.config)
Make sure that pluginDatabaseConnectionString uses the correct database and credentials. Usually the connection string should be the same as in
Permissions for private queues
Open Computer Manager (Server Manager at Windows Server 2008), find Message Queuing under Features and expand Private Queues.
There are lots of queues here as you can see, but in terms of permissions there are two groups:
- Plugins and UI queues such as tp.bugzilla, tp.bugzillaui, tp.git, tp.gitui, tp.search, tp.searchui and similar queues with the plugin name. They need Full Control for SYSTEM and Administrators. To check that, right-click the name of the queue, pick Properties and switch to the Security tab.
- Internal or service queues: tp.error, tp.inputcommand, tp.inputcommandui, tp.pluginssubscriptions and all the tp.proxy.xxx queues. Apart from the permissions that the previous group has, these also need Full Control for the user specified as your Application Pool Identity.By default it is Network Service and we recommend keeping it this way. In some cases when you need the application to be run as a different user, that user needs Full Control for the following queues:
Too many messages in Private Queues
If you have thousands of messages in private queues, it may be a bad sign.
If you are not using a plugin which has a number of messages, you can delete them by expanding the queue -> Queue messages -> All tasks -> Purge. However, purging the queue could result in some data loss. So be careful with that for the plugins you are using. The best approach to deal with unused plugins is to uninstall them.
These are the most common issues, but not all the possible ones. If that does not help, contact Targetprocess support (it would be great if you attach the above-mentioned logs right away).