Jiwa

Is there any way to use the Jiwa DLLs in a .net core application, provided it runs under Windows as I don't believe the Jiwa DLLs are seen as conforming to any of the .net "Standards"?

Whilst I've been able to compile a core program with them as soon as you call logon, you get exceptions.

SBarnes wrote:Is there any way to use the Jiwa DLLs in a .net core application, provided it runs under Windows as I don't believe the Jiwa DLLs are seen as conforming to any of the .net "Standards"?

Whilst I've been able to compile a core program with them as soon as you call logon, you get exceptions.

I believe the short answer will be 'not easily, if at all'. .NET Framework and .NET Core are not nearly as compatible as their naming would suggest.

Besides Jiwa itself, it has many third party dependencies, and they would all need to be 'compatible' to have success.

You'd probably have a better experience having your .NET Core applications communicate with the JIWA REST API running on a JIWA Server. That could arguably be considered a better architecture, too.

Hi Ryan,

Thanks for the feedback, you are largely confirming what I had suspected is the case given my knowledge of core, I had also thought of the Rest API solution also given ServiceStack's support .net core but had hoped to avoid the double handling if I could.

Pretty much what Ryan said.

It would be a bit of an effort to separate out the bits which could target the .NET Standard 2.1 and thus be used by both .NET Core (or .NET 5 as the next version of .NET Core will be known) or the classic .NET Framework.

Mainly we'd "just" need to move dependencies on things like Crystal Reports and all Windows Forms related stuff to be it's own set of .NET Framework assemblies, and the core business logic could then target .NET Standard and those would be able to be referenced by both .NET Framework apps and .NET Core apps.

It would mainly be the Business Logic DLLs that would matter as obviously the user interface relies on third party controls etc, the reason for looking at Core is obviously that's going to be the way forward with recent decisions from Microsoft and Core does support a number of features in terms of dependency injection and lose coupling etc that make it an attractive choice going forward.

I would imagine though supporting .Net Standard 2.1 would be a pretty big undertaking given the scope of business objects in the system without a huge ROI.