Mix Gen 8.6 .NET 3.5 and .NET 4.x proxies in IIS with unique names

Products

Gen Gen - Run Time Distributed Gen - Workstation Toolset

Issue/Introduction

Migrating a Gen server application from Mainframe to Windows/.NET.
Have a transition requirement to have both the current .NET 3.5 proxies and the new .NET 4. proxies deployed to the same directory/application under IIS.

Is there a way to generate a Gen 8.6 .NET proxy with a different name than the Server Manager source name to avoid old and new proxies having the same names ?
For example:
For a Procedure Step named PStep1 and a Server Manager name of PSTEP1SM, the proxy code through the proxy generator is named PSTEP1SM.interfaces.dll and PSTEP1SM.components.dll.
There is no option to give the proxy dll files another name in the Proxy generator window.
If the proxy dll files were manually renamed would they still function correctly ? e.g. rename the dll files to new.PSTEP1SM.components.dll and new.PSTEP1SM.interfaces.dll
If unique naming is possible is it also possible to deploy the old and new dll files to the same same directory/application under IIS?

Environment

Gen 8.6 .NET proxy

Resolution

Proxy unique custom name

There is no option to change the name of a generated standard proxy in Gen.
Also the generated proxy dll files cannot be simply renamed.
Creating a custom proxy will allow the use of unique name for the proxy.
The steps required are listed below (refers to model name cstest1 with server PStep name SVR1 and its Server Manager name S1)

1. In Gen Studio:
  1. Under the PStep Interface Designer right click on the PStep name SVR1 and use "Create Interface" with name custom1.
    On the custom1 Input Mapping and Output Mapping tabs enable all import/export views with Mapping = "<Variable>" to replicate the full standard non-custom proxy.
  2. Under Custom Proxies use "Add Proxy Definition" with name custproxy1. Right mouse button on it and use "Add Proxy", selecting the custom1 interface.
2. In Gen Toolset under Proxy Generation > Custom Proxies generate and install custproxy1 for CLR/.NET/Local.
3. Create a new application in IIS for the built sample proxy with alias custproxy1 pointing to directory: cstest1.ief\proxy\NET\deploy\Custproxy1\samples\ASP.NET.
  By default it will usually be assigned to a .NET 4.x Application Pool e.g. DefaultAppPool.
4. Load the proxy (http://localhost/custproxy1/) and execute the customer interface custom1 to the server.
5. The default commcfg.txt placed into the directory cstest1.ief\proxy\NET\deploy\Custproxy1\samples\ASP.NET\bin has everything commented out.
  To enable trace add this line at the end:
  CMIDEBUG ON c:\temp\trace.out
  Restart IIS to pick up the change and then verify the proxy -> server coopflow details from the resulting trace.out file.

Deploying both NET 3.5 and .NET 4.x proxy dll files into the same directory

Per Gen 8.6 docs page "Technical Requirements > Third-Party Software Version"
"Gen .NET applications require a .NET v2.0 Application Pool. After applying RTA86103, Gen .NET applications require a .NET v4.0 Application Pool"
Similarly article 74016: Gen 8.6 applications .NET version support
Therefore on the assumption that the existing .NET 3.5 dll files are currently running under a CLR 2.0 Application Pool, as tested by Gen Support introducing the .NET 4.x dll files will cause a runtime exception e.g. "Could not load file or assembly... This assembly is built by a runtime newer than the currently loaded runtime...".
Additionally, trying to run the old .NET 3.5 configuration environment inside a CLR 4.x pool typically results in duplicate section errors in the web.config file unless extensive manual modifications are made.
If the entire application is migrated to a .NET 4.x Application Pool i.e. the .NET 3.5 standard proxy dll files S1.ASP.NET.dll, S1.proxy.dll are copied to directory cstest1.ief\proxy\NET\deploy\Custproxy1\samples\ASP.NET\bin, Support testing confirmed that both old and new proxy operations will execute successfully because the .NET 4.x Framework is backward compatible with the .NET 3.5 version dll files.
NOTE: There is no need to copy the S1.interfaces.dll file because the .NET 4.x version is already there and will function correctly with both proxy versions.
Details of testing the sample with both version dll files present:
1. Assuming the old .NET 3.5 samples directory is still available copy the Svr1.aspx file from directory cstest1.ief\proxy\NET\deploy\Svr1\samples\ASP.NET to directory cstest1.ief\proxy\NET\deploy\Custproxy1\samples\ASP.NET.
2. In directory cstest1.ief\proxy\NET\deploy\Custproxy1\samples\ASP.NET update the file operations.htm to add an extra line for standard proxy operation Svr1:
  <p><a href="custom1.aspx">custom1</a></p>
  <p><a href="Svr1.aspx">Svr1</a></p>
3. Load the proxy (http://localhost/custproxy1/) and execute both operations to verify success.

Therefore option #2 is the recommended solution.