Problems after installing Add-ins

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.

"urn:schemas-microsoft-com:office:office" />

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.

Comments (14)
  1. Sam Gentile says:

    I have tried all these steps and I still can’t get VS.NET 2003 to load. I did a regtlib on dte.olb and I have done 3 complete reinstalls and I still get this message. Do you any other ideas?

  2. phil says:

    IDE Unable to load Dte.olb

    Register dte.olb with the command below:

    regsvr32 "C:Program FilesCommon FilesMicrosoft SharedMSEnvDTE.OLB"

  3. Craig says:

    There are a few other tlbs that you need to make sure are registered. Register all the tlbs in Program FilesCommon FilesMicrosoft SharedMSEnv. Also, try repairing Office. We use some tlbs from there, and if the installer is confused into thinking they are properly installed, but they are not, then that could keep VS from starting.

  4. natasha says:

    I had a similar problem with that dte.olb not loading. i just cut and pasted this command at the run command

    try this:

    type this at the run prompt in ur computer

    regsvr32 "C:Program FilesCommon FilesMicrosoft SharedMSEnvDTE.OLB"

  5. vieboi says:

    I have a similar problem with you guys and I did register with this line below

    regsvr32 "C:Program FilesCommon FilesMicrosoft SharedMSEnvDTE.OLB"

    VS.NET 2003 doesn’t ask me to load DTE.OBL, no message any more, but I still can’t open it yet. When I run it, just flash and done.

  6. vieboi says:

    It still not work after I did that register command… Also, my Fontpage and Norton Anti-virus 2003 have the similar problem. I can’t uninstall these programs and re-install… Any help please?

  7. Tintin says:

    I also had same problem….Now I registered with following link and it is working now

    Register dte.olb with the command below:

    regsvr32 "C:Program FilesCommon FilesMicrosoft SharedMSEnvDTE.OLB"


  8. Excluding envDte, extensibility, VSLangProj and other VS assemblies from the Setup project seems to be not quite correct thing to do. Believe or not, some of my users report that they have version of EnvDTE.dll on their machines that differ from that is referenced by my add-in. The former is 7.0.9466.0, while the latter is 7.0.3300.0. And those users also report that the following code in add-in causes invalid cast:

    <br>EnvDTE.ProjectItemsEvents myProjectItemsEvents;
    <br>myProjectItemsEvents = (ProjectItemsEvents)
    <br>applicationObject.Events.GetObject (&quot;CSharpProjectItemsEvents&quot;); // throws InvalidCastException

    I think that the reason for the invalid cast is version mismatch of envDTE. So, it follows that I still need to install the correct envdte.dll on user machines. And how can I prevent VS COM servers from unregistration if not by excluding the abovementioned assemblies from Setup?



  9. Stuart Elliott says:

    Thanks that just fixed it for me and prevented further hair loss.

  10. Craig Skibo says:


    We had a problem between VS 7 & 7.1 where the assembly version number remained the same (3300), but the file version number was different (3300 and 9466). We are looking into this and trying to see if there are problems because of this, and what the impact is.

  11. Dmitry Shaporenkov says:


    thanks for your reply. However, it seems that it was just a false alarm on my side. In fact, the user who have the different version of EnvDTE.dll reported me that the invalid cast disappeared after he had registered dte.olb and csproj.dll. So I think that the real problem is that when dte.olb is not registered on a machine (due to e.g. faulty add-in installation that unregistered it), this cast fails.

  12. Ken Ferguson says:

    I’ve got an application which I’m trying to install. It tells me that it requires stdole.dll version 7.0.3300.0 installed in the GAC… The problem is that my stdole.dll is version 7.0.9466.0 from installing the .NET 2 framework. I have all of the .application and .dll.deploy files… is there something I can do to fix the problem? Will I have to depend on the developer to rework the dependency on this version of stdOle?

    Thanks Craig!


Comments are closed.

Skip to main content