Try OpenEdge Now
skip to main content
.NET Open Clients
Configuring and Deploying .NET Open Client Applications : Selecting a .NET Open Client Runtime package
 

Selecting a .NET Open Client Runtime package

.NET Open Clients use the .NET Open Client Runtime. This supports the AppServer, AppServerDC, AppServerS, and AppServerDCS and HTTP and HTTPS connection protocols on an intranet or internet. The assemblies that make up the .NET Open Client Runtime are:
*Progress.o4glrt.dll
*Progress.ssl.dll
*Progress.Messages.dll
Based on the run-time configuration you want to support, you have the option of selecting one of the following Open Client Runtime distribution packages:
*Strong-named and digitally-signed runtime package — Supports tightly secure .NET applications. If you use this set of Open Client Runtime assemblies, you must use these exact same assemblies for generating proxies both for building your .NET client application and for deployment. For OpenEdge product updates, you must regenerate your proxies using the new (updated) assemblies, rebuild your application using the updated proxies, and then deploy the updated proxy and application along with the new OpenEdge assemblies.
This configuration gives you the ability to strong-name the proxy and the .NET application. You can also digitally sign the proxy and .NET application. This configuration also allows you to load the OpenEdge .NET assemblies into the Global Assembly Cache.
This set of assemblies is located in:
OpenEdge-install-directory
\dotnet\deploy\strongnamed-signed
*Digitally-signed only runtime package — Supports .NET applications where security is not a high concern. You can use these assemblies to generate proxies and build and deploy your application. For OpenEdge product updates, you do not need to regenerate your proxies or rebuild your application. You can simply give your users the updated OpenEdge assemblies.
This configuration does not give you the ability to strong-name the proxy and the .NET application. As a result, this configuration prevents you from loading the OpenEdge .NET assemblies, the proxy, and the .NET application into the Global Assembly Cache. However, you can digitally sign the proxy and .NET application.
This set of assemblies is located in:
OpenEdge-install-directory
\dotnet\deploy\signed
Strong-named only runtime package — Supports a less common type of assembly required by some applications. The assemblies are strong-named but are not digitally signed. A strong-named assembly will allow the Windows system to determine the assembly's data-integrity (i.e., has it been altered since it was compiled and linked). But the strong-name cannot be used as a proof of authenticity because it lacks the digital signature that can be used to identify the author of the assembly.
If you use this set of Open Client Runtime assemblies, you must use these exact same assemblies for generating proxies both for building your .NET client application and for deployment. For OpenEdge product updates, you must regenerate your proxies using the new (updated) assemblies, rebuild your application using the updated proxies, and then redeploy the updated proxy and application along with the new OpenEdge assemblies.
This configuration gives you the ability to strong-name both the proxy and the .NET application. You can also have the OpenEdge .NET assemblies loaded into the .NET Global Assembly Cache. However, you cannot digitally sign the proxy or the .NET application.
This set of assemblies is located in:
OpenEdge-install-directory\dotnet\deploy\strongnamed
In ProxyGen, in the .NET client settings of the Generate Proxy dialog box, you can specify what distribution package to use. The selected assemblies are copied to the ProxyGen output directory (which is the location of the generated proxies).
Note: Only the message resources for the current locale are copied to the ProxyGen output directory. To support additional languages, you must copy the files yourself as described in Supporting localized messages for .NET client interfaces.
The classes in the .NET Open Client Runtime are written in C#, but can be accessed by any .NET language.
* Supporting localized messages for .NET client interfaces