Continuing with the concept introduced in previous articles in the “Creating and Deploying a Smart Client with Plug-Ins” series, this article focuses on the design techniques for the plug-in assembly, as well as techniques to deploy the application. This article will also discuss vital code access security concepts that must be accommodated before running the smart client(s) from the URL.

Plug-in Design Techniques

As illustrated in “Creating and Deploying a Smart Client with Plug-Ins – Application Concept,” figure 1.1, the application plug-ins exists as separate .NET assemblies that inherit from a single base form class. This class contains a segment of common properties and methods that a plug-in must implement to be hosted within the application frame.

This arrangement makes it easy for a developer to simply create a new plug-in application that can run within the application frame with a minimum amount of knowledge of how the interaction between the plug-in and the application frame works. Additionally, developers can choose to make the plug-in available as a standalone application or function within the application frame. Using this approach, the assembly can dynamically determine from where it is being run and adjust its behavior accordingly. The following sections describe the techniques for designing a plug-in.

Accommodating the application configuration file

The application configuration file for the assembly (containing any specific instructions for application configuration interpreted and evaluated at runtime), is normally accessible by using the System.ConfigurationSettings.AppSettings namespace. However, the challenging element is that the plug-in will run inside another parent assembly. If a developer chooses to use the aforementioned method to obtain plug-in configuration file settings, the plug-in will most likely throw an exception. The reasons for this are as follows.

Because the invocation of the assembly within the application frame occurs within another assembly, the System.ConfigurationSettings.AppSettings directives forces the plug-in to use the configuration file of the parent assembly. This is due to the fact that the child assembly must reside within the parent’s AppDomain. This will result in a null reference exception. This situation might not be apparent if the plug-in’s main form makes a reference to the application configuration file on load. The resulting error in this case is that of a TargetInvocationException into the parent assembly. The developer will have to evaluate the InnerException of the TargetInvoicationException to determine what caused the error.

The workaround for this situation is to create and implement a custom XML configuration file system and abandon the .NET built-in configuration file classes. This can be accommodated by coding it into the PluginBase.dll and consuming the functionality through inheritance in the plug-in application. Because the plug-in is a smart client, it can access and utilize the XML configuration file directly from the URL. The following diagram depicts this concept:

Figure 1.3: Plug-in application configuration file workaround.

Standalone vs. plug-in modes

A developer may want to provide the plug-in as a separate and standalone application. To that end, the plug-in can inspect its own environment during startup and configure itself accordingly. This methodology is extremely helpful during the development process. In order to unit test and debug a plug-in (i.e., step thorough the code) it must be run from the .NET IDE. Debugging an assembly inside a launching assembly abstracts the convenience of .NET IDE debugging. Additional attention must be paid to ensuring that the PluginBase configuration settings method can switch between a HTML URL and a file based URL.

The following table outlines the code that will ensure that the plug-in is aware of where it is being launched.

//Determine what mode to operate in. 
     if(this.MdiParent == null)
     {
          //Standalone
          this.txtSQLServer.Enabled = true;
     }
     else
     {
     //In MDI Mode
          this.txtSQLServer.Enabled = false;
          this.txtSQLServer.Text = 
base._ConnectedSQLServer;
     }

Table 1.6: Determine plug-in mode.

The methodology in the above example is to determine whether the assembly is running as an MDI child. Based on this determination, developers can enable or disable the appropriate plug-in functionality. In the previous instance, and in keeping with the aforementioned horizontal application frame functionality, the plug-in will allow users to choose the SQL Server by enabling a text box. Otherwise, it will obtain the SQL Server based on the value already set by the application frame.

Deployment Design Techniques

The deployment of the smart client (the application frame and its associated plug-ins) can be accommodated through by using an ASP.NET Web application and an ASP.NET Web Deployment Project. This project should be a part of the original solution for the application frame. The underlying principle of the deployment component of the solution is that the ASP.NET Web project will represent the “home” for the application frame and its plug-ins.

Essentially, the ASP.NET project can be a placeholder which serves the executables for the smart client(s), or scale in complexity to have a menu-driven interface that will allow users to make choices, obtain support information, or run multiple smart clients. Regardless, the structure of the Web site should isolate the application frame executable code and its associated files from the plug-ins. Each plug-in should have its own named folder in the virtual directory. The following example illustrates a sample directory structure:

Figure 1.4: ASP.NET smart client deployment virtual directory structure.

The second technique used to deploy the application frame is to compile and build the .dll. By including the application frame, the deployment site, and the deployment project in the same solution, each can build off each other to produce a simple .msi file containing all elements required to establish the application frame deployment site and the application frame itself on a Web server.

Assuming that most developers are familiar with concept of the .msi deployment model (a .NET project that wraps all compiled code and content files into a .msi file, which can be run on a server to install the Web site or application), the methodology used to create a single .msi file to contain the .NET site for deployment as well as the application frame executables are as follows:

1. Create a ASP.NET Deployment Project and configure default properties accordingly.
2. Add the Primary Output and Content Files from the ASP.NET deployment site project in the current solution.
3. Manually create the folder structure to mirror that of the deployment site project in the current solution (i.e., the folder structure in figure 1.4).
4. In the ApplicationFrame folder, add the Primary Output from the application frame project in the current solution, as well as any other dependent .dlls not automatically included by the setup project (i.e., SQL-DMO.dll).
5. Compile the deployment project after compiling all other projects and install the corresponding .msi on the destination server.

