With Microsoft no longer supporting VB6 development, many companies consider transferring from their old software to the modern programming languages seeking the performance, security, and possibility to use the new technologies.

In this case study, we describe how we helped our customer decrease the software license costs for 75% of their users by reimplementing slow AutoCAD procedures in a much faster C# variant.

## Project Background

In 2019 we started a collaboration with a company that is a world’s leading manufacturer in their area. At that time the company used a number of tools written in different languages at different times ranging up to 20 years ago. It has become increasingly hard to support such a diverse set of applications. The long-term goal was to have a single state-of-the-art tool that would be able to design all types of products.

We embarked with a complete revamp of the first tool – an AutoCAD plugin written partially in VBA, partially in LISP. It had problems during installation, each new version of AutoCAD brought new issues for the plugin. Some parts of the functionality stopped working completely. VBA is still supported in AutoCAD, but it is not available by default and requires a separate download and installation.

This project perfectly fitted our profile. We have experience working with AutoCAD (Advanced Drilling Guidance Software). Also, we have completed a number of projects converting from VB6 to .NET (for example, Migrating Legacy ERP for USA Company to Web, Swiss children sponsorship management).

## Our Approach

Starting with a thorough analysis of the plugin functionalities, we have detected the riskiest parts and created a detailed roadmap for the conversion process.

There was made a decision to convert plugin to .NET C#, remove dependencies on AutoCAD and make it one of the modules of a single standalone tool. WPF UI was implemented using MVVM Light Toolkit.

For regular users, simple wizards covering common workflows were envisaged.

For advanced users, there was introduced advanced mode with the possibility to execute all possible commands in any required order.

At the same time, AutoCAD plugin in .NET C# was written to be used by experienced engineers for the most complex tasks where additional AutoCAD functionality was required.

Separating common code for the plugin and standalone application module into a shared library ensured the same correct behavior and reduced possibility of desynchronization as a result of future changes.

To allow reading and saving *.dwg and *.dxf formats, exporting to PDF, the cost-effective solution was to integrate a third-party library WoutWare CadLib.

Plugin workflow took input profile and applied an algorithm to produce a number of polylines. This algorithm was rewritten from VB to C#. We converted VBA (Visual Basic for Applications) plugin to Visual Basic 6, then to VB.NET with Visual Studio 2003 and then converted VB.NET to C#. This left us with partially ready C# code where we manually had to rewrite several parts of code too complicated for the automatic converter.

The Lisp part made some preparations with polylines generated on the previous step and then AutoCAD command BOUNDARY was used. This wasn’t working correctly in AutoCAD because this command depends on a visual representation of polylines and lacks the required precision. For a big number of polylines, BOUNDARY froze outright. So we designed and implemented a mathematically precise algorithm to replace BOUNDARY. For the usual number of lines used before, the algorithm is almost instantaneous. In the case of a big number of lines when AutoCAD freezes, the bespoken algorithm works for a couple of seconds. The same algorithm was used in both the standalone program and the plugin.

The frequent operation was a generation of tolerance polylines with the usage of AutoCAD Circle by Tan Tan Radius function and further replacing part of the profile with an arc of the circle. So we implemented our own Tan Tan Radius algorithm and fully automated replacement of the part of the polyline. Such native AutoCAD functions as OFFSET, TRIM, EXPLODE, PEDIT were also replaced when automating this routine.

Preparing the report file for the customer included finding an appropriate zoom level, annotating individual curves of a polyline, filling template tables with used parameters. All these numerous activities are now done with a single button click.

There were written unit tests that take a collection of input profiles, execute each workflow and compare results with etalon values. During the project, new improvements to the algorithms had to be made to account for the new types of input profiles. Executing unit tests allowed us to quickly identify cases when new improvements broke support of old input files and resolve the issue to correctly handle all situations.

The project was finished on time and within budget and successfully released to the client. New program automated common routines, fixed issues present in the old plugin, significantly speed up the process of designing new profiles, allowed usage by less experienced users. There were made savings on license costs for 75% of users as the standalone application doesn’t require AutoCAD.

We continue working with the company on the conversion of other applications to C# .NET WPF.

### Posted in:

$${}$$