Using a resource file to store configuration information is not always the best solution. Therefore we will implement once last change to the service: We will add a configuration file.
Actually, we will create two configuration files. The first will be the application-specific configuration file that is supported by default in all .NET applications. This is where system and technology settings modify the behavior of the application. The other configuration file is an application-processing configuration file that will store information for preparing the options that the service will use to perform its tasks. Currently, we have three such options: Input, Output, and FileType.
We will use XML for both the application-processing file and the application-specific configuration file as required by .NET.
Application-Specific Configuration File
To create our application-specific configuration file, go to the Properties window of the project and select Settings. Create a key/value pair named Configuration with a value of Configuration.Xml. Then save and compile your code. \[note] If you are going to store the configuration file in the same folder as the service executable, you don’t need to put in the %path%. Instead, just set the value to Configuration.xml; the service will look for the file locally by default.
When you look in your debug or release bin folder—depending on which type of build you are performing—you will see Tutorials.Exe.Config. All application-specific configuration files must be named in following the format: servicename.exe.config, where servicename is the name of the service executable, not the service name itself. In this situation the application-specific configuration will be named Tutorials.exe.config.
You may also notice that you now have a file called App.config in your project, stored with the rest of the source code. This is fine—you can ignore it. Do not edit the App.Config directly from the development environment; instead use the Settings Tab of the Project Properties to add or remove values. The App.config is used at design time by the Microsoft Visual Basic IDE, and the servicename.exe.config file is used at runtime. You can,, updated the runtime config file manually after you release your code.
For Listing 1, please refer to the App.Config file in your project folder for a full file listing. Here we will focus on the ApplicationSettings section only.
Listing 1. An example of an application-specific configuration file.
<?xml version="1.0" encoding="utf-8" ?><configuration> <applicationSettings> <Tutorials.My.MySettings> <setting name="Configuration" serializeAs="String"> <value>Configuration.Xml</value> </setting> </Tutorials.My.MySettings> </applicationSettings></configuration>
|
In Listing 1, you can see a new configuration item called Configuration with a value of Tutorials.Xml in the Tutorials.My.MySettings scope. This item allows us to access this property through the My object, which is what we want to do in the <Tutorials.ThreadFunc> method.
We need to provide access to the configuration file at run time from the Tutorials service by adding the code in Listing 2 to the Tutorials.vb file.
Listing 2. Accessing My.Settings application settings.
Dim configstr As String = My.Settings.Configuration
|
This will return the value of the Configuration setting, which will point to the configuration file.
The Application-Processing Configuration File
The next step is to create the application-processing configuration file that will store Input, Output, and FileType information for each FileWorker class instance. This step allows us to avoid hard-coding or trying to use a resource file to store this information, which requires a recompile each time a change is needed. Listing 3 shows a copy of the Configuration.xml file that I created. You will need to also create this file because the system will not generate it automatically. You can use any standard editor, such as Notepad, to generate this file, or you can generate it in Visual Studio itself.
Listing 3. User-generated configuration file.
<?xml version="1.0" encoding="utf-8" ?><Configuration> <FileWorkerOptions> <FileWorkerOption> <IncomingPath>c:\temp\incoming</IncomingPath> <OutgoingPath>c:\temp\outgoing</OutgoingPath> <FileType>*.txt</FileType> </FileWorkerOption> <FileWorkerOption> <IncomingPath>c:\temp\incoming2</IncomingPath> <OutgoingPath>c:\temp\outgoing</OutgoingPath> <FileType>*.dat</FileType> </FileWorkerOption> <FileWorkerOption> <IncomingPath>c:\temp\incoming3</IncomingPath> <OutgoingPath>c:\temp\outgoing</OutgoingPath> <FileType>*.ico</FileType> </FileWorkerOption> <FileWorkerOption> <IncomingPath>c:\temp\incoming4/</IncomingPath> <OutgoingPath>c:\temp\outgoing</OutgoingPath> <FileType>*.bat</FileType> </FileWorkerOption> <FileWorkerOption> <IncomingPath>c:\temp\incoming5</IncomingPath> <OutgoingPath>c:\temp\outgoing</OutgoingPath> <FileType>*.inf</FileType> </FileWorkerOption> </FileWorkerOptions></Configuration>
|
We have created a simple XML file that allows us to avoid hard-coding configuration settings, to configure a single incoming folder to have multiple threads monitoring for different file types.
In the configuration file listed previously, I have created the same five entries that I hard-coded in the <Tutorials.ThreadFunc> method.
Next we have to update the <Tutorials.ThreadFunc> so that it uses a configuration file, instead of hard-coded values.
