Managing DXL Scripts on several client installations

SystemAdmin - Mon Feb 23 05:02:23 EST 2009
Hi,
The easiest way is to add a couple of registry keys to the client (Addins & ProjectAddins) where the data values are paths to network areas that all your DOORS users can read. The client will then search these areas for scripts during startup. 'Addins' is for formal module custom menus, 'ProjectAddins' is for Explorer level menus. The location in the registry should be something like HKEY_LOCAL_MACHINE\SOFTWARE\Telelogic\DOORS 9.1\Client\Config\Addins.
Regards,
Andrew

justus - Mon Feb 23 11:23:14 EST 2009
Does anyone know what we need to tweek to get that Registry Edit to work with 8.3 of the client?

Thanks,
Justus

llandale - Tue Feb 24 15:14:51 EST 2009
The idea is to put the DXLs on a single spot on some servers and instruct the DOORS clients to check that out when building menues, it does NOT copy DXL to the local client. I do recall in the old forums someone coming up with a method where each DXL first checked the server and copied new DXL to the local client. Don't see the point of that unless the server is 'far away' and module init times are slow building the menues.

IT departments all over are restricting install rights to the clients; thus folks more and more lack edit rights to the HKEY_LOCAL_MACHINE area of the Registry. They can, however, edit the HKEY_CURRENT_USER area to do the same thing, but it applies only to them not to all users of the machine. That is, edit:
HKEY_CURRENT_USER\Software\Telelogic\DOORS\8.3\Config, values 'addins' and 'projectaddins'. Never actually used it but DOORS gives a configuration utility to do this via dialog box.

You can do basically the same thing using DOORS icon command line switches, e.g.
"c:\Program Files\Telelogic\DOORS_8.3\bin\doors.exe" -a "\\MyServer\MyDxl\Addins" -J \\MyServer\MyDxl\ProjectAddins"

thus not modifying the registry at all.

> Louie

SystemAdmin - Tue Feb 24 17:57:36 EST 2009
Andy, Louie,

Thanks for the great instructions. Using the startup shortcut to redirect to a shared addins folder sounds like the best practice. I have two questions about the potential risks involved.

1) I tried redirecting my local addins directory to another location as a test. I'm using DOORS 9.1.0.2 by the way. When I started the DOORS client, I got a strange message asking me to locate the doors installer MSI. Any idea why that happened?

2) The addins directory is part of the larger DXL library. When you redirect just the addins sub-folder, is there a risk of breaking existing DOORS integrations? For example, would the DOORS-Change or DOORS-Team Foundation Server integration be affected? Would any of the standard integrations store files in the addins sub-folder? If so, this could make things confusing, especially if only some of the DOORS clients are using a particular integration.

SystemAdmin - Mon Feb 23 05:02:23 EST 2009
Hi,
The easiest way is to add a couple of registry keys to the client (Addins & ProjectAddins) where the data values are paths to network areas that all your DOORS users can read. The client will then search these areas for scripts during startup. 'Addins' is for formal module custom menus, 'ProjectAddins' is for Explorer level menus. The location in the registry should be something like HKEY_LOCAL_MACHINE\SOFTWARE\Telelogic\DOORS 9.1\Client\Config\Addins.
Regards,
Andrew

SystemAdmin - Wed Feb 25 17:51:52 EST 2009
We're having some trouble with the -Addins folder redirect switch.

The custom DXL scripts integrate with the “right-click menu” through-out DOORS. During a normal install the .dxl goes into \lib\dxl\config\*folderforscript* and \lib\dxl. It doesn't seem like there's a way to redirect those locations. Any Suggestions?

SystemAdmin - Tue Feb 24 18:03:16 EST 2009
Here's a followup question to any DOORS-Change users. In the recent versions of the integration, a new capability was added. The integration can be used to deploy any files you want beneath the DXL directory in your DOORS installation. It's talked about in the manual but I haven't tried this out yet myself. Has anybody else used this new feature to deploy DXL scripts? What was your experience with that approach? Would you say it's better or worse than maintaining a shared addins directory?

SystemAdmin - Wed Feb 25 17:51:52 EST 2009
We're having some trouble with the -Addins folder redirect switch.

The custom DXL scripts integrate with the “right-click menu” through-out DOORS. During a normal install the .dxl goes into \lib\dxl\config\*folderforscript* and \lib\dxl. It doesn't seem like there's a way to redirect those locations. Any Suggestions?

SystemAdmin - Thu Mar 05 12:54:48 EST 2009
I have set up our shortcuts to use the -a and -J flags. I have been able to successfully add scripts to the menu's inside of DOORS. I have found one problem so far and I was hoping someone might be able to help me. If you have the TFS integration installed (locally) you will get an error while trying to run a DXL script in the module window. The error states that it cant find a certain file, which does exist in the local file system. If we remove the flags from the shortcut, the TFS integration works, but we can't use our network shared integrations.

It seems to me that with these two switches the DOORS client ignores any local DXL scripts, is this true? Is there a way to work around this problem?

Tony_Goodman - Fri Mar 06 07:29:27 EST 2009
No that is not true.
The command line switches add additional paths to the addins and projectaddins environment variables.

Addins can be set in two ways:
1. By addition to the registry
2. By command line switch

Registry entries can be viewed by print getenv("ADDINS")
Comand line entries can be viewed by print getenv("DOORSADDINS")

Not sure what order DOORS checks these paths.

My instinct is that this is a bug in the TFS integration - they may have done something "clever" in the code that breaks when there is more than one addins path.

Try using the command line switch but with paths to the local install and see if that still breaks TFS.

SystemAdmin - Fri Mar 06 19:54:09 EST 2009
Good call Tony. Instead of using the -a flag, I put our custom script location in that registry key, using a semicolon, and it works fine!

Is there a way to add the "Projects" path to the registry? (-J switch)

Thanks for the help.

-Dan

SystemAdmin - Fri Mar 06 19:54:09 EST 2009
Good call Tony. Instead of using the -a flag, I put our custom script location in that registry key, using a semicolon, and it works fine!

Is there a way to add the "Projects" path to the registry? (-J switch)

Thanks for the help.

-Dan

Tony_Goodman - Mon Mar 09 05:24:01 EDT 2009
The registry key for database menu addins is PROJECTADDINS.

Did you tell IBM about the TFS issue?

Tony_Goodman - Fri Mar 06 07:29:27 EST 2009
No that is not true.
The command line switches add additional paths to the addins and projectaddins environment variables.

Addins can be set in two ways:
1. By addition to the registry
2. By command line switch

Registry entries can be viewed by print getenv("ADDINS")
Comand line entries can be viewed by print getenv("DOORSADDINS")

Not sure what order DOORS checks these paths.

My instinct is that this is a bug in the TFS integration - they may have done something "clever" in the code that breaks when there is more than one addins path.

Try using the command line switch but with paths to the local install and see if that still breaks TFS.

lnorton - Tue Apr 14 17:21:46 EDT 2009
Although this has been answered, we do it differently than any place else that I've seen. We store all dxl scripts on one server and instead of pointing to the local drive we point the home key to the server. We install the client from a Common LAN menu using a script and just include it there, no new registry values need to be created.

We then create custom menus.

We have found this to work beautifully because we can then add in any dxl to the menu no matter what directory it is in (doesn't need to be in the addins folder), we can call it whatever we want to instead of just a *.dxl name, and most importantly, we can control access through groups.