Introduction
In this Internet world of connected network applications, it is reasonable to expect that your Web applications scale to meet the needs of millions of users who will access your Web site. COM+ is a core element in the Windows DNA 2000 methodology to create scalable, extensible, and maintainable distributed applications. However, in the .NET world, COM+ components are referred to as serviced components. Due to the number of changes in the .NET strategy, the deployment model for serviced components is different from deploying traditional COM+ components. In this article, we will understand how to deploy serviced components using the various tools provided by the .NET Framework. Along the way, we will also highlight how the deployment model varies for different types of serviced components. Finally, we will wrap it up by understanding how the deployment of serviced components can be automated using a Windows installer project.
Component services in Windows 2000 has a wealth of enterprise functionality that provides all the plumbing required for creating distributed, Web-enabled applications. Although COM+ services were originally designed for use with COM components, it would be nice if .NET components could also use them because of services such as object pooling, database connection pooling, sharing resources, role based security, and distributed transaction processing monitoring that the COM+ runtime provides.
In the .NET Framework, there is a separate namespace called System.EnterpriseServices
that contains all the classes required for providing COM+ services to applications. For an introduction to COM+, please take a look at the following link from TechNet: Introduction to COM and COM+.
The Problem
We have a web server that hosts a number of different applications, classic ASP websites, ASP.NET applications, and console applications scheduled in MS-Tasks. All of these applications use our SMTP server to send emails. Our SMTP server requires user authentication. We have a single email account dedicated for our web to be used as a sender email ID from all our applications.
Imagine that your development manager asked you to change that email account password for security reasons and he has a plan for changing it frequently every month. It is really a pain to go through all your .NET application web.config files and change the email setting and all your classic ASP websites also to change the include files.
The Solution
I am sure there are so many solutions now to overcome the problem mentioned above, but here I am just sharing my experience from six years ago, in 2003, when I was working as a developer in a software development company. At that time, I had very good experience working in Classic ASP, but only two years experience working in .NET. And we were using MS VS2003 and coding in VB.NET. I was not very familiar with C# :)
The first thing I thought about was to do a global DLL file which would read a single config file located in our web server; this DLL file could be used in any application, whether it is a classic ASP, .NET, or Java application.
I utilize the COM+ serviced component to develop a class library that has a public function for sending emails. The email setting would be read from an XML config file located in the web server.
Using the Code
Here I am going to explain my solution step-by-step (in VS2005):
Imports System.EnterpriseServices
You have to make your class inherit from the “ServicedComponent
” class:
Public Class btnmail
Inherits EnterpriseServices.ServicedComponent
I then create just a simple function (HelloWorld
) for testing purposes only:
Public Function HellowWorld() As String
ContextUtil.SetComplete()
Return "Hello World"
End Function
This is the email function that is used to send emails:
Public Function SendEmail(ByVal sender, ByVal sname, ByVal recipient, _
ByVal cc, ByVal subject, ByVal body) As Boolean
Dim retVal As Boolean = False
Try
Dim ds As DataSet = New DataSet()
ds.ReadXml("d:\smtpmailsetting\config.xml")
Dim smtpserver As String = ds.Tables(0).Rows(0)("ServerName")
Dim UserName As String = ds.Tables(0).Rows(0)("UserName")
Dim Password As String = ds.Tables(0).Rows(0)("Password")
Dim bcc As String = ds.Tables(0).Rows(0)("BCC")
ds.Dispose()
Dim message As New MailMessage()
message.IsBodyHtml = True
message.From = New MailAddress(sender, sname)
message.To.Add(recipient)
If Not String.IsNullOrEmpty(cc) Then
message.CC.Add(cc)
End If
If Not String.IsNullOrEmpty(bcc) Then
message.Bcc.Add(bcc)
End If
message.Subject = subject
message.Body = body
Dim emailClient As New SmtpClient(smtpserver)
If Not String.IsNullOrEmpty(UserName) And _
Not String.IsNullOrEmpty(Password) Then
Dim SMTPUserInfo As New _
System.Net.NetworkCredential(UserName, Password)
emailClient.UseDefaultCredentials = False
emailClient.Credentials = SMTPUserInfo
End If
emailClient.Send(message)
retVal = True
ContextUtil.SetComplete()
Catch ex As Exception
Dim sw As StreamWriter = _
New StreamWriter("d:\smtpmailsetting\logs\" & _
Now.ToString("ddMMyyyy-hhmmss") & ".log", True)
Try
sw.Write(ex.Message)
Catch ex1 As Exception
Finally
sw.Flush()
sw.Close()
End Try
retVal = False
ContextUtil.SetAbort()
End Try
Return retVal
End Function
Then, we will create a key file using the sn utility. To generate the key file, we will run the Visual Studio .NET command prompt and then enter the command as shown below:
sn -k btnmail.snk
Copy “testkey.snk” to your project solution.
Add “AssemblyInfo.vb” and add the key info:
<Assembly: AssemblyTitle("")>
<Assembly: AssemblyCompany("")>
<Assembly: AssemblyProduct("")>
<Assembly: AssemblyCopyright("")>
<Assembly: AssemblyTrademark("")>
<Assembly: CLSCompliant(True)>
<Assembly: AssemblyKeyFile("..\..\btnmail.snk")>
Now we need to install it in the Global Assembly Cache, “GAC”.
regsvcs (path of the dll)
Create a vbs file to test it. Create “test.vbs” which contains the following code:
set obj = CreateObject("smtpbtnmail.btnmail")
msgbox(obj.HelloWord)
Double click on it to run it.