InRule support for .NET Core takes the form of additional support in the NuGet packages. The InRule.Common, InRule.Repository, and InRule.Runtime packages contain libraries that target both the full .NET Framework 4.7.2 and .NET Standard 2.0. This allows you to use the runtime SDK in either framework.
This topic describes this support in more detail.
Which Framework Should I Use?
The choice of whether to use the full .NET Framework or the .NET Core Framework is not a simple one. .NET Core is Microsoft's future direction, and their guidance is to use .NET Core, unless you can't.
InRule recommends .NET Core in these situations.
- You want to migrate away from the Windows platform
- You are beginning a new development project
- You want to take advantage of the newest framework technologies
- You expect a performance benefit from using .NET Core
Here are some reasons you might want to use the full .NET Framework.
- You have an existing implementation with a relatively small number of irServer cores
- You require functionality that .NET Core does not provide
You should not attempt to mix the full .NET Framework and the .NET Core Framework in the same application. Doing so would give unpredictable results.
Setting up irSDK for .NET Core
To use the irSDK support in .NET Core, first install InRule version 5.1.0 or later on a Windows computer, selecting the irSDK component. This places the NuGet packages in the install directory, under irSDK\NuGetPackages. From there, deploy the NuGet packages as you would otherwise.
Based on your license type, you may need an additional license to use the .NET Core Framework.
Of course, you still have to activate irSDK. On a non-Windows computer, the InRule Activation Utility is not available because it has a Windows user interface. Instead, you may download the .NET Core activation utility from the InRule support site, support.inrule.com. This utility is a command line program which you must run on the computer where you deploy irSDK.
To run the Activation Utility on Linux, for example, enter the command dotnet ActivationUtility.dll, followed by command-line parameters, as outlined in License Activation Utility. Since the Windows Event Log is not supported on non-Windows platforms, the parameters -il (Install Log) and -ul (Uninstall Log) are not supported.
After completing license activation on Linux, the InRuleLicense.xml file will be stored by default in the home directory of the user that activated the license, e.g. ~/.inrule/InRuleLicense.xml. This file may be moved to /etc/inrule/InRuleLicense.xml so that irSDK may be licensed for the system, not just the current user. The license file may also be copied to the directory of the application that consumes irSDK.
irSDK Limitations in .NET Core
At this time, .NET Core support consists strictly of the irSDK runtime. These InRule components are not included:
- irServer Rule Execution Service. You may engage InRule ROAD Services if you want help writing a service wrapper.
- irAuthor, irCatalog, irWord, etc.
There is no installation program, per se.
Some Rule Actions are not available in .NET Core.
- Execute Web Service (Execute REST Service is supported)
- Execute Workflow
- Execute SQL Query with an Oracle or OLE DB Endpoint (SQL Server and SQLite Databases will work as expected)
irAuthor: irAuthor does not currently identify unsupported Rule Actions.
The .NET Assembly Schema element supports a .NET Standard assembly, but not a .NET Core assembly.
POSIX: irSDK for .NET Core does not support en-us-POSIX.
InRule Catalog Service: The InRule Catalog Service uses WsHttpBindings by default, but .NET Core can only use BasicHttpBindings.
Here is a sample WCF configuration for the IIS Catalog Service:
<system.serviceModel>
<bindings>
<wsHttpBinding>
<binding name="WSHttpBinding" maxReceivedMessageSize="50000000">
<readerQuotas maxStringContentLength="50000000" />
<security mode="None">
<!-- **WARNING** Changes to the security binding must also be made in
client binding code -->
<transport clientCredentialType="None" proxyCredentialType="None" />
<message clientCredentialType="None" />
</security>
</binding>
</wsHttpBinding>
<basicHttpBinding>
<binding name="BasicHttpBinding" maxReceivedMessageSize="50000000">
<readerQuotas maxStringContentLength="50000000" />
<security mode="None">
<transport clientCredentialType="None" proxyCredentialType="None" />
</security>
</binding>
</basicHttpBinding>
</bindings>
<services>
<service name="InRule.Repository.Service.RepositoryService"
behaviorConfiguration="repositoryServiceBehavior">
<endpoint address="" binding="wsHttpBinding"
bindingConfiguration="WSHttpBinding"
contract="InRule.Repository.Service.ICatalogServiceContract" />
<endpoint address="core" binding="basicHttpBinding"
bindingConfiguration="BasicHttpBinding"
contract="InRule.Repository.Service.ICatalogServiceContract" />
<!-- ** NOTE Metadata not supported SSL at this time **-->
<!--<endpoint address="mex" binding="mexHttpBinding"
contract="IMetadataExchange"/>-->
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="repositoryServiceBehavior">
<serviceDebug httpHelpPageEnabled="true" />
<!-- Enables the IMetadataExchange endpoint in services that -->
<!-- use "metadataSupport" in their behaviorConfiguration attribute. -->
<!-- In addition, the httpGetEnabled and httpGetUrl attributes publish -->
<!-- Service metadata for retrieval by HTTP/GET at the address -->
<!-- "http://localhost:8080/SampleService?wsdl" -->
<!-- ** NOTE Metadata not supported SSL at this time **-->
<!-- <serviceMetadata httpGetEnabled="true" httpGetUrl=""/>-->
</behavior>
</serviceBehaviors>
</behaviors>
<serviceHostingEnvironment multipleSiteBindingsEnabled="True" />
</system.serviceModel>
Here is a sample WCF configuration for Windows Service Catalog Service:
<system.serviceModel>
<bindings>
<wsHttpBinding>
<binding name="WSHttpBinding" maxReceivedMessageSize="50000000">
<readerQuotas maxStringContentLength="50000000" maxNameTableCharCount="50000000" />
<security mode="None">
<!-- **WARNING** Changes to the security binding must also be made in
client binding code -->
<transport clientCredentialType="None" proxyCredentialType="None" />
<message clientCredentialType="None" />
</security>
</binding>
</wsHttpBinding>
<basicHttpBinding>
<binding name="BasicHttpBinding" maxReceivedMessageSize="50000000">
<readerQuotas maxStringContentLength="50000000" />
<security mode="None">
<transport clientCredentialType="None" proxyCredentialType="None" />
</security>
</binding>
</basicHttpBinding>
</bindings>
<services>
<service name="InRule.Repository.Service.RepositoryService"
behaviorConfiguration="repositoryServiceBehavior">
<endpoint address="http://computername:8082/InRuleRepositoryService_v5.0.29"
binding="wsHttpBinding" bindingConfiguration="WSHttpBinding"
contract="InRule.Repository.Service.ICatalogServiceContract" />
<endpoint address="http://computername:8082/InRuleRepositoryService_v5.0.29/core"
binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding"
contract="InRule.Repository.Service.ICatalogServiceContract" />
<!--<endpoint address="mex" binding="mexHttpBinding"
contract="IMetadataExchange" />-->
</service>
</services> <behaviors>
<serviceBehaviors>
<behavior name="repositoryServiceBehavior">
<serviceDebug httpHelpPageEnabled="true" />
<!-- Enables the IMetadataExchange endpoint in services that -->
<!-- use "metadataSupport" in their behaviorConfiguration attribute. -->
<!-- In addition, the httpGetEnabled and httpGetUrl attributes publish -->
<!-- Service metadata for retrieval by HTTP/GET at the address -->
<!-- "http://localhost:8080/SampleService?wsdl" -->
<!-- ** NOTE Metadata not supported SSL at this time **-->
<!-- <serviceMetadata httpGetEnabled="true" httpGetUrl=""/>-->
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
Known Issues
At runtime, Windows and Linux behave differently in some cases.
Culture-specific string comparisons: On Windows, comparing "Straße" = "Strasse" results in true. On Linux, the same comparison results in false.
Date round tripping: Converting a date to a string and back can give incorrect results. For example, 1/16/2067 converts to the string "1/16/67" which then converts to the date 1/16/1967.
InRule recommends you do not convert dates to strings.
Serialization with BinaryFormatter: When serializing Entity or Session state and using a bound .NET Assembly configured to use BinaryFormatter, any DateTime.Kind will not be preserved when deserializing; it will always default to DateTimeKind.Unspecified. This is a known issue in .NET Core.
The RuleApplicationDef or any Def instance that includes a collection will fail to serialize with BinaryFormatter because the .NET Core version of CollectionBase is not marked as [Serializable]. This affects both Windows and Linux.
Logging
InRule uses the Windows Event Log for its logging. Since this is not available on other operating systems, any attempt to use it will fail in .NET Core.
Performance Considerations
In benchmark tests at InRule, the same Rule Application was run on various operating systems and platforms. Here are the execution times, in milliseconds.
Platform |
Windows |
Linux |
.NET Framework 4.6.2 |
1423 |
N/A |
.NET Core 2.0.7 |
1382 |
2097 |
.NET Core 2.1.0 Preview 2 |
1312 |
1555 |
Mono 5.10 |
1628 |
1898 |
This shows that the .NET Core Framework generally outperforms the full .NET Framework, and that it is improving. It also shows that .NET Core on Windows performs better than the same test on Linux.
Comments
0 comments
Please sign in to leave a comment.