WebAdmin .Net Core Migration

With the new migration to .Net Core on WebAdmin, there are some dependencies that no longer work and/or are no longer supported. Special attention should be given to code that is shared between WebAdmin and the client project, such as GenioServer custom classes and GlobalFunctions Manwins. These include the following:

• iTextSharp
• CrystalReports

WCF Migration

For everyone who is using WCF in their client applications and webadmin, these will need to be adapted to work with the new changes in WebAdmin.

1. Move client classes to a new location

The WCF client classes should move to a .Net Standard 2.0 based project, this is so the same code can be shared between .Net Core and .Net Framework projects. We recommend putting them in CSGenio.core, which matches the requirements to comply with the migration.

Genio offers a way to create files in CSGenio.core, through a MANWIN of the type "CLASSES":

In the parameters, the syntax must be "core.". If needed, the WCF could be added to a subfolder, by changing the syntax and adding the folder name in between. On the image, the MANWIN code will be generated into CSGenio.Core (inside the folder "business", which is added by Genio), in a folder called "ServiceReference", with the filename "WebAdmin_Proxy.cs" (please note that the file extension is added automatically by Genio).

2. Adding WCF client configuration to appsettings.json

On .Net Framework projects using a WCF Client, it is most likely that the configuration was added to web.config and read automatically by the client itself. Since WebAdmin is now in .Net Core, web.config no longer exists and thus the configuration needs to be available on the appsettings.json file.

2.1 Adding the configuration

Despite being a json file instead of XML, a similar structure has been kept to resemble the original configuration. All the properties have to be added under a "Service" object, with two sub-properties "Endpoint" and "Bindings", like in the example below:

{
  "services": {
    "endpoints": {
      "WebAPISoap": {
        "address": "https://jenkinsvm/genioweblatest/admin/webapi.asmx",
        "maxItemsInObjectGraph": 750000,
        "binding": "basicHttpBinding",
        "bindingConfiguration": "BasicHttp",
        "userName": "QUIDGEST",
        "password": "12345"
      }
    },
    "bindings": {
      "basicHttpBinding": {
        "default": {
          "dnsIdentity": "localhost",
          "closeTimeout": "00:10:00",
          "openTimeout": "00:10:00",
          "receiveTimeout": "00:10:00",
          "sendTimeout": "00:10:00",
          "maxBufferSize": 20524888,
          "maxReceivedMessageSize": 20524888,
          "maxDepth": 150,
          "maxStringContentLength": 20400320,
          "maxArrayLength": 20524888,
          "maxBytesPerRead": 16384,
          "maxNameTableCharCount": 524888,
          "securityMode": "TransportWithMessageCredential"
        },
        "BasicHttp": {
          "dnsIdentity": "localhost",
          "closeTimeout": "00:10:00",
          "openTimeout": "00:10:00",
          "receiveTimeout": "00:10:00",
          "sendTimeout": "00:10:00",
          "maxBufferSize": 20524888,
          "maxReceivedMessageSize": 20524888,
          "maxDepth": 150,
          "maxStringContentLength": 20400320,
          "maxArrayLength": 20524888,
          "maxBytesPerRead": 16384,
          "maxNameTableCharCount": 524888,
          "securityMode": "TransportWithMessageCredential"
        }
      }
    }
  }
}

In the example, the endpoint configuration is wrapped in a "WebAPISoap" object, this name is VERY IMPORTANT to fetch the configuration later on. You can choose to name it something custom, but if you want it to read the configuration automatically, it should match the "ConfigurationName" on the ServiceContractAttribute, on the WCF Client.

2.2 Reading configuration into WCF client

There are two ways of importing the configuration into the WCF client, both using classes that Genio makes available for this purpose.

RECOMMENDED Using the ClienteBaseFactory<> to build client:

This is the best way of using the provided classes to fetch the configuration. You can use the static methods in the ClientBaseFactory<> to instance the WCF client, passing the WCF interface as the type, if the appsettings configuration matches the "ConfigurationName" (as mentioned in step 2.1) it should be read automatically.

In case you have specified a custom ConfigurationName in the endpoint configuration, the value can be passed through the GetServiceClient() method. A custom XML besides the appsettings.json can also be used, the GetServiceClient() also has an overload to receive an IConfiguration object.

Passing through the WCF constructor:

This might be the easier way of adapting current implementations, where the developer only needs to instance the EndpointFactory that fetches the configuration and feed it to the WCF through its constructor, but it is not recommended.

(optional) 3. Update the webservice endpoints

When migrating to core, keep in mind that the webservice endpoints are case sensitive, which means that if you were sending SOAP requests to webapi.asmx, for example, this should now be WebAPI.asmx.

https://jenkinsvm/GQTADMIN/webapi.asmx -> https://jenkinsvm/GQTADMIN/WebAPI.asmx

https://jenkinsvm/GQTADMIN/usermanagement.asmx -> https://jenkinsvm/GQTADMIN/UserManagement.asmx

Errors in WCF client

If you have a generated class and you are facing issues migrating following the steps above, your WCF class is throwing errors, you may need to generate again using a recent version of svcutil.

First off, start by installing the latest version with the dotnet package manager:

Now, using the new package, you can generate the client class one of two ways:

• Using the original WSDL file:

• Using the SOAP Endpoint:

The WCF client code will be in the file "Reference.cs", located in the path you were positioned on the moment the svcutil was executed. You can now try following the steps again with the newly generated code, ensuring it also works on the client project (in .Net Framework).