按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
section describes how to enable signing。
The CallRuntimeImplementation project is the user application and is responsible for calling
the functionality in Implementations1 and Implementations2。 What you need to consider very
carefully in the CallRuntimeImplementation project structure is that in the References node；
only the Definitions project is present。 It does not contain references to Implementations1 or
Implementations2。
It is important to understand that when a project does not have a reference to another
project； it does not imply that the functionality cannot be used。 To use the functionality of a
project that is not referenced； you need to write code that will load the assembly dynamically。
With a dynamically loaded assembly； you can do whatever is possible with a hard…linked reference。
■Note Remember that assemblies are the results of piling a project。 A code library will produce a DLL
file； while an executable project will produce an EXE file。
Signing an Assembly
Signing an assembly is giving the assembly a strong name； which is a unique name。 Think of it
as follows。 My name is Christian Gross； and on this planet we call Earth； there are probably a
few dozen people with the name Christian Gross。 Our governments distinguish between the
various people with my name by way of a passport。 A passport is a unique identifier that converts
my mon name into a strong name。 This is exactly what happens when you use strong names
with an assembly。 A strong name is required when you want to add the assembly to the global
assembly cache （GAC）。 The GAC is where you can place an assembly to make it available for
global shared access。 You’ll learn more about the GAC in the “Loading a Strongly Named
Assembly” section later in this chapter。
By default； signing is not used。 To enable signing； you need to alter the properties of
the project。 Follow these steps to enable signing for the Implementations2 project and the
Definitions project：
1。 Right…click the project in the Solution Explorer and select Properties。
2。 Click the Signing tab。
3。 Check the Sign the Assembly check box。
4。 Select from the bo box； which pops up a dialog box allowing you to specify
the file name。
…………………………………………………………Page 340……………………………………………………………
318 CH AP T E R 1 2 ■ L E A R N I N G A B OU T A PP L I CA TI O N CO N F I G U R AT IO N AN D D Y N A M I C L O AD I N G
5。 Type in a key file name and a password； and then click OK。
6。 Save your project。
Setting the Output Path
The aim of the chapter is to demonstrate two things： configuration files and the dynamic abil
ities of 。 Explaining； debugging； and running the configuration source code is simple； because
everything is laid out for you in the Visual Basic IDE。 You will not run into any problems running
the configuration code。 However； for the dynamic loading； there is a plication。
As you’ve seen； the CallRuntimeImplementation project does not have explicit references
to Implementations1 and Implementations2。 This means that if the code from Implementations1
or Implementations2 is referenced from CallRuntimeImplementations using dynamic techniques；
Visual Basic Express will have no clue as to what you are doing。 You might argue that there is
one Visual Basic Express solution； and Implementations1 and Implementations2 are part of the
overall project； but unless an explicit reference is made； Visual Basic Express does not know
about this。
However； you can overe this problem fairly easily by changing where the projects
place their piled output。 As a habit； I often make all projects build to a central directory。
You can set the output directory in the pile tab of a project’s Properties window； as shown
in Figure 12…2。
Figure 12…2。 Setting the build output path to a mon path （。。bin）
You need to set the Build Output Path field to a mon location for all projects。 When
you do that； a build will result in a directory structure like that shown in Figure 12…3 （in the next
section）。 With all of the files in a mon directory； running the dynamic…loading routines
bees trivial。
…………………………………………………………Page 341……………………………………………………………
CH AP T E R 1 2 ■ L E AR N IN G AB O U T AP P L I CAT I ON CO N F IG U R AT IO N A N D D Y N A M IC L O AD IN G 319
Defining and Processing a Configuration File
A configuration file is a file that contains information about how a program should behave。
Configuration files by themselves do not control how a program behaves。 For a configuration
file to influence the behavior of a program； the program needs to read and act on the informa
tion in the configuration file。
Using a configuration file is not as easy as you may think it is。 Yes； it is easy to define a
configuration file and read the configuration file。 What is difficult is how to define where
the configuration file is located。
Suppose you have an application that is installed on the hard disk； and the application
must make an assumption about where the configuration file is stored。 One assumption could
be the root directory of the C： drive。 Yet that could be incorrect； because some puters don’t
have C： as the root drive。
solves this problem in an interesting way： whatever the executing application is called；
the configuration file has the same name with a 。config extension。 Figure 12…3 shows an example；
in which the console application is CallRuntimeImplementation。exe。 The configuration file is
CallRuntimeImplementation。exe。config。