I've added some functionality to my C# application in VS 2008 that integrates Outlook 2003 via this article:
http://www.keithelder.net/blog/archive/2007/01/11/WinForm-Programming-Send-Email-Using-Outlook-Interop-or-System.Diagnostics.Process.aspx

After I bring this project into my setup project and package it, outlook option fails????

I posted this on the website above in hopes to get a response:

Great article, one question though. This works great when I "run" my application. If I add my Application and those dependecies (Office.dll, and outlook interopt, etc) to a "setup project in vs 2008" when I click the email button on my form I get the dialog asking to install office, then a nasty error about interopt not finding outlook? Yet, Outlook is running, and this app works in vs2008 by running it in that enviroment???

Your original post says that Office starts to repair when you run your app. That's because there's some overlap between your setup and Office.

When I say "something you've installed has broken Office", what I mean is that virtually every single file and registry entry installed by Office is registered (and I don't mean COM) as an installed MSI component. If youdisturb any of these you can trigger an Office repair. Ok, so Word runs, Outlook runs, but nevertheless something that Office installed was changed by what you installed and Office is repairing to restore it. The Event log will have some MsiInstaller entries describing the missing pieces. I assume you don't want this to happen to every client system you install your app on.

When I say you should be using the correct Office PIAs, I mean this type of thing:

http://www.microsoft.com/downloads/details.aspx?familyid=59daebaa-bed4-4282-a28c-b864d8bfa513&displaylang=en

you're not supposed to generate to generate your own Office interop assemblies. That redist contains, for example, the interop assembly Microsoft.Office.Interop.Outlook, and the point of using that is that you don't need to worry about what does or does not need registering. You ship that download exe as a prerequisite for your clients and ask them to install it.You use references to those assemblies to build your apps.

If all you want to do is send email from your app without all this pain, that Simple Talk article explains how to do it. You don't need interop assemblies anywhere and it works on all Office versions I've tried it with.

---

Phil Wilson

Something you've installed has broken Office, so it's repairing. Without knowing exactly what you're installing (are you using the official interop assemblies, the Office PIAs?) it's gard to say what.

Read the last couple of paragraphs here:
http://www.simple-talk.com/dotnet/visual-studio/build-and-deploy-a-.net-com-assembly/

The late binding office interface means you don't need to use interop assemblies at all to send email.

---

Phil Wilson

I don't think I've hurt my office installation since I can run Word, Outlook, etc from desktop shortcuts, etc without getting the dialog for installation, etc. The app work fine. I read posting in the link you provided and I'm asking two questions for your reply:

1.) Does this mean I need to set register in COM these assemblies; The two office dependencies are Microsoft.Office.Interop.Outlook.dll, and office.dll. Also, I currently leave these in the application directory on the target machine, should I place in system32?
2.) What does you mean I do not need Interop for mailing? Every article I've read shows it performed this way (per the link I provided above). Is there a better way? Please let me know, I thought there should be. This is a Windows Application, not web so this should be easier with using Outlook.

My Windows App project runs fine though, Outlook mailing works great. So it must be the packaging in the setup project.

Thanx for your help.

An interesting fact: If I just "Publish" my applicationfrom withinVS 2008 and install it it works great, including the Outlook piece. I believe the publish feature puts the application in the users documents and settings area (which is one of the reasons I wanted to use setup project to install in program files, etc).

So this means that my set-up project is the issue. But what do I need to do differently to either have permissions or whatever is needed to run my Outlook piece of functionality? Is this a rights issue? Do myoffice DLL's need to be in system32? Do I need to register them?
Help?

Your original post says that Office starts to repair when you run your app. That's because there's some overlap between your setup and Office.

When I say "something you've installed has broken Office", what I mean is that virtually every single file and registry entry installed by Office is registered (and I don't mean COM) as an installed MSI component. If youdisturb any of these you can trigger an Office repair. Ok, so Word runs, Outlook runs, but nevertheless something that Office installed was changed by what you installed and Office is repairing to restore it. The Event log will have some MsiInstaller entries describing the missing pieces. I assume you don't want this to happen to every client system you install your app on.

When I say you should be using the correct Office PIAs, I mean this type of thing:

http://www.microsoft.com/downloads/details.aspx?familyid=59daebaa-bed4-4282-a28c-b864d8bfa513&displaylang=en

you're not supposed to generate to generate your own Office interop assemblies. That redist contains, for example, the interop assembly Microsoft.Office.Interop.Outlook, and the point of using that is that you don't need to worry about what does or does not need registering. You ship that download exe as a prerequisite for your clients and ask them to install it.You use references to those assemblies to build your apps.

If all you want to do is send email from your app without all this pain, that Simple Talk article explains how to do it. You don't need interop assemblies anywhere and it works on all Office versions I've tried it with.

---

Phil Wilson