Configuring SmartPlant Foundation to load the custom assembly - SmartPlant Foundation - IM Update 44 - Customization & Programming - Hexagon

SmartPlant Foundation Customization

Language
English
Product
SmartPlant Foundation
Search by Category
Customization & Programming
SmartPlant Foundation / SDx Version
10

In each defined SmartPlant Foundation site, you can find a file named Settings.xml. Edit this file with a text editor and locate the node named <Modules>. This is where you need to add the custom project.

Ensure the server is not running when you edit this file and run iisreset from the command prompt.

If your custom assembly just contains interfaces and not Server APIs, you need to add an entry into the <CustomAssemblies> section.

<customassembly name="Training" filepath="SPFServerModuleTraining.dll" />

If your custom assembly contains Server APIs, it will need a module. You must also add lines similar to this towards the end of this block:

<module name="Training" assembly="SPFServerModuleTraining" classtype="SPF.Server.Modules.TrainingModule">

<modulehandlers default="Training">

<modulehandler name="Training" assembly="SPFServerModuleTraining" classtype="SPF.Server.Modules.TrainingHandler" />

</modulehandlers>

</module>

SHARED Tip It's always a good idea to compile into the current directory. However, you can prefix this entry with a file path.

On some systems that are running older versions of IIS and the worker process is aspnet.exe, you may experience problems having both entries and see duplicate class errors on startup. If you see these errors, remove the entry above.

Save this file and exit. The following is the complete text of the settings.xml file.

<?xml version="1.0" encoding="utf-8" ?>

<configuration>

<!--

CONFIG FILE SETTINGS

==========================================================================

<serverhandler name="" assembly="" classtype="" />

- use this to specify a new process request handler at the server level.

- you must provide a unique name, path to the assembly it is contained

within and the complete type name of the class to instantiate.

- different server handlers can be written to interpret different types

of xml request, e.g SPF requests and responses look totally different

to TEF ones.

<module name="" assembly="" classtype="">

- use this to specify a new module (BSL)

- the core modules should always be loaded, although they could be

overridden in a new assembly and then this could be referenced instead.

- custom modules could provide services such as progress or workflow.

- a new/updated serverhandler may need to be implemented so that requests

are routed to this new module.

<modulehandler name="" assembly="" classtype="" />

- use this to specify a new process request handler at the module level.

- this works much like a server handler except it operates at a module

level, it has more business logic in it associated with its particular

module.

<customassembly name="" filepath="" />

- used to load custom assemblies that may contain interface overrides eg: ISPFLoginUser1

but not modules. The filepath needs to be a full path to the dll.

  -->

<server>

<serverhandlers default="SPF40">

  <serverhandler name="SPF40" assembly="SPFServerModuleCore" classtype="SPF.Server.SPFHandler" />

  </serverhandlers>

<modules default="Core">

<module name="SC" assembly="SPFSchemaCompProvider" classtype="SPF.Server.Modules.SCModule">

<modulehandlers default="SC">

  <modulehandler name="SC" assembly="SPFSchemaCompProvider" classtype="SPF.Server.Modules.SCHandler" />

  </modulehandlers>

  </module>

<module name="Core" assembly="SPFServerModuleCore" classtype="SPF.Server.Modules.CoreModule">

<modulehandlers default="Core">

  <modulehandler name="Core" assembly="SPFServerModuleCore" classtype="SPF.Server.Modules.CoreHandler" />

  </modulehandlers>

  </module>

<module name="Progress" assembly="SPFServerModuleProgress" classtype="SPF.Server.Modules.ProgressModule">

<modulehandlers default="Progress">

  <modulehandler name="Progress" assembly="SPFServerModuleProgress" classtype="SPF.Server.Modules.ProgressHandler" />

  </modulehandlers>

  </module>

<module name="AppLayer" assembly="SPFServerModuleAppLayer" classtype="SPF.Server.Modules.AppLayerModule">

<modulehandlers default="AppLayer">

  <modulehandler name="AppLayer" assembly="SPFServerModuleAppLayer" classtype="SPF.Server.Modules.AppLayerHandler" />

  </modulehandlers>

  </module>

<module name="LoadPP" assembly="SPFServerModuleLoadPreProcessor" classtype="SPF.Server.Modules.LoadModule">

<modulehandlers default="LoadPP">

  <modulehandler name="LoadPP" assembly="SPFServerModuleLoadPreProcessor" classtype="SPF.Server.Modules.LoadHandler" />

  </modulehandlers>

  </module>

<module name="TEF" assembly="SPFServerModuleTEF" classtype="SPF.Server.Modules.TEFModule">

<modulehandlers default="TEF">

  <modulehandler name="TEF" assembly="SPFServerModuleTEF" classtype="SPF.Server.Modules.TEFHandler" />

  </modulehandlers>

  </module>

<module name="Training" assembly="SPFServerModuleTraining" classtype="SPF.Server.Modules.TrainingModule">

<modulehandlers default="Training">

  <modulehandler name="Training" assembly="SPFServerModuleTraining" classtype="SPF.Server.Modules.TrainingHandler" />

  </modulehandlers>

  </module>

  </modules>

<customassemblies>

  <customassembly name="Training" filepath="SPFServerModuleTraining.dll" />

  </customassemblies>

  </server>

  </configuration>