How do I wrapper an existing C# DLL in a C# web API?

First, I'm new to web APIs so maybe this is an ambitious first project.

My team manages a C# DLL that contains methods for several different applications used by one team at work. This DLL is used on hundreds of workstations and my team is interested in wrapping this DLL in a web API so DLL management will be less work and we can move into the 21st century. So, I copied the DLL folder into packages, created a reference in the web API project. Some of the methods return or require an object or object array.

Already tried creating a web API using 4.7x framework in VS 2015, as well as an ASP.NET Web API with MVC (2015) and today, an ASP.NET Core Web API in VS 2022.

Questions:

1. Is this possible or am I misunderstanding the boundaries?
2. When I tried this out using VS 2015 (this project uses 4.7x framework), it compiles just fine but gives me an HTTP error when the browser loads. How do I install this on an IIS instance and test it properly?
3. Can objects be passed in and out of methods from the DLL using a web API?
4. If I'm on the wrong path here, what's the best way to get on the right one?

On your original questions

1. Yes, this should be possible (but point 3 and 4 will amend that): in general, your C# DLL could be used as a library in your API project. You could use the methods provided by the DLL as you would in any other C# project.
   The only difference here is that you would be calling these methods inside your API controller actions and returning their results as HTTP responses.

2. In order to host your web API on an IIS instance, you will need to follow these general steps:

   • Publish your project from Visual Studio. You can do this by right-clicking on the project in Solution Explorer and selecting "Publish". This will generate a publish profile, and you can choose to publish to a folder.
   • Open the Internet Information Services (IIS) Manager on your machine or server. You can do this by typing "inetmgr" into the Run dialog (Windows Key + R).
   • In the IIS Manager, right-click on "Sites" and select "Add Website". You will need to give it a name, set the physical path to the location of your published files, and set the port number.
   • Click OK and your site should be running. You can access it by typing "localhost:[port]" into your web browser. Replace "[port]" with the port number you chose when setting up the site.

   If you are getting an HTTP error, check the logs to get more information about what is going wrong.

3. Yes, you can pass objects in and out of methods from the DLL using a web API. However, you will need to ensure that the objects are serializable to JSON (or XML if you prefer) since that is how they will be transmitted over HTTP. For complex objects, you might need to create DTOs (Data Transfer Objects) that match the structure of your objects but only include the properties that you want to expose over the API.
   That is where some redesign start to be necessary.

   Joe Mayo adds in the comments:

   > You might want to wrap the call to the DLL (from the Web API) in a try/catch block.
   Then, you can respond with a proper HTTP Error code.
   > E.g. if you have an authentication endpoint that fails, you'll want to return a 401 Unauthorized.
   Otherwise, an unhandled exception translates into 500 Internal Server Error, which is not helpful to the developer consuming the API.
   Consider using Swagger too, for documenting/testing the interface.

4. Yes, but: if you are dealing with a legacy DLL that is built on .NET Framework 4.x, and you are having issues wrapping it with a web API, then you might need to consider a more comprehensive redesign.
   Possible options are, for instance:

   1. Refactor the DLL into a .NET Standard Library, if possible. .NET Standard is a specification of .NET APIs that are intended to be available on all .NET implementations. This will allow your library to be consumed by both .NET Framework and .NET Core applications. After that, you can create a .NET Core Web API that references this .NET Standard Library. However, this approach may require significant work if the DLL uses APIs that are not available in .NET Standard.

   2. Use a .NET Framework Web API: Since your DLL is built on .NET Framework 4.x, it might be easier to stick with a .NET Framework for your web API. You can still take advantage of many of the features of a modern API, and it should be easier to work with your DLL.

   3. Implement a Facade Pattern: Create a new layer that will interact with your DLL and expose a more modern, web-friendly interface. This can be a good compromise that lets you keep the existing DLL while still offering a modern API interface.
      See "Facade Design Pattern: Still relevant in ASP.NET Core?" by Adam Storr as an illustration.

   4. Use a .NET Core/.NET 5+ Web API with a Windows Compatibility Pack: .NET Core 2.x and later, as well as .NET 5 and later, offer a Windows Compatibility Pack that adds back some of the APIs that were only available in .NET Framework. This might allow you to use your DLL with a more modern .NET Core or .NET 5+ Web API. However, be aware that not all .NET Framework APIs are available, and this only works on Windows.
      See "Use the Windows Compatibility Pack to port code to .NET"

As with any redesign, the process should be iterative. You might not get it right the first time, but with each attempt, you will understand the problem better and be able to make more informed decisions.
I would recommend a comprehensive set of tests to ensure that the functionality remains consistent as you refactor and redesign. If your DLL does not have a good set of tests, then creating those tests first might be the right first step.

Consider also if there are other architectural changes that could improve the overall system design. Such a redesign could be a larger project, but it might also offer significant benefits in terms of maintainability, scalability, and flexibility.

For example, suppose your DLL provides methods for user authentication. Instead of having this logic embedded in a DLL that needs to be distributed and referenced by multiple applications, you could create a User Authentication microservice. This microservice would expose endpoints for operations like "Login", "Register", "Forgot Password", etc. Your applications would then interact with this service over HTTP, removing the need to directly reference the DLL.
See ".NET Microservices: Architecture for Containerized .NET Applications" for illustrations.

Is this possible or am I misunderstanding the boundaries?

no, it's just not that easy

When I tried this out using VS 2015 (this project uses 4.7x framework), it compiles just fine but gives me an HTTP error when the browser loads. How do I install this on an IIS instance and test it properly?

you should already have IIS in visual studio (https://learn.microsoft.com/en-us/aspnet/web-forms/overview/deployment/visual-studio-web-deployment/deploying-to-iis); to test the API you can install swagger nuget package (https://santansarah.github.io/swashbuckle/)

Can objects be passed in and out of methods from the DLL using a web API?

yes, very easy with json

• string jsonString = JsonSerializer.Serialize(yourVar);
• JsonSerializer.Deserialize<YourObjectType>(jsonString);

If I'm on the wrong path here, what's the best way to get on the right one?

you are on the right path