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, 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.
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, its use makes unauthorized code changes very difficult to implement. Thus, strong naming can also be seen as a security measure. 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. You can choose to use strongly named assemblies with or without digital signing. Strong naming with digital signing is the most common choice. Assemblies with strong naming but no digital signing are a less common use case, but might be required in some environments.
Depending on the option you choose (see .NET clientdetails), .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 OpenEdge Development: .NET Open Clients.
Strong-named and signed Open Client Runtime assemblies