Library Not Registered Error

[Greg Truby]

OK this has had me doin' the now for three hours. I am just plain out of ideas...

Got new notebook. (Don't get me started...)

Trying to run code that worked perfectly well on old machine, but blowing apart on new machine...

The crux of the matter:

Sub emailReports()
'¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
    Const cstrMsgFileName As String = "e-mail text.html"
 
    '// __booleans___________
    Dim booIStartedOutlook As Boolean, _
        booIOpenedDataWB As Boolean, _
        booScrnUpdate As Boolean
 
    '// __integers___________
    Dim hndInput As Integer, i%, p&
 
    '// __objects: outlook___
       Dim appOL As Outlook.Application, _
        emlNew As Outlook.MailItem, _
        objRecipients As Outlook.Recipient
...
    '// Create a Handle to Outlook
    On Error Resume Next
    Set appOL = Nothing
 
    Set appOL = GetObject(, "Outlook.Application")
    MsgBox "app is " & IIf((appOL Is Nothing), "", "NOT ") & "nothing.", vbInformation
    On Error GoTo CleanUp
    If appOL Is Nothing Then
        booIStartedOutlook = True
        Set appOL = New Outlook.Application
    Else
        booIStartedOutlook = False
    End If
...

This code worked just fine on the old 'puter. Now she throws a shoe every time. If I change the On Error Resume Next to On Error GoTo 0 before calling GETOBJECT, I get a "Error -2147319779... Library not registered"



I have tried everything I can think of to get this to work and nothing is helping. I have

• Hacked the registry to give myself "total control" over the HKEY_CLASSES_ROOT folder.
• Hacked the registry to give myself the ability to register libraries. (Then, of course, I right-clicked the MSOUTL.OLB file and registered it.)
• Set a copy of the MSOUTL.OLB file in the C:\WINDOWS\SYSTEM and ...SYSTEM32 directories
• Shuffled the sequence of the references, moving the OUTLOOK reference up to #3, just below VBA & Excel.
• Confirmed that this library is registered.
• ...more that I've forgotten.

Nothing works to resolve this error.

The only workaround was to change all the DIM statements to declare as generic OBJECTS. Then the code works just fine. But how the devil does one actually fix this? Like I said, the same code runs just fine on my old machine.

 

[starl]

not gonna read a mile a long link..
did you try unregistering it the reregistering?

what version of outlook? same as the old?

 

[Greg Truby]

OK. I think, maybe, just MAYBE I fixed this.

I went so far as to have IS re-install Office 2003. Still did not fix my problem. And FWIW, I had another project derail, it kept telling me it had problems with a different reference. However, by going 1-by-1 through the references, I determined that the problem, again was with the Outlook reference and not where it was telling me (not the first time the compiler has lied to me about reference errors BTW).

As a last ditch hail-Mary, I searched the registries on both old and new notebooks for "MSOUTL.OLB"

On the new machine I found an entry that did not exist in the old machine's registry:

[HKEY_CLASSES_ROOT\TypeLib\{00062FFF-0000-0000-C000-000000000046}\9.3]
"PrimaryInteropAssemblyName"="Microsoft.Office.Interop.Outlook, Version=12.0.0.0, Culture=neutral, PublicKeyToken= ««deleted»»"

I don't have Office 12, only Office 11. So I exported this as a precaution and then deleted it and voilá, the code appears to be working just fine now. No more "library not registered" error.

I have no idea how this key could possible have been created. And I hope that this post never helps another soul, i.e. I hope no one else ever has this same problem. But if you do, please post here and let me know that at least I had some company.

Footnote: Also posted this same problem here.

 

[Richard Schollar]

Hi Greg

If you are using GetObject then you can specify what type library you want to use:

Set appOL = GetObject(, "Outlook.Application.11")

This might have prevented this error from occurring. Glad you sorted it though!

 

[Greg Truby]

Where in billy blue blazes were you two weeks ago!!! I spent hours on this #@$&*-ing problem! But you can bet that if I ever run into a similar situation I'll give that a try. 'course two weeks ago I didn't know that there was a 2nd registry entry referencing a phantom version twelve, so I probably would never that thought to specify that anyhow.

 

[Richard Schollar]

No, I must admit I wouldn't (ordinarily) think of specifying the lib type to use either - by default (and if not using Get/CreateObject) the latest type library will be used (and unless you use Get/Create, you can't amend this behaviour without tinkering with the registry). It's interesting that you had a ref to Office12 on your machine...

 

[fisher_antony]

Ah - ha - I've just spent about 8 hours trying to solve why one particular client cannot use a Outlook library we provide when theres nothing visibly wrong with the application or Outlook ... to find that, yes ... find that Outlook.12 registry entry, detele it, and it all works fine.

The client does have Office2007 Interop Assemblies installed which may be where it came from.

Thanks for posting the hack

 

[Greg Truby]

I'm glad to hear that this helped you! (Well, sorta glad -- it would have been better had you never wasted those eight hours! :wink

Also, I should note that on the other forum where I posted this problem, a fellow in Germany wrote

Finally I followed your suggestion and removed the Key

[HKEY_CLASSES_ROOT\TypeLib\{00062FFF-0000-0000-C000-000000000046}\9.3]
"PrimaryInteropAssemblyName"="Microsoft.Office.Interop.Outlook, Version=12.0.0.0, Culture=neutral, PublicKeyToken= XXXXXXXXXX"

But it didn't work. Then I deleted the complete folder 9.3 and now it works.

So depending on one's circumstances, perhaps this tidbit might help.

 

[LizWalker]

Thank you, thank you, thank you - 5 hours until I found your post and it was 9.3 for me too!

 

[Darren Reynolds]

OK. I think, maybe, just MAYBE I fixed this.
...
And I hope that this post never helps another soul, i.e. I hope no one else ever has this same problem. But if you do, please post here and let me know that at least I had some company.

Yep. January 2015 and your fix is still going strong.

Had Office Home & Business 2010 32 bit and Access 2010 32 bit installed and wanted to upgrade to 64 bit because of the size of our spreadsheets which were causing frequent crashes. Uninstalled 32 bit. Went to install 64 bit. Home & Business went fine, but the Access 2010 64 bit installer wasn't having our Product Key.

So, went and bought the current version, Access 2013, with a new product key, and installed that instead. OK, great, now we have everything 64 bit.

Ran the Access app - oops, got the error your post is about. At this point I don't know if it's the upgrade from 2010 to 2013, the 2010/2013 co-existence, or the upgrade from 32 bit to 64 bit that is causing the problem.

All I know is that Dim o as Object fixed the problem and that's good enough for me. Thank you very much.