Configuring Restricted Systems

Programmers who are on projects that involve writing point-of-sale, information kiosk, industrial control, and other such systems are often tasked with blocking users from accessing any other programs on the system, particularly things like task manager or other system applications. One of the biggest programming mistakes you can make is to allow such users local administrative access and then try to block them in code.

The reason it is a mistake is that unless you code to a very low level your measures can easily be circumvented by a knowledgeable user who has local administrative access. They can easily boot the system in safe mode and disable your ‘protection’ and do whatever they want to do with the system. Low level solutions, which would have to be written in unmanaged C++ code or Assembly, may have undesirable side effects and are really a waste of programming resources when Windows already provides tools for this purpose.

Another benefit to using policies is that the system will be easier to support because local system admins who can login without restrictions to perform routine maintenance tasks. System administrators really don’t have time to deal with ’secret handshakes’ and the like to get around your security when they’re trying to maintain 100’s, if not 1000’s, of systems.

Therefore, it is important that you work with a system administrator to set policies that limit what users who need to be restricted can do on the system. This Microsoft Knowledge base article covers the basics and has links to other articles with more details on how to administer group policies: How to implement system policies for Windows XP-based, Windows 2000-based, and Windows Server 2003-based client computers in non-Active Directory environments. You can also search MSDN and TechNet articles to find additional information that would apply better to your particular network configuration.

Add comment May 15th, 2007

ClickOnce Deployment

ClickOnce is a new deployment technology available from Microsoft that comes with Visual Studio 2005. It has some neat features that could help you manage deployment of your applications over the Internet or a local Intranet but it also has some quirks that you need to watch out for as well.

First, let’s look at some of the advantages. ClickOnce deployment allows you to create self-updating Windows-based applications that can be installed and updated with very little user interaction. It also handles partial updates for you so that your users don’t have to do a full re-install of the program. ClickOnce only installs the changes. Since the applications are in a “sandbox” shared component conflicts won’t be a problem in many cases. Lastly, it can be installed by non-administrative local users who only have limited installation rights, thus reducing support time.

The biggest quirk that you’ll notice is that instead of installing to the standard “Program Files” directory structure the program installs to the user’s application “sandbox” area. This path is usually something like this:

C:\Documents and Settings\[UserName]\Local Settings\Apps\2.0\[code]\[code]\[code]"
.
.
.

It also installs on a per-user basis so that you will have as many copies of the program installed as there are users and you can’t install a ClickOnce app for All Users. If your target deployment systems are used by multiple users this could limit your ability to use ClickOnce effectively.

Also, although it allows a limited rights installation it does require writing to the registry in the installing users area. Some system admins have disabled this ability so this may also limit its usefulness.

Managing common user data areas is a bit tricker with a ClickOnce application. My.Computer.FileSystem.SpecialDirectories.AllUsersApplicationData does not return the
actual “All Users” data folder but a data folder in the ClickOnce “sandbox” cache. You’ll need to use
Environment.SpecialFolder.CommonApplicationData to get the “All Users” folders on ClickOnce deployed apps.

For more information on ClickOnce deployment, see this MSDN article: ClickOnce Deployment Overview

Add comment May 15th, 2007

Why Option Strict?

Why should you use Option Strict?

VB programmers, like BASIC programmers before them, usually haven’t paid much attention to variable types. We commonly concatenated strings and number values together and did other such type conversions on the fly. So why would we want to restrict our freewheeling methods by using Option Strict?

The main reason is that it improves the quality of our code. Just like Option Explicit, which require variables to be declared, Option Strict helps us prevent bugs before they can happen. Bugs are much easier and less expensive to fix in the early stages of development and they become progressively more expensive as a project goes on. Conversion related errors plagued many VB6 and earlier applications. Often we would see intermittent, weird, bugs that were hard to track down and tricky to fix reliably. This was often called “evil type coercion”, or “ETC” for short, in VB6 circles. Thus, by using Option Strict, we avoid one of the most common problems encountered in classic VB development.

But what else happens if you don’t use Option Strict? Yes, the .NET Framework will do the conversion for you using the System.Object just like the VB6 runtime did with Variants. However, this has the same drawbacks as in VB6, difficult to trace bugs and a considerable performance hit. In fact, the performance hit is greater than using Variants in VB6 because of the additional conversion work the System.Object has to do.

If you turn on Option Strict in a existing project you may be shocked to see just how many poorly typed operations you have. It’s very likely to exceed the 100 or so errors that the Error List window holds. Don’t panic, it’s not that tough to replace them with the .NET conversion standard functions of DirectCast, TryCast or CType (I’ll discuss these in another article at some point). Making this fix to your code is a quick and easy way to improve your app’s performance and stability.

You will probably want to also take the step of turning on Option Strict for all your new applications. Unfortunately, the VB.NET IDE ships with Option Strict off, probably in order to make transition easier for VB6 programmers. To turn it on for your apps, open the Options Dialog from the Tools menu and navigate down the tree to “Projects and Solutions” and then “VB Defaults”. From the combo, select On, click OK and you’re done.

1 comment May 9th, 2007