UAC Compliant

UAC stands for User Account Control and is the new technology in Windows Vista to provide users with different level of administrative rights and privileges. UAC main purpose is to support a more secured environment then what Windows XP offers.

Microsoft has a good white paper that covers UAC in detail and therefore I have no intention to cover it here:

• The Windows Vista and Windows Server 2008 Developer Story: Windows Vista Application Development Requirements for User Account Control (UAC)

Most developers I know have intentionally disabled UAC because they found it to be rather annoying, time consuming and too restrictive.

Although I can agree with these opinions I try to have it enable as much as possible simple because that will be the most likely scenario for many of my customers. In addition, from a general point of view I support it because by default all users (except Guests) are logged on to Windows Vista as standard users and get extended rights only when needed.

Since we can disable the UAC we may believe that we can solve most issues when installing different kind of softwares. However, in my own experience it may or may not be true.

In my case, I got some old ActiveX controls and .NET controls where they are either no longer updated or my subscriptions have expired and I have not renewed them. The errors I have faced when installing these controls as well as older softwares are:

Error 2738
This error occurs when the installation package needs to run a VBScript file and it cannot find the vbscript.dll. The error message is something like “The installation script shipped with the package needs access to an earlier version of VBScript”. In order to resolve it we need to locate the vbscript.dll on the targeting computer and registrate it with regsvr32.exe. But if Windows Script Host (WSH) is not available on the targeting computer then it must be installed prior installation of the wanted softwares. This issue is not related to whether UAC is disabled or not.

Speaking about Script Languages and Tools check out the Script Center at Microsoft.

Error 1720
The error message that popups during the installation is like “There is a problem with this Windows Installer package.” The only workable solution in this case is simple to disable UAC, install the software, and finally enable UAC again.

Of course, the best would be if the vendors can provide us with so called UAC compatibility applications.

Windows Vista and UAC Compatibility Applications
The above referenced white paper includes a stepwise process to analyze and to create Windows Vista and UAC compatibility applications. It also includes links to analyze tools which are useful to test if applications meet the requirements.

For my MSI (Microsoft Installer Packages) with customized add-ins and solutions this is too advanced. Honestly, I did find the last chapters of the white paper to be “far over my head”. 

Anyway, the key question is the same: 

• How can we make our MSI packages UAC compliant?

Included in the latest Windows SDK for Windows Vista is a new version of the Orca tool which makes it rather easy:

• Start Orca
• Open the wanted MSI file
• Select the command View | Summary Information…
• Check the option UAC Compliant as the following screenshot shows (and then save the updated MSI file):

If you only want to use this new version of the Orca tool and not install the whole SDK you may download it from here. 

Of course, my own favorite tool for creating managed add-ins  – Add-in Express .NET – has also this possibility as the following image shows:

As You note, there also exist an option to make the setup compatible with standard users. This is convenient as we, when using it, don’t need to test if the setup will work with standard users or not. A setup that target this group of users do not place anything under the Program section or in any other section that standard users do not have elevated right to access

All in all, now I got a working main development platform where Windows Vista is the operating system.

Kind regards,
Dennis

.NET Co Library – Part IV

To read previously posts about the .NET Co Library please see the following entries:

• Part I
• Part II
• Part III

Here in this post focus is set to deployment and known issues.

Deployment
Requirements
Using one of the following Microsoft Windows versions:

• Windows 2000 SP-4 and later
• Windows XP SP-2 and later
• Windows Vista and later

MS Excel
Using MS Excel 2000 with SP-3 or later versions.

.NET Framework
Prior installation of .NET Co Library .NET Framework 2.0 and later versions must be installed. If you are using Windows Vista then .NET Framework 3.0 is already installed.

MS Installer
If running Windows 2000 then MS Installer 3.1 or later version must be installed prior installing .NET Co Library. Later versions of Windows are shipped with MS Installer 3.1 and later.

MS Data Access Components (MDAC)
If running Windows 2000 then MDAC 2.6 or later version must be installed prior installation of .NET Co Library.

