.NET Components: General Information

  • Component supporting files.
  • Unique NET Control Assembly names.
  • Supported .NET Control types.
  • Remote use: Webspace.

Component Supporting Files

Component supporting files are automatically created from the original .NET source assembly (e.g. ChartControls.dll).

Assemblies referenced by the source assembly and not installed in the assembly cache must be put in the same folder.

The component creation process creates the following essential files for a .NET source assembly to support hosting and communicating with all the components created from the selected controls in the source assembly:

File Description
<Occ><ordinal number>_<source assembly name>.dll: Component assembly
<Occ><the same ordinal number>_<source assembly name>.tlb Component type library
Note:
  • Occ is short for Orion COM Component (Orion is the original name of Component Client.).
  • Do not manually delete the essential supporting files.
  • Some temporary or debugging files may be created; they are not essential for the components to function.
  • If the same source assembly is selected to the Add Components process the second time, the ordinal number will increase.

Unique NET Control Assembly Names

A control assembly name (e.g. ChartControls) must be unique among all .NET control assemblies that are used to build CIMPLICITY containable components.

If a name is not unique unexpected results may happen as the .NET runtime will use the first loaded control assembly for all same named assemblies.

Note:
  • .NET has provisions to support loading assemblies with the same name but different versions.

However, that requires the versioned assemblies be signed and installed into the system assembly cache; this scenario is not appropriate to the current case and thus is not supported.

  • The full name (namespace and class name) of any .NET control must be unique.

Supported .NET Control Types

Component Hosting Release 1.0 supports following two .NET control types.

These types basically cover all .NET controls used for non-web-based applications.

Specifically, custom or third-party controls that are derived from the following .NET Framework 4.0 classes can be hosted:

WPF
  • System.Windows.UIElement
  • System.Windows.FrameworkElement
  • Any of the over 100 control classes in the System.Windows.Controls namespace
WinForms
  • System.Windows.Forms.Control
  • Any of the over 60 control classes in the System.Windows.Forms namespace.
Note: All custom controls must define a parameter-less constructor or no constructors at all (so the compiler will add a parameter-less one) in order for them to be created in an environment that no parameters may be passed to. This is the same requirement for all ActiveX controls working with a COM client and all .NET controls used by a user-interface configurable .NET environment.

Remote Use: Webspace

If  you are working remotely with CimView screens that include .NET components, use Webspace to insure that the components, which are ActiveX controls display and perform correctly.