WCF Web Service Consumers
Magic xpa provides WCF consumption capabilities, including the loading and executing of WCF Web services. Access to the WCF services is provided using .NET integration via Magic’s Composite Resource Repository (CRR).
Once a service is selected in the CRR, it is compiled into a C# file by SvcUtil.exe (https://msdn.microsoft.com/en-us/library/aa347733(v=vs.110).aspx), and then compiled (by the Studio) into an assembly.
If the service cannot be loaded into a C# file, errors are written to a log file in the WCFClientModules\Temp folder. The same errors can also be seen in the tooltip of the error icon in the CRR.
The assembly compiled from the WCF service is base64-encoded and is saved in the project’s source file (Comps.xml).
The content of the configuration file (generated by SvcUtil.exe) of each loaded service is automatically saved (by the studio) in the project’s source file and merged into the following two files in the WCFClientModules folder, which are referenced by MgxpaRuntime.exe.config:
Using these definitions, you can configure the client, including the endpoint, security, and so on.
Note: The compiled assembly and configuration file generated by SvcUtil.exe will remain in the assembly’s folder, allowing an additional option for consuming the service for developers familiar with WCF.
However, execution of each WCF component is done from memory (the base64-encoded assemblies) rather than the assemblies in the file system.
When you export WCF components, the base64-encoded assemblies’ code and configuration entries are exported.
When you import WCF components, the configuration entries are merged into the system.servicemodel.client.config and system.servicemodel.bindings.config files.
Note: Unlike the initial loading of a WCF service, importing the sources will not create the assembly in the file system (WCFClientModules) that were saved for manual testing purpose during the initial loading of the service.
When consuming a WCF service configured to use Windows authentication, after importing the WCF Consumer project export (created on another machine), you need to either reload the component or change the machine name in the userPrincipalName property in the WCFClientModules\system.servicemodel.client.config file. This is required because when the WCF component is generated, it creates a configuration specific to the machine (the logged on user when Windows authentication is used) and this configuration is not changed when you import a project or a WCF component.
Generated assemblies, configuration files, and entries merged into the configuration files in the WCFClientModules file are not deleted. This is because the assemblies and configuration entries might still be in use by other Magic xpa projects being developed on the same machine.
If there are multiple endpoints (such as WSHttpBinding_ICalculator_EP1 and WSHttpBinding_ICalculator_EP2 below) in the configuration file with an identical contract= (such as ServiceReference1.ICalculator below), you need to specify which endpoint to use while instantiating the WCF client proxy (using a non-default constructor). For example:
<?xml version="1.0" encoding="utf-8"?>
Each operation in the Web service is exposed as a method in the .NET reference.
Arguments sent to the Web service and processed after completing the Web service call are managed using .NET integration, settings and getting values on/from the service reference.
Executing a service
Executing the Web service client is similar to executing any .NET assembly, with one exception – the assembly content is in the project’s source file rather than in the file system.
The existing MgxpaRuntime.exe.config can be used to control the Web service’s security and other behaviors, similar to any WCF consumer application.
The WCFClientModules folder should be copied from the development machine into each deployment machine. This is similar to the Invoke Web S operation.
Loading a WCF Component from Behind a Proxy Server