# Library Not Registered Error



## Greg Truby (Feb 26, 2008)

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 (Feb 26, 2008)

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 (Mar 12, 2008)

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 (Mar 12, 2008)

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 (Mar 12, 2008)

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 (Mar 12, 2008)

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 (Aug 6, 2008)

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 (Aug 6, 2008)

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





			
				Daniel said:
			
		

> 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"_
> ...


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


----------



## LizWalker (Aug 18, 2008)

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


----------



## Darren Reynolds (Jan 13, 2015)

Greg Truby said:


> 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.


----------



## Greg Truby (Feb 26, 2008)

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.


----------



## ACurtin (Jun 26, 2015)

Same here. I had Office 2010 installed and SharePoint Designer 2013. Apparently, if you install any office component that belongs to a suite that is newer than the version that Excel runs in then it causes problems like this VBA error. Other symptoms in my case were that the option in Excel to "Send the current sheet as the message body" of an email was failing to launch outlook and the open this whatever in Outlook functionality of our SharePoint site stopped working as well. The underlying issue appears to be that any program that relies on the Microsoft Outlook libraries fails because the newest installed component installs and registers Outlook 2013 DLLs on the system and VBA always uses the DLL with the newest version. If you are using the 2013 DLL, but you don't have Outlook 2013 installed on your PC then things go horribly from there on. 

An easy way to spot this issue conclusively is to go into the Tools menu of the VBA editor in Excel and go to the References option. If you have this issue then you will see that the Microsoft Excel Object Library will have an older version than the Microsoft Outlook Object Library (in my case with Excel 2010 and SPD 2013 it displays as Excel 14.0 and Outlook 15.0).
To fix it you have to remove the reference to the newer library in your registry -or- uninstall that program which removes it as well. In my case I just uninstalled SharePoint Designer 2013 and installed the 2010 version instead. When I launched Outlook after that the first run wizard popped up and automatically re-registered all the 2010 DLLs. After that everything started working normally and Microsoft Outlook 14.0 Object Library showed up in references. The newer registry key that didn't belong automatically vanished from the registry so I didn't wind up having to mess with that.

One thing to be careful of with the registry hack. The key didn't just magically show up, some office installer put it there. In my case it was SharePoint Designer 2013 and, as it happens, our SP server is 2010 anyway so I could uninstall that. If I did have use for SPD 2013 and decided to use the hack mentioned, I would imagine that it may have wound up causing errors in SPD 2013 if I tried to reference the Outlook library in that program. I have no way to test, but if you remove the newer registry key be sure to back it up in case it breaks the newer Office component that installed it.

P.S. In Greg's fix he deleted [HKEY_CLASSES_ROOT\TypeLib\{00062FFF-0000-0000-C000-000000000046}\9.3] which mentioned in a sub-key that it was tied to Outlook 12.0.0.0 (aka 2007) and he was using 11.0.0.0 (aka 2003). This issue seems to still exist on much newer versions as well. A more universal approach would be this:
*You'll need admin rights to do any of this.*
1. Open RegEdit and navigate to HKEY_CLASSES_ROOT\TypeLib\{00062FFF-0000-0000-C000-000000000046}
2. Within that key you will see a sub-key for each version of the Outlook DLL you have registered
    a. The sub-keys should have names like 9.1, 9.2, 9.3, 9.4, 9.5, etc
    b. If you only find one sub-key in here then this is not your problem and this fix is not for you
3. If you click the key you will see a property called PrimaryInteropAssemblyName and the data value will indicate the outlook version
4. Find the key with version of Outlook you are running (2010 was version 14 which was a key named 9.4 in my case)
5. Export any keys with a version greater than that (in my case SPD 2013 had created key 9.5) and keep them in a safe place
6. Delete those keys and then re-launch Outlook and any other Office programs you have running
7. If something else breaks then double click the exported key file you saved to put it back.


----------



## StreetMike (Mar 16, 2018)

Greg Truby said:


> 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
> 
> So depending on one's circumstances, perhaps this tidbit might help.



Wow, this post is the gift that keeps on giving. I'd deleted all references to other (not installed) outlook versions...but thanks to this post, found the folder (9.6 in my case) that was the problem and deleted it. Bingo. 

Not sure how it ever happened in the first place, but my problem is fixed. Thanks a million - been looking for help for days, and Microsoft had no idea either. (Not super surprising).

Thanks!
Mike


----------

