NuGet Packages: Upgrading to the .NET Standard

As the technology landscape has evolved from more platform-constrained deployments to more generalized solutions, the introduction of the .NET Standard has made it easier than ever to support a wide range of platforms and applications.

For an organization such as Service Objects, with many customers spread out among an increasingly large number of different platforms, it would be quite challenging to create and continually rewrite our NuGet API client for each and every client. However, with this new framework, we are able to rewrite our existing NuGet packages only once, which considerably reduces our time spent tailoring solutions to specific customers, as this framework supports just about every needed .NET platform natively.

One example is the first NuGet package that we released in the .NET Standard, Address Validation – US. The NuGet package that was released for Address Validation – US many years ago was functional and fit the needs of our customers at the time, however, as time went on many features of that code started to become outdated as the industry evolved.

These design features, such as the native client for .NET 4, made sense at the time as there were no alternative versions of .NET. The introduction of .NET Core and .NET 6+ necessitated the switch to a more generalized solution.

This first required a fairly large investment to rewrite the entire integration client with newer features, such as swapping the XML endpoint to use the newer JSON endpoint and creating an http client that could desterilize the API return data into any arbitrary C# class. However, for future integrations, we would end up saving significant time and costs associated with the conversion.

Advantages of our newly designed NuGet packages

Our newly designed NuGet packages have several useful features for our clients. The first is that it works on both our production and trial endpoints, which allows seamless conversion from an initial testing period to fully adaptable production code. This means that in order to deploy to production you will only need to add a production license key, as the trial license keys only work for trial endpoints and you will need to switch the IsLive parameter to true instead of false.

The second is that it has failover implemented as part of the package, which will automatically switch from the primary production server to our backup server in case of possible outages in service. The failover that is implemented in the packages reduces the amount of code needed to implement the service in your systems and ensures that with failover implemented you are using best practices ensuring 99.999% uptime.

Lastly, our service also provides the strongly typed objects needed to deal with the response from the service, making response handling much simpler and requiring minimal effort to integrate.

Keeping NuGet packages up-to-date

Many of Service Objects’ NuGet packages written in .NET 4 have already been converted into the .NET Standard, with more being continually converted to support newer platforms every day. These packages are available through NuGet.org and can be locally installed on any system using Visual Studio or manually using the .NET command line tool.

Service Objects continues to maintain support for legacy systems while at the same time working to modernize our existing code base to maintain support amid changing technology trends.