A .NET DLL contains Intermediate Language which requires the .NET runtime to execute it and probably some .NET base libraries that it uses/depends on.

This means that the DLL can only be used on hardware/operating systems that have a matching .NET Framework available.

Writing code for all possible platforms is nearly impossible and I would advise you to figure out what platforms you really need to support because even when you find a way to run the DLL on all platforms it would cost a lot of effort to actually test it on all platforms and support it on all platforms. It will be a lot cheaper/easier to cover the key/main operating systems for your clients.

A DLL is a format used for shared libraries by the Microsoft Windows operating system. Other operating systems use other formats, and since DLLs are binary they cannot generally be used on other processor architectures such as ARM devices. Therefore, DLLs are of no or little use under Mac OS X, on Linux-based operating systems such as Ubuntu, and on mobile devices (e.g. running iOS, Android, or Windows Phone).

(the point about processor architectures is not quite true since C# programs are typically compiled to intermediate bytecode that’s architecture-independent. However, other DLLs don’t have this flexibility)

Furthermore, code written in C# will typically require the .NET framework or at least the .NET runtime in order to work. Different Windows operating systems support different .NET libraries. Code targeting the desktop might not work on mobile devices. Microsoft’s .NET libraries are not currently available on non-Windows systems.

While your C#-written DLL will be of little use on non-Windows systems, there are a few possibilities to make your code more widely usable:

• The WINE project offers a Windows compatibility layer for Unix-like operating systems. Provided that the processor architecture matches, this allows users to run EXEs, which may also use DLLs. However, WINE is not viable mechanism for making libraries usable. Unfortunately, the WINE project – as a volunteer effort – is lagging years behind in Windows features.

• The Mono project offers a reimplemenation of the .NET framework and the C# language which runs on a variety of devices and operating system, including Linux and mobile devices. You could then recompile your library for each target system using Mono. However, the Mono implementation is lagging years behind, so you will not be able to use modern language features or newer additions to .NET APIs. Porting your code to Mono is possible, but may take some effort. Microsoft has announced that it will add support for non-Windows systems, but until then Mono is your best bet.

• If you are content with only targeting Windows systems, offer compiled packages via NuGet. This makes it easy for other C# programmers to get and incorporate your library.

• Consider publishing the source code. This makes debugging much easier for users of your library, and helps others help you. GitHub is a good place to start of you’re using Git for version control.

• Forget C#, and use a language that’s really cross-platform. However, you’ll always lock into a specific ecosystem. If you go with Java, your library can only be used from other languages running on the JVM (but the JVM runs on any operating system). Nearly any language can easily interface with a library written in C, but writing C is difficult (even more so if you want your code to be portable).

There may be more newer ways, but it’s been a couple of years since I last wrote C#…