다음을 통해 공유


(2) A Simple Componentized Application

Of course, the Hello World application that was previously discussed is completely trivial and hardly representative of even the simplest real-world program. So, now you can look at a version of the component-based program that was described in detail in the Introduction to Developing with the .NET Framework tutorial. This new version, which can be found in the 2_Simple subdirectory, uses Client.exe to call methods on only the types contained in a single component (Stringer.dll). The code for the Stringer component (located in Stringer.cs) includes several important statements, the first of which specifies where in the global namespace the contained types can be found:

namespace org {...}

Again, you must create a class:

public class Stringer {...}

The class then has a single field (StringsSet), a constructor (Stringer, the same name as the class itself), a defined method (GetString), and a property (Count) with a corresponding property accessor (get_Count) automatically created by the compiler:

private string[] StringsSet; 
public Stringer() {...}
public string GetString(int index) {...}
public int Count {
       get { return StringsSet.Length; }
}

Putting all this together, a client program would fully qualify a reference to the GetString method as, for example, org.Stringer.GetString.

Not surprisingly, an Ildasm.exe display of the compiled component shows all the members:

The client includes a second using statement that specifies the namespace to allow easy access to the types in Stringer.dll (the code is in Client.cs):

using org;

Building the files in this project is straightforward. First, you build the Stringer.dll component. Then, you build Client.exe, importing the component by using the name of the file that contains the manifest, rather than the namespace name (which is org, in this case):

csc /target:library ... Stringer.cs
csc /reference:Stringer.dll ... Client.cs

Just like Hello.exe, the new Client.exe contains manifest information about itself, the .NET Framework class library, and the types it uses. However, it now contains information about the Stringer component and the referenced, contained types (in this case, org.Stringer).

**Note   **The client uses private assemblies, so version information is not checked.

The following figure shows the manifest information for the Stringer component:

In this particular example, the DLL composes the entire assembly. This is not always true, however. For example, in some development scenarios, it might be necessary to combine DLLs that were authored in several languages into a single assembly. It might also prove advantageous to combine several DLLs into a single assembly to take advantage of special scoping rules that allow access to methods among the components but keep the access internal to the assembly itself. In these situations, you can use the Assembly Linker (Al.exe), which is described in Appendix B: Packaging And Deployment Tools, to customize your assemblies.

See Also

Deploying Componentized Applications | (3) Path for Private Components | (4) A Shared Component | (5) Component Versioning | Packaging and Deployment Summary | Appendix A: Additional Packaging and Deployment Information | Appendix B: Packaging and Deployment Tools