Plugin Template

[jeremy_sg]

Unfortunately, our license doesn't allow users to redistribute our dlls. I would be happy to make sure that all of the dlls you need for your plugin to work are included in the ClientAPI zip file, so that your users (or your installer) could download all of the dlls they need in one shot.

I think that the only dll I would need to add is VaultPluginLib, right?

Thanks for doing this work, I look forward to seeing how the community embraces it.

[kbonnin]

Hi Jeremy,

The project uses these libs (which I copied from my Vault Client install):

ValutPluginLib
VaultServiceBase

All the others are part of the Vault Server install. So, if you could add those two we'd be fine. This is actually a good idea, because my project is referencing local copies of the Vault Server install, which means when someone upgrades their server this plugin would most likely break.

I'll get this pulled together and notify you on this thread.

k.

[robe070]

Hi Jeremy,

I've found some time again to investigate this issue. I've resolved all issues to the point of a commit firing an OnEndTx into the Plugin code and being able to debug it, including logging in correctly.

Main issue was that the security of IE on Windows Server 2003 64 bit stops the posting of the reply back to http://localhost/PluginServiceTemplate/ ... nformation

No messages are displayed. No errors in sgvault.log.

I couldn't find an IE setting that made a difference to this.

I got around it by using the Web Browser in VS 2005. First I debug into the plugin. IE displays the web page. I the go back to VS 2005 and go to View\Other Windows\Web Browser, and then paste in the URL. I can then debug the setup code. Once thats working, debugging OnEndTx doesn't require these steps.

Any ideas which security setting might alleviate the IE issue?

thanks

Rob Goodridge
ps I've had to halt work on Vault again due to other commitments.

Hi Jeremy,

I'm feeling quite frustrated that I have too little knowledge of WebServices to work this out myself

I've downloaded the latest Server, Client, Client API, and VaultPluginTemplate. I have made no changes to the plugin except for mandatory conversion to VS 2005. I've note even changed the hard coded configuration values like WebConfigLoginKey="vaultlogin".

I have searched the machine for vault objects and they are all the correct version.

I have got to the stage of debugging the PluginServiceTemplate. Note we are using VS 2005.
The debugger Output pane has this as its last line:
'w3wp.exe' (Managed): Loaded 'C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\pluginservicetemplate\22b680cd\15180c15\App_Web_defaultwsdlhelpgenerator.aspx.cdcab7d2.7mwku77f.dll', Symbols loaded.

So it seems to be debugging OK. The expected web page is displayed.

I've set a break point in UpdateVaultConnectionInformation.

I select UpdateVaultConnectionInformation on the web page, enter details, click invoke. Debugger does not break. Web page does not change.

sgvault.log has no changes, not even a login line (apart from previous GUI Client logins), though I don't think there should be any at this stage. I have also performed a check out and I see no version errors like there were before the upgrade.

Not sure if this is relevant but if I look at the Design tab in VS 2005 for PluginServiceTemplate.asmx.cs I get this error:

One or more errors encountered while loading the designer. The errors are listed below. Some errors can be fixed by rebuilding your project, while others may require code changes.

The designer must create an instance of type 'VaultPluginLib.VaultPluginServiceBase' but it cannot because the type is declared as abstract.

thanks

Rob Goodridge

[jeremy_sg]

The two plugin libraries (ValutPluginLib and VaultServiceBase) are included in the VaultClientAPI zip file as of 4.1.2. This means that users of developed plugins should only need to download the latest API zip file and put all of the dlls next to the plugin in the virtual directory.

[kbonnin]

Sweet! I'll be installing 4.1.2 and I'll rework the project to use them.

[jeremy_sg]

Plugins do not have the ability to abort a transaction. We made this decision, because a plugin can take an arbitrary amount of time to run. It was unacceptable for us to risk slowing down checkins to wait for plugins.

[vonwyss]

Is there any documentation on the return values of the Vault Plugin Service methods OnStartTx and OnEndTx? They return an int, but I can't seem to find it's meaning.

I am looking for a way to intercept the beginning of a transaction and ensure that it contains a valid bug tracking id. If it does not, I would like to transaction to fail.

[jeremy_sg]

Sorry, but our plugins do not have the capability to cause a transaction to fail, either in BeginTx or EndTx.

[vonwyss]

Is there another way to enforce a valid bug tracking id in the transaction comment?

[jeremy_sg]

If you're using Fortress, there's a built-in way of enforcing a valid bug id with every checkin. Otherwise, there is no way to reject a checkin because it lacks a bugid. You could still set up a plugin to listen for EndTx events to notify you when a bugless checkin was done, but it would only be advisory.