Sage Evolution SDK Certificate Expiration

Introduction

The Sage Evolution SDK (Software Developers Kit) is an assembly file (Pastel.Evolution.dll) developed within the .NET Framework which allows 3rd party developers to integrate directly with the Sage Evolution 200 application.

The Sage Evolution SDK contains all the business logic in order to successfully process certain transactions and source documents within the Sage Evolution 200 application.

The certificate with which the SDK has been signed with over the last couple of years, is due to expire on 12 November 2021 and may no longer validate successfully going forward for such customers depending on the custom software development architecture which was used.     

Two ways of implementing the Sage Evolution SDK 

A) Using the .NET Framework

This type of implementation is done by utilizing the Sage Evolution SDK natively within a .NET project.

For example:

A developer making use of Visual Studio in order to develop an application in either C# or Visual Basic.NET

B) Using COM Interop 

This type of implementation is done by utilizing the Sage Evolution SDK using other coding languages outside of the Microsoft .NET Framework.

For example:

A developer developing an application using either Delphi, VBA, Visual Basic 6, Python, Java, PHP etc.

Impacted 3rd party applications using the Sage Evolution SDK

Application developed using the .NET Framework in theory should not be impacted by the expiring certificate which is majority of applications. If an application was developed using C# or Visual Basic.NET, there should be no impact on the client’s side.

Only applications developed via the COM Interop architecture will be affected and only within specific scenarios. If an application was developed using either Delphi, VBA, Visual Basic 6, Java, PHP, or Python there might be an impact on the client side which will be explained a bit more in-depth down below. 

3rd party applications developed using COM Interop

Third party application which are developed via COM Interop might need to be recompiled using the latest Evolution SDK for that specific version which got impacted. Below is a list of all the various impacted versions of the Evolution SDK:

Version 7.20.xx

  • v 7.20.0.68 up until v 7.20.0.83

Version 10.00.xx

  • v 10.0.0.4 up until v 10.0.0.25

Version 10.1.xx

  • v 10.1.0.0 up until v 10.1.0.36

If an application was developed using COM Interop and the application made use of one of the above Evolution SDK versions, the application may have to be recompiled ONLY under the following circumstances:

  • If the application is a brand-new application in the process of being developed and the developer must register the ‘Pastel.Evolution.tlb’ (type library) via the GAC Utility.
  • If it’s is an existing application which needs to be installed at the client for the first time and the client must register the ‘Pastel.Evolution.tlb’ (type library) via the GAC Utility.

In both scenarios the developer would need to:

  1. Replace the Evolution SDK with the latest version of that specific SDK assembly.
  2. Recompile the client application
  3. De-register the previous of the ‘Pastel.Evolution.tlb’ (type library) via the GAC Utility.
  4. Register the latest ‘Pastel.Evolution.tlb’ (type library) via the GAC Utility.

Questions which may arise & answers

1. Can we update our clients with the latest signed SDK dll's or should wait for the customer's Evolution installation to be updated?

Answer:  If your solution uses one of the above SDK versions and requires the SDK to be registered using GAC Utility you will have to make use of the latest signed SDK which will then also include the customer to upgrade his Evolution. This would ONLY be for new installs of your solution or having to again register the SDK using the GAC Utility.

PS: However, it’s advisable that if the customer upgrade the Evolution application, the SDK is upgraded as well.

2. If our apps using SDK dll's are signed with the expiring certificate will they continue to run uninterrupted, or will Windows block them from being loaded by our app?

Answer: In theory they should still be running fine. We have conducted some tests on our side which stated this but obviously we are not in a position to replicate each and every scenario that an ISV could use or mimic their application. If the application however runs using elevated privileges there could be a risk of failure after the 12th of November 2021.

3. What is the recommended guideline if an application was developed using Python? Is the COM Interop required?

Answer: If standard Python is used for development you would need to go the route of COM Interop. Therefore, the developer would need to register via the SDK assembly via the GAC Utility. If a developer decides to take the .NET route, he/she would need to develop using either ‘Python for.NET’ or ‘IronPython’.

Anonymous