As the owner of this blog, I can see how people are getting here using the referrers list. One thing that I see show up often in the list of referrers is a search on a popular search engine for the string “dte.olb could not be loaded”. Believe it or not, this can happen because of a common error when building Add-ins.


Suppose you run the Add-in wizard to generate the code for an Add-in. Well, there seems to be a problem where sometimes, not always, but sometimes one of the files which should be marked as excluded within the setup project become marked so they are installed by the setup project. These files include DTE.OLB, EnvDTE.DLL, Extensibility.DLL, Office.DLL, or stdole.DLL. Another way to make these files not excluded is to add a file which depends on a file. This is common with stdole.DLL, you add a COM object to the project and stdole is seen as a dependency, so it is added also. For the purposes of this example we will suppose that DTE.OLB is not marked as exclude. So you build the setup project, and then (being the good developer that you are) test out the install project. Install is done flawlessly, and your Add-in works as it should. You then uninstall, and that where the troubles start. Why does this happen?


Well, when a tlb is installed by an MSI file it is registered in the system registry. DTE.OLB is just a typelib, embedded into the resources of a DLL which is then renamed to have the extension olb (there are historic reasons as to why this was done, and that may be the subject of a later blog entry). When the MSI file is unregistered, Windows Installer, thinking it is doing the correct thing and unregisters that type lib. In most cases this is the correct thing to do, you should remove everything that you put on the system during install. But in this case unregistering the tlb is not the right thing to do because other components, such as Visual Studio, the Macros IDE, and Add-ins, need this type library to be on the system so they can work properly. Since the registry keys identifying the tlb have been removed, it can no longer be found. The next time you start VS, you will see errors such as “dte.olb could not be loaded”.


You can work around this problem by making sure that you exclude this file from your setup projects. In fact, you should exclude all files which you know will be on the computer you are installing to, including include DTE.OLB, EnvDTE.DLL, Extensibility.DLL, Office.DLL, and stdole.DLL. You know these files will be there when installing an Add-in because if they are not, then your Add-in will not run because VS is not installed.


If you find yourself in the state where these files have been unregistered, there are a few ways to fix it. You could try running VS setup and performing a repair. This can be a bit slow, however, so this can be used as a last chance fix. The best fix is to find and use a tool such as regtlb (register typelibrary), and then find the common files that become unregistered, such as DTE.OLB. Lastly, you could create a setup project which references DTE.OLB, install that project, and leave it installed for all time. If it becomes unregistered again for any reason, re-run your project’s repair option, which will be much faster than running VS’s setup.