locked
SMTP works in solution, but fails as imported class RRS feed

  • Question

  • User-1643276126 posted

    Enviro: 2007 Exchange Server, 2 Intranet servers (1 deploy, 1 dev) running .NET 2.0 app - all within same network / behind firewall. I am working on a legacy app by our previous web guy, when our sysadmin upgraded to exchange 2007 and put it on a new server all of the mail functions in old app broke. Had to upgrade to .NET 2.0 (from 1.x) and nothing worked untill I tried new SMTP code in a local function in the codebehind of a page of the app instead of calling a class, as follows:

    Function SendNow(ByVal strFrom As String, ByVal strTo As String, ByVal strSubject As String, ByVal strBody As String) As Object
    
     Dim msg As New MailMessage()
    
     Dim smtp As SmtpClient
    
     msg.From = New MailAddress(strFrom)
    
     msg.To.Add(strTo)
    
     msg.Subject = strSubject
    
     msg.Body = strBody
    
     smtp = New SmtpClient("OurMailServer")
    
     smtp.UseDefaultCredentials = True
    
     smtp.Send(msg)
    
     Return True
    
    End Function


    So the above works fine, in that file. The problem is that the app was designed to call a class that resides on the dev server. When I move this same code into the class on the dev server I get transport errors. I think this has to do with the fact that we're using integrated authentication with impersonation=true and it seems to get dropped due to the class being on a different server (even though it's behind our firewall).

    I could either try moving the classes to the production server or somehow keep the authentication in the class working through the hops. Either way I need to keep the class because it's referenced all over the place (in more than just this app). I am not that savvy in .NET and I cannot figure out where the setting is within the app that defines where the class is imported from. It just seems to be available no matter where the app is deployed. (Working files are on same server as classes, then publish the app to production server).

    Can someone give me a clue?


    Friday, November 13, 2009 7:38 PM

All replies

  • User-1643276126 posted

    bump, anyone?

    Monday, November 16, 2009 1:38 PM
  • User-952121411 posted

    You may want to begin by looking into the following link that has the details on several methods to consume a shared .dll on a remote server:

    How to consume assemblies that are located in a folder that is different from the application base folder in Visual Basic .NET:

    http://support.microsoft.com/kb/897297/

    Now I am not sure which of the methods you are using, but once you have narrowed it down you can look into how security works specific to that method.  You may need to increase the .NET Trust level of the assembly or something along those lines.

    HOW TO: Change the Trust Level for a .NET Framework Assembly:

    http://support.microsoft.com/kb/815147

    Honestly though, every time I start dealing with shared functionality in the manner you speak of there are much better avenues to handle exposing it.  The 1st (2) that come to mind are either a WCF or .asmx web service.  Both are easily consumable by the client and security is handled in a much more organized fashion than consuming some .dll across the network in the GAC or something on a remote server.

    Now I realize you may not have the time or ability to port your code over now, but you could easily expose sending emails (a common functionality) via a WCF service.  This is something you may want to consider in the future.

    I think the fastest and easiest solution at this point for you to implement is wrapping that .NET code in Impersonation.  With Impersonation, you can create a token of a Windows User passing in the credentials and running the code under that account.  In your case you could impersonate an administrator or whatever level account you need to send the email.  You could have the client pass the credentials in or possibly store them encrypted locally to the .dll and decrypt them at runtime.  Regardless, Impersonation could probably solve any security issues is this manner.

    Take a look to the following article that has a detailed explanation and code example for using Impersonation:

    WindowsImpersonationContext Class:

    http://msdn.microsoft.com/en-us/library/system.security.principal.windowsimpersonationcontext.aspx

    Hope this helps! Smile

    Wednesday, December 2, 2009 9:36 AM