Software Deployment

You can find more info on MSDN
Usually we do not delete registry keys that have conflicts. You have problems if you have conflicting files.

i would really appreciate if someone could explain the foolowing reg keys to me, their purpose and so on:-
typelib and interface keys

It's a good question - I'm not clear on what these keys are used for either so anyone out there who can explain or point us towards some reference material would definately get some post ratings.

As far as removing them goes - personally I wouldn't unless they relate to a capture of an app including the installshield engine.

If they are keys which have changed reg stuff in the base build then it's your choice.. removing them may stop your app working properly (which probably wouldn't become apparent until it's tested) - leaving them would mean you may need to make the components installing then permenant to avoid them being removed on uninstall. If you are going to do this it would be wise to create new component/s just to install the keys you are going to make permenant so that no other (unnecessary) stuff is left on the machine.

Kinda depends on how thorough your QA process is and what tools you have to use - Test Expert (part of the WPS QA module) is good for testing uninstalls and which reg keys / files have been destroyed in the base build - it's quite expensive though.

Cheers,
Rob.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_foxhelp9/html/be797e96-7fe7-4ada-b422-3159dafb4e7b.asp
Type libraries are COM Component definition files that include information about types and objects exposed by an OLE application. A type library can be a standalone binary (.tlb) file, compiled in an application (.exe) file, embedded in an ActiveX control (.ocx), or included in a dynamic-link library (.dll or DLL) file. DLL files with one or more type libraries are often compiled as object (.olb) libraries.

You should be able to register your type libraries from the TypeLib table

Registering the Type Library from Inside Distributed COM: Type Libraries and Language Integration

Before you can make full use of a type library, its existence must be noted in the registry. Languages such as Visual Basic and Visual J++ scour the registry in search of components containing type libraries. Registering a type library consists basically of inserting the necessary entries under the HKEY_CLASSES_ROOT\TypeLib and HKEY_CLASSES_ROOT\Interface keys in the registry. The HKEY_CLASSES_ROOT\TypeLib key declares each type library installed on the system. A library identifier (LIBID) consists of a globally unique identifier (GUID) that identifies each registered type library. Every LIBID key in the registry contains several subkeys that specify the version number of the type library, the path to that library, several flags, and an optional path to a directory containing help files with information about the contents of the type library.

A registration (.reg) file can be used to create these registry entries. It is preferable to integrate the type library registration step with the component self-registration step, however. Programmatically registering a type library is as easy as calling the LoadTypeLibEx function. This call can be used to create all the necessary entries automatically. In addition to filling in a complete registry entry under the TypeLib key, the function adds entries for each of the Automation-compatible interfaces (including dual interfaces) defined in the type library. This information is required to create instances of these interfaces. It is important to note that COM objects are not registered by LoadTypeLibEx (that is, the type library registration functions do not write any values into the CLSID key of the object).

NOTE For more information on registration (.reg) files and their use with type libraries, consult Chapter 2 "IUnknown and IClassFactory" of Inside Distributed COM by Guy Eddon and Henry Eddon.

The HKEY_CLASSES_ROOT\Interface key contains information about each COM interface available on the system that has an interface identifier (IID). This section begins with {00000000-0000-0000-C000-000000000046}, the IID of the IUnknown interface, and then proceeds with some very standard COM interfaces, such as IClassFactory, IMalloc, and IMarshal, before heading off into some of the more esoteric COM interfaces, such as IExternalConnection, and finally delving into the world of custom interfaces. One IID subkey is required for each new interface your application defines.