Who has shared add-in solution that works?

Question

Hi everybody,

I know I should not run away from my problems. But what else can I do? I have an VSTO Word solution. This part works fine. I also installed it on a other pc than my, and it just works perfect. But there is one small thinh that is missing. And this is where my problem starts:

When the user starts "Word" for example. There shlould be a button in the "Standard" Menubar. I tired this with a shared add-in. And it also works but only on my pc where the VS2005 is installed. I just can't install it on an other pc. I tried it a few times and every time after starting "Word" the registry value of "LoadBehavior" gets back to 2. What means he can't find the add-in. And of course there is no button.

Has someone a solution that worked ? If so what have you done ? Or can I add this button without an add-in? Thank you!

Answer 1

Hi, I'm a program manager on the team that makes VSTO.

If I'm reading this right, you're saying that your shared add-in works ok on your dev box, but it does not work on a machine without VS2005, right?

You didn't mention which version of Office you're testing, but based on your mention of VSTO I assume it's Office 2003. In that case, please make sure your Office box is patched with the update associated with KB907417. It came out with AutoUpdate in early October, but you can apply it manually as well, in case it hasn't gotten applied to your Office 2003 box already.  The KB article doesn't have too many details about the issue, but the fix associated with it is intended to help solve a known problem with shared add-ins in .Net 2.0.

If this doesn't help (or if your Office version is older than 2003) then you may want to wait a couple of days for an update to KB908002. In a few days, that article will point to a downloadable add-on to VS2005 that should resolve the issues that may be currently preventing your shared add-in from working. That update will, among other fixes, contain a redistributable version of extensibility.dll which is typically needed to enable shared add-ins to work on Office machines. The absence of extensibility.dll on your Office machine may be an other possible reason for the shared add-in not working on your Office box.

Hope this helps
Martin

Answer 2

Hi Martin,

Thanks for your answer. Well I give all the facts of my situation so things might be clearer.
I work withe the VS2005 Beta 2 on the .Net Framework Beta 2. Correct, I use Office 2003 withe the SP1. I 'm not sure if I already should use SP2. But it also has to work with SP1.

On the enduser machine I have done this bevor I installed the add-in solution:

- .Net Framework 2.0 installed
- Office 2003 reinstalled
- installed the SP1
- VSTO Runtime installed
- then installed my add-in
- I also checkd the registry bevor I started the application
- but well after starting no signal and the registry value falls back to 2

So I will try this update option, but how can I check if the extensibility.dll is on the machine? Just run a search ? And what if its realy that easy, and the DLL is missing. How can I install / copie the DLL. I hope this is the answer to all my questions. Let's hope it works this time.

Answer 3

It works !!!

I installed the update and tried but it didn't work. So I checked if there was the extensebility.dll on the machine (made a search for the dll). And there was no DLL. So it just couldn't work. Then I copied the dll manualy in the application folder and it worked.
Now I try to uninstall the update and try it again.  Maybe it works even without the update.

The setup-project excluded the "extensebility.dll" by default. Now I have put it back. Thanks again.

Answer 4

Thomas,
I'm glad the extensibility.dll fix worked for you.
Note you need not bother trying to uninstall KB907417 for two reasons:
1) you need it. That KB update has a fix which is the other thing necessary to make .Net 2.0 shared add-ins work in o2003
2) it's not uninstallable anyway

KB908002 will explain what's going on in a bit more detail in the next couple of days. We're doing the final touches to its content right now.

Best regards
Martin

Answer 5

Hi Martin,

I have exactly the same problem. however, I implement the Outlook Addin instead of a Share Addin. And this even happens on my dev. machine. When run in the debug mode I can see my Addin Button and it stays there ever after. But if I have it in the Release mode and try to install on my Dev machine I can't see the Addin Button. It did register in the Registry and the LoadBehavior does change to 2 where it should be 3.

I have try the update kb908002. however, it doesn't work.

Please help!

Thanks,

Martin Sawicki wrote:

Thomas, I'm glad the extensibility.dll fix worked for you. Note you need not bother trying to uninstall KB907417 for two reasons: 1) you need it. That KB update has a fix which is the other thing necessary to make .Net 2.0 shared add-ins work in o2003 2) it's not uninstallable anyway KB908002 will explain what's going on in a bit more detail in the next couple of days. We're doing the final touches to its content right now. Best regards Martin

Answer 6

I had the same problem. The fix KB article fix worked for me, but its not a very good work around because, msi is for the application is distributed and difficult to distribute setup file. What I did was, I installed the add-in on development environment and took the extensibility.dll from there and added it back to setup project, then built the setup project. When I installed it on non-development machine, everything worked fine.

I am not sure its a valid work around but it got the job done!!

hope this helps

Answer 7

Hi;

I just did a search of my entire hard drive (on my dev box where my Add-In works) and found just one extensibility.dll, it is 4,608 bytes in size and appears to be version 7.0.3300.0.

I have VS 2005 Developer (release version) installed on my system. Is there anything else I need to do to get extensibility.dll?

thanks - dave

Answer 8

Hi;

Just to confirm, if I have run the latest windows update and it shows no updates for Word, then the fixes in KB907417 should be on my machine - correct?

I have never run the fix in KB907417 and on my dev machine it has version 7.10.5077.0 but my test system, which shows no pending office updates, has 7.10.3191.0. So it looks like I do have to install it.

Do we run this same update for Word 2002 and Word 2000? Or is there a different update in their cases?

And for our customers, I assume we have to point them at this fix? Or will it be included in the Windows update soon? Or can we include it in our install? Does it just update this one dll?

For KB908002, this is added to the setup program. However, we use WIX for our setup. How do we add this to our setup, and what does it do?

thanks - dave

Answer 9

Yes, KB907417 is needed to get your otloadr.dll updated with the right version on an Office 2003 machine. 5077 is what you need. If your test machine has something older than that, then you'll need to update that. If AutoUpdate hasn't kicked in yet, it's probably because it's not turned on or no-one's logged in as an admin yet. (note that both KB907417 and KB908002 require admin privileges on the Office machine to be installed properly)

Now, KB907417 is only for Office 2003. For Office XP and 2000, the only "easy" way to deploy the fix is via the VS2005 update (KB908002) as part of your addin setup that you'd create in VS.

If you're not using VS2005 to build your setup though, then getting the needed fixes to a user machine is much trickier, primarily because of the redistribution and licensing issues involved. I'll have to look into this issue more and get back to this thread hopefully within a few days (given the Christmas season this may take a while - sorry). I think what may have to come out of this is another KB with pointers at updates for older versions of Office that end uses can install themselves on their Office machines, rather than relying solely on VS2005 shared addin setups.

Techincally, fixing the Office 2000 and XP machines is not difficult. All you need is a special regkey setting that KB908002 puts in VS2005 setup projects for shared add-ins. This fixes the CLR problem on an Office machine. And then you also need extensibility.dll to be on the target machine, if you're relying on it for the IDTExtensibility2 interface. And that's the other thing KB908002 adds to shared addin setup projects. (For O2003, it additionally installs the otkloadr.dll update from KB907417). That's all.

The question then is: how can you get these two fixes (the regkey and extensibility.dll) onto an Office XP/2000 machine without having to rely on VS2005's setup projects --- and that's the question I'll need to get back to you on...

Best regards,

Martin

Answer 10

Martin Sawicki wrote:

Yes, KB907417 is needed to get your otloadr.dll updated with the right version on an Office 2003 machine. 5077 is what you need. If your test machine has something older than that, then you'll need to update that. If AutoUpdate hasn't kicked in yet, it's probably because it's not turned on or no-one's logged in as an admin yet. (note that both KB907417 and KB908002 require admin privileges on the Office machine to be installed properly)

You might want to check, I have admin privileges and I ran Windows Update. It did not show this as an option.

Martin Sawicki wrote:

Techincally, fixing the Office 2000 and XP machines is not difficult. All you need is a special regkey setting that KB908002 puts in VS2005 setup projects for shared add-ins. This fixes the CLR problem on an Office machine. And then you also need extensibility.dll to be on the target machine, if you're relying on it for the IDTExtensibility2 interface. And that's the other thing KB908002 adds to shared addin setup projects. (For O2003, it additionally installs the otkloadr.dll update from KB907417). That's all.

We already include extensibility.dll in our setup. So if we could have permission to include otkloadr.dll and you can tell us the registry change (I don't think we need permission to do that), then we would be set.

I strongly prefer that our install have everything so we don't have to point users at install after install to get up and running. (We do point them to the .NET 2.0 and J# redist installers on the MS website as those are very big.)

thanks - dave

Answer 11

Hi Martin,

I still have problems getting my VS2003 Outlook Add-in to run after installing .Net 2.0.
I installed the KB 908002 patch, the extensibility update and lockbackRegKey.msi

-Extensibility.dll has version 7.0.9466.0
-Otkloadr.dll has version 7.10.5077.0

Are these correct versions?
Are there other components that require a specific version?

Thanks,

Maarten

Answer 12

Hi,

I Have found my problem!!!

The issue was that i was using the MailItemClass instead of the Interface MailItem in my Add-in. This has changed in .Net 2.0, see this post: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=179069&SiteID=1

My only problem left is that i'm unable to debug my Outlook Add-in (this worked prior to installing .Net 2.0)

KR,

Maarten

 

 

Answer 13

Maarten

If you're having this debug problem after installing KB908002, then you must be running into a different issue of some sort. I'm not sure what that could be. I'll see if I can get someone else to help you. You should be hearing from him soon.

Best regards

 

 

Answer 14

Hi,

I didn't express myself correctly, sorry for that.

I meant that i couldn't debug using VS2003 unless i used the config file. This is okay for the moment, i hope to migrate all our applications to VS2005 soon.

The debuggin works fine with VS2005

Thanks for the quick reply,

Maarten

Answer 15

I know this thread is 2 years old at this point, but the problem is still around.

I created an office add-in project in Visual Studio 2005 aka .NET 2.0 that added a button to the office tool bar.  We are targeting Office 2003, and I'm running XP for development. 

Client machines, where it wasn't working, are Win2k with Office 2003.

When it came time to QA, it worked on some machines, not others.  It almost seemed hit or miss.  There was no error, no logging (I'd added extensive file logging), nada: the add-in simply wasn't firing at all.

After a couple days of looking everywhere, I finally supplemented the out-of-the-box Visual Studio office Add-in project with a COM Shim style office->unmanaged C++ shim proxy->managed add-in approach, thinking the problem might be security (something to do with limited registry access on their AD domain?), or perhaps something to do with managed and unmanged code interaction (I had in the back of my head that you shouldn't use managed code for explorer shell extensions).  The COM Shim wizard is a breeze.  But it didn't solve the problem: no add-in showing up.

I finally stumbled across this golden thread and, after dropping extensibility.dll into the folder next to my other Add-in dlls, it worked. 

I should note that I used the Visual Studio Add-in setup default dependencies (which don't include extensibility.dll) , and also tried installing the Office 2003 PIA's as well as the fixes for KB 907417 and KB 908002.  The only thing that worked was copying extensibility.dll along side my other Add-in dll's.

For more info see http://www.rootsilver.com/2007/08/why-doesnt-my-custom-office-ad.html

Hope that helps,
Jeff

Answer 16

I know that this thread is very old, but I am having the same problem described above and I don't know how to proceed.  The VS patch works fine for machines using VS2005, but some of our computers do not have VS2005 and are running Office XP, so I cannot get our Word Add-in to work on these systems at all. 

Martin had said: 

Techincally, fixing the Office 2000 and XP machines is not difficult. All you need is a special regkey setting that KB908002 puts in VS2005 setup projects for shared add-ins.

Does anyone know what this registry entry is?  If I have to manually add the registry entry to our machines, I would happily do it.  Thanks to anyone that responds!