Please note, these character sets must be installed on the system using aspNetEmail, or an exception will be thrown. For a larger subset of character sets, click here.

When emailing HTML web pages, if the web page has the <META   CHARSET="some charset" > tag present, the EmailMessage.CharSet property should match the same value as found in the MEATA tag.

EmailMessage msg = new EmailMessage();
msg.AddAttachment( Server.MapPath("invoice.pdf") );

If you are emailing from a Windows Form, your code may look like:
EmailMessage msg = new EmailMessage();
msg.AddAttachment( “invoice.pdf") );

EmailMessage msg = new EmailMessage();
msg.FromAddress = "list@myCompany.com";
msg.ReplyTo = "marketing@myCompany.com";

EmailMessage msg = new EmailMessage();
msg.ConfirmRead = true;

Solution 1: If you are using VS.NET with the codebehind model, you will need to Import the aspNetEmail.dll into your project. Then you will need to set a reference to the aspNetEmail.dll. VS.NET will then properly move the aspNetEmail.dll to the /bin directory.

Solution 2: If you’ve already set a reference to the aspNetEmail.dll, you will need to add the Imports statement (for VB.NET) or the using statement (for C#), at the top of your page.

Add the following code to the top of your page
[VB.NET]
Imports aspNetEmail

[C#]
using aspNetEmail;

Solution 3: If you are using inline script on your .aspx page, simply add the aspNetEmail.dll to your /bin directory, and the ASP.NET process will locate the aspNetEmail.dll.

Solution 4: If you’ve already added the aspNetEmail.dll to the /bin directory, you will need to add the following Import directive to the top of the page.
<%@ Import Namespace="aspNetEmail.dll" %>

Solution 5: Some customers are in a hosted environment, and do not have access to the aspNetEmail.dll, or would rather reference the aspNetEmail.dll that is installed in the GAC (Global Assembly Cache). To do this, you will need to add an <assembly> tag to the web.config file.

Locate the <system.web> tag, and add the following entry:(here is a complete example).

<configuration>
   <system.web>
      <compilation>
         <assemblies>
            <add assembly="aspNetEmail, Version=2.0.0.1, Culture=neutral, PublicKeyToken=bc571e8da1c1f543"/>
         </assemblies>
      </compilation>
   </system.web>
</configuration>

<add assembly="aspNetEmail,
    Version=...
    Culture=...
/>

Basically, here is what is happening. VS.NET sometimes places a shadow copy of aspNetEmail to the /bin directories, so even if you uninstall aspNetEmail, a copy of the dll can still be in the /bin directory. We've also had customers report that IIS seems to keep a copy of the dlls in memory, and once they've removed the eval version, and restarted iis, and installed the production version, the new dll was properly referenced.

Here's a complete checklist for verifying aspNetemail is removed.

1. If you are using VS.NET, remove any references to aspNetEmail.
2. Try to compile your project, IT SHOULD FAIL. This guarantees it isn't referencing aspNetEmail.
3. Be sure "Show All Files" is enabled in VS.NET. Check the /bin directory for any shadow copies of aspNetEmail.
4. If you are using aspNetEmail in IIS, and If possible, shut down IIS (IIS sometimes keeps a copy of the dlls it references in memory, even after they are uninstalled).
5. Close down VS.NET.
6. Uninstall aspNetEmail.
7. Check the install directory to verify it has been removed (usually found at C:\Program Files\AdvancedIntellect\aspNetEmail\ ).
8. If possible, reboot machine (not usually required, but better safe than sorry).
9. Verify the GAC does not have a copy of aspNetEmail (usually found at c:\winnt\assembly) If a program is referencing the GAC installed copy it will not be removed until reboot (see previous step). It is recommended you do this from a command prompt, because windows explorer does not always show all copies of GAC installed .dlls.
10. If the dll(s) are still there, you may need to remove the dll with the command line tool gacutil.
     
    From a command prompt, execute:
          c:\>gacutil –u aspNetEmail
    
    If you get an error message, you may want to try
          c:\>gacutil –uf aspNetEmail
    
    which forces the uninstall.
    More information on gacutil, can be found on MSDN:GacUtil here.
    If you see an error messages similar to
         Assembly: aspNetEmail , Version=2.5.0.0, Culture=neutral, PublicKeyToken=bc571e8da1c1f543, Custom=null
         Unable to uninstall: assembly is required by one or more applications
         Pending references:
              SCHEME: ID: DESCRIPTION :
         Number of items uninstalled = 0
         Number of failures = 0
    
    Then, for some unknown reason, according to Microsoft, your registry has been corrupted by the MSI installer process. You will need to manually remove the references to the installer, from inside the registry. BE SURE TO BACK UP YOUR REGISTRY BEFORE MODIFYING IT.
    
    Using regedit, navigate to the following registry keys, search for aspNetEmail, and delete them.
         [HKCU\Software\Microsoft\Installer\Assemblies\Global]
         [HKLM\SOFTWARE\Classes\Installer\Assemblies\Global]
    
    A complete article on this topic can be found by one of Microsoft’s team members, Alan Shi, over here.
    If that link is down, we have a local, cached copy, here.
    
    
11. If that still doesn’t work, and the assembly is still in the GAC, we still have another option. You can forcibly delete the assembly, from a command prompt.
    From a command prompt, navigate to the Assembly directory (typically C:\winnt\assembly\gac), and execute the following command
         rd /s aspNetEmail
    
         For example C:\winnt\assembly\gac>rd /s aspNetEmail
    
    This should remove the aspNetEmail directory, and everything below.
    
12. Install the production version of aspNetEmail.
13. Verify all VS.NET references to aspNetEmail are not broken.
14. Recompile your application.
15. This should fix it. If it doesn't, feel free to contact us using one of the following options at here.

We recognize this is a problem for both you and us. Therefore, in the near future we will be switching to external xml licensing files. Currently, evaluation versions of aspNetEmail have the expiration date hard coded, internally, to expire. With the new xml licenses, the evaluation version, will be the same assembly used in production, the only difference, will be the license file. The evaluation license file, will have the expiration date coded into it, while the purchased license file, will not expire. We expect this to go live with version 3.0 of aspNetEmail. If you have any feedback, please let us know.