Troubleshooting Plugin Issues
Background
Starting with version 2.21.16 we have introduced a new plugin architecture. It is based on MSMQ component and NServiceBus to communicate with message queues between a plugin and the core TargetProcess application. Task Creator is the first plugin developed with this new architecture.
Subversion Integration, POP3 inbound emails and Test Run Import followed in version 2.22.0. More plugins are on the way.
The main advantage of this solution is: new plugins work as services that do not have to be installed on one 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.
Troubleshooting
First off, check if the plugins and Message Queuing services are up and running.
Right click (My) Computer, select Manage:

If they are stopped, try to start them. If the services were started successfully, but the plugins still do not appear in the list, try restarting IIS.
If the plugin services cannot be started this might mean that:
1. Plugin files are not where they are supposed to be
To check on that, navigate to the folder where TargetProcess is installed (by default this should be c:\inetpub\wwwroot\TargetProcess2) and make sure that Plugins folder contains such folders as TaskCreator and SubversionIntegration, and that they are not empty.
If you see that the folders are either missing or empty, and there are some strange folders like PluginSetup or TempTaskCreator this means something went wrong with the upgrade and the system could not re-install the plugins. The safest option would be to re-run setup.exe file to ensure that the correct version of the plugin is installed.
Alternatively, you can rename PluginSetup to Plugins folder and then copy PluginSettings.config from each of temp plugin folders (TempSubversionintegration, TempTaskCreator, etc.) to a corresponding Plugins folder (.../Plugins/Subversionintegration, .../Plugins/TaskCreator, etc). Overwrite existing files.
2. Windows service is not pointing to plugin executable
Right click the plugin service and see if path to executable points to your TargetProcess application:

Usually there’s no need to worry about it. However, if you try to install two instances of TargetProcess on the same machine, only one will work correctly. That will be the one that the service is pointing to.
To change that path, modify registry entry for HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\TpSubversionIntegrationPlugin
3. Database was not updated correctly and the required tables are not in database
This might happen if you move the application from one server to another making an upgrade at the same time.
The easiest way to check on that is to open MS SQL Server Studio and see if the database contains tables such as dbo.Plugin, dbo.PluginDbVersion, etc.
If they are not there, make sure that c:\inetpub\wwwroot\TargetProcess2\wwwroot\web.config connection string uses the correct database:
<session-factory> <property name="connection.connection_string">Server=.\sqlexpress2k8r2;initial catalog=TargetProcess2.22;user id=sa;password=sa;Language=English</property>
and re-run the installer to update the database.
4. The Log On User service has no access to database
If you use Windows Authentication to access database, and your SQL Server is installed on another machine, it might be that the service has no access to database.
So, you can switch Log on value of the service to a user that is already in database:

OR, you can add this user to Database Login and Users:

5. Plugin configuration file points to a wrong database
This may happen if you move your database to another location. With the old plugin architecture, changing TargetProcess web.config was enough. However, now each plugin has its own configuration file and these files need to be updated as well.
The database connection is configured at c:\inetpub\wwwroot\TargetProcess2\Plugins\SubversionIntegration\PluginSettings.config
Make sure that pluginDatabaseConnectionString uses the correct database and credentials.
Feel free to contact us if the above solution did not help.