Jump to content


This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Photo

1911 type lib register error


5 replies to this topic

tomwelsh

tomwelsh
  • Members
  • 2 posts

Posted 02 March 2001 - 14:34

My typelib will not register.  At run-time I get error 1911.  I have confirmed that I have a valid GUID and have set the Locale ID to 0 as cautioned in the InstallShield Knowledge Base article Q102742.  All other components of the COM component seem to register fine.  My settings for this component have been entered manually since the Component Wizard was not able to read information directly from the server EXE.  Here is the contents of my type library description:

Typelib name: xTools Type Library.
   GUID: {AB3DC4B4-CCEA-11D2-B93F-0060089CDDBA}
   Locale ID: 0
   Version: (not set)
   Cost: 1
   Help Path: [INSTALLDIR]
   Description: xTools type library.

I tried setting and not setting the Version, Help Path, and Description fields.  I also tried several GUID, including some automatically supplied by InstallShield, manually created and from the server application definition. All variations generated the identical failure result.

Has anyone got a notion about what is happening here?  It seems like this should be a simple operation, but I am obviously missing something.  All
help would be appreciated.



SteveP

SteveP
  • Members
  • 126 posts

Posted 02 March 2001 - 19:57

I don't use IS, so I don't know how this works out with that interface, but I have run around the block with this error a number of times.  

In general, I have found that the problem crops up when you are registering a DLL file that contains a number of COM objects.  What I have seen is that the RGS blocks for the imbedded objects are out of sync ... and what generally happens is that there are more than one TypeLib entry in the registry information internal to the DLL.

This has happened from time to time in our development environment when we have merged two or three objects into one DLL and one of the registry blocks does not match the others.

In my packager, I have the luxury of working with the MSI tables in SQL format ... partly for this very reason.  What I have done to find this kind of problem is to sort all the TypeLib entries in my MSI by Component_ and look for duplicates.  Since I have only one DLL per component, the problem will jump out clearly.

The issue we have dealt with is that each DLL should have only one TypeLib GUID that is shared by all the objects in the library.


tomwelsh

tomwelsh
  • Members
  • 2 posts

Posted 02 March 2001 - 23:25

Steve,

This may indeed have bearing on my problem.  I can find no error or other options to my approach within the InstallShield setup.  I was beginning to think that the problem resides with the component files themselves.  I am working with legacy code, so I do not know exactly what I am dealing with, but I can make a few statements.  First, the object is an EXE COM server.  It will register and work if I manually register it via in the form MyApp.exe -regserver.  This allows me to see where all of the registry settings are placed and their values in a true "working" environment.  From within the Windows installer process, all of the non-typelib-specific registry entries are made mostly as expected.  But as described before, the typelib registration fails.  I reviewed the resource files, IDL, and RGS files and all seems OK to my only slightly trained eye.  There are 2 RGS files.  One describes the AppID registry entry for the server.  The second describes the exposed COM class.  This second files has two distinct GUIDs.  One serves as the CLSID for the exposed class.  The other is used to identify the AppId and is also assigned as a value to 'TypeLib'.  This AppId does match that contained in the other RGS file.  Does any of this ring a bell to you?  The problem could easily be right under my nose.

Also, do you know a way to test the extraction of the Typelib information from COM EXE?  If I can test the file directly, then I could isolate the problem from installation script.

Thanks for your help.


SteveP

SteveP
  • Members
  • 126 posts

Posted 06 March 2001 - 22:23

Tom,

From what you said about your second RGS file, you may have a problem there.  You said, "The second describes the exposed COM class.  This second files has two distinct GUIDs.  One serves as the CLSID for the exposed class.  The other is used to identify the AppId and is also assigned as a value to 'TypeLib'.  This AppId does match that contained in the other RGS file. "

What I find of concern here is that the same GUID is used to identify the AppID *AND* the TypeLib ... which, so far as I know, is invalid.  Also, the AppID GUID should be specific to the DLL and not change from place to place.  I am going to append an example from one of my EXE files ... edited a bit, of course:

HKCR
{
NoRemove AppID
{
{848375EF-****-****-****-***************} = s 'MyApp'
'MyApp.EXE'
{
val AppID = s {848375EF-****-****-****-***************}
}
}
}

HKCR
{
MyApp.1 = s 'MyApp Class'
{
CLSID = s '{848375FB-****-****-****-***************}'
}
MyApp= s 'MyApp Class'
{
CLSID = s '{848375FB-****-****-****-***************}'
CurVer = s 'MyApp.1'
}
NoRemove CLSID
{
ForceRemove {848375FB-****-****-****-***************}= s 'MyApp Class'
{
ProgID = s 'MyApp.1'
VersionIndependentProgID = s 'MyApp'
ForceRemove 'Programmable'
LocalServer32 = s '%MODULE%'
val AppID = s '{848375EF****-****-****-***************}'
'TypeLib' = s '{848375EE****-****-****-***************}'
}
}
}

The things to note here are that the AppID remains the same throughout, that it differs from the CLSID of the class objects (there are more of them), and that it differs from the TypeLib.  The TypeLib should match the entry in the lirbray section of the IDL file.  It will appear as uuid(<TypeLib>).

The IDL is a better source for the TypeLib than the RGS files ... I have seen several instances where the incorrect TypeLib (or even several different instances of incorrect TypeLib GUID's) appear in RGS files, and they don't appear in the IDL.  Once all the entries match, there is generally little difficulty getting things to register.

The way we confirm the registry information for a file that has the SelfRegister entry point is to use a LoadLibrary call followed by reading the resource string table.  Then we identify those resource blocks that are identified as Registry information (or look for HKCR ...) and then parse the strings to recover imbedded registry data.

If this sounds as though it is on the right track, and you need more specific details, please feel free to drop me an email, and we can get down to cases.


paulc

paulc
  • Members
  • 1 posts

Posted 20 May 2003 - 11:11

I experienced a similar problem registering type libraries. In my initial build all worked perfectly, but subsequent build generated the 1911 error for just 2 components.

Whether you add COM information manually or create a component using the wizard, the COM information is stored in the internal tables ClassId, ProgId and TypeLib. Should any of the COM information change between builds then this static information gets out of sync with the correct COM information.

My solution was to delete the static data from the troublesome components and set the Extract COM at Build option for the component to Yes.

You can test this by setting the Extract COM at Build option to yes without deleting the statis COM information first. During the build process you should get warnings that the extracted COM information is different to the static information.


FrankSpierings

FrankSpierings
  • Members
  • 22 posts

Posted 16 January 2006 - 11:58

Mabey my issue with error 1911 can help somebody in the future.

I repackaged an application. Deleted several registry keys (containing class / typelibrary info), and put these components on "Extract COM information at build".

When i compile my MSI from ISM, without having the original package installed, the resulting MSI will display several 1911 errors. These errors occur because the extraction found two more type libraries, which actually didn't apply to the component. Every failing component has the following to extra type library ID's:
{000204EF-0000-0000-C000-000000000046}
{EA544A21-C82D-11D1-A3E4-00A0C90AEA82}

To resolve this issue, i compile a package (which uses the extraction) only when the original source is installed.

Later on you install the newest correctly compiled package, when compiling the new packages.

Hope this helps the repackagers in the future.

Greets.