This will install the ASP.NET deployment Web site, where users will run the application frame and plug-ins from, as well as the compiled version of the application frame in a single operation.

A plug-in can be built within the same project, or a completely separate project. The recommended approach would be to have a plug-in developed in a separate project so that the application frame solution does not incur bloat. If a plug-in is being developed within the same solution as the application frame, its Primary Output can be included into the folder structure of the deployment project so that it too will be deployed along with the ASP.NET deployment site. If the plug-in is not being developed within the same solution as recommended, a simple robo-copy or XCOPY directly into a new folder under the Plug-ins directory within the virtual directory of the deployment site is all that is required.

Subsequently, the assembly information for the plug-in and its associated security access rights must be added to the authentication service (database) so that the application frame can present the assembly as a choice to selected users.

Code access security considerations

In order for a smart client to run on a user’s machine, it must be a trusted assembly. Users attempting to run a smart client that does not have rights to execute on the machine will receive a security exception error when trying to invoke the executable from the URL. The .NET concept of code access security enables assemblies to run at varying levels of permissions. These levels of permission depend directly on the types of activities that the application undertakes.

As a result, the easiest method to establish trust on a user’s machine is to utilize the caspol.exe. The caspol.exe tool is installed with the .NET framework and can be relied upon by developers who need to ensure their assemblies are trusted on the user’s machine. The tool sets a security level for assemblies originating from a specific virtual directory, thereby endowing the assembly the rights to conduct activities on the user’s machine.

The following example is a caspol.exe command (run from the command line), which will ensure that all assemblies coming from the applications Webserver Web site will be granted full trust:

CasPol -q -machine -addgroup All_Code -url 
http://applicationWebserver/WindowsFormsVD/* FullTrust -n MyApplication 
-polchgprompt off

It is generally not good practice to specify that assemblies have the FullTrust permission for security reasons. (Refer to MSDN documentation for the differing levels of trust assignments for the appropriate levels for applications.) This command must be run from the C:\Windows\Microsoft.NET\Framework\v1.1.4322 directory. Additionally, the CasPol.exe supports a reset switch that will reset all assembly permissions back to the machine’s default. This can be a dangerous operation if multiple assemblies have differing levels of trust on a particular machine.

From a deployment perspective, a batch file can run the CasPol tool by switching to the CasPol path and ensuring permissions are granted to any assembly coming from a specified URL. The batch file can be distributed and installed via traditional enterprise methodologies (i.e., SMS Server, email or otherwise). Additionally, it can be placed in the deployment site virtual directory where users can access it.

Web Service Design Techniques

The authentication service, as depicted in “Creating and Deploying a Smart Client with Plug-Ins – Application Concept,” figure 1.1 <Note to Kimberly: this refers to a figure located in charran10, which has already been published> represents a method for the application frame to present menus to users within a clearly defined security context. This Web service’s premise is that it has two methods of authentication. The security class included with the Web service uses the built-in classes in .NET (System.DirectoryServices) to obtain key elements from the Active Directory using an LDAP searcher.

Primarily, the authentication service returns domain group information as a dataset to the calling application. Additionally, the Web service can store accounts and groups in its own database, along with assembly information and accept authentication requests of both types. A bit argument in the Web service method indicates to the Web service the type of query being run (Active Directory authentication or database authentication).

The added advantage is that applications will be able to query a central source and to provide security and only have to maintain group information. This precludes the requirement for each application to maintain its own list of users and groups separately. Each application can leverage existing Active Directory or database structures, so the need for repeating data is eliminated. The structure of the Web service is as follows:

DataSet 
AuthetnicateUser(string 
uName, string pWord, bool 
ADSIAuthentication)

DataSet 
GetAdditionalInfo(string 
applicationType, DataSet 
groupSet)

Table 1.8: Authentication service structure.

The authentication service database model also contains the capability to store generalized sets of information. This allows applications, such as the application frame to store and retrieve menu, assembly and security information in one pass.

Application Framework Premise

The majority of methodology migrations in IT infrastructure and management are moving towards the world of Service Oriented Architectures (SOA). As a result, the lifetime of the highly specific, single or dual function application and executable is now definable. So, even when developers are creating traditional, silo-like applications, they must adopt a paradigm shift towards building framework-based applications.

This shift will lend solutions better to a SOA implementation because they are based on designing loosely-coupled, shared solutions which can easily be exposed or leveraged through XML, shared components or plug-ins. The general shift developers must accommodate is that when designing an application, horizontal or common functionality (present and future) should be abstracted into a foundation or framework. Subsequently, code with higher specificity can be nested in this foundation. This prevents the hard establishment of silos and makes the enterprise application layer extremely extensible. As specified above, the smart client application model lends itself directly towards this purpose.

--

Eric Charran is currently working as a Technical Architect and Web Developer, in Horsham, PA. Eric holds Microsoft Certifications in SQL Server and has significant experience in planning, designing, and modeling n-tier applications using SQL Server 2000, as well as architecting and implementing .NET framework based applications, solutions and Web services. Eric’s other professional skills encompass Database Administration, Data Warehousing and Application Architecture, Modeling and Design, as well as Data Warehouse Transformation and Population using DTS. Eric is also skilled in developing and implementing ASP.NET and Windows forms applications, using technologies such as COM+, the .NET framework, VB.NET and other .NET languages.