Dynamics GP eConnect Can Work with .NET 5
.NET 5 has hit the scene and I have mixed feelings about it.
Microsoft introduced .NET Framework in 2002 for developers to create programs to run on Windows. Since then, many alternative computing platforms have gained significant use including Linux, macOS and other Cloud and mobile platforms.
In 2014 Microsoft announced .NET Core, which would allow .NET programs to run on both Windows and non-Windows platforms. At the same time, Microsoft released .NET licenses to an independent foundation so that control would be community-owned rather than corporate-directed. In the years that followed, both .NET Framework and .NET Core were actively developed with new features being added to each.
In 2019 the .NET Foundation announced that the next version of .NET Core would unify .NET Core and .NET Framework. That product is simply .NET 5 – neither Core nor Framework. No new features will be added or developed in .NET Framework and all future development will be in .NET.
.NET 5 offers a welcome relief to the struggle of choosing targets between Core or Framework. A unified target means less time spent on branching, building and deployment.
However, there are pieces of the aging .NET Framework that are not supported and will never be implemented in .NET 5. Third-party libraries with dependencies on unsupported elements will fail. It is in this environment that I set out to build a new Dynamics GP eConnect integration using a project that targeted .NET 5. I believe these same strategies will apply to older .NET Core projects as well.
The first hurdle I encountered was that .NET 5 does not support NamedPipes, which is a critical piece of the eConnect service architecture. The error thrown from eConnect was the following:
This error points to a somewhat known, but not widely documented feature of eConnect available as a workaround. When using the .NET eConnect libraries, there is a setting that allows the program to connect directly to the Dynamics GP SQL database without using the eConnect service. This feature is especially useful when deploying integration programs in an environment where it may not be possible to install the eConnect Windows Service at all. The flag is set by using the RequireProxyService property of Microsoft.Dynamics.GP.eConnect.eConnectMethods, which defaults to true. (Note: In Microsoft.Dynamics.GP.eConnect.GetNextDocNumbers and GetSopNumber the property is RequireServiceProxy). The property can be set discretely on each instance of an eConnect class created in code or, if using a config file, the following key can be appended to the AppSettings section, where it will be referenced by the eConnect objects.
Here’s an example:
Having conquered the connectivity issue, I immediately hit another error:
After some deep tracing and some Google-Fu, I determined the issue is that when eConnect sets up its event log pipeline, it relies on the CurrentPrincipal property of the executing Thread object to assign security.
.NET framework assumes that the executing user’s security can be passed on to the thread. Because .NET Core (and hence .NET 5) is cross-platform, it no longer makes that assumption, so it does not default any value to the CurrentPrincipal property.
I added the following code to explicitly assign the current Windows account as the thread security principal. This enables eConnect to set up logging properly and run as designed.
These small tweaks will get an eConnect integration up and running in .NET 5 but there are a few additional considerations. Bypassing the eConnect Windows Service requires the executing account to have direct access to the Dynamics GP SQL databases. This could result in reduced overall security at the database level. The thread security code will only work on Windows – other platforms will need to use another method of assigning a security Principal. Finally, there could be other pitfalls using the eConnect libraries on a non-Windows platform, but that is a project for another day.
About Tony Marinaro
Tony means business when it comes to efficiency. He loves turning an organization’s clunky procedures and tasks into lean, automated processes. Tony also enjoys helping companies put business intelligence to use, with the goal of helping them get meaningful information out of their business systems. He was affectionately nicknamed “Google” by co-workers because he always seemed to come up with the answers they needed.