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