xfNetLink .NET, in conjunction with .NET Framework or .NET 6 and higher, enables you to create a .NET client for xfServerPlus. Using the component generation tools in xfNetLink .NET, you can create a Synergy .NET assembly that references Synergy methods defined in the SMC. (These tools can be accessed from within Workbench or from the command line.) The assembly can be used in any .NET environment to call routines residing on the Synergy server. For example, the client might be a Windows application written in a .NET-capable language such as C#, or a web application that uses ASP.NET, or a web service. We discuss a few of these options below in Development options. Although .NET is a Microsoft solution, your Synergy routines can reside on any supported Synergy platform.
Figure 1 shows the primary components of a distributed application that accesses Synergy code from a .NET Framework client. The diagram describes two machines:
- A client machine running xfNetLink .NET, .NET Framework (or .NET 6 and higher), and an application that uses a Synergy assembly. If you’re developing a two-tier system with a Windows client application, the client is the end-user’s machine. If you’re developing a three-tier system with a web client application, the client is the web server machine.
- A Synergy server running xfServerPlus, which handles the remote execution of Synergy routines. The routines are made available for remote execution by including them in an ELB or shared image and defining them in the Synergy Method Catalog (SMC), also located on the server machine. You can populate the SMC with routine information by entering it manually through the Method Definition Utility or by attributing your code, running dbl2xml to create an XML file, and then loading that file into the SMC. You may use multiple servers; each machine requires an xfServerPlus license.
xfNetLink .NET enables you to use your existing Synergy code without rewriting it, provided that the code is already written in the form of an external subroutine or function. If any of the routines require input from or send messages to the user, or if they might generate untrapped errors, they must be adjusted to work as server-level logic.
.NET Framework vs. .NET 6
In version 12 and higher, you can use .NET Framework or .NET 6 and higher with xfNetLink .NET. A good explanation of the differences between these technologies can be found at Differences Between .NET Framework, .NET Core, and .NET Standard.
How you create your assembly determines which .NET products and versions it will be compatible with:
- An assembly generated using the tools in Workbench will be compliant with .NET Framework 4.7.2 and higher.
- An assembly generated using the command line tools and built with the batch file will be compliant with .NET Framework 4.7.2 and higher.
- An assembly generated using the command line tools and built using the project generated by gencs is a .NET Standard DLL and will be compliant with .NET Framework 4.7.2 and higher as well as .NET 6 and higher .
If you’re developing a new application with xfNetLink .NET, you’ll probably want to use the method in bullet 3 and develop your application with .NET because that’s the direction Microsoft is going with its .NET development.
If you have an existing xfNetLink .NET application that you are updating, you’ll probably want to stick with the method you’re currently using.
Development options
ASP.NET and ASP.NET Core
Active Server Pages .NET are a combination of HTML coding and scripting language. For ASP.NET, the scripting language can be any Common Language Runtime-compliant language, such as C#. Using ASP.NET enables you to create a three-tier distributed system, which includes an end-user machine running a web browser, a web server where xfNetLink and your ASP.NET pages are located, and a Synergy server. ASP.NET requires a Windows web server running Microsoft IIS. ASP.NET Core is a redesign of ASP.NET; see Overview of ASP.NET Core on the Microsoft website for more information.
Web services
Web services are business components that provide functionality to a web or desktop application. They serve as “black boxes”: callers use the API that you publish and don’t need to know anything about the inner workings of the component. Web services provide you with discreet, reusable components. They are easily upgraded and can be called by multiple applications. Because web services are a .NET solution, you can write them in any language that supports .NET; however, they can be deployed only on Windows servers running Microsoft IIS.
A web service is not a complete solution. It is simply a component that is called by another application. Web services must be published on the web so that anyone can use them, which requires that you establish and adhere to strict security protocols.
