Using Chilkat Mono in a Visual Studio C# Project

The Chilkat Mono assembly can be used in a Visual Studio project (any version of Visual Studio).

(From a programming perspective, using the Chilkat Mono classes is the same as using the Chilkat .NET classes. The Chilkat .NET assemblies (available from Chilkat .NET Downloads are mixed-mode assemblies. The outer-layer is fully managed, and the inner core contains the native C++ implementation. The Chilkat Mono solution is different: The .NET/Mono assembly is 100% managed, and there is a 2nd DLL that contains the native C++ implementation. The 100% managed assembly (internally) calls into the native DLL using P/Invoke.)

Actually.. you don’t even need to build the 100% managed assembly.  You can instead just add the Chilkat *.cs source files to your project directly.  (If you open one of the .cs source files, you’ll see how P/Invoke is used.)

  1. Created a Visual Studio project in C:\MyProject
  2. Downloaded the Chilkat Mono .zip from https://www.chilkatsoft.com/mono.asp  and unzipped in C:\MyProject
  3. You now have a directory c:\MyProject\chilkatMono-9.5.0.    Within that directory, I have a chilkatCs directory, and a nativeDll directory.
  4. Add all of the .cs source files from chilkatCs to your Visual Studio C# project.  (Note: If you find an “Accounts.cs” source file, delete it and do not add it.)
  5. You don’t necessarily need to add all of the .cs sources, but you must add whatever is necessary to resolve all references.  For example, if you add MailMan.cs, you’ll certainly need to add Email.cs, and that in turn will require Cert.cs, etc.  A good strategy is to add everything, then delete various things that are likely unreferenced by other things.  For example, you can safely get rid of Csr.cs if not using CSR’s.
  6. Add code to your app.  For example:

    Chilkat.Zip zip = new Chilkat.Zip();
    MessageBox.Show(zip.Version);

  7. You can try building and running, but it’ll fail because the native DLL won’t be found..
  8. Copy the desired 32-bit or 64-bit native DLL into the same directory where your .exe is created.  For example, copy c:\MyProject\chilkatMono-9.5.0\nativeDll\windows\x64\chilkatMono-9_5_0.dll to c:\MyProject\bin\Debug
  9. Assuming your Visual Studio project is “Any CPU”, and you don’t have a “Prefer 32-bit” checkbox checked (in Project Settings), and that you’re running on a 64-bit system, then the .NET runtime should locate and load the 64-bit chilkatMono-9_5_0.dll, and your program runs fine.

Visual Studio Web Site Project vs. Web App Project (32-bit vs. 64-bit)

Some good information from a Chilkat customer:

It turns out the problem was that we were using a Visual Studio Web Site project type. Instead of this, we found that using a Visual Studio Web App project type works. A “site” runs in some whimpy web server on the developer machine that is only 32-bit, something called Cassini, but some people adamantly declare it’s not *really* Cassini… Whatever, I have no tolerance for any web server on my development machine that cannot run in 64-bit whether it is the real Cassini or not! Ha! So anyway, we created a new Web App project and then you get a ton of options that allow you to specify the target processor platform, etc. We set everything to x64, and then we configured the Web App to use the REAL IIS 8.0 web server on my 64-bit machine, connecting to a real IIS Application, and then everything works. Of course, we need to run Visual Studio with elevated permissions in order to debug but that is just fine with us.

So the moral of the story is… If you want 64-bit on a development machine, use a Web App project, not a Web Site project!