An application domain is a boundary between objects in the same application scope, which is established by the CLR. Application domains provide the ability to isolate multiple applications running within a process. You can have multiple application domains loaded onto the CLR and destroy each of them independently without stopping and restarting Integration Server.

For information on managing application domains in Integration Server, see The Manage Application Domains Page.

The webMethods Microsoft Package uses wmSystem as the primary domain internally to facilitate the infrastructure. For running any DLL, webMethods Microsoft Package provides a default application domain with the domain name webmDomain. When you run a DLL in any application domain, it becomes locked, meaning that you cannot rename, modify, or delete it at the file system level. If the DLL is in the default webmDomain, you have to stop and restart the CLR from Integration Server Administrator to unlock it. By creating a separate application domain running a .NET service in it, you can unlock the DLL by destroying the application domain rather than stopping the CLR.

When you create a .NET service from a DLL using Designer, Designer creates a domain named IntrospectionDomain to introspect this DLL. This implies that the DLL is referenced by the IntrospectionDomain. Now, when you run this created .NET service by giving a custom application domain name, this DLL is also referenced by the custom application domain. To rename, modify, or delete this DLL, you must first destroy the custom application domain, and then also destroy the IntrospectionDomain. If you had not specified a custom application domain to invoke this DLL, DLL is invoked under the default application domain named webmDomain, and you must restart the CLR to modify this DLL.