I want to send a text file as an attachment with email. When I run my code on local development server it runs properly and file gets attached. But when I publish the site on server, it doesn't pick the attachment and the mail is also not sent. Its not an issue of sending mails, because I have checked it by sending mail without attachment and the mail is sent. The problem is only while attaching file. I have written the path for text file attachment as
string filepath=#"E:\Pwavel\Attachfile\" + filename;
Attachment MyAttachment = new Attachment(filepath);
objmsg.Attachments.Add(MyAttachment);
I have also created "Pwavel" and "Attachfile" folders in E: drive of server.
Is there a problem in path? Or any permission issue? I am not able to understand what the problem is. Please Help me...
If your tests are working on your development machine then this does sound very much like a permission issue.
If you have the authority I'd suggest going to your Attachfile folder and adding Read permission for "Everyone", just to test. If this works you can target specific user / permissions depending on what version of IIS you are using by looking at this:
http://www.iis.net/learn/get-started/planning-for-security/understanding-built-in-user-and-group-accounts-in-iis
Hope this helps.
Related
I looked on SO an found several ways to do kind simmilar things, but those aren't the solution.
A user is on the web page and on a click on a file (which is stored in byte[] on server) should open the mail client, where the attachment, subject and mailfrom is set.
Subject and Mail From is no problem, but the attachment. Here are some points I need/need not to:
I cannot/I am not allowed to Create a file such as mymailmessage.eml
on a client (access denied)
I cannot use MailMessage
(System.Net.Mail) because for this I need to create a file to open the mail client with Process.Start(filename)
I cannot use mailto: because there I cannot add an attachment
So the way I am on for now is to use MAPI. Unfortunately I have not found a solution. My source is a byte[] and I can write this in a MemoryStream. Is it possible to create a kind of virtual file path in C#? But I don't know how to open the mail client including the parameters. All the MAPI projects (like https://github.com/PandaWood/Simple-MAPI.NET or https://www.codeproject.com/Articles/10881/MAPIEx-Extended-MAPI-Wrapper are using local files. I tried those, but in my case the mail client isn't starting, so no mail message window is popping up.
So what I am looking for is: Create a MapiMessage with MailFrom, Subject, an attachment and then open the mail client (like with mailto) including the attachment.
An other C# project is this: https://www.codeproject.com/Articles/17561/Programmatically-adding-attachments-to-emails-in-C
According to this codeproject, I cannot find the line, where the programm is saying the mail client please open (like Process.Start()) and open the prepared mail message for me.
Is there any other way except MAPI, when I only have a byte[] in the web application and need to open a mail client message including the attachment not storing/downloading it on the user client?
I am currently having an issue where I am creating a MailMessage with attachments. This works perfectly well on a local server, however once it is moved to a remote server, the application is unable to find the files that were attached. The code I am using is:
foreach (string s in e.attachments)
{
mail.Attachments.Add(new Attachment(s));
}
Where e.attachments is simply a List<string> of paths to files on the client's computer.
The error message I am receiving is:
I'm assuming this is happening because the application is looking at the C: drive of the server it is running on. How would I go about solving this issue?
You first have to upload the attachment to the server.
As you say, the file you are trying to attach is on your local storage and not on your webserver.
This post should help you uploading your attachments:
Cheers, Martin
I have an application in Visual Studio C# which includes saving into a text file, how can I have a .exe sent to another computer and not have an exception in saving?
I need to send a .exe file by email (Yes it's possible) and this application includes saving the state of the game. How can I send this .exe file and let the user be able to save in his computer please?
The problem is that when I send my application's executable file on another computer, I'm getting an exception in saving. Because on the other computer I don't have the text file which I'm saving the game.
I am saving here :
StreamWriter myFile = File.CreateText(Directory.GetCurrentDirectory()+"//ConnectFour.txt");
in the obj/Debug/ of the project..
Thanks for your help :)
Sending an executable should work just fine.
Make sure the other computer has the appropriate Microsoft .NET Framework installed.
Latest framework installer: MSDN
Also, make sure the path inwhich you're saving the file to exists on the remote computer. For example, if you're trying to save to the D:\ drive and it doesn't exist. You will get an exception.
Most likely current location is not writable by current user.
Using "current directory" is dangerous as you have no control over where application is launched from. It is very useful for command line utilities, but not so much for regular windowed applications. Use location that you know you can save files to - i.e. "My Documents".
var filePath = Path.Combine(
Environment.GetFolderPath(Environment.SpecialFolder.MyDocuments) + "\\",
ConnectFour.txt");
using(var myFile = File.CreateText(filePAth))
{
// save data here.
}
The problem when sending executables by email are the anti-virus-scanners. Some of them refuse e-mails containing executables. Others accept the mails but delete the attachment.
The solution consists in hiding the executable. This can be done by zipping the executable and sending the zip-file.
Often this is enough to solve the problem but some anti-virus-scanners are very smart and even recognize executables within the zip-attachment. The solution here is to encrypt the zip-file with a password. I often just use the password "pwd" and mention it in the e-mail text. The anti-viruses are not (yet) smart enough to understand this text.
UPDATE
Now I understand your problem. It has nothing to do with sending the executable.
An application can determine from which directory it has been started like this
string dir = System.IO.Path.GetDirectoryName(
System.Windows.Forms.Application.ExecutablePath
);
An alternative is (if you don't have a reference to WinForms):
string dir = System.IO.Path.GetDirectoryName(
System.Reflection.Assembly.GetEntryAssembly().Location
);
You probably do not have sufficient privileges to save the file on the remote machine. If you give us more information on the exact exception that is being thrown (type of exception, message, stack trace, etc) you will get a more accurate answer.
I am trying to build a winform app to
read mails from google app
save mail and attachment to local folder
mark mail as read
Save the email body and attachments to a SQL-Server database
The latter is ok but I'm really having trouble with the first 3.
I've look everywhere and people are telling me how to send mail on a winform app but not how to read, mark and save content and attachment.
CodeProject is probably the next best resource online after SO (IMHO.) Here are some well-reviewed sample projects that will get you a long way:
http://www.codeproject.com/Articles/14304/POP3-Email-Client-NET-2-0
http://www.codeproject.com/Articles/6062/A-POP3-Client-in-C-NET
http://www.codeproject.com/Articles/188349/Read-Gmail-Inbox-Message-in-ASP-NET
http://www.codeproject.com/Articles/34495/Building-your-own-Mail-Client-using-C
http://www.codeproject.com/Articles/15611/POP3-Email-Client-with-full-MIME-Support-NET-2-0
We're using Exchange 2007 WS to process mail folders and are hitting various problems if we try and forward a message we've already received. Our process is:
Windows Service monitors mailbox folder, on finding a new mail we process the information and move the item to a 'Processed folder' and store the Exchange Message Id.
Users may opt to forward the mail externally. We use the Exchange API to find the item using the Message Id we stored earlier, and then again use the API to forward.
Except finding the mail again is proving rather flaky. We regularly get the following error:
The specified object was not found in the store.
Is there a better/more reliable way we can achieve the same? The documentation for Exchange WS is rather sparse.
This is a bug in microsoft exchange manage API. here is a link for more information
http://maheshde.blogspot.com/2010/09/exchange-web-service-specified-object.html
Are you saving the Message ID of the newly found message or the message once it has been moved to the 'Processed' folder? The id will change when it moves to a new folder.
The method recommended in the book Inside Microsoft Exchange Server 2007 Web Services is to grab the PR_SEARCH_KEY (0x300B, Binary) of the newly discovered item, then move it to the 'Processed' folder. You can then search for it in the new folder based on the PR_SEARCH_KEY and get it's new Message id to forward it.
I have come to the conclusion that this happens to me is because while my app is processing the emails, someone else is fiddling with an email at the same time.
So to cure the problem, I put it the code in a try catch and see if the exception is == the that object not found in store, if so I just skip it and move on to the next item. So for has no issues.
I wrote a program that reads the emails in inbox downloads attachments to the specified folder, wrote the email info and the saved path to the database, and finally deletes the email. I run this program as a windows service. After all tests are finished I run this program to the main server and run it. Program runs successfully but sometimes I got this error. I checked everything and finally I found that I forgot to stop service on my computer. 2 programs that runs on my computer and on real server checking the same mailbox at the same time. If you get this error make sure that only one program can process at the same mailbox.