C# Context Classes

Using .NET for implementing context classes is a bit simpler than implementing C++ context classes, since .NET provides a dynamic interface, and thus, no context class factory has to be provided. Context classes are assigned by the class name assigned to the database or GUI resource.

Context classes have to be linked into a dynamic library. Usually, separate libraries are provided for database context classes (business rules) and GUI context classes (application rules). The name of context class library has to be defined in the resource database (database context library) and /or in the application's configuration or ini-file (option variables CTXI_DLL for database context library and PROJECT_DLL for GUI context library).

Loading managed assemblies from the network by default is restricted to assemblies with a strong name (read signed assemblies). If you require to load your context assemblies from a network share you have three options:

• Using signed assemblies - This is the most secure option although the most inflexible one too (see Versioning and signing .Net context assemblies).
• Register trusted host: One may include the host that provides the network share into the list of trusted hosts (usually when loading unsigned assemblies from a host it should be trusted anyway). To do that see http://support.microsoft.com/kb/174360.
• General permission: One may generally allow assemblies loaded from the network (not suggested, since this allows any webpage to do anything on the pc as soon starting browsing using the internet explorer).

In order to enable secure execution of .Net assemblies from a network share, one has to assign what Microsoft(tm) calls a 'Strong Name' and what practically means signing them. Microsoft decided that only signed assemblies are allowed to link against signed assemblies which means that one has either to sign everything or nothing. Futhermore, using a signed assembly ties the component to the exact version of the assembly, and thus, it is strongly recommented to use assemblies with properly set AssemblyVersionAttribute, which allows using different versions at the same time.

The general process of signing .Net assemblies is described in detail at http://msdn.microsoft.com/en-us/library/xc31ft41.aspx. There is also a trick documented in order to sign third party assemblies (see http://buffered.io/2008/07/09/net-fu-signing-an-unsigned-assembly-without-delay-signing/), although doing so, most propably one will violate license agreements with that third party vendor.

For enabling signing C# context assembly from the ODE ClassEditor please follow the subsequent steps:

• When there is no key available for signing the assembly, a key has to be generated by starting Visual Studio command line and run: sn -k <path-to-your-key>.
• In the `bat' subdirectory of the ODE project directory open the `vsdll_cs.bat' and append the following line: /KEYFILE:<path-to-your-key>

That's it. From now on C# context assembly should be signed automatically when using the build function provided in the ClassEditor.

In order to enable versioning all one has to to is to create a file called `<name-of-assembly>.cs' in the `rc' subdirectory of the project directory. The content of that file should look more or less like the code in the Example below. That's all, from now on the assembly will get new version everytime when it is build. For major and minor version changes one has to adjust the `AssemblyVersionAttribute' manually.