.Net SDK

We’re excited to announce we’ve released our .Net core SDK for Paydock. This is SDK makes is easier to use Paydock from any of the .Net based languages and deals with a lot of the plumbing necessary to make the HTTP calls.

Supporting .Net Core

We released our .Net 4.0 SDK earlier this year. We targeted .Net 4.0 as this was the most immediate need and most of our customers were running on .Net 4.0-4.5. However, we knew we’d also want to provide good support for .Net core.

When we built the .Net 4.0 SDK it was based around supporting the maximum number of developers, which limited our options. With the .Net core SDK we had more freedom to use more modern libraries and tools. The question for us was to find the best way to support both.

Option 1 – Complete re-write

We could release a completely new SDK, re-written from scratch. This would mean that we could choose the best tools, unencumbered by any limitations of .Net 4.0 era. However it would mean no re-use and any changes to the SDK would immediately have to be applied to both core and 4.0 SDKs.

Option 2 – Single codebase

We could completely re-use the codebase. This is a little problematic as some of the features used by the 4.0 SDK were not available in Core. We could handle this with pre-processor directives, however that can become difficult quickly. It also meant we could not support features asyc/await.

Option 3 – Partial Sharing

We could share some parts of the SDK between Core and 4.0. Essentially the .Net 4.0 SDK is: a HTTP wrapper, Models for request/response, helper classes and service classes that glue it together. Some of these can be completely shared (e.g. models), however others (e.g. HTTP wrapper) are more complex.

In the end, we decided to select this option.

Tech Details

Given that we’re sharing part of the code, it made sense to keep this in the same repo.

However, for ease of building the code, we split this into two separate solutions. For the .Net core app, we shared the code files as links, which meant we could add the Core SDK without significant restructuring to the existing codebase.

Functionally the two SDKs looks very similar (just add await), but under the sheets there are quite a few differences, including a heavier use of generics in the .Net core SDK.

We welcome feedback and we’d love to hear about how we can do this better in the future, feel free to raise an issue on github.

Find out more

JOIN THE EMAIL LIST

JOIN THE EMAIL LIST:*

We'll respect the heck out of your email. Seriously, we're no more fond of spam than you.

This website or its third-party tools use cookies, which are necessary to its functioning and required to achieve the purposes illustrated in the cookie policy. If you want to know more or withdraw your consent to all or some of the cookies, please refer to the cookie policy. By closing this banner, scrolling this page, clicking a link or continuing to browse otherwise, you agree to the use of cookies. Find out more.