On the development of Excel (eight) installation and deployment of Excel projects

Related articles:

On Excel Development (1) Overview of Excel Development

On Excel Development (II.) Excel menu system

On the development of Excel (III.) Excel object model

Some of the previous articles on the development of excel in several major and more important aspects, such as menu system, Excel object model, custom function, RTD function, asynchronous custom function, user-defined task panel, etc., in the actual development we will encounter all kinds of "strange" problem, As well as the development of a number of considerations and techniques, and so on, I will write the article introduction. When our Excel add-in application is developed, it needs to be used by the user, which involves the installation and deployment of the application, and this article briefly describes the installation and deployment of the Excel project.

Unlike the Windows Form programs in general. NET, Excel Development is often a plug-in development mechanism that needs to crash on Excel and implement specific business logic by calling Excel's APIs. When the host Excel runs, it reads the registry-specific location based on the current user and the Excel version information to find the plug-in information registered under the current user of the computer, and then loads one at a time. There are some issues that need to be considered in connection with the installation of the deployment.

Issues to consider when installing a plug-in

Excel has some issues to consider when installing the deployment:

The type of plug-in, whether document level or application level, is based on VSTO development or shared add-in technology development. This has a significant impact on installation deployments.

To determine the number of bits to deploy the machine, 32-bit and 64-bit machine Excel plug-in information is different in the registry location, for 64-bit operating systems, some content will be written to the \wow6432node\ node.

Whether the Excel,excel version is installed on the user's machine, how many digits Excel has, and if the installed Office 2003 has a SP3 patch, and what the patch version number is. The point here is that, starting with Office 2010, Excel is divided into 32-bit and 64-bit versions, and these two versions of DLLs are generally not compatible, and in application development, if our plug-ins decide to be compatible with these two versions, You also need to compile and publish the corresponding DLLs for different target machines, and if they are not, you need to determine the version of Office.

If you are using. NET technology development, you need to determine whether the. NET Framework and the version of the framework are installed on the user's machine.

If you have Excel 2003 installed, if you use some features, you need to determine whether the user installed the appropriate patch, if not installed, you need to install silently.

When the installation is complete, the appropriate permission settings, such as for some directories, need to be added to the security directory, so that Excel does not prompt for security when opening its own directory with macro files.

When deploying Plug-ins, the above issues need to be considered when installing the deployment, and obtained by way of code. There are also some conditions, such as the user may be installed green version or incomplete version of Excel, these strange problems we need to consider. However, if the above conditions are considered, the installation and deployment of Plug-ins should be up to 90%.

To understand the installation deployment of the Excel plug-in we need to know how Excel loads the plug-in, below is a description of the loading and running mechanism of the Excel plug-in.

Loading and operating mechanism of two Excel Plug-ins

Here, for example VSTO Add-in, the Shared add-in principle and mechanism are similar.

When we used the Office development tool to develop add-in, we actually created an assembly (assembly) that was written in managed code that could be loaded by office. After an assembly has been loaded, add-in is able to respond to events initiated by an Office application. Add-in can also invoke the open object model of Office to extend its functionality, and of course it can use the various features provided in the. NET class Library.

The interaction between an assembly and an Office COM component is achieved through what Office provides, called the primary Interop Assembly (PIA).

If there are multiple VSTO created add-in deployed to the target machine, each add-in will be loaded into their respective AppDomain when Office is started, which greatly improves the stability of the plug-in, meaning that if a add-in is not working properly, Other add-in features are not affected, and second, when Office applications are closed, all add-in assemblies can be purged from memory.

While Add-in's assembly is the most important thing to focus on in development, office is also playing a key role in discovering and loading the add-in we write, several other components and parts. This is important to familiarize yourself with the installation and deployment of add-in.

2.1 registry Key

Excel loads Plug-ins through a series of registry keys. At the time of deployment, we also need to write information about our plug-ins to the registry of the target machine. Registry operations typically require administrator privileges in Vista and above versions of Windows.

a when deploying, we need to determine whether to deploy to the CurrentUser or the LocalMachine node.