다음을 통해 공유


(3) Path for Private Components

The Client example previously discussed has one important weakness: both Client.exe and Stringer.dll must reside in the same directory. In the real world, however, it is often advantageous to use a directory structure to manage components. The .NET Framework provides a configuration mechanism that allows administrators to specify a directory from which to load private components.

Building on the previous Client example, the 3_SimplePath subdirectory contains a version of the program that works with a private directory. All the source code is the same, but the build process has been modified for illustration purposes to build Stringer.dll in the Stringer subdirectory:

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

While the /reference: compile option works to locate a component in a subdirectory when compiling the program, a separate XML-based application-configuration file is required at run time to support components located in other directories. For client executable files, like the ones covered in this tutorial, the configuration file resides in the same directory as the executable file, and it has the complete name of the executable file with an additional file name extension of .config. The sample Client.exe.config file specifies a privatePath tag:

Listing 1. Configuration File for Client.exe (Client.exe.config)

<configuration>   
  <runtime>
    <assemblyBinding
       xmlns="urn:schemas-microsoft-com:asm.v1">
       <probing privatePath="Stringer"/>
    </assemblyBinding>
  </runtime>
</configuration>

When this configuration file is placed in the same directory as the executable file, the .NET environment uses the privatePath tag at run time to determine where to look for components — in addition to looking in the application's directory.

**Note   **When loading an assembly, the runtime also searches for a private path that is equal to the name of the assembly.

See Also

Deploying Applications with Private Paths | (4) A Shared Component | (5) Component Versioning | Packaging and Deployment Summary | Appendix A: Additional Packaging and Deployment Information | Appendix B: Packaging and Deployment Tools