PIAs
.NET Co Library is shipped with version neutral IAs so .NET Co Library does not requires that any PIAs are available.

Trust Access to Visual Basic Project
In MS Excel the option “Trust Access to Visual Basic Project” must be checked
in order to use .NET Co Library.

Selecting deployment model based on the targeting group of users
In my opinion we can use different approaches to deploy solutions based on the primarily targeting groups for tools like .NET Co Library. I usually use the following categories although it’s not so easy to define them:

• End Users 
  This group should be supported well so they can start to use the tools immediately without any issues. It means that any prerequisites should be included in the installation package, well writen helpfiles and that as much as possible are done with automation.
• Power Users
  This group should also be supported in a similar way as with the group of End Users but we can require that they can make some more ‘advanced’ configuration settings. Other requirements can include being able to check out that their platform(s) can meet specific requirements before installing tools. It also can include to downloading and installing prerequisites from Internet and from other medias.
• Unofficially VBA-Developers
  This group is quite similar to the group of Power Users and should require the same support. The difference between these two groups is that VBA-developers develop solutions where VBA is included to a higher degree then in solutions from the group of Power Users.
• Professional VBA-Developers
  This group includes external consultants and officially VBA developers in corporate. Compared with other groups this group tends to want more information on how deployment processes effect their computers and settings. The helpfile should include a list of all files and their location on the computers as well as links or references to more technical information (if necessary). On the other hand we should require that they can do error trapping and make their own decisions when it comes to install hotfixes etc. 
  In my own experience I know that members of this group tend to skip to read the helpfiles.

Since .NET Co Library targets primarily the groups of unofficially/officially VBA-developers I have excluded any requirement’s checks during installation of .NET Co Library. It also means that any prerequisites are not part of the installation package. (In addition, by excluding the prerequisites it does not matter if the setup.exe is executed or the MSI package.)

Speaking about helpfiles, I will make the file for .NET Co Library available in the same location as the installation package will be available for download. It enables everyone to read the helpfile before installing the tool. 

Installation
In order to install .NET Co Library it requires administrative rights in Windows 2000, Windows XP and in Windows Vista.

Except for the Access db all files are per default installed in the main folder c:\Program Files\XL-Dennis\NET Co Library (which can be changed during the installation process). The following screenshot shows the list of files being installed:

The Access db is installed in the following locations:

• Windows 2000 and Windows XP:
  c:\Documents and Settings\UserName\My Documents\NET Co Library
• Windows Vista:
  c:\Users\UserName\Documents\NET Co Library

Why is the Access database separated from the other files? The answer is two folded:

• Write rights in Windows Vista exclude the whole Program Files section.
• Easy to locate, for instance when opening it in MS Access. In general the user’s application data folder (AppData) is recommended to place user’s data in but since this folder is usually in hidden mode the Access db is more available in other folders.

Known Issues
In general it is always recommended to make sure that you run the latest service packs for Windows, the Office suite and for .NET Framework.

The most known issue is the KB908002. If you run Windows 2000 or Windows XP with Office 2003 or earlier version of Office then this issue will probably appear. When Excel is launched an error message is showed with some ‘geeks’ information.

A close known issue to KB908002 is KB907417. It can be installed in a similar way as with KB908002. In my experience the KB908002 usually fix any issues with managed COM Add-ins so KB907417 should only be installed after KB908002 fix has been installed and tested with a negative outcome.

When installing .NET Co Library a subfolder (‘Hotfix’) is created under the main folder which includes subfolders for each above ‘KB issues’. 

In my opinion the above approach support a better stepwise troubleshooting then ‘just in case’ install the KB fixes. 

Last words
All in all, nowadays I find it rather easy to work with managed COM Add-ins and with the deployment processes. But I can understand that other find it to be a rather complex area and far away from the ‘one Excel file installation’.

Now I will finalize the helpfile for .NET Co Library and collect the last comments from individuals who have been tested it.

Kind regards,
Dennis