When we use MetaBots, we can invoke Microsoft Dynamic Load Libraries (DLLs). Here we discuss what that means and how to achieve it.
When we compile source code, we end up with an executable binary that can be run. There are times when we want to write code that will be used in a variety of applications. We then write subroutines/functions that encapsulate the logic to achieve a task and then we wish to invoke these routines. This provides re-use and consistency. When we aggregate such functions together, we end up with a concept called a Library. Now when we write higher level applications, we can link those with the library which allows the calling application to re-use the functions contained within that library. In this mode of operation, the library is statically bundled with the application resulting in a binary that contains both the application logic and a copy of the library routines. While this is acceptable, it suffers from a few negatives. First, the resulting binary becomes larger. Imagine you have two or more applications each of which leverage the library. Each application will result in its own statically bound copy of the library. If both applications are run at the same time, then both will load the same library code into their own address spaces. Second, if we find that we have a bug in our library, not only do we need to fix that by recoding/changing the library, but we also must rebuild our applications so that they now link with the new library.
A solution to these puzzles is the DLL notion. When we compile the library, we can build a DLL file that contains the library functions that we will eventually wish to invoke. Now when we link with our application, instead of the library functions being statically linked with our code, our code remembers that the functions it needs for operation can be found at runtime within the DLL file. This means that when our application starts, it will dynamically load the required DLL file. The functions and the applications which use them are separated. The applications (individually) become smaller as they no longer integrate the library functions. In addition, when multiple applications refer to the same DLL, only a single copy of that DLL is loaded into memory. Finally, if we need to repair/correct the logic in a DLL, we can simply replace the DLL file with a new version and then at runtime, that new version will be pulled in to satisfy the functions from the calling application. There is thus no need to relink/rebuild the calling applications when the libraries change.
Within our AA environment, we can instruct a MetaBot to leverage a DLL to provide functions that otherwise would not be available in an ordinary AA distribution. While this is great, if one wishes to leverage this capability, it assumes that the AA programmer has the skills to be able to create new DLLs. Here we will start to illustrate how to achieve that.
We will leverage the Microsoft .NET environment which provides a super-rich set of services and application building techniques. There are many programming languages we can use to create .NET libraries but in these examples, we will stick to C#.
Our goal will be to create a new DLL that exposes a function that we wish to call from an AA MetaBot. That function will itself be written in C#. Our first step is to consider the tools required to build such a DLL. Fortunately, Microsoft makes this extremely easy for us. Microsoft produces a development environment called Visual Studio. This is a complete project management system for editing, compiling, testing and managing source projects. Even better, it has a community version that is free of charge for download and use.
Let us walk through a simple example.
The following video illustrates this technique and then goes further illustrating how to invoke it from a MetaBot.
Read our article on working with Slow Web Pages in Automation Anywhere.