It's my first question/post :-/
Background to question:-
I have an ongoing project which is an Azure hosted ASP.NET solution. Its a generic ERP and is intended for small enterprise businesses. An additional requirement came up and I'd like it to be part of the Azure solution (previous attempt to create a VSTO add-in went bad).
I've been asked to automate this process:- Users spend a long time (daily basis) manually saving emails into network shared directories according to what company project the emails relate to. E.g. everytime Sally sends or receives an email, she copies and renames the .msg file from outlook into her "G:/" drive (which is just a network share on the enterprise LAN). Someone else in the enterprise has the job of creating a specific directory structure for sally (and her co-workers) to save the emails in (e.g. Correspondance-In, Correspondance-Out etc..). Staff need to be able to search the directories for messages based on some scraped meta data.
I'm considering an exchange web service managed API application in Azure which has a service that polls the Exchange Server (for every user) with a pull subscription to identify new/changed mails. Each identified mail will be then assessed against a rule that the user has pre registered in my application (i.e. from person x with project ID in the subject field). The application will then rename the email and put it in the network share (also scrape metadata to provide search functionality).
Question:-
a) How do I get my remote application to request the Exchange Server or CAS to export the MailItem to a local network share using exchange web services in the most efficient way? Preferably without having to deploy something into the enterprise.
b) is this a ridiculous solution?
Additional Info:
I expect the typical environment to be quite old. However, I can assume Exchange Server 2007+ and Outlook Clients 2007+ on Win7 (no Office365 though and no sharepoint). I decided to use a pull subscription as it will be a loosely coupled environment and therefore assumed streaming to be not the best fit.
MailItems are likely to contain large attachments (CAD drawings etc) so for obvious reasons, I would like to avoid pulling these across the WAN.
I have investigated the potential to create server side mailbox rules with EWS therefore allowing this exchange server to manage the export - however if I understand correctly, rules don't support exporting MailItems to the filesystem.
I want to collect weekly feedback from my peers about their workload (numbers 0-9 for every workday). At the moment, they just send me a blank email with the subject line "5,8,6,2,9" and I have to put this information manually into a spreadsheet. This is too much work so I would like to automate the process.
Outlook in combination with Access has the nice feature to create emails and process the responses automatically: http://office.microsoft.com/en-us/access-help/collect-data-by-using-e-mail-messages-HA010015427.aspx
Unfortunately, this does not seem to support "who" (put the sender of the response into the database) sent the email.
This is why I was thinking about creating a small add-in to read the subject of incomming emails and extract the "3,9,..." automatically and put it to a Access database.
Only question if this is the right approach for this task or if I am overdoing it.
Please note: External Websites (like surveymonkey are not an option).
In my opinion it's one of the right approachs. It's very easy to write an Outlook Add-In which iterates through all mails with a specific subject and saves Sender and Mail-Body to a file.
I write system, that collects informations about local system. It's a system like admin-client. Client collects and sends log to admin. There's of course possibility to get this log by admin over LAN, but I'd like to add option send log over Internet.
I thought about skype. Client must have logged skype and when admin (of course there must be appropriate authorization, but it's separate topic) send request by skype - client must e.g. connect to SQL database or simple file with collected log and send it over skype.
How can I do this?
Is this the best way? Plugin in skype? What lib may I use?
I think it's an either/or situation.
If you want an administrator who is already using Skype to be able to send this information over the internet, then a plugin which exposes that functionality in Skype is the way to go.
If you want the administrator to be able to send the information over Skype's network, but not necessarily have to have the application running (perhaps this will be done through the application that gathers data), then using the API to control Skype externally is better.
You can find the documentation for Skype here:
http://developer.skype.com/accessories
Skype has a COM API called Skype4COM which you could use through COM interop in order to access Skype.
It should be noted that SkypeKit is now available for use in both embedded and desktop programs. There's a small one-time registration fee (currently $5 USD) for each program, but it will allow you to access Skype without actually using any UI functionality (it's completely up to you to provide the interface).
Until SkypeKit is released, you're limited to the Skype Public API. However according to the docs this API only allows to specify the recipient and open the file dialog, initiating a file transfer automatically seems to be impossible (see "OPEN FILETRANSFER" in the docs).
I suggest you use an open protocol like HTTP or FTP instead.
is it possible to integrate outlook with my c# program without having Microsoft office installed?
It depends on what functionality you are trying to achieve?
It also depends on your environment.Do you have access to exchange server?
For example, If you want to create appointments in outlook client for individual user, you can very well make use of webservice provided by Exchange server. However, it works starting with outlook 2007.
In a word, no. If you want to call an Outlook dll you will need Outlook installed.
Perhaps if you describe what you need to do there may be an alternative approach, such as calling Exchange Server as suggested by Edwin.
I’m using .NET 3.5, and I want to automatically send a mail. I’m currently using the following:
Microsoft.Office.Interop.Outlook.MailItem mailMsg =
(Microsoft.Office.Interop.Outlook.MailItem)outlookApplication.CreateItem(
Microsoft.Office.Interop.Outlook.OlItemType.olMailItem);
mailMsg.To = recipient;
mailMsg.Subject = subject;
mailMsg.Body = body;
mailMsg.Send();
However, I’ve found several articles that seem to imply I should be using the following method:
System.Net.Mail.MailMessage mailMsg = new System.Net.Mail.MailMessage();
mailmsg.To = recipient;
mailmsg.Subject = subject;
mailmsg.Body = body;
Can anyone tell me what the difference between the two namespaces if, and why you might want to use one over the other?
The first one, I assume, required Outlook to be installed in the machine so that the Office Interop assemblies are installed. The second one is pure .Net framework.
The second example needs a SMTP server, to make a direct connection, and uses this SMTP server to send the email. It has low overhead, will normally work.
If you need to compose & send an email on behalve of the current user, you could use outlook.
So far I have only seen answers with disadvantages for outlook. But it has a few advantages:
You do not have to ask the user for any configuration.
Outlook already knows the Exchange / SMTP server,
and the email address of the user
Email you send will be stored in the sent-items list of the user. So the user can see wat is sent in his name.
Add-ons that sign / encrypt outgoing email, or add a standard company disclaimer will be used, so you will follow company policies
Can prompt the user if it is allowed to send email (yes, this can be an advantage to)
You can choose to only compose the mail, present it to the user. The user can edit and choose to send it or not.
Edit:
I use the SMTP method for sending technical emails (like log files & error messages) to our support unit, these mails go out fast and unnoticed.
The Outlook method I use for sending mails on behalve of my user to other humans. These mails are slow, but are trackable, etc.
The first method is using interop by creating an instance of Outlook (outlookApplication) and having that instance of Outlook send the e-mail.
The second is used for sending e-mail over regular old SMTP and doesn't require outlook at all.
Unless you have specific needs for interop there's no need to send an e-mail using outlook (and your code won't work on any machine that doesn't have outlook installed).
First one uses COM interop, which is unneeded overhead. Second is pure .net with all it's features. Plus it is more flexible.
As other have mentioned, the first one uses outlook to send email. The disadvantage is that the user has to have outlook installed; the advantage is that it will look like outlook is sending it.
The second method will try to send mail directly. The advantage is that it doesn't require outlook to be installed, and is a lot less overhead. The disadvantage with this option is that most enterprises these days block port 25, so when you try to send the message, it will fail.
They are different.
MailItem represents message item in Outlook.
MailMessage represents an e-mail message that can be sent using the SmtpClient class.
Check MailItem and MailMessage.
First one is using COM Interop and uses Outlook as its base. It needs outlook configured. The second is using SMTP Client. The interop could run you into issues related to outlook, but will allow for some cool features like Opening a Mail Window (but its generally not worth it). The second one will send silent mail, though you can show some window of your own, but still it wont allow flexibility of Outlook Automation. My choice is System.Net.Mail.*.
The first one is using MS Office which you don't want to publish while System.Net.Mail is available when .Net framework is installed.
The first example uses libraries installed by the Office Interop Assemblies download.
The second example uses libraries installed by default with the .NET framework, System.Net.
The first example uses Microsoft Interop Libraries. I would go with your second example, since it's part of the default .NET install. The Interop libraries will have more overhead that isn't required as well.
The Microsoft.Office uses Microsoft Outlook to send the email. It requires Outlook to be installed, and is (at least the last time I tried sending mail this way) more prone to difficulties. (For example, it prompts the user to let them know that a program is attempting to send mail on their behalf, etc.)
The System.Net.Mail just uses pure .NET, and the specified SMTP server to send mail.
Trust me.. Avoid using the Office unless there's a need.
You need to use the second option any day. It's pure .NET.
If you use first option, i guess Outlook should have been installed in that machine. When you deploy, you will have problems if you don't have MS Office installed in the server.