Partager via

Problems after installing Add-ins

  • Article

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

  • Anonymous
    February 09, 2004
    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?
  • Anonymous
    February 11, 2004
    IDE Unable to load Dte.olb

    Register dte.olb with the command below:
    regsvr32 "C:Program FilesCommon FilesMicrosoft SharedMSEnvDTE.OLB"

  • Anonymous
    February 14, 2004
    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.
  • Anonymous
    February 16, 2004
    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"

  • Anonymous
    March 19, 2004
    The comment has been removed
  • Anonymous
    March 24, 2004
    The comment has been removed
  • Anonymous
    May 04, 2004
    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"


    Thanks,
  • Anonymous
    May 12, 2004
    The comment has been removed
  • Anonymous
    May 15, 2004
    Thanks that just fixed it for me and prevented further hair loss.
  • Anonymous
    May 17, 2004
    Dmitry,

    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.
  • Anonymous
    June 01, 2004
    The comment has been removed
  • Anonymous
    August 08, 2006
    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!
    --Ferg
  • Anonymous
    June 09, 2009
    PingBack from http://hairgrowthproducts.info/story.php?id=4545