SL 2011 introduced a ExecuteLocation field in modules table.
(Select ExecuteLocation from Modules where ModuleCode = 'xs')
I have several 3rd party apps all have same name prefix XS, if a product set
ExecuteLocation as a sunfolder in SL application, other products with prefix XS broken
Any suggestion to deal with the naming conflict?
I am not sure what you are saying here exactly. My company develops a large set of the programs that work under Dynamics SL and we place these in a folder under SL\Applications, assign them to a module and set the module execution folder to that folder and they launch just fine. It appears that you are doing the same with the old exception that you are using a 4 character folder name and we use a 2 character folder name which, as far as I know, should not be an issue.
I suggest that you double-check the definitions for your modules by first going the module maintenance under administration and make sure your module is there and the alternate location column has your folder name in it (not SL\Applications\XSBS but just XSBS). Next, go to screen maintenance and make sure your screens and reports have that same module indicator.
Let me know if all that is correct and you still have the issue and I will try a 4 character folder name and make sure that works.
Sorry I did not explain it clearly. Here is detail:
The 3rd party solution have 3 exe screens, one of them is XS97500. All installed in \Application\XSBS.
The solution automatically set alternative location to execute from as XSBS so they are called correctly from menu.
The problem is we have another XS screens in \Application root folder, since XS execute folder is set as XSBS subfolder, all the menu for other XS screens are also set to XSBS subfolder, therefore, the call failed.
You probably already know this but I do not want to assume. The Screen Maintenance process (found under Administration) defines the screens and reports that are available and for each screen or report there is an indication of the module the item belongs to. Under Module Maintenance, you can define an alternate location to execute from for screens and reports that belong to that module. So, it sure sounds like these 3 screens that live in the XSBS folder are members of a module with a specified alternate location and that the other screens that live in the application folder are also part of that same module. Therefore, when they are selected, the system looks in that same XSBS folder for them. Finally, Menu Maintenance defines a command line for each menu item and you can specify not only the name of the exe file but also a path name so it is possible that your issue could be affected by the menu setup as well.
I do have some more questions. First, when you say that the solution sets the alternate location, are you saying it does this programmatically or that the install sets up the module, screen and menu values? My next questions is: why do you not just move the XS programs into the XSBS folder instead of leaving them in the application folder since that is where SL wants to launch them anyway? I think I am still missing some of the reasoning behind your setup.
The application automatically installed and configured the database. I end up move delete the xsbs ExecuteLocation from Modules where ModuleCode = 'xs'. The make sure all XS are in root folder.
I have to live with that different modules from different vendors use same prefix.
Now I see. These are modules from different vendors both saying they are module XS. While shat you did works the other option would have been to assign a different module ID to the screens and reports from one of the vendors and set that up in the modules screen and the screen maintenance screen. I highly suspect that the actual programs do not care what module ID you give them. However, your solution works just as well as long as all the screens and reports labeled as an XS module live in the same location. Let's just hope that the two vendors do not end up with conflicting screen or report names.
I did do some testing and there is no problem with module IDs more than two characters that I could find so the two vendors could be a bit more verbose with the module ID they select.
Other Microsoft Sites
I'm a Customer
I'm a Partner
Follow Microsoft Dynamics