Home » Auto-Deploying Windows Forms .NET Applications: The Revenge of the Fat Client

Auto-Deploying Windows Forms .NET Applications: The Revenge of the Fat Client

he .NET framework provides new tools to make deployment of fat client .NET applications easier. This article describes the basics of .NET Auto-Deployment technology and the security mechanism that prevents users from inadvertently running code distributed by hackers and virus writers.

.NET Automatic Deployment is a feature built into the .NET Framework allowing applications to download assemblies (via HTTP) from remote locations on an as-needed basis.

With this feature, you can post your fat client application to a Web server and be sure that users automatically use the latest version the next time they run the application. Imagine that: No more CDs to ship with updates, and no more support calls from users that are a few versions behind!

The .NET Framework provides a lot of the functionality required for automatic deployment out-of-the-box. For example, .NET knows how to download an assembly from a remote location, cache it in the user’s disk, and download it again only when a new version is available in the remote location. All these features come built into the .NET Framework.

Auto-Deploying an Executable
There are two pieces to auto-deploying a Windows Forms .NET application. One piece lets your users have access to the main executable. The other piece lets your users download the rest of the application as they use it.

.NET applications know how to download code from a remote location, when to download it, and how to cache it for future reference.

Let’s talk about the first piece. Giving users access to the main executable is fairly easy to do with .NET. You just need to post your executable to a Web server and let the users know the URL.

For example, let’s say that you have an executable called loader.exe. You can create a virtual folder on your company’s Web server and let the user know that the executable is available at http://www.mycompany.com/myapp/loader.exe.

Users can run the executable by pointing a browser to the URL (see Figure 1.) Users can also run the executable by entering the URL via the Run option in the Start menu. Or, you can create a Web page with an HTML HREF tag referencing the URL.

Auto-Deploying the Rest of the Application
So far, you’ve seen how to deploy an executable over HTTP. This works fine for small applications like the loader (45KB). But applications are typically much larger than 45KB. What if your application is 3MB? You wouldn’t want your users to download 3MB from your Web server every time they run the application. This brings us to the second piece of auto-deployment.

A better approach is to install a copy of the main executable on the users’ hard disks and let this main executable download the rest of the application on an as-needed basis. For example, users could download a few kilobytes when they run the Invoicing module of your application, another few kilobytes when they run the Employees module, and so forth (see Figure 3).

It’s All About Security

With .NET Security Policies, you can protect users from accidentally running code from unknown sources.

Security Policies in .NET are a necessary pain. Without them, letting users point their browsers to any URL, download a .NET executable, and automatically run it on their computers is every virus writer’s dream come true. With Security Policies in .NET, you can protect users from accidentally running code from unknown sources.

You have probably heard before that .NET is highly integrated with the operating system. Security is one area where this integration is particularly evident.


Figure 5: Adding a trusted site

.NET Security Policies are very powerful and highly configurable. Let’s take a look at how these policies are structured and how you can configure them to allow users to download executables from trusted URLs.

.NET Security and Internet Explorer Security Settings
The first place where you can configure security settings to allow users to run executables via HTTP is, not surprisingly, in Internet Explorer. To do so, launch Internet Explorer, go to the Tools menu option, select Internet Options, click on the Security tab, select Trusted sites, and click on the Sites button.

Let’s add http://127.0.0.1 as a trusted site (Figure 5). Notice that the Require server verification… checkbox is unchecked in order to be able to add this site to the list.

Now that http://127.0.0.1 is a trusted site, let’s try to run the executable again with the URL http://127.0.0.1/CodeDownloadDemo/Loader.exe Now the application will actually run, although .NET lets us know that some security issues are still unresolved (Figure 6).

Figure 6: The information icon indicates that the application runs in a partially trusted context.

Figure 7: .NET generates an error if you try to access resources outside the partially trusted site.

You can see that the loader application actually ran this time. Notice the small information icon on the upper left corner that indicates that this application is running in a partially trusted context and therefore some features of the application might not work. For example, trying to load data from the Employees Form generates a security error (Figure 7). The form is attempting to read data from SQL Server’s Northwind database in localhost and the application does not have security permissions to do it.

Notice also how the URL (127.0.0.1) and the word “trusted” have been added to the application’s title bar.

.NET Security and the Framework Configuration Tool
Although Internet Explorer allows you to configure some of the security settings for .NET applications, it does not provide a comprehensive list of things that you can allow or deny to .NET applications.

In order to get access to the full range of security options available to .NET applications, you need to use the .NET Framework Configuration Tool. This tool is part of the .NET Framework (not VS.NET), which means that every user with the .NET Framework installed has the Configuration Tool installed as well. To launch it, go to the Windows Control Panel, select Administrative Tools, then choose Microsoft .NET Framework Configuration.

Using this tool, you can configure .NET Security Policies and decide what locations you want to trust and the degree of privileges that a location will receive.


Figure 8: Using the .NET Framework Configuration Tool to configure Code Groups and Permission Sets

A complete explanation of .NET Security Policies and the tools to configure them is beyond the scope of this article. But let’s take a brief tour of how to use the .NET Framework Configuration Tool to configure Code Groups and Permission Sets (Figure 8).

In Code Groups, you categorize which code is to be trusted and which code is to be denied access. You can probably recognize that the predefined code groups in the Figure 8 correspond to the Zones that you saw in the Internet Explorer Security Setting.

Permission Sets are a means to assemble various permissions under a single name. For example, Figure 9 shows the permissions assigned by default to Permission Sets LocalIntranet and Permission Sets Internet.

Figure 9: Default permission sets

Figure 10: Defining custom Code Groups and Permission Sets

You can define custom Code Groups and Permission Sets by right-clicking in the appropriate node. For example, follow these steps to give full trust to code coming from URL http://127.0.0.1 so that the previous example does not raise any security errors:

Open the Code Groups branch, right-click on the All_Code branch and select New (see Figure 10).
Enter a name for the new Code Group, perhaps MyCodeGroupFor127, and then click Next

Select URL as the condition type for the code group and enter http://127.0.0.1/* as the URL to trust (see Figure 11), and then click Next.

Figure 11: Choosing a URL condition type for a code group

Figure 12: Assigning a permission set to a code group

Finally, select Full Trust (see Figure 12), and click Next and then Finish.

Now, if you go back to Internet Explorer and launch the loader.exe program with the URL http://127.0.0.1/CodeDownloadDemo/Loader.exe, the application will run without Security problems. You can even go to the File menu, and then launch the Employee Form and load Employee data with no problems.

In the previous example, you gave Full Trust to a URL. This is not a problem for a demo; but in production environments you need to be more selective and give locations the minimal permissions required in order for them to work properly. Your network administrator will probably not let you grant permissions otherwise.

I highly encourage you to play with this configuration tool and learn about how to create groups and permission sets that will match your particular security requirements.

Deploying .NET Security Policies
In the previous section, you created a security policy to trust code coming from the URL http://127.0.0.1. You wouldn’t want to have to ask your users to follow the same steps as you did to trust your assembly on their computers, would you?

Fortunately, once you have defined a Security Policy, you can distribute it to your users and have them add it to their system with a single click.

You can use the .NET Framework Configuration Tool to configure a wide range of security options available to .NET applications.

After you define a Security Policy, you can create a Deployment Package that installs the Security Policy via a Windows Installer File (an .MSI file.) To create a Deployment Package, simply right-click on the Runtime Security Policy branch, and select the Create Deployment Package option (see Figure 13).

Assembly.LoadFrom Revisited
Now, let’s review what .NET does behind the scenes when you use the Assembly.LoadFrom method to load an assembly from a remote location. Let’s take this code for example:

   'Define URL.   Dim URL As String   URL = _   "http://localhost/CodeDownLoadDemo/ModuleA.DLL"   'Load assembly from the URL defined above.   Dim a As [Assembly]   a = [Assembly].LoadFrom(URL)

When .NET executes the LoadFrom method, it goes to the URL http://localhost/CodeDownloadDemo and looks at the ModuleA.DLL assembly on the Web server. .NET verifies whether you have downloaded this assembly before. If you never have, .NET downloads this assembly and stores it in the .NET Assembly Download Cache.

The second time you run this same code, .NET realizes that the assembly has been downloaded before. If the version in the Web server is the same as the one that you have in your Assembly Download Cache, .Net uses the one that you already have on disk.

Let’s say that you run this code a third time and .NET realizes that the version on the Web server is more recent than the one that you have on disk. .NET automatically downloads the new version, stores it in the Assembly Download Cache, and runs it.

The Assembly Download Cache is a special folder located under c:windowsassemblydownload. Figure 15 shows how the assembly cache looks on my computer.

About Our Editorial Process

At DevX, we’re dedicated to tech entrepreneurship. Our team closely follows industry shifts, new products, AI breakthroughs, technology trends, and funding announcements. Articles undergo thorough editing to ensure accuracy and clarity, reflecting DevX’s style and supporting entrepreneurs in the tech sphere.

See our full editorial policy.