Difference between revisions of "IS:.NET"
| Line 9: | Line 9: | ||
== Assembly requirements == | == Assembly requirements == | ||
| − | .NET assemblies must be signed and placed in the Global Assembly Cache to have permission to load. | + | .NET assemblies must be signed and placed in the Global Assembly Cache to have permission to load. .NET assemblies do not have to be specially compiled for usage in Inner Space, unless the assembly needs to use Inner Space API. |
== Developing for Inner Space in .NET == | == Developing for Inner Space in .NET == | ||
Revision as of 01:46, 1 December 2006
Contents
Overview
As of version 1.08 (released Nov 28, 2006), Inner Space supports loading .NET 2.0 assemblies in-process.
Executing an assembly
The DotNet is used to launch assemblies, as well as list active application domains, and close them.
Application Domains
An application domain represents the logical separation of .NET "processes". Any number of assemblies can be loaded into a single application domain, and likewise into any number of additional application domains. Application domains are referenced by name, and there is no restriction on naming schemes. When loading an assembly, use an application domain name of your choice. If you want to load the application into the same domain as another, simply reuse the name. When the domain is unloaded, all assemblies in that domain are subsequently unloaded.
Assembly requirements
.NET assemblies must be signed and placed in the Global Assembly Cache to have permission to load. .NET assemblies do not have to be specially compiled for usage in Inner Space, unless the assembly needs to use Inner Space API.
Developing for Inner Space in .NET
Known Issues
- Application main thread is the process's main thread. Many .NET apps use a message loop in the application's main thread. Inner Space will soon launch applications in a new thread.
- System.Console.Write and friends do not yet filter through InnerSpace.Echo
