按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
D Y N A M I C L O AD I N G
What is useful with convention architecture is that you are not limited to what is defined
in the configuration file； as there is a general logic。 When implementing a convention architec
ture； you are not discarding configuration； but you are making assumptions for the user and
implementation of the code。 You will still probably have a configuration file； but the configuration
is for specific functionality。
Regardless of whether you use a configuration architecture or a convention architecture；
you will dynamically load assemblies； as demonstrated in this chapter。
Setting Up the Dynamic Loading Projects
For this chapter’s examples； four projects are defined：
o Definitions： A class library that contains the definition for the interface IDefinition and
the class ConfigurationLoader。 The class ConfigurationLoader will contain the functionality
to dynamically load the assemblies Implementations1 and Implementations2。
o Implementations1： A class library that contains the class Implementation and implements
the interface IDefinition。 The class Implementation is defined in the namespace
Implementations1 and is not declared Public。
o Implementations2： A class library that contains the class Implementation and imple
ments the interface IDefinition。 The class Implementation is defined in the namespace
Implementations2 and is not declared Public。
o CallRuntimeImplementation： A console application that will be referenced throughout
the chapter as the user application。
In the Definitions project； the references are to the standard libraries （ System；
System。Core； and so on）。 The unique reference that you need to add is to System。configuration。
The System。configuration reference contains the types that you need to read the application
configuration file。
Here is the code for IDefinition：
Public Interface IDefinition
Function TranslateWord（ByVal word As String） As String
End Interface
The Implementations1 project contains the file Implementation。vb； which is the type
Implementation and implements the interface IDefinitions。 The implementation of
Implementation is as follows （make sure you add a reference to the Definitions project）：
Imports Definitions
Class Implementation ： Implements IDefinition
Public Function TranslateWord（ByVal word As String） _
As String Implements IDefinition。TranslateWord
Return 〃〃
End Function
End Class
…………………………………………………………Page 339……………………………………………………………
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 317
The class Implementation has a hard reference to IDefinition； so under the References
node in the Implementations1 project is a reference to the Definitions project。 Because there
is a hard reference to IDefinition； the interface IDefinition is declared as Public； but
Implementation is not。
The Implementations2 project has the same implementation and reference to Definitions
as Implementations1。 What is special about Implementations2 is its use of a strong name； which
makes it unique。 Thus far； all of your assemblies are not unique。 To make them unique； you
need to enable signing。 You must also enable signing in the Definitions project。 The next
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 w