The .NET proxy generation options also allow you to choose from three alternative Open Client Runtime assemblies to use and deploy with your .NET proxy, depending on the level of security that your executable code demands.

The basic difference between these assemblies for Open Client deployment is that the most secure runtime assemblies require more of your executable code to be rebuilt when you make a change to the Open Client application:

  • Strong-named and signed Open Client Runtime assemblies

    This is the most secure option because Progress Software Corporation builds the OpenEdge .NET assemblies both strong-named and digitally signed. Strong-naming an assembly guarantees that the assembly contents have had no unauthorized changes (without a spoof being detected) and digitally signing the assembly identifies who created it (Progress Software Corporation). Using strong-named Open Client Runtime assemblies supports the following options and requirements:

    • You can strong-name both the proxy and the .NET application, and you can digitally sign the proxy and the .NET application. If you want, for a .NET Framework application, you can also have the OpenEdge .NET assemblies loaded into the .NET Global Assembly Cache.
    • When you are ready to deploy updated OpenEdge .NET assemblies, you must regenerate the proxy and rebuild the Open Client application, then redeploy all the files.
    • After installing any service pack or other fix, you must regenerate the proxy and rebuild the Open Client application, then redeploy all the files.
  • Signed-only Open Client Runtime assemblies

    This is the less secure option because Progress Software Corporation builds the OpenEdge .NET assemblies digitally signed, but not strong-named. Digitally signing an assembly identifies who created it (Progress Software Corporation), but does not guarantee that the assembly contents have had no unauthorized changes (allowing a spoofed assembly to go undetected). Using signed-only Open Client Runtime assemblies supports the following options and requirements:

    • This is the default option, allowing the least disruption during redeployment, in exchange for lessened security.
    • You cannot strong-name either the proxy or the .NET application; but you can digitally sign both the proxy and the .NET application. You also cannot have the OpenEdge .NET assemblies loaded into the .NET Global Assembly Cache.
    • When you are ready to deploy updated OpenEdge .NET assemblies, you can simply redeploy the updated .NET assemblies without redeploying the proxy or Open Client application.
    • After installing any service pack or temporary fix, you can simply redeploy the updated .NET assemblies without deploying the proxy or Open Client application.
  • Strong-named (but unsigned) Open Client Runtime assemblies

    This is a less common type of assembly required by some applications. The assemblies are strong-named but are not digitally signed.

    Note: Using the strong-named ONLY versions of the open client assemblies should be avoided as much as possible unless a very specific need is identified that requires their use.

    Using strong-named-unsigned Open Client Runtime assemblies supports the following options and requirements:

    • You can strong-name both the proxy and the .NET application. You can also have the OpenEdge .NET assemblies loaded into the .NET Global Assembly Cache.
    • When you are ready to deploy updated OpenEdge .NET assemblies, you must regenerate the proxy and rebuild the Open Client application, then redeploy all the files.
    • After installing any service pack or other fix, you must regenerate the proxy and rebuild the Open Client application, then redeploy all the files.
Note: The strong naming process allows applications to precisely match the version of a DLL needed by a caller. In environments where several versions of an assembly might be needed to support multiple products or versions of the same product, strong naming is vital. Because strong naming uses several criteria to precisely identify the version of a DLL, it helps with dependency resolution. Strong naming entails the overhead of more careful code management. For this reason, you should carefully research the pros and cons of strong naming before enabling this option. Strong naming with digital signing is the most compatible choice. Assemblies with strong naming but not digital signing are less common and should be avoided unless absolutely necessary.

Depending on the option you choose (see .NET client details), .NET proxy generation causes the corresponding Open Client Runtime assemblies to be copied to the output directory for ease of deployment (See the Output Directory field described in General settings for proxy generation).

ProxyGen generation performs the following actions, writing any output to the output directory that you specify in the generate preferences (Output Directory in the general settings):

  • Saves the Open Client interface definition to the project file
  • Performs Open Client interface validation
  • Generates a Java proxy, .NET proxy, and/or SOAP Web service definition, as specified
  • For .NET proxies, provides a copy of the selected Open Client Runtime assemblies

For more information on the generated proxy for a .NET client and working with the different runtime assemblies, see .NET Open Clients.