| Groups | Blog | Home |
visual studio .net setup : Unable to run Outlook 2000 com addin built via .NET/VS 2003
I have built a com addin designed for Outlook 2000 using VS version 7.1.3088 and .NET framework version 1.1.4322 SP1. The language used is C#. I used the "Shared Addin" wizard to create the addin and only selected the Outlook option. The addin is designed to load when the host app (Outlook) starts and be available to all users. The dependencies are: Extensibility.dll, Interop.Office.dll, Interop.Outlook.dll, MS09.dll, msoutl9.dll, Office.dll I have 2 major problems: 1. When installed on the box where the addin was developed the addin is run (when Outlook starts) from the build location not the install location. That is if the build directory is c:\myproj\bin\Debug and the install directory is c:\program files\outlook-addin\myproj then the addin is executed from the build directory. The install goes ok and the correct registry entries are created. I have tested to see where the addin is running from by checking the value of Assembly.GetExecutingAssembly and it returns the build path. Also, if I remove the myproj.dll file from the bin\Debug directory the addin isn't started with Outlook. 2. The other issue (and I suspect it is related to 1) is that the addin cannot be installed onto another machine running W2K and Outlook 2000. Again, the install goes fine but nothing happens when Outlook is started. Strangely, the addin used to work (i.e. could be installed on another W2K machine and run in Outlook) but nothing has changed (in terms of the configuration of the project) for it to behave this way. Can anyone help? This is a cross-post from microsoft.public.dotnet.framework where "Peter Huang" has been providing assistance, but alas to no avail... The registry entry for Outlook finding the addin is created (in HKLM) on the target machine correctly but the associated CLSID entry is not being created. I am reluctant to run regasm on the target machine for the relevant DLL because this will then "pollute" the target environment and make it difficult to diagnose what the actual problem is, let alone issues of cleanup for subsequent reinstalls.
Hi Gary,
[quoted text, click to view] >Strangely, the addin used to work (i.e. could be installed on another W2K >machine and run in Outlook) but nothing has changed (in terms of the >configuration of the project) for it to behave this way. After reviewed this issue and discussed it with Peter, I think your Outlook 2000 addin's installation package does't work in the client machine as well as your developing machine, so do you mean this addin was able to be installed and loaded well in a client W2K machine once before? If so, have you tried to install this addin in other machines for test? By the way, since the addin used to work, has its setup project been modified by chance? I mean if you create a new simple Outlook addin and use its default setup package to install into your target W2K machine, is it OK? Thanks! Best regards, Gary Chang Microsoft Community Support -------------------- Get Secure! ¡§C www.microsoft.com/security Register to Access MSDN Managed Newsgroups! http://support.microsoft.com/default.aspx?scid=/servicedesks/msdn/nospam.asp &SD=msdn This posting is provided "AS IS" with no warranties, and confers no rights.
Hi Gary,
Thanks for the response. I have tried to install the addin on "clean" machines, i.e. where it wasn't installed before, and my boss tried to install on a clean machine that also didn't have the .NET environment on it, the install went ok but the install didn't require the .NET environment to be downloaded and installed first (like it had on other machines). The full "history" of the addin is as follows... I initially created the addin as a proof-of-principle (as you tend to do ;). The addin had a "temporary" name. I then formalised the addin code and had to change the name. However changing the name stopped the addin from working on the development/build machine. I then changed the GUID to see if that would help and it didn't. I then created a whole new VS project (same language, using the wizard and same options) and re-created all the source and data files from scratch (a rather painful process). This time I named the addin with the correct name and didn't touch the GUID at all. At this point the addin, when installed on the development machine, did not run from the install directory, it ran from the build directory (I eventually got around this issue, because I needed the install path to get some properties files, by creating a registry entry for the install path which I read when the addin is started). Also, the addin still worked when I sent a copy to my boss. However (and nothing had changed) after a couple of builds it just stopped working on my boss's machine and on other machines he tried to install it on. This time after re-creating the project from scratch I was very careful to not touch any of configuration/registry settings. Which is why I'm a bit stumped. On my boss's machine the Outlook/Addins registry entry is being created correctly but the CLSID entry is not, trouble is I don't know why... I'll try and create a "blank" Outlook addin and see what happens. If you have any other suggestions as to what I can try that would be great, we've actually got customers who are expecting this addin soon... so the faster the resolution the better! Gary [quoted text, click to view] ""Gary Chang[MSFT]"" wrote:
> Hi Gary, > > >Strangely, the addin used to work (i.e. could be installed on another W2K > >machine and run in Outlook) but nothing has changed (in terms of the > >configuration of the project) for it to behave this way. > > After reviewed this issue and discussed it with Peter, I think your Outlook > 2000 addin's installation package does't work in the client machine as well > as your developing machine, so do you mean this addin was able to be > installed and loaded well in a client W2K machine once before? If so, have > you tried to install this addin in other machines for test? > > By the way, since the addin used to work, has its setup project been > modified by chance? I mean if you create a new simple Outlook addin and use > its default setup package to install into your target W2K machine, is it > OK? > > > Thanks! > > Best regards, > > Gary Chang > Microsoft Community Support > -------------------- > Get Secure! ¡§C www.microsoft.com/security > Register to Access MSDN Managed Newsgroups! > http://support.microsoft.com/default.aspx?scid=/servicedesks/msdn/nospam.asp > &SD=msdn > > This posting is provided "AS IS" with no warranties, and confers no rights. >
Hi Gary,
[quoted text, click to view] >I initially created the addin as a proof-of-principle (as you tend to do ;). > The addin had a "temporary" name. >I then formalised the addin code and had to change the name. However >changing the name stopped the addin from working on the development/build >machine. I am not very clear about which the "temporary" name you mentioned above, is it the addin's name in the corresponding registry key or just its progid? [quoted text, click to view] >I then created a whole new VS project (same language, using the wizard and >same options) and re-created all the source and data files from scratch (a >rather painful process). This time I named the addin with the correct name >and didn't touch the GUID at all. On this point, do you mean you use a brand new name or just the previous addin's correct name to your new OutLook addin, and how about its GUID, is it a new one generated by the wizard or you copy it from the previous one? [quoted text, click to view] >At this point the addin, when installed on >the development machine, did not run from the install directory, it ran from >the build directory (I eventually got around this issue, because I needed the >install path to get some properties files, by creating a registry entry for >the install path which I read when the addin is started). Also, the addin >still worked when I sent a copy to my boss. >... >Which is why I'm a bit stumped. On my boss's machine the Outlook/Addins >registry entry is being created correctly but the CLSID entry is not, trouble >is I don't know why... If you suspect there is some problems during the the installation, I suggest you use a logfile to monitor the installation process, to record a logfile during the installation, you can use the msiexec /l*v /qf "../../yourAddin.msi" to launch your Addin's setup package, please refer to the following MSDN doc for the usage of the Msiexec.exe: The Command-Line Options for the Microsoft Windows Installer Tool Msiexec.exe http://support.microsoft.com/default.aspx?scid=kb;en-us;314881 Thanks! Best regards, Gary Chang Microsoft Community Support -------------------- Get Secure! ¡§C www.microsoft.com/security Register to Access MSDN Managed Newsgroups! http://support.microsoft.com/default.aspx?scid=/servicedesks/msdn/nospam.asp &SD=msdn This posting is provided "AS IS" with no warranties, and confers no rights.
Hi Gary,
Thanks for the response, sorry for the delay, as is ever the case other things popup ;) In answer to your specific questions I'd changed the name in the GuidAttribute value, it is now: [GuidAttribute("3B2854FA-9620-4CBD-AF81-6ADF47D4FDFD"), ProgId("traxSync.Connect")] The GUID was also new as well. I had (when I re-created the project) changed the name in the wizard as well. Due to my lack of knowledge in this area I don't know what the relationship is (if any) between the ProgId value and the name in the wizard. (I must confess I'm actually a Java programmer and I've been dunked in the deep-end with .NET and C#). For the log file, I've done that on my local machine and will get my boss to do the same. Any idea what I should be looking for? There's a lot of information output in the log but it all looks "dutch" to me! Many thanks, Gary P.S. I found that I needed to specify a log file name after the /l*v option otherwise the installer wouldn't work ;) [quoted text, click to view] ""Gary Chang[MSFT]"" wrote:
> Hi Gary, > > >I initially created the addin as a proof-of-principle (as you tend to do > ;). > > The addin had a "temporary" name. > >I then formalised the addin code and had to change the name. However > >changing the name stopped the addin from working on the development/build > >machine. > > I am not very clear about which the "temporary" name you mentioned above, > is it the addin's name in the corresponding registry key or just its progid? > > >I then created a whole new VS project (same language, using the wizard and > >same options) and re-created all the source and data files from scratch (a > >rather painful process). This time I named the addin with the correct > name > >and didn't touch the GUID at all. > > On this point, do you mean you use a brand new name or just the previous > addin's correct name to your new OutLook addin, and how about its GUID, is > it a new one generated by the wizard or you copy it from the previous one? > > >At this point the addin, when installed on > >the development machine, did not run from the install directory, it ran > from > >the build directory (I eventually got around this issue, because I needed > the > >install path to get some properties files, by creating a registry entry > for > >the install path which I read when the addin is started). Also, the addin > >still worked when I sent a copy to my boss. > >... > >Which is why I'm a bit stumped. On my boss's machine the Outlook/Addins > >registry entry is being created correctly but the CLSID entry is not, > trouble > >is I don't know why... > > If you suspect there is some problems during the the installation, I > suggest you use a logfile to monitor the installation process, to record a > logfile during the installation, you can use the msiexec /l*v /qf > "../../yourAddin.msi" to launch your Addin's setup package, please refer to > the following MSDN doc for the usage of the Msiexec.exe: > > The Command-Line Options for the Microsoft Windows Installer Tool > Msiexec.exe > http://support.microsoft.com/default.aspx?scid=kb;en-us;314881 > > > Thanks! > > Best regards, > > Gary Chang > Microsoft Community Support > -------------------- > Get Secure! ¡§C www.microsoft.com/security > Register to Access MSDN Managed Newsgroups! > http://support.microsoft.com/default.aspx?scid=/servicedesks/msdn/nospam.asp > &SD=msdn > > This posting is provided "AS IS" with no warranties, and confers no rights. >
Hi Gary,
Thanks for your coming back to me:) [quoted text, click to view] >The GUID was also new as well. I had (when I re-created the project) >changed the name in the wizard as well. Due to my lack of knowledge >in this area I don't know what the relationship is (if any) between the >ProgId value and the name in the wizard. If you use a brand new GUID and ProgID, the new Outlook Addin will be totally different from the previous one--I mean it is not an upgrade version of the previous one. [quoted text, click to view] >For the log file, I've done that on my local machine and will get my boss >to do the same. Any idea what I should be looking for? There's a lot of >information output in the log but it all looks "dutch" to me! If so, I suggest you upload this log to the newsgroup(zip it and attach the zip package to your newsgroup message), maybe we can help you to investigate it first. By the way, would you please tell me which the Outlook version of your develop machine, is it also an Outlook 2000 just same as your Boss' Outlook? Thanks! Best regards, Gary Chang Microsoft Community Support -------------------- Get Secure! ¡§C www.microsoft.com/security Register to Access MSDN Managed Newsgroups! http://support.microsoft.com/default.aspx?scid=/servicedesks/msdn/nospam.asp &SD=msdn This posting is provided "AS IS" with no warranties, and confers no rights.
Hi Gary,
Thanks for the response, apologies again for the delay... there just never seems to be enough time! [quoted text, click to view] > If you use a brand new GUID and ProgID, the new Outlook Addin will be --> I was kind of hoping that... which is why I created a whole new project. > totally different from the previous one--I mean it is not an upgrade > version of the previous one. I thought it might be that the registry entries were getting "confused"... oh well... [quoted text, click to view] > --> Bugger... I can't find anywhere on the form to attach a file... I'm > If so, I suggest you upload this log to the newsgroup(zip it and attach the > zip package to your newsgroup message), maybe we can help you to > investigate it first. posting through the MSDN managed newsgroup site... Am I missing something? Or is there an ftp area I can upload it to... Should I try and use a newsreader instead? (I'm currently using a browser) [quoted text, click to view] > --> Currently it's Outlook 2000 for the development machine on a W2K Pro OS. > By the way, would you please tell me which the Outlook version of your > develop machine, is it also an Outlook 2000 just same as your Boss' Outlook? My bosses setup is the same as mine, altough I am moving to WinXP Pro and Outlook 2003 I'll be retaining the existing setup for regression testing, especially since the addin will have to be re-worked a little to work on both MSO2003 and 2000... Many thanks, Gary
Hi Gary,
[quoted text, click to view] >--> Bugger... I can't find anywhere on the form to attach a file... I'm >posting through the MSDN managed newsgroup site... Am I missing >something? Or is there an ftp area I can upload it to... Should I try >and use a newsreader instead? (I'm currently using a browser) yes, if use a newsreader(such as Outlook Express), you can attach files to your newsgroup message. Or you may send the zip package of the setup log file directly to my mailbox, please remove the "online" of my email address... Thanks! Best regards, Gary Chang Microsoft Community Support -------------------- Get Secure! ¡§C www.microsoft.com/security Register to Access MSDN Managed Newsgroups! http://support.microsoft.com/default.aspx?scid=/servicedesks/msdn/nospam.asp &SD=msdn This posting is provided "AS IS" with no warranties, and confers no rights.
Hi Gary,
After reviewed the setup log file you sent, I can find the expected registry operations in the log, and also there is no related opearation failed message followed them. So I suspect is this problem caused by the previous version Outlook addin which installed in the problematic machine, in this scenario I suggest you perform a test to install your Outlook Addin on a clean system, and check does it work well. On the other hand, you can try to remove the previous version of the Outlook addin from those machines which have the problem. By the way, how about this Outlook Addin's setup package, have you added some custom actions/modification to its setup project? Thanks! Best regards, Gary Chang Microsoft Community Support -------------------- Get Secure! ¡§C www.microsoft.com/security Register to Access MSDN Managed Newsgroups! http://support.microsoft.com/default.aspx?scid=/servicedesks/msdn/nospam.asp &SD=msdn This posting is provided "AS IS" with no warranties, and confers no rights.
Hi Gary,
Thanks for the response, and sorry for the delay. We've tried installing on a "clean" machine with W2K and Outlook 2000 but still have the same problem, i.e. that the install goes ok (although we noticed that in that instance the install didn't require the installation of the .NET runtime) but the addin won't load in Outlook when it starts. Everytime the addin is installed we have to first uninstall the previous version (which, btw, doesn't remove ALL the registry entries it creates, there still seem to be some remaining for the registered C# classes). There are no custom actions in the setup package (to be honest I don't even know how to do that, yet). And the only modification I have made was to add the suggested registry entry which seemed to be missing. I was wondering, is there a way to start Outlook so that it will "log" what it is doing during startup and perhaps then indicate why the addin hasn't been loaded? If you have any other suggestions (anything at all!) that would be great, my boss is now starting to get really agitated about this... Many thanks, Gary [quoted text, click to view] ""Gary Chang[MSFT]"" wrote:
> Hi Gary, > > After reviewed the setup log file you sent, I can find the expected > registry operations in the log, and also there is no related opearation > failed message followed them. > > So I suspect is this problem caused by the previous version Outlook addin > which installed in the problematic machine, in this scenario I suggest you > perform a test to install your Outlook Addin on a clean system, and check > does it work well. > > On the other hand, you can try to remove the previous version of the > Outlook addin from those machines which have the problem. By the way, how > about this Outlook Addin's setup package, have you added some custom > actions/modification to its setup project? > > > Thanks! > > Best regards, > > Gary Chang > Microsoft Community Support > -------------------- > Get Secure! ¡§C www.microsoft.com/security > Register to Access MSDN Managed Newsgroups! > http://support.microsoft.com/default.aspx?scid=/servicedesks/msdn/nospam.asp > &SD=msdn > > This posting is provided "AS IS" with no warranties, and confers no rights. >
Hi Gary,
[quoted text, click to view] >We've tried installing on a "clean" machine with W2K and Outlook 2000 >but still have the same problem, i.e. that the install goes ok (although we >noticed that in that instance the install didn't require the installation of >the .NET runtime) but the addin won't load in Outlook when it starts. The .NET redistribution merge module(Dotnetfxredist_x86.msm) should be already contained in your Outlook addin's setup project(which generated by the VS.NET 2003 IDE), but it would be marked as "Exclude" by default. So I suggest you can check all the dependency modules(in the Detected Dependencies folder of that setup project) and uncheck the "Exclude" make in these modules' context menu first... Thanks! Best regards, Gary Chang Microsoft Community Support -------------------- Get Secure! ¡§C www.microsoft.com/security Register to Access MSDN Managed Newsgroups! http://support.microsoft.com/default.aspx?scid=/servicedesks/msdn/nospam.asp &SD=msdn This posting is provided "AS IS" with no warranties, and confers no rights.
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
| home · blog · groups | Questions? Comments? Contact the dn |