Plugin Template
Moderator: SourceGear
Sorry that this post slipped by for so long.
"not a valid IIS application" probably means that you're compiling against 32 bit libraries (the only kind we ship), but on a box where IIS only accepts 64 bit binaries. You should configure IIS to accept 32 bit binaries, and make sure that you're building your plugin as a 32 bit app.
"not a valid IIS application" probably means that you're compiling against 32 bit libraries (the only kind we ship), but on a box where IIS only accepts 64 bit binaries. You should configure IIS to accept 32 bit binaries, and make sure that you're building your plugin as a 32 bit app.
Thanks that enabled the compile to work. The way to do this is documented at this link: http://www.microsoft.com/technet/prodte ... x?mfr=true
Note that you must not put quotes around True.
BUT, Vault is now not working because of the WOW change:
Unable to connect to http://devsrv/VaultService. No server was found at the specified URL. Please verify your network settings using the Options dialog under the Tools menu in the Vault GUI Client. Web Exception: The request failed with HTTP status 503: Service Unavailable.
Note that you must not put quotes around True.
BUT, Vault is now not working because of the WOW change:
Unable to connect to http://devsrv/VaultService. No server was found at the specified URL. Please verify your network settings using the Options dialog under the Tools menu in the Vault GUI Client. Web Exception: The request failed with HTTP status 503: Service Unavailable.
The conclusion we have reached is that this has stopped working because we upgraded to 4.1.0.
Before we made the latest changes to WOW we used the plugin that we compiled on another machine - the one that worked originally. It didn't work.
We've now made all the WOW changes, compiled on the 64-bit PC successfully and its still not logging in to Vault. (plugin gets executed).
Please test with 4.1.0.
regards
Rob G
Before we made the latest changes to WOW we used the plugin that we compiled on another machine - the one that worked originally. It didn't work.
We've now made all the WOW changes, compiled on the 64-bit PC successfully and its still not logging in to Vault. (plugin gets executed).
Please test with 4.1.0.
regards
Rob G
To confirm what Rob said - the sample plugin worked before we installed 4.1.0. After installing it, it no longer works.
To be precise, it was intercepting the OnEndTx event properly, but execution terminates when it hits ServerOperations.Login(). The login details we're using are correct - the fault seemed to be within the API that the plugin's calling.
After making the fixes you suggested above & seeing it behaving the same way, I thought that perhaps I should get the latest version of the Client API dlls instead of those we'd been using (from 4.0.6). Having done so and recompiled, I went through the steps for registering the plugin - so far so good. Then I tried checking in a file ... and now the plugin doesn't fire up at all, so we've gone from bad to worse.
Btw, all we want to do is execute a batch file whenever the OnEndTx and OnBeginTx events occur, passing it a string of arguments such as filename, transaction type, TxDate, TxID, User & Comment. We're basically going to all this effort just in order to fire off a system call to a batch file.
Vault seems to be a reasonably mature product now, but right now there's no way to setup something like this without writing a plugin using an unofficial & unstable API - this is a critical function for us so you can maybe understand how nervous we feel about this.
Would it be possible to add four text fields to the Web Admin for Vault providing the ability to specify batch files to execute when those events occur? That would make it a lot easier to extend Vault's functionality on the server side without all this hassle, and system administrators can be confident their server-side scripts will work with future Vault upgrades.
cheers,
Andrew
To be precise, it was intercepting the OnEndTx event properly, but execution terminates when it hits ServerOperations.Login(). The login details we're using are correct - the fault seemed to be within the API that the plugin's calling.
After making the fixes you suggested above & seeing it behaving the same way, I thought that perhaps I should get the latest version of the Client API dlls instead of those we'd been using (from 4.0.6). Having done so and recompiled, I went through the steps for registering the plugin - so far so good. Then I tried checking in a file ... and now the plugin doesn't fire up at all, so we've gone from bad to worse.
Btw, all we want to do is execute a batch file whenever the OnEndTx and OnBeginTx events occur, passing it a string of arguments such as filename, transaction type, TxDate, TxID, User & Comment. We're basically going to all this effort just in order to fire off a system call to a batch file.
Vault seems to be a reasonably mature product now, but right now there's no way to setup something like this without writing a plugin using an unofficial & unstable API - this is a critical function for us so you can maybe understand how nervous we feel about this.
Would it be possible to add four text fields to the Web Admin for Vault providing the ability to specify batch files to execute when those events occur? That would make it a lot easier to extend Vault's functionality on the server side without all this hassle, and system administrators can be confident their server-side scripts will work with future Vault upgrades.
cheers,
Andrew
First, to address your suggestion of batch files. The problem is that there's a limited amount of useful information that we could communicate over a command line. That means that the batch file _probably_ will have to log in to server to get detail. That means that it will be connecting through the (as of 4.1.1 fully supported) client API, which brings the upgrade trouble you're seeing.
One thing that might help is to look at your Vault server log file to see if that mentions any problems connecting to your now-4.1.0 plugin.
One thing that might help is to look at your Vault server log file to see if that mentions any problems connecting to your now-4.1.0 plugin.
Hi Jeremy,
The log has many of these entries. Any ideas how we can correct this?
regards
Rob Goodridge
----11/04/2008 5:10:37 PM --()-- Exception in plugin thread : System.Web.Services.Protocols.SoapException: Server was unable to process request. ---> System.IO.FileLoadException: Could not load file or assembly 'VaultLib, Version=4.0.6.15954, Culture=neutral, PublicKeyToken=a74d7badb9387c36' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
File name: 'VaultLib, Version=4.0.6.15954, Culture=neutral, PublicKeyToken=a74d7badb9387c36'
at VaultPluginLib.VaultPluginServiceBase.EndTxEvent(Int32 nRepID, Int64 nTxID)
WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.
To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].
--- End of inner exception stack trace ---
The log has many of these entries. Any ideas how we can correct this?
regards
Rob Goodridge
----11/04/2008 5:10:37 PM --()-- Exception in plugin thread : System.Web.Services.Protocols.SoapException: Server was unable to process request. ---> System.IO.FileLoadException: Could not load file or assembly 'VaultLib, Version=4.0.6.15954, Culture=neutral, PublicKeyToken=a74d7badb9387c36' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
File name: 'VaultLib, Version=4.0.6.15954, Culture=neutral, PublicKeyToken=a74d7badb9387c36'
at VaultPluginLib.VaultPluginServiceBase.EndTxEvent(Int32 nRepID, Int64 nTxID)
WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.
To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].
--- End of inner exception stack trace ---
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
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
I can't seem to get it to register...
Hi Jeremy,
I've completed my Vault/FogBugz checkin tool, and it's spiffy! I'm having one issue, however, and that's with registering. In this block of code:
I'm finding I'm only getting a Finalize() and Dispose(), and none of the very cool other ones (i.e. EndTxEvent). I'm using the libraries from my installation, both web and client. All Vault libraries have a version of 4.1.1.18060.
Any ideas?
Ken
I've completed my Vault/FogBugz checkin tool, and it's spiffy! I'm having one issue, however, and that's with registering. In this block of code:
Code: Select all
ArrayList alNotifyEvents = new ArrayList(4);
Type myType = this.GetType();
MethodInfo[] miarr = myType.GetMethods(BindingFlags.NonPublic|BindingFlags.Instance|BindingFlags.DeclaredOnly);
Debug.WriteLine(" Server supports " + miarr.Length + " event(s):");
foreach (MethodInfo mi in miarr)
{
if (mi.DeclaringType == myType && mi.Name == "OnEndTx")
{
Debug.WriteLine(" * " + mi.Name + " - REGISTERING"); eventCount += 1;
alNotifyEvents.Add(VaultLib.VaultPluginEvent.EndTxEvent);
}
else if (mi.DeclaringType == myType && mi.Name == "OnBeginTx")
{
Debug.WriteLine(" * " + mi.Name + " - REGISTERING"); eventCount += 1;
alNotifyEvents.Add(VaultLib.VaultPluginEvent.BeginTxEvent);
}
else if (mi.DeclaringType == myType && mi.Name == "OnLogin")
{
Debug.WriteLine(" * " + mi.Name + " - REGISTERING"); eventCount += 1;
alNotifyEvents.Add(VaultLib.VaultPluginEvent.LoginEvent);
}
else if (mi.DeclaringType == myType && mi.Name == "OnLogout")
{
Debug.WriteLine(" * " + mi.Name + " - REGISTERING"); eventCount += 1;
alNotifyEvents.Add(VaultLib.VaultPluginEvent.LogoutEvent);
}
else
Debug.WriteLine(" * " + mi.Name);
}
Any ideas?
Ken
Can you post the line where you call the Vault server to inform it that your plugin is calling VaultService to register the event?
Also, if you look in the sgvault database, does your tblplugins have an entry for your plugin? Another thing to check is the Vault server log file to see if there's an error trying to find your plugin.
Also, if you look in the sgvault database, does your tblplugins have an entry for your plugin? Another thing to check is the Vault server log file to see if there's an error trying to find your plugin.
Subscribe to the Fortress/Vault blog
Hey Jeremy -
I got it. I had moved the RegisterWithServer code out to its own class file, so in the register where it did a this.GetType() it was no longer looking at the ASMX class which had the events in it. Up and running! Here's an example of an entry this plugin creates for FB case 6411:
Ken
I got it. I had moved the RegisterWithServer code out to its own class file, so in the register where it did a this.GetType() it was no longer looking at the ASMX class which had the events in it. Up and running! Here's an example of an entry this plugin creates for FB case 6411:
I'll prepare this code for other's use and post it for the community's use if you'd like!Edited by Vault Checkin 5/9/2008 (Today) 2:31 PM
Ken Bonnin, Jr modified file(s) at 5/9/2008 2:31:14 PM, comments are:
6411 - Ahhh, looks like I've got all the register/unregister stuff working. I'm done for now!
The changes made are:
1$/tools/FogBugzVaultPlugin/webservice/fbvault.asmx.cs -- Checked In
1$/tools/FogBugzVaultPlugin/webservice/FogBugVaultPlugin.csproj -- Checked In
1$/tools/FogBugzVaultPlugin/webservice/Vault.cs -- Checked In
Ken
Groovy. Before I do, however, there's an issue of the Vault*.dll libraries. I just copied them into a folder for development, and the installer copies them into the plugin webservice; I'm not referencing the Vault*.dll libraries that the Vault server is using, just a copy.
Is SourceGear OK with my including those libraries in the installer? I plan on making the installer and full code available to community (and in fact, if you want to snarf it and include it in your product I'd be thrilled).
If I can't bundle the libraries, then I'll need to do a bit of work to correct that.
Ken
Is SourceGear OK with my including those libraries in the installer? I plan on making the installer and full code available to community (and in fact, if you want to snarf it and include it in your product I'd be thrilled).
If I can't bundle the libraries, then I'll need to do a bit of work to correct that.
Ken