ImageGlue .NET is made up of two components.

ImageGlue7CE.DLL is the core engine: it contains the core graphic manipulation code.

ImageGlue.DLL is a .NET tier comprising the visible interface and less speed critical code. When the assembly is loaded it locates and loads the core engine establishing a direct high speed link between the two components.

The .NET tier is placed in the GAC so that you can reference ImageGlue .NET from any of your projects. However should you require it you can always copy the DLLs to the bin directory of your application.


You need to add a reference to ImageGlue from your Visual Studio Project.

This tells Visual Studio to link the ImageGlue assembly into the build.

If you are not using Visual Studio you will need to consult the documentation for your chosen development environment.


There are three public namespace in ImageGlue. You can reference them using the following directives:

[C#] using WebSupergoo.ImageGlue7;
using WebSupergoo.ImageGlue7.GDIPlus;
using WebSupergoo.ImageGlue7.Config;

[Visual Basic] Imports WebSupergoo.ImageGlue7
Imports WebSupergoo.ImageGlue7.GDIPlus
Imports WebSupergoo.ImageGlue7.Config

Source Compatibility with Version 6

Because the ImageGlue API in Version 7 is different than the API in Version 6, you will need to change existing code. To avoid doing this continue using the version 6 namespace:

[C#] using WebSupergoo.ImageGlue6;

[Visual Basic] Imports WebSupergoo.ImageGlue6

This keeps compatibility with Version 6 API and still leverages the new V7 functionality since in ImageGlue7 WebSupergoo.ImageGlue6 is a thin layer over common V7 code.

This is some simple example code. All it does is report the ImageGlue Version.

[C#] Response.Write("License: " + XSettings.Version");

[Visual Basic] Response.Write("License: " + XSettings.Version")


ASP.NET operates under a restricted set of security permissions. It is quite common for the ASPNET user not to be able to create or write files.

So if you want to save a file from your ASP.NET code it is quite likely that you will need to adjust the permissions on your destination directory to allow write access for the ASPNET user.