Build a C# DNS MX (Mail Exchange) Record Query Class by Peter A. Bromberg, Ph.D.

The .NET Framework provides wrappers to native APIs for a very large number of classes and functions, including the System.Net.Dns classes. However, it doesn't cover all of them. One useful API is the set of DNS query methods in the Dnsapi.dll library, and a particularly useful technique of note is the ability to query a domain and get back the list of MX (Mail Exchange) records of the mail servers associated with the domain. Once you have the code completed to handle this, you will be able to validate an email address against its domain for the mail exchange ("MX") type entries. If there aren't any, then you have a pretty good idea that the email address you are dealing with is BOGUS. Obviously, this can be helpful in tasks such as verifying user registrations on your web site and to fight SPAM. The implementation I provide here is a simplified and very "narrow" one that is intended solely to deal with the MX record lookup. If you want a more complete implementation, there are a number of examples in the Net-o-sphere. One interesting one can be found here. For starters, it might be wise to visit the Platform SDK section on DNS to familiarize ourselves with what we need to create a managed C# PInvoke call to the underlying method. As can be seen, there are three DnsQuery calls, with DnsQuery_W (Unicode) being the most commonly used. There is an fOptions parameter where the types of queries can be combined, the wType type of record parameter, and a ppQueryResultsSet [in, out] pointer parameter. Finally, we are told that we need to free the returned RR Sets with the DnsRecordListFree API call. Note that in the sample code implementation below, VBByRefStr is used for the marshaling directive. The argument is treated as "byref" on the managed side, but stays "byval" on the unmanaged side.  If the unmanaged side writes into the buffer, it won't mangle the managed string, which remains immutable.  Instead, a different string is propagated to the managed side, preserving managed string immutability. In VB.Net, you could code as if the VBByRefStr is actually byval on the managed side, and the compiler will clean up after you, but in C# you must explicitly add the "ref" keyword in the right places: namespace PAB.DnsUtils{ using System; using System.Collections; using System.ComponentModel; using System.Runtime.InteropServices; public class DnsMx { public DnsMx() { } [DllImport("dnsapi", EntryPoint="DnsQuery_W", CharSet=CharSet.Unicode, SetLastError=true, ExactSpelling=true)] private static extern int DnsQuery([MarshalAs(UnmanagedType.VBByRefStr)]ref string pszName, QueryTypes wType, QueryOptions options, int aipServers, ref IntPtr ppQueryResults, int pReserved); [DllImport("dnsapi", CharSet=CharSet.Auto, SetLastError=true)] private static extern void DnsRecordListFree(IntPtr pRecordList, int FreeType); public static string[] GetMXRecords(string domain) { IntPtr ptr1=IntPtr.Zero ; IntPtr ptr2=IntPtr.Zero ; MXRecord recMx; if (Environment.OSVersion.Platform != PlatformID.Win32NT) { throw new NotSupportedException(); } ArrayList list1 = new ArrayList(); int num1 = DnsMx.DnsQuery(ref domain, QueryTypes.DNS_TYPE_MX, QueryOptions.DNS_QUERY_BYPASS_CACHE, 0, ref ptr1, 0); if (num1 != 0) { throw new Win32Exception(num1); } for (ptr2 = ptr1; !ptr2.Equals(IntPtr.Zero); ptr2 = recMx.pNext) { recMx = ( MXRecord) Marshal.PtrToStructure(ptr2, typeof(MXRecord)); if (recMx.wType == 15) { string text1 = Marshal.PtrToStringAuto(recMx.pNameExchange); list1.Add(text1); } } DnsMx.DnsRecordListFree(ptr2, 0); return (string[]) list1.ToArray(typeof(string)); } private enum QueryOptions { DNS_QUERY_ACCEPT_TRUNCATED_RESPONSE = 1, DNS_QUERY_BYPASS_CACHE = 8, DNS_QUERY_DONT_RESET_TTL_VALUES = 0x100000, DNS_QUERY_NO_HOSTS_FILE = 0x40, DNS_QUERY_NO_LOCAL_NAME = 0x20, DNS_QUERY_NO_NETBT = 0x80, DNS_QUERY_NO_RECURSION = 4, DNS_QUERY_NO_WIRE_QUERY = 0x10, DNS_QUERY_RESERVED = -16777216, DNS_QUERY_RETURN_MESSAGE = 0x200, DNS_QUERY_STANDARD = 0, DNS_QUERY_TREAT_AS_FQDN = 0x1000, DNS_QUERY_USE_TCP_ONLY = 2, DNS_QUERY_WIRE_ONLY = 0x100 } private enum QueryTypes { DNS_TYPE_MX = 15 } [StructLayout(LayoutKind.Sequential)] private struct MXRecord { public IntPtr pNext; public string pName; public short wType; public short wDataLength; public int flags; public int dwTtl; public int dwReserved; public IntPtr pNameExchange; public short wPreference; public short Pad; } }} The downloadable sample solution includes a simple Console Tester app that makes the following call: static void Main(string[] args) { string[] s= PAB.DnsUtils.DnsMx.GetMXRecords("microsoft.com"); foreach (string st in s) Console.WriteLine("Server: {0}",st); Console.ReadLine(); which will return the following output: Remember, hamburger@hamburgerhal.com is a valid email address. But, that doesn't mean that you can actually send mail to it. This handy class, along with some good REGEX match strings, should be sufficient to validate most any email address that can be thrown at you. The downloadable solution has more user-friendly exception handling built in.   Download the Visual Studio.NET Solution that accompanies this article

출처 : http://www.eggheadcafe.com/articles/20050129.asp

Table of Contents

1. Introduction.......................................................................................................................................... 1

2. Style Guidelines.................................................................................................................................... 2

2.1 Tabs & Indenting................................................................................................................................ 2

2.2 Bracing............................................................................................................................................... 2

2.3 Commenting........................................................................................................................................ 2

2.3.1 Documentation Comments............................................................................................................. 2

2.3.2 Comment Style............................................................................................................................. 3

2.4 Spacing............................................................................................................................................... 3

2.5 Naming............................................................................................................................................... 4

2.6 Naming Conventions............................................................................................................................ 4

2.6.1 Interop Classes............................................................................................................................. 4

2.7 File Organization................................................................................................................................. 5

Introduction

Most of us will have experienced the dread of updating documentation at some point or other. C# and Visual Studio .NET (VS.NET) give us the ability to maintain code and documentation in the same file, which makes the whole process a lot easier. VS.NET does this by taking specially marked and structured comments from within the code and building them into an XML file. This XML file can then be used to generate human-readable documentation in a variety of forms including web pages, MSDN style documentation and Intellisense within the code window.

Configure XML Commenting

VS.NET produces XML comments by taking specially marked and structured comments from within the code and building them into an XML file. This XML file can then be used to generate human-readable documentation in a variety of forms including web pages, MSDN style documentation and Intellisense within the code window. The first thing you need to do is enable the XML commenting feature for your VS.NET project.

1. Right Click on the project in the solution explorer and select "Properties".
2. Within the properties dialog double click on the “Configuration Properties” node.
3. The Build node should be already selected and you should be able to see the “XML Documentation File” entry under “Outputs”. Here is where you must enter the name of the XML file that will contain the comment data. You can call the file what you like, but for compatibility with all the features of XML commenting, it should take the form of MyAssemblyName.Xml e.g. Adjuster.BusinessServices.dll has a related XML file called Adjuster.BusinessServices.Xml

With this enabled, your XML comment data file will be rebuilt each time you build your project. Any problems that occur when trying to generate the file will not prevent a build but will be flagged in the VS.NET Task List. Assuming you do not have compile warnings set to errors.

VS.NET Task List flagging XML commenting error.

With that enabled you can start to use the special XML tags in your procedure “headers”. To get you started, place the cursor on the line directly above a procedure’s definition. Once there, press the “/” key three times, this will automatically insert a summary tag into your code. If the procedure had any arguments there should now be a param tag for each one.

/// <summary> ///  /// </summary> /// <param name="data"></param> public void SaveData(ref DataSet data) { } 

The SaveData code above is what is inserted as default

/// <summary> /// Connects to the database and attempts to apply  /// all adds, updates and deletes /// </summary> /// <param name="data">a dataset, passed by reference,  /// that contains all the  /// data for updating>/param> public void SaveData(ref DataSet data) { } 

This SaveData code is after I have added my comments describing what the routine does in the summary tag and what the data parameter is. This very simple action has given us enough to provide basic documentation including intellisense just like that provided by the .NET Framework assemblies.

It is clear from just this feature, how useful XML commenting is. When you include a reference to a .NET project that has XML commenting enabled, the XML documentation file we named earlier is copied over along with the binary to the current project’s \bin directory. This gives you the intellisense across assemblies.

The summary tag is the most basic of tags. The list below is the complete set currently supported by VS.NET. The ones marked with a * are the ones I feel are the most useful and the ones we will be dealing in the following examples.

• c
  The c tag gives you a way to indicate that text within a description should be marked as code. Use code to indicate multiple lines as code.

• code*
  The code tag gives you a way to indicate multiple lines as code. Use <c> to indicate that text within a description should be marked as code.

• example*
  The example tag lets you specify an example of how to use a method or other library member. Commonly, this would involve use of the code tag.

• exception*
  The exception tag lets you specify which exceptions a class can throw.

• include
  The include tag lets you refer to comments in another file that describe the types and members in your source code. This is an alternative to placing documentation comments directly in your source code file.

• para
  The para tag is for use inside a tag, such as <remarks> or <returns>, and lets you add structure to the text.

• param*
  The param tag should be used in the comment for a method declaration to describe one of the parameters for the method.

• paramref
  The paramref tag gives you a way to indicate that a word is a parameter. The XML file can be processed to format this parameter in some distinct way.

• permission*
  The permission tag lets you document the access of a member. The System.Security.PermissionSet lets you specify access to a member.

• remarks*
  The remarks tag is where you can specify overview information about a class or other type. <summary> is where you can describe the members of the type.

• returns
  The returns tag should be used in the comment for a method declaration to describe the return value.

• see
  The see tag lets you specify a link from within text. Use <seealso> to indicate text that you might want to appear in a See Also section.

• seealso*
  The seealso tag lets you specify the text that you might want to appear in a See Also section. Use <see> to specify a link from within text.

• summary*
  The summary tag should be used to describe a member for a type. Use <remarks> to supply information about the type itself.

• value*
  The value tag lets you describe a property. Note that when you add a property via code wizard in the Visual Studio .NET development environment, it will add a <summary> tag for the new property. You should then manually add a <value> tag to describe the value that the property represents.

MSDN Style Documentation and NDOC

We have taken the intellisense format as far as it will go, but there is much more we can do with MSDN style documentation. There is a tool that comes with VS.NET that you will find at “Tools|Build Comment Web Pages…” which will take your C# XML comments from source files and generate linked HTML files. This comes straight out of the box so should not be totally disregarded. But if you want to create easy-to-use, helpful, cross-referenced and attractive documentation, then I can strongly recommend the free, open source tool NDoc. The screenshot below is taken from a compiled help file produced from NDoc and is an example of the quality it can produce.

The two routines below will show the correct usage for most of the XML comment tags we saw earlier. The cref attribute of the exception tag is used for cross-referencing to an Exception type. This attribute is also used in the seealso, permission and see tags to reference a type. The type must be available from the current compilation environment. The compiler checks that the referenced type exists and passes relevant data to the output XML.

/// <summary> /// Gets or sets the age of the person involved in the accident /// </summary> /// <value>Age of the claimant.</value> /// <remarks> The value must be numeric. /// </remarks> /// <exception cref="System.ApplicationException">Thrown when a non- /// numeric value is assigned.</exception> public string Age { } 

This Age property once processed by NDoc will produce this.

I have drawn attention to areas in the picture and their corresponding XML comment tags.

/// <summary> /// Connects to the database and attempts to apply all adds,  /// updates and deletes /// </summary> /// <seealso cref="Adjuster.BusinessServices.Accident"/>  /// <param name="data">a dataset, passed by reference,  /// that contains all the  /// data for updating</param> /// <example> This sample shows how to call the SaveData  /// method from a wireless device. /// <code> ///  ///AccidentCRUD accCRUD = new Adjuster.BusinessServices.AccidentCRUD(); ///accCRUD.SaveData(ref ds); /// ///</code> ///</example> ///<permission cref="System.Security.PermissionSet">Everyone  ///can access this method.</Permission> public void SaveData(ref DataSet data) { } 

This SaveData method once processed by NDoc will produce this

Again I have drawn attention to areas in the picture and their corresponding XML comment tags. The Accident cross-reference in the “See Also” section is the only one that I added. By default NDoc adds cross-referencing for the parent class, the parent class’ members and the parent class’ namespace.

With the combination of NDoc and VS.Net & C#’s ability to produce these comments you can get great technical documentation at a level so close to the code, that there is absolutely no excuse for it not telling it as it is.

About Patrick Long

I have been programming now for 10 years starting with COBOL, CICS and DB2 and ending up with ASP.NET and C#. I am currently working for Charteris in London. We have a strong partnership with Microsoft UK and I my current project involves working as part of a Microsoft team. When I am not working i like playing tournament paintball. Click here to view Patrick Long's online profile.

출처 : http://www.codeproject.com/csharp/csharpcommentinganddocs.asp

Introduction

The Windows API provides a function RegNotifyChangeKeyValue, which notifies the caller about changes to attributes or the content of a specified registry key.

Unfortunately, this function is not provided by Microsoft.Win32.RegistryKey class. Because I needed that functionality, I've written a simple wrapper class.

Usage

The usage of this is straight forward. First you have to instantiate a RegistryMonitor object. You set its RegistryKey property and subscribe to the monitor's RegChanged event. Now you may start the monitoring by calling Start(). This creates an internal thread running in an endless loop. In this loop, the thread waits for both an event fired by RegNotifyChangeKeyValue and the terminate event, which is set by the Stop() method. Whenever the registry key changes, the RegChanged event is fired.

Example

Here's a console sample monitoring HKCU\Environment (that's where the current user's environment variables are stored):

public class MonitorSample{    static void Main()     {        RegistryMonitor monitor = new RegistryMonitor();        monitor.RegistryKey = Registry.CurrentUser.OpenSubKey(@"Environment",                                                              false);        monitor.RegChanged += new EventHandler(OnRegChanged);        monitor.Start();         while(true);    }             private void OnRegChanged(object sender, EventArgs e)    {        Console.WriteLine("registry key has changed");    }}

Provided with this article is another demo, which is a WinForm application (however, a VS.NET 2003 solution).

Points of interest

The implementation is pretty straightforward. One interesting point is the access to the registry handle. The RegNotifyChangeKeyValue expects a registry handle, but, unfortunately, the handle is a private member of RegistryKey. Well, reflection is your friend:

public static IntPtr GetRegistryHandle(RegistryKey registryKey){    Type type = registryKey.GetType();    FieldInfo fieldInfo = type.GetField("hkey",                               BindingFlags.Instance | BindingFlags.NonPublic);    return (IntPtr)fieldInfo.GetValue(registryKey);}

History

About Thomas Freudenberg

Click here to view Thomas Freudenberg's online profile.

출처 : http://www.codeproject.com/csharp/registrymonitor.asp

Introduction

As MFC/SDK programmers move into .NET, what surprises them most is the fact that everything is now so much more easier then ever before. Christian Graus was complaining that it was too easy and that the abominable allowance of gotos annoyed him. He might have a point there, but making coding easy is not such a bad thing after all. It's funny when you think of all the effort Chris Maunder and others put into those MFC & SDK tray icon classes that are ever so popular with copy/paste programmers. I dedicate this article to Chris M and others involved in the brilliant tray icon class project over the last few years.

Adding  the icon to your project

Ctrl-Shift-A will bring up the Add-New-Item dialog box. Select Icon File from the list of available templates. If the list is too populated to your liking select Resources from the tree control on the left. This will bring up a smaller list on the right and it will be easier for you to select Icon File. Now click open. You'll end up with the VS.NET icon editor. You may now create your icon here or copy/paste an icon from elsewhere.

Now right click on this icon from Solution Explorer. Take properties. And change the Build Action property to Embedded Resource. This will instruct the compiler to embed this icon along with your EXE file, thus saving you the annoyance of having to distribute the icon with your EXE.

Adding the NotifyIcon member to your form

Okay. Now that we have our icon ready we need to add it to our form class.

private NotifyIcon m_notifyicon;

Alright, so we have added a NotifyIcon member. Now let's initialize it and set some default properties. This should be done from the form object's constructor.

m_notifyicon = new NotifyIcon();m_notifyicon.Text = "Hello, what's cooking?"; m_notifyicon.Visible = true; m_notifyicon.Icon = new Icon(GetType(),"Icon1.ico"); //Thanks to Hasaki for this.

Alright, now compile and run your program. You'll see the icon in your tray. That was rather simple, huh? But usually people like to add a context menu to their tray icons. A tray icon simply sitting there is not very useful.

Adding a context menu to the tray icon

The first thing we need to do is to add a ContextMenu member to our form.

private ContextMenu m_menu;  

Now we need to initialize it and add some menu items.

m_menu = new ContextMenu(); m_menu.MenuItems.Add(0,     new MenuItem("Show",new System.EventHandler(Show_Click))); m_menu.MenuItems.Add(1,     new MenuItem("Hide",new System.EventHandler(Hide_Click))); m_menu.MenuItems.Add(2,     new MenuItem("Exit",new System.EventHandler(Exit_Click)));

We have added three menu items and have also associated click event handlers for each of those menu items. I could have created an array of MenuItem objects but that's not really needed here.

Now we need to associate this ContextMenu with our tray icon. So we do this.

m_notifyicon.ContextMenu = m_menu;

Now let's fill up those event handlers.

protected void Exit_Click(Object sender, System.EventArgs e) {    Close();}protected void Hide_Click(Object sender, System.EventArgs e) {    Hide();}protected void Show_Click(Object sender, System.EventArgs e) {    Show();}

Okay. Compile and run it. Now right clicking on the tray icon brings up the context menu. You can hide and show the form window using the two menu options. And the "Exit" option will exit the application.

A small problem

Now you'll notice a slight annoyance. The tray icon does not vanish when you exit the program. But when you move the mouse over the tray the icon vanishes. So, what do we do to avoid that? Again as with everything else with this whole .NET thing, it's as easy as 1,2,3. Override your form object's Dispose function and put the following lines of code into it.

protected override void Dispose( bool disposing ) {     if( disposing )     {         this.m_notifyicon.Dispose(); //we dispose our tray icon here    }    base.Dispose( disposing );}

Full Source Listing

using System;using System.Drawing;using System.Windows.Forms;using System.Data;namespace TrayTest{    public class Form1 : System.Windows.Forms.Form    {        private NotifyIcon m_notifyicon;            private ContextMenu m_menu;                public Form1()        {            Text = "TrayIcon test program";                        m_menu = new ContextMenu();                                                m_menu.MenuItems.Add(0,                new MenuItem("Show",new System.EventHandler(Show_Click)));            m_menu.MenuItems.Add(1,                new MenuItem("Hide",new System.EventHandler(Hide_Click)));            m_menu.MenuItems.Add(2,                new MenuItem("Exit",new System.EventHandler(Exit_Click)));            m_notifyicon = new NotifyIcon();            m_notifyicon.Text = "Right click for context menu";            m_notifyicon.Visible = true;            m_notifyicon.Icon = new Icon(GetType(),"Icon1.ico");            m_notifyicon.ContextMenu = m_menu;                                }                protected void Exit_Click(Object sender, System.EventArgs e)         {            Close();        }        protected void Hide_Click(Object sender, System.EventArgs e)         {            Hide();        }        protected void Show_Click(Object sender, System.EventArgs e)         {            Show();        }                protected override void Dispose( bool disposing )        {            if( disposing )            {                this.m_notifyicon.Dispose();            }            base.Dispose( disposing );        }                [STAThread]        static void Main()         {            Application.Run(new Form1());        }            }}        

Conclusion

I would like to thank James Johnson for his valuable tips while I was struggling with embedding icons into my exe. Also a special thanks to Colin for keeping me cheered up with Bobs while I was burying myself in despair after my bad experiences with the new CD writer.

About Nishant S

Editor Site Builder

Nish is a Microsoft Visual C++ MVP from Trivandrum, India and has been coding since the year 1990. Currently, Nish works as a Contract Employee for CodeProject and works from home. He has authored a romantic comedy Summer Love and Some more Cricket as well as a programming book – Extending MFC applications with the .NET Framework. He also maintains an MVP tips and tricks web site - www.voidnish.com where you can find a consolidated list of his articles, writings and ideas on VC++, MFC, .NET and C++/CLI. Nish intends to travel a lot and cover as much of the planet as he possibly can before the end of his life. It must also be mentioned here that Nish does not usually speak about himself in the 3rd person. Oh, by the way, you might want to check out his blog on C++/CLI, MFC, .NET and a lot of other stuff - blog.voidnish.com Click here to view Nishant S's online profile.

출처 : http://www.codeproject.com/csharp/trayiconmenu01.asp

Introduction

Ever got fed up with creating all the code behind parameters for your stored procedures? I have. So, I wrote this stored proc to do the code for me. (I love code that writes code). This has been written for use with "Microsoft Data Application Block" (SQLHelper.cs), however it could be hacked around to write the code without using the MDAB or even to write the code in VB. The script handles both input and output parameters, setting the size of text types, and you could even use it for direct access to a view or table.

Using the code

To implement, just copy the code into Query Analyzer and run. This will create a SPROC called "tools_CS_SPROC_Builder".

To use, just execute the SPROC passing the name of the SPROC you want the code for (see below). Note: don't include any owner prefix, e.g.: (dbo.).

EXEC tools_CS_SPROC_Builder 'mySprocsNameHere'

The message window in the Query Analyzer will write out all the code required for your class or code behind. There is a variable in "tools_CS_SPROC_Builder" called "@connName" which you can set to the name of your connection instance. By default, it's set to "conn.Connection" - just alter this for your own project's naming convention.

The code

CREATE     PROCEDURE tools_CS_SPROC_Builder(@objName nvarchar(100))AS/*___________________________________________________________________Name:  CS SPROC BuilderVersion: 1Date:  10/09/2004Author:  Paul McKenzieDescription: Call this stored procedue passing the name of your   database object that you wish to insert/update  from .NET (C#) and the code returns code to copy  and paste into your application.  This version is  for use with "Microsoft Data Application Block".    */SET NOCOUNT ONDECLARE @parameterCount intDECLARE @errMsg varchar(100)DECLARE @parameterAt varchar(1)DECLARE @connName varchar(100)//Change the following variable to the name of your connection instanceSET @connName='conn.Connection'SET @parameterAt=''  SELECT  dbo.sysobjects.name AS ObjName,  dbo.sysobjects.xtype AS ObjType, dbo.syscolumns.name AS ColName,  dbo.syscolumns.colorder AS ColOrder,  dbo.syscolumns.length AS ColLen,  dbo.syscolumns.colstat AS ColKey,  dbo.systypes.xtypeINTO #t_objFROM          dbo.syscolumns INNER JOIN dbo.sysobjects ON dbo.syscolumns.id = dbo.sysobjects.id INNER JOIN dbo.systypes ON dbo.syscolumns.xtype = dbo.systypes.xtypeWHERE      (dbo.sysobjects.name = @objName)  AND  (dbo.systypes.status <> 1) ORDER BY  dbo.sysobjects.name,  dbo.syscolumns.colorderSET @parameterCount=(SELECT count(*) FROM #t_obj)IF(@parameterCount<1) SET @errMsg='No Parameters/Fields found for ' + @objNameIF(@errMsg is null) BEGIN  PRINT 'try'  PRINT '   {'  PRINT '   SqlParameter[] paramsToStore = new SqlParameter[' + cast(@parameterCount as varchar) + '];'  PRINT ''    DECLARE @source_name nvarchar,@source_type varchar,    @col_name nvarchar(100),@col_order int,@col_type varchar(20),    @col_len int,@col_key int,@col_xtype int,@col_redef varchar(20)   DECLARE cur CURSOR FOR  SELECT * FROM #t_obj  OPEN cur  -- Perform the first fetch.  FETCH NEXT FROM cur  INTO @source_name,@source_type,@col_name,@col_order,    @col_len,@col_key,@col_xtype   if(@source_type=N'U') SET @parameterAt='@'  -- Check @@FETCH_STATUS to see if there are any more rows to fetch.  WHILE @@FETCH_STATUS = 0  BEGIN   SET @col_redef=(SELECT       CASE @col_xtype    WHEN 34 THEN 'Image'    WHEN 35 THEN 'Text'    WHEN 48 THEN 'TinyInt'    WHEN 52 THEN 'SmallInt'    WHEN 56 THEN 'Int'    WHEN 58 THEN 'SmallDateTime'    WHEN 59 THEN 'Real'    WHEN 60 THEN 'Money'    WHEN 61 THEN 'DateTime'    WHEN 62 THEN 'Float'    WHEN 99 THEN 'NText'    WHEN 104 THEN 'Bit'    WHEN 106 THEN 'Decimal'    WHEN 122 THEN 'SmallMoney'    WHEN 127 THEN 'BigInt'    WHEN 165 THEN 'VarBinary'    WHEN 167 THEN 'VarChar'    WHEN 173 THEN 'Binary'    WHEN 175 THEN 'Char'    WHEN 231 THEN 'NVarChar'    WHEN 239 THEN 'NChar'    ELSE '!MISSING'      END AS C)    --Write out the parameter   PRINT '   paramsToStore[' + cast(@col_order-1 as varchar)     + '] = new SqlParameter("' + @parameterAt + @col_name    + '", SqlDbType.' + @col_redef    + ');'   --If the type is a string then output the size declaration   IF(@col_xtype=231)OR(@col_xtype=167)OR(@col_xtype=175)    OR(@col_xtype=99)OR(@col_xtype=35)    BEGIN    PRINT '   paramsToStore[' + cast(@col_order-1 as varchar)      + '].Size=' + cast(@col_len as varchar) + ';'    END   PRINT '   paramsToStore['+ cast(@col_order-1 as varchar)     + '].Value =  ;'      -- This is executed as long as the previous fetch succeeds.      FETCH NEXT FROM cur   INTO @source_name,@source_type,@col_name,@col_order,     @col_len,@col_key,@col_xtype   END  PRINT ''  PRINT '   SqlHelper.ExecuteNonQuery(' + @connName +   ', CommandType.StoredProcedure,"' + @objName + '", paramsToStore);'  PRINT '   }'  PRINT 'catch(Exception excp)'  PRINT '   {'  PRINT '   }'  PRINT 'finally'  PRINT '   {'  PRINT '   ' + @connName + '.Dispose();'  PRINT '   ' + @connName + '.Close();'  PRINT '   }'    CLOSE cur  DEALLOCATE cur ENDif(LEN(@errMsg)>0) PRINT @errMsgDROP TABLE #t_objSET NOCOUNT ONGOSET QUOTED_IDENTIFIER OFF GOSET ANSI_NULLS ON GO

Output Example

try   {   SqlParameter[] paramsToStore = new SqlParameter[9];    paramsToStore[0] = new SqlParameter("@organisationid", SqlDbType.BigInt);   paramsToStore[0].Value =  ;   paramsToStore[1] = new SqlParameter("@DisplayName", SqlDbType.NVarChar);   paramsToStore[1].Size=100;   paramsToStore[1].Value =  ;   paramsToStore[2] = new SqlParameter("@DefaultCurrencyFID", SqlDbType.Int);   paramsToStore[2].Value =  ;   paramsToStore[3] = new SqlParameter("@TaxCode", SqlDbType.NVarChar);   paramsToStore[3].Size=60;   paramsToStore[3].Value =  ;   paramsToStore[4] = new SqlParameter("@UserFID", SqlDbType.BigInt);   paramsToStore[4].Value =  ;   paramsToStore[5] = new SqlParameter("@IsClient", SqlDbType.Bit);   paramsToStore[5].Value =  ;   paramsToStore[6] = new SqlParameter("@IsContractor", SqlDbType.Bit);   paramsToStore[6].Value =  ;   paramsToStore[7] = new SqlParameter("@IsSupplier", SqlDbType.Bit);   paramsToStore[7].Value =  ;   paramsToStore[8] = new SqlParameter("@IsDesigner", SqlDbType.Bit);   paramsToStore[8].Value =  ;    SqlHelper.ExecuteNonQuery(conn.Connection, CommandType.StoredProcedure,"usp_Insert_Organisation", paramsToStore);   }catch(Exception excp)   {   }finally   {   conn.Connection.Dispose();   conn.Connection.Close();   }

All you then have to do is copy-paste and fill in the values you want to pass and catch any exceptions... (Yes you do have to write some code!).

Points of Interest

In order for me to work out the @col_xtype variable from sysobjects, I ran lots of tests on a table I created with every type variation in both directions. It certainly works fine for all the usual data types, but I haven't had a chance to test all types within .NET, so if you find a bug, let me know. Enjoy!

McCodeJunky

Click here to view McCodeJunky's

멋진 사람 ㅋㅋ

출처 : http://www.codeproject.com/cs/database/CSCodeBuilder.asp

Introduction

This paper is written for users who deal with SQL Profiler or collect Microsoft SQL Server traces and want to automate trace collection, trace manipulation, and trace replay.

Knowledge of the C# language and some experience with the SQL Profiler tool is required to fully take advantage of the information provided.

SQL Server trace is a mechanism for monitoring and recording activity inside SQL Server. Essentially, when any activity occurs (a query is sent against the instance of SQL Server, for example), a special entity called an event is generated inside the server. The event is then shipped to a monitoring tool called SQL Profiler, which displays this event and all its attributes (called columns).

This combination of SQL Trace and SQL Profiler has proven to be a very powerful performance analyzing and tuning tool—it enables users to see what activity a particular application generates and what impact it has on the server.

However, the SQL Profiler tool is completely manual; therefore, it is not easy to automate the creation of the trace or perform trace analysis and trace manipulation. For most of these tasks, users must start SQL Profiler and use it interactively.

Trace and Replay objects, a new feature in Microsoft SQL Server 2005 that offers a new managed API for tracing and trace replay, are introduced to enable automation.

Trace and Replay objects simplify the management of SQL Server in the following ways:

• First, they enable users to completely automate tuning, security audits, and health monitoring of traced servers.
• Second, they enable automatic functional verification of new server releases and security packs.
• Third, they provide users with the ability to establish performance benchmarks against current server performance.

This paper discusses Trace objects and Replay objects in detail.

Trace Objects

Organizations where the tracing of SQL Servers is performed on a regular basis often have to deal with large amounts of trace data, which needs to be processed and analyzed. SQL Profiler provides features to filter the traces; such an approach can be extremely labor-intensive, however. The ability to create a small program that would perform analysis in an automated fashion would provide a better way to handle this. For example, such a program could crawl through trace data and identify the most frequently executed query on the server. Such a program could be reused and perhaps later expanded to include increasingly sophisticated analysis logic.

Another important aspect of automation is a timely reaction to events that are happening on the server. It would be convenient to have a program that could start a trace, monitor events of the trace, and perhaps alert the administrator if the duration of particular queries exceeds a certain threshold.

It would also be convenient to be able to implement a way to perform other tasks, like moving trace files into SQL Server tables, or from tables to files, in a customized fashion.

Trace Object technology can help address these and other problems.

Trace objects serve the purpose of starting a new trace, and of reading and writing trace log files and trace tables. Essentially, there are three classes for accomplishing these purposes:

• TraceServer—Starts and reads a new trace.
• TraceFile—Reads and writes to a trace file.
• TraceTable—Reads and writes to a trace table.

These classes belong to the Microsoft.SqlServer.Management.Trace namespace and provide an abstraction of a stream of trace events. This stream could be read-only (TraceServer) or provide reading and writing capabilities (TraceFile and TraceTable). Figure 1 illustrates the relationships between these classes.

Figure 1. Microsoft.SqlServer.Management.Trace namespace

Example 1: How to Start a Trace

To gain a better understanding of Trace objects, here's an example of how to construct a simple C# program that starts a trace and prints the names of the first 10 events:

1. Create a TraceServer object:

   TraceServer reader = new TraceServer(); 

2. Create an object that is responsible for storing connection information:

   ConnectionInfoBase ci = new SqlConnectionInfo("localhost"); ((SqlConnectionInfo)ci).UseIntegratedSecurity = true; 

3. Pass connection information to the InitializeAsReader() method of the TraceServer class as a first argument. The second argument is the name of the trace template file. You can create such a template file by using the SQL Profiler tool, or use stock templates that are shipped with SQL Server 2005 (templates are located in the \Program Files\Microsoft SQL Server\90\Tools\Profiler\Templates folder):

   reader.InitializeAsReader(ci, @"Standard.tdf"); 

4. Declare an event counter:

   int eventNumber = 0; 

5. Continue reading in the loop and incrementing a counter until 10 events have printed:

   while (reader.Read()) { Console.Write( reader.GetValue(0).ToString() ); eventNumber ++; if (eventNumber == 10) break; } 

6. Close the reader:

   reader.Close(); 

The complete program looks as follows:

// need to reference // %Program Files$\Microsoft SQL // Server\90\SDK\Assemblies\ // Microsoft.SqlServer.ConnectionInfo.dll public void FileToTable() { TraceServer reader = new TraceServer(); ConnectionInfoBase ci = new SqlConnectionInfo("localhost"); ((SqlConnectionInfo)ci).UseIntegratedSecurity = true; reader.InitializeAsReader(ci, @"Standard.tdf"); int eventNumber = 0; while (reader.Read()) { Console.Write( "{0}\n", reader.GetValue(0).ToString() ); eventNumber ++; if (eventNumber == 10) break; } reader.Close(); } 

The same code is applicable to starting a trace against Analysis Services. The only difference is in the ConnectionInfo object. Instead of SqlConnectionInfo, OlapConnectionInfo should be created:

OlapConnectionInfo connection = new OlapConnectionInfo(); connection.ServerName = "localhost"; 

Note   The reader.Read() call is synchronous, meaning that it will not return until the event is read or the trace is stopped. To stop a trace, you need to call TraceServer.Stop() from a separate thread.

Example 2: FileToTable Utility

The following sample is a simple utility that converts data that is stored in a file to a table. The advantage of using this utility over the Transact-SQL fn_trace_gettable function is that this utility can read Microsoft SQL Server 7.0 and SQL Server 2000 files, and it can modify the data "as it goes."

// need to reference // %Program Files$\Microsoft SQL // Server\90\SDK\Assemblies\ // Microsoft.SqlServer.ConnectionInfo.dll //Main routine public void FileToTable() { SqlConnectionInfo connInfo = new SqlConnectionInfo("localhost"); connInfo.DatabaseName = "master"; TraceFile reader = new TraceFile(); reader.InitializeAsReader("input.trc"); TraceTable writer = new TraceTable(); writer.InitializeAsWriter(reader, connInfo, "SampleOutputTable"); writer.WriteNotify += new WriteNotifyDelegate(OnWriteNotify); while( writer.Write() ){}; writer.Close(); } // Event handler gets invoked before writing of every row private void OnWriteNotify( IDataRecordChanger currentRecord, out bool skipRecord ) { currentRecord.SetValue(1, "New Data"); skipRecord = false; } 

The preceding utility is provided as an example. With moderate modifications, you can change this utility to become a Table-to-File converter as shown in the following example:

1. The main routine in this utility is called FileToTable(). Start this routine by creating the SqlConnectionInfo object:

   SqlConnectionInfo connInfo = new SqlConnectionInfo("localhost"); connInfo.DatabaseName = "master"; 

   For more information about that class, see SQL Server Books Online for SQL Server 2005. This class basically provides connection information to the server and the database where the table will be stored (master in this case).

2. Use calls to create and initialize the TraceReader class:

   TraceFile reader = new TraceFile(); reader.InitializeAsReader("input.trc"); 

   Note   The input.trc filename is provided here. The full path is also acceptable.

3. Create and initialize the table writer object:

   TraceTable writer = new TraceTable(); writer.InitializeAsWriter(reader, connInfo, "SampleOutputTable"); 

   The table name is SampleOutputTable. The server connection information is provided earlier in Step 1.

4. Set up the OnWriteNotify event handler:

   writer.WriteNotify += new WriteNotifyDelegate(OnWriteNotify); 

   This event handler will be invoked on every write the writer performs.

5. Sit in the loop and write:

   while( writer.Write() ){}; 

6. As writing is done, close the writer (which closes the reader as well):

   writer.Close(); 

Through the IDataRecordChanger interface, the event handler can examine the record (by way of the IDataReader interface from which the IDataRecordChanger inherits the record) and change the values of the columns. In this case, the column is changed with index 1 and the value is set to the string "New Data":

currentRecord.SetValue(1, "New Data"); skipRecord = false; 

Trace Objects Advanced

This section discusses how Trace objects are built in more detail. This information is helpful, but not essential for understanding how to use the objects. Figure 2 illustrates the Trace object hierarchy.

Figure 2. Trace object hierarchy

The main interface for accessing data is the .NET Framework interface called IDataRecord from the System.Data namespace. It allows users to access a row of data at a time—a row consists of columns that can be examined by index or name. (For more information, see the .NET Framework documentation).

The IDataRecord interface is extended to IDataReader, which is also a standard .NET Framework interface. The most important thing IDataReader adds is Read() methods, which allow record navigation in sequential read-only forward-only fashion.

The methods associated with IDataReader are implemented in the abstract class TraceReader, which provides reading capabilities that all three classes (TraceServer, TraceTable, and TraceFile) inherit. TraceTable and TraceFile also possess writing capabilities that are implemented in the TraceReaderWriter class, which extends the TraceReader class.

TraceServer, TraceTable, and TraceFile, in addition to the capabilities discussed earlier, provide the following initialization methods:

• TraceServer:

  InitializeAsReader (ConnectionInfoBase serverConnInfo, String profileFileName)

  • serverConnInfo: Provides connection information to the server that will be traced.
  • profileFileName: A path to a file that contains a SQL Profiler trace profile. (For more information about how to create one, see SQL Server Books Online.)
• TraceTable:

  InitializeAsReader (ConnectionInfoBase serverConnInfo, String tableName, String tableOwner)

  • serverConnInfo: Provides connection information to the server that contains trace table.
  • tableName: The name of the table.
  • tableOwner: The schema to which the table belongs.

  InitializeAsWriter (TraceReader source, ConnectionInfoBase serverConnInfo, String destinationTableName)

  • source: A TraceReader object that contains trace data (could be TraceFile or TraceTable)
  • serverConnInfo: Provides connection information to the server that contains trace table.
  • destinationTableName: The name of the table to which the trace data is written.
• TraceFile:

  InitializeAsReader (String fileName)

  • Filename: The name of the file that contains trace data.

  InitializeAsWriter (TraceReader source, String destinationFileName)

  • source: A TraceReader object that contains trace data (could be TraceFile or TraceTable).
  • destinationFileName: The name of the file to which the trace data is written.

    Note   TraceFile and TraceTable also have InitializeAsReplayOutputWriter() methods, which will be discussed later in this paper.

Replay Objects

Replay objects provide functionality to replay a trace against an instance of SQL Server, thus simulating the load that occurred on the server at the time the trace was taken. This technology is built on top of the SQL Profiler replay that now is being made accessible by means of the programmatic interface.

Replay objects contain two classes: the TraceReplay class, which implements all the replay functionality, and the TraceReplayOptions helper class, which helps configure the TraceReplay object.

The TraceReplay class provides the following methods:

• Start()—Starts replay.
• Pause()—Pauses replay.
• Stop()—Stops replay.

The TraceReplay class provides the following properties:

• Source—a mandatory TraceReader object that contains the trace to be replayed.
• OutputFile—an optional file to which the output will be streamed.
• OutputTable—an optional table to which the output will be streamed.
• Connection—mandatory Connection information objects. TraceReplay will replay the trace against the server that is specified in this connection object.
• Options—configuration options (see below).

The TraceReplay class provides the following events:

• OnReplayStart—a handler is invoked on Replay Start.
• OnReplayPause—a handler is invoked on Replay Pause.
• OnReplayStop—a handler is invoked on Replay Stop.
• OnReplayEvent—a handler is invoked before replaying an event.
• OnReplayResultEvent—a handler is invoked on every result of repayable event.

TraceReplayOptions provides the following configuration options:

• NumberOfReplayThreads—the number of threads Replay employs.
• HealthMonitorPollInterval—how often the health monitor wakes up and examines stale threads.
• HealthMonitorWaitInterval—the stale thread maximum time to live.
• Mode—the mode of replay (either Sequential or connection level).
• KeepResults—specifies whether to keep the replay results.

Example 1: FileReplay Utility

// need to reference // %Program Files$\Microsoft SQL // Server\90\SDK\Assemblies\ // Microsoft.SqlServer.ConnectionInfo.dll public void TestReplay_SQL_File() { TraceReplay replay = new TraceReplay(); TraceFile source = new TraceFile(); source.InitializeAsReader("input.trc"); replay.Source = source; SqlConnectionInfo connection = new SqlConnectionInfo(); connection.ServerName = "localhost"; connection.UseIntegratedSecurity = true; replay.Connection = connection; replay.OnReplayEvent += new TraceReplay.OnReplayEventHandler(OnReplayEvent); replay.Start(); } public static void OnReplayEvent( int recordNumber, IDataRecordChanger currentRecord, out bool skipRecord ) { skipRecord = false; currentRecord.SetValue(2, 2); //setting database id to the new value } 

1. The main routine is called TestReplay_SQL_File(). Start this routine by creating the TraceReplay object:

    TraceReplay replay = new TraceReplay(); 

2. Use calls to create and initialize the FileReader class that will be used as a source of the replay:

    TraceFile source = new TraceFile(); source.InitializeAsReader("input.trc"); replay.Source = source; 

   Note   The input.trc filename is provided here. The full path is also acceptable.

3. Create and configure connection information by using the SqlConnectionInfo class:

   SqlConnectionInfo connection = new SqlConnectionInfo(); connection.ServerName = "localhost"; connection.UseIntegratedSecurity = true; replay.Connection = connection; 

4. Set up the OnReplay event handler:

   replay.OnReplayEvent += new TraceReplay.OnReplayEventHandler(OnReplayEvent); 

5. Start Replay:

   replay.Start(); 

   Note   The start method does not return until Replay is finished; if you need to stop or pause a replay in progress, use a separate thread.

Again, the IDataRecordChanger interface not only provides a way to examine the record (by way of the IDataReader interface from which the IDataRecordChanger inherits the record) but also changes the values of the columns. In this case the column is changed with index 2 and the value is set to 2:

skipRecord = false; currentRecord.SetValue(2, 2); //setting database ID to the new value 

Conclusion

The Trace and Replay objects technology takes advantage of the Microsoft .NET platform that is now integrated with SQL Server 2005 to enable its users to perform routine tracing and replay tasks in automated fashion.

The unique features of the Trace and Replay objects enable users to easily manipulate tracing, read and write to trace files and tables, and replay traces. Optionally, users can also modify the data in trace files by using writers' event handlers.

The scenarios of usage can be analysis of large trace file logs, live monitoring tasks, converting or altering trace data, and automated replay.

Introduction

This article describes the past, present, and future of Microsoft data access technologies, including DB-Library, ESQL, DAO, Microsoft® Data Access Components (MDAC) (including ODBC, ADO, and OLE DB), ADO.NET, and SQL Native Client. This article identifies which technologies are being enhanced, and which technologies and components are being deprecated or excluded from future releases.

Microsoft Data Access Components (MDAC)

With Microsoft Data Access Components (MDAC), developers can connect to and use data from a wide variety of relational and non-relational data sources. You can connect to many different data sources using ActiveX® Data Objects (ADO), Open Database Connectivity (ODBC), or OLE DB. You can do this through providers and drivers that are either built and shipped by Microsoft, or that are developed by various third parties.

Current MDAC Architecture

With the current MDAC architecture, client-server, n-tier, or Web browser applications can access SQL, Semi-Structured, and Legacy Data stores. Additionally, with MDAC (depending on requirements), these applications have the flexibility to access the data using ADO, OLE DB, or ODBC.

Figure 1. Current MDAC architecture

For the purposes of this document, you can divide the MDAC stack into the following components, based on technology and products:

Current MDAC Components

These components are supported in the current release. Use these components when you develop new applications or upgrade existing applications.

• ADO: ActiveX Data Objects (ADO) provides a high-level programming model that will continue to be enhanced. Although a little less performant than coding to OLE DB or ODBC directly, ADO is straightforward to learn and use, and can be used from script languages such as Microsoft Visual Basic® Scripting Edition (VBScript) or Microsoft JScript®.
• ADOMD: ADO Multi-Dimensional (ADOMD) is to be used with multi-dimensional data providers such as Microsoft OLAP Provider, also known as Microsoft Analysis Services Provider. No major feature enhancements have been made to it since MDAC 2.0; however, it will be available on the 64-bit Microsoft Windows® operating system.
• ADOX: ADO Extensions for DDL and Security (ADOX) enables the creation and modification of definitions of a database, a table, an index, or a stored procedure. You can use ADOX with any provider. The Microsoft Jet OLE DB Provider provides full support for ADOX, while the Microsoft SQL OLE DB Provider provides limited support. No major enhancements are planned for ADOX in future MDAC releases; however, it will be available on the 64-bit Windows operating system.
• OLE DB: OLE DB is a comprehensive set of COM interfaces for accessing a diverse range of data in a variety of data stores. OLE DB providers exist for accessing data in databases, file systems, message stores, directory services, workflow, and document stores. OLE DB core services (though not every OLE DB provider) will be available on the 64-bit Windows operating system.
• SQLOLEDB: Microsoft OLE DB Provider for SQL Server (SQLOLEDB) supports access to Microsoft SQL Server 6.5 and later. This OLE DB Provider will be the primary focus of future MDAC feature enhancements. It will be available on the 64-bit Windows operating system.
• Microsoft SQL Server Network Libraries: The SQL Server Network Libraries allow SQLOLEDB and SQLODBC to communicate with the SQL Server database. The following SQL Server Network Libraries are currently deprecated in MDAC releases: Banyan Vines, AppleTalk, Servernet, IPX/SPX, Giganet, and RPC. TCP/IP, Named Pipes, and Shared Memory SQL Server Network Libraries will continue to be enhanced and will be available on the 64-bit Windows operating system.
• ODBC: The Microsoft Open Database Connectivity (ODBC) interface is a C programming language interface that allows applications to access data from a variety of Database Management Systems (DBMS). Applications using this API are limited to accessing relational data sources only. ODBC will be available on the 64-bit Windows operating system.
• SQLODBC: Microsoft SQL Server ODBC Driver (SQLODBC) enables access to Microsoft SQL Server 6.5 and later. SQLODBC will be available on the 64-bit Windows operating system.

Deprecated MDAC Components

These components are still supported in the current release of MDAC, but might be removed in future releases. Microsoft recommends that when you develop new applications, you avoid using these components. Additionally, when you upgrade or modify existing applications, remove any dependency on these components.

• Jet: Starting with version 2.6, MDAC no longer contains Jet components. In other words, MDAC 2.6, 2.7, 2.8, and all future MDAC releases do not contain Microsoft Jet, Microsoft Jet OLE DB Provider, or the ODBC Desktop Database Drivers.
• MSDASQL: The Microsoft OLE DB Provider for ODBC (MSDASQL) provides ADO clients access to databases through ODBC Drivers. This has been the default provider for ADO; however, for future releases of MDAC and the 64-bit Windows operating system, MSDASQL has been deprecated. Therefore, to access the database from ADO, clients must use appropriate Native OLE DB Providers, such as SQLOLEDB, to access Microsoft SQL Server. MSDASQL will be not available on the 64-bit Windows operating system; however, it will still be possible to use on the 64-bit Windows operating system through the 32-bit Windows subsystem.
• MSDADS: With the Microsoft OLE DB Provider for Data Shaping (MSDADS), you can create hierarchical relationships between keys, fields, or rowsets in an application. No major feature enhancements have been made since MDAC 2.1. This Provider has been deprecated in future MDAC releases. Microsoft recommends that you use XML instead of MSDADS.
• Oracle ODBC: The Microsoft Oracle ODBC Driver (Oracle ODBC) provides access to Oracle database servers. It provides full support for Oracle 7. It also uses Oracle 7 emulation to provide limited support for Oracle 8 databases. The Oracle ODBC Driver has not yet been tested with Oracle 9 databases.
• RDS: Remote Data Services (RDS) is a proprietary Microsoft mechanism to access remote ADO Recordset objects across the Internet or an intranet. No major feature enhancements have been made to RDS since MDAC 2.1. This component is being deprecated. Microsoft now ships the Microsoft SOAP Toolkit 2.0, in which applications can access remote data by using an open, XML-based standard. Applications that use RDS should migrate to SOAP.
• JRO: The Microsoft Jet OLE DB Provider and other related components have been removed from the MDAC stack since MDAC 2.6. Jet Replication Objects (JRO) is used only with Jet (Access) databases, basically to create or compact the Jet Database and Jet Replication Management. JRO has been deprecated and MDAC 2.7 will be its last release. It will not be available on the 64-bit Windows operating system.
• SQL XML: SQL XML provides extensions to Microsoft OLE DB Provider for SQL Server (SQLOLEDB) to allow clients to request Microsoft SQL Server 2000 data through XML, and to retrieve XML streams. It was first released with MDAC 2.6. With SQL XML Web Release 1, clients can insert, update, and delete data in SQL Server 2000 using Updategrams and Bulk Load. This component is not being deprecated, but it is being removed from future MDAC releases. Current and later versions of this product are available as Web downloads. SQL XML will be available on the 64-bit Windows operating system.

MDAC Releases

Here is a list of the supportability scenarios of past, present, and future MDAC releases, starting with the earliest.

• MDAC 1.5, MDAC 2.0, and MDAC 2.1: These versions of MDAC were independent releases that were released through the Microsoft Windows NT® Option Pack, the Microsoft Windows Platform SDK, or the MDAC Web site. These versions of MDAC are no longer supported.
• MDAC 2.5: This version of MDAC was included with the Windows 2000 operating system. Future services packs of MDAC 2.5 will be included with corresponding Windows 2000 service packs. Additionally, these MDAC services packs will be released to the MDAC Web site in accordance with the Windows 2000 service pack release schedule. You can only install this version of MDAC on Windows NT, Windows 95, and Windows 98 platforms. You can only install this version on Windows 2000 and Windows Millennium Edition platforms through the operating systems or their services packs. This version is currently supported.
• MDAC 2.6: MDAC 2.6 RTM, SP1, and SP2 were included with Microsoft SQL Server 2000 RTM, SP1, and SP2, respectively. Additionally, these MDAC service packs were released to the MDAC Web site in accordance with the Microsoft SQL Server 2000 service pack release schedule. You can install this version of MDAC and its service packs on Windows 2000, Windows Millennium Edition, Windows NT, Windows 95, and Windows 98 platforms. This version is no longer supported.
• MDAC 2.7: This version of MDAC is included with the Microsoft Windows XP RTM and SP1 operating systems. You can install this version of MDAC and its service packs on Windows 2000, Windows Millennium, Windows NT, and Windows 98 platforms. You can only install this version on the Windows XP platform through the operating system or its services packs.
  • The 32-bit version of MDAC 2.7 has been released to the MDAC Web site.
  • The 64-bit version of MDAC 2.7 will release with the 64-bit version of Windows XP only.
• MDAC 2.8: This version of MDAC is included with Windows Server 2003 and Windows XP SP2 and later.
  • The 32-bit version of MDAC 2.8 will also be released to the MDAC Web site at the same time Windows Server 2003 is released to the customer.
  • The 64-bit version of MDAC 2.8 will release with the 64-bit version of Windows Server 2003 only.

SQL Native Client (SQLNCLI)

SQL Native Client (SQLNCLI) is a data access technology that is new to Microsoft SQL Server 2005, and it is a stand alone data access Application Programming Interface (API) that is used for both OLE DB and ODBC. It combines the SQL OLE DB Provider and the SQL ODBC Driver into one native dynamic link library (DLL) while also providing new functionality that is separate and distinct from the Microsoft Data Access Components (MDAC). SQL Native Client can be used to create new applications or enhance existing applications that need to take advantage of new SQL Server 2005 features such as Multiple Active Result Sets (MARS), User-Defined Types (UDT), and XML data type support.

ADO.NET

ADO.NET is an evolutionary improvement over traditional ADO for creating distributed, data sharing applications. It is a high-level application programming interface that is targeted at loosely coupled, n-tier, Internet-based applications that support disconnected access to data. It is a core component of the Microsoft .NET Framework.

Figure 2. ADO.NET architecture

ADO.NET provides .NET-managed providers for connected access, and DataSets that read and write in XML for disconnected management of retrieved data and user interaction. The following data providers are available for ADO.NET:

• Microsoft SQL .NET Data Provider: This provider allows .NET applications to directly access a Microsoft SQL Server database.
• Microsoft OLE DB .NET Data Provider: This provider allows .NET applications to access databases using their native OLE DB Providers.
• Microsoft ODBC .NET Data Provider: This provider allows .NET applications to access databases by using their ODBC drivers.
• Microsoft Oracle .NET Data Provider: This provider allows .NET applications to access an Oracle database.

The DataSet reads and writes XML and the XMLDataDocument integrates relational and XML views.

Obsolete Data Access Technologies

Obsolete technologies are technologies that have not been enhanced or updated in several product releases and that will be excluded from future product releases. Do not use these technologies when you write new applications. When you modify existing applications that are written using these technologies, consider migrating those applications to ADO.NET.

The following components are considered obsolete:

• DB-Library: This is a SQL Server-specific programming model that includes C APIs. There have been no feature enhancements to the DB-Library since SQL Server 6.5. Its final release was with SQL Server 2000 and it will not be ported to the 64-bit Windows operating system.
• Embedded SQL (E-SQL): This is a SQL Server-specific programming model that enables Transact-SQL statements to be embedded in Visual C code. No feature enhancements have been made to the E-SQL since SQL Server 6.5. Its final release was with SQL Server 2000 and it will not be ported to the 64-bit Windows operating system.
• Data Access Objects (DAO): DAO provides access to JET (Access) databases. This API can be used from Microsoft Visual Basic®, Microsoft Visual C++®, and scripting languages. It was included with Microsoft Office 2000 and Office XP. DAO 3.6 is the final version of this technology. It will not be available on the 64-bit Windows operating system.
• Remote Data Objects (RDO): RDO was specifically designed to access remote ODBC relational data sources, and made it easier to use ODBC without complex application code. It was included with Microsoft Visual Basic versions 4, 5, and 6. RDO version 2.0 was the final version of this technology.

For More Information

For more information, visit the following Microsoft Web site:

• The Data Access and Storage Developer Center Web site

출처 : http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnmdac/html/data_mdacroadmap.asp

Enterprise Services Issues and Info

I have been spending most of this week (yes, even on New Year's Day as well!) working out some issues I have been having with Enterprise Services (ES), as I mentioned some of my work in a previous post.  This is also a continuation of Sam's thoughts that he posted about our work on the ES architecture for our client.

In particular, we are running distributed transactions against Oracle, using Oracle's Data Provider for .Net (typically has better performance than Microsoft's version).  I have been able to get everything to work correctly using Windows 2000 and Windows XP.  When using Windows Server 2003, we are having issues.

According to this article:  http://support.microsoft.com/?id=817066, some things have changed with MS DTC in regards to security (in the right direction, I might add).  You need to enable XA transactions, as well explicitly add an XADLL registry entry that contains your resource manager's XA transaction manager dll.  No problem.  After much research, it appears that this is Oracle's file (for 9.2.0.x version):  heteroxa9.dll.  The problem is when that file reference is put in place, it doesn't seem to work.   We are still puzzling through this as I write this, but I want to at least blog about it to see if anyone else had similar problems (or, hopefully, solutions).

A hack that works, but doesn't give me the real solution is to set all but one of the connection strings to the various resource managers to “Enlist=false“.  What this means is you can single out one of the connections to use COM+, and the others won't (in other words, these connections can still see the TransactionId, but rollbacks won't be possible on this connection because they weren't “enlisted“ in the distributed transaction).  Again, that's a hack, and doesn't give you real distributed transactions -- it just simply takes MS DTC out of the picture.  So, as far as I can tell the issue is with Window Server 2003 and the new MS DTC changes, not with Enterprise Services.

I have spent time as well really digging underneath the covers of ES to determine how it all works and interacts with COM+.  One point I made a couple of days ago in a previous post was it appeared as long as the namespace System.EnterpriseServices was referenced by an assembly, then that assembly's methods could be involved in a transaction, even though the assembly class itself may not be derived from ServicedComponent (a requirement in order to be a “configured” component).  Upon further checking, I noticed that these three key assemblies also reference System.EnterpriseServices by default:  System.Data.dll, System.Web.dll, and System.Web.Services.dll. 

As an example, within System.Data, as you might expect, if a COM+ Transaction is detected, then if a local transaction has started, it is rolled back, and the System.Data.SqlClient.Transaction class takes over to allow a COM+/ES transaction to take place instead.  Interesting stuff.

posted on Friday, January 02, 2004 2:11 PM

Introduction

As a matter of fact Microsoft Windows services, formerly known as NT services enable you to create long-running executable applications that run in its own Windows session, which then has the ability to start automatically when the computer boots and also can be manually paused, stopped or even restarted.

This makes services ideal for use on a server or whenever you need long-running functionality that does not interfere with other users who are working on the same computer. You can also run services in the security context of a specific user account that is different from the logged-on user or the default computer account.

Windows services don’t have any interface to the user, so it can not be debugged like any regular application, but it’s debugged as a process. .NET has a very nice tool that enables processes debugging while it’s in the run status, by easily pressing Ctrl + Alt + P shortcut.

Background

I’ve searched well so many sites about a code that I can with the help of it, build a simple Windows service, but I found a lot of code on how to manage the current Windows services of the system and that’s through the ServiceController class.

After searching the MSDN, I’ve found some nice code that helped me to create this simple Windows service. Hope it can help as a basic architecture for and usage of such a Windows service.

Using the code

At first you should simply open VS.NET and then at the File menu click on New, Project. From the New Project Dialog Box, choose the Windows service template project and name it MyNewService like shown below:

The project template automatically adds a component class that is called Service1 by default and inherits from System.ServiceProcess.ServiceBase.

Click the designer. Then, in the Properties window, set the ServiceName property for Service1 to MyNewService.

Set the Name property to MyNewService. Set the AutoLog property to true.

In the code editor, edit the Main method to create an instance of MyNewService. When you renamed the service in step 3, the class name was not modified in the Main method. To access the Main method in VC#, expand the Component Designer generated code region.

static void Main(){     System.ServiceProcess.ServiceBase[] ServicesToRun;     //Change the following line to match.     ServicesToRun = new         System.ServiceProcess.ServiceBase[] { new MyNewService() };     System.ServiceProcess.ServiceBase.Run(ServicesToRun);  }

In the next section, you will add a custom event log to your Windows service. Event logs are not associated in any way with Windows services. Here the EventLog component is used as an example of the type of components you could add to a Windows service.

To add custom event log functionality to your service:

1. In the Solution Explorer, right-click Service1.vb or Service1.cs and select View Designer.
2. From the Components tab of the Toolbox, drag an EventLog component to the designer.
3. In the Solution Explorer, right-click Service1.vb or Service1.cs and select View Code.
4. Edit the constructor to define a custom event log.

To access the constructor in Visual C#, expand the Component Designer generated code region.

public MyNewService(){     InitializeComponent()    if(!System.Diagnostics.EventLog.SourceExists("DoDyLogSourse"))    System.Diagnostics.EventLog.CreateEventSource("DoDyLogSourse",                                                          "DoDyLog");    eventLog1.Source = "DoDyLogSourse";    // the event log source by which     //the application is registered on the computer    eventLog1.Log = "DoDyLog";}

To define what happens when the service starts, in the code editor, locate the OnStart method that was automatically overridden when you created the project, and write code to determine what occurs when the service begins running:

protected override void OnStart(string[] args){     eventLog1.WriteEntry("my service started"); }

The OnStart method must return to the operating system once the service's operation has begun. It must not loop forever or block. To set up a simple polling mechanism, you can use the System.Timers.Timer component. In the OnStart method, you would set parameters on the component, and then you would set the Timer.Enabled property to true. The timer would then raise events in your code periodically, at which time your service could do its monitoring.

To define what happens when the service is stopped, in the code editor, locate the OnStop procedure that was automatically overridden when you created the project, and write code to determine what occurs when the service is stopped:

protected override void OnStop(){     eventLog1.WriteEntry("my service stoped");}

You can also override the OnPause, OnContinue, and OnShutdown methods to define further processing for your component. For the method you want to handle, override the appropriate method and define what you want to occur. The following code shows what it looks like if you override the OnContinue method:

protected override void OnContinue(){    eventLog1.WriteEntry("my service is continuing in working");}

Some custom actions need to occur when installing a Windows service, which can be done by the Installer class. Visual Studio can create these installers specifically for a Windows service and add them to your project. To create the installers for your service.

1. Return to design view for Service1.
2. Click the background of the designer to select the service itself, rather than any of its contents.
3. In the Properties window, click the Add Installer link in the gray area beneath the list of properties. By default, a component class containing two installers is added to your project. The component is named ProjectInstaller, and the installers it contains are the installer for your service and the installer for the service's associated process.
4. Access design view for ProjectInstaller, and click ServiceInstaller1.
5. In the Properties window, set the ServiceName property to MyNewService.
6. Set the StartType property to Automatic.

Tip

To avoid being asked about the system username and password you must change the Account for the serviceProcessInstaller to LocalSystem. This is done by opening the ProjectInstaller design and then selecting the serviceProcessInstaller, press F4 and then change the Account property to LocalSystem. Or you can manually do that by creating a class that inherits from System.Configuration.Install.Installer like this:

[RunInstaller(true)]public class ProjectInstaller : System.Configuration.Install.Installer private System.ServiceProcess.ServiceProcessInstaller                                   serviceProcessInstaller1;private System.ServiceProcess.ServiceInstaller serviceInstaller1; /// <summary> /// Required designer variable. /// </summary> private System.ComponentModel.Container components = null;public ProjectInstaller()   // This call is required by the Designer.   InitializeComponent();   // TODO: Add any initialization after the InitComponent call } private void InitializeComponent() {    this.serviceProcessInstaller1 =      new System.ServiceProcess.ServiceProcessInstaller();    this.serviceInstaller1 =      new System.ServiceProcess.ServiceInstaller();    // serviceProcessInstaller1    //    this.serviceProcessInstaller1.Account =      System.ServiceProcess.ServiceAccount.LocalSystem;    this.serviceProcessInstaller1.Password = null;   this.serviceProcessInstaller1.Username = null;    //    // serviceInstaller1    //    this.serviceInstaller1.ServiceName = "MyNewService";    this.serviceInstaller1.StartType =      System.ServiceProcess.ServiceStartMode.Automatic;   //    // ProjectInstaller    //    this.Installers.AddRange     (new System.Configuration.Install.Installer[]    {        this.serviceInstaller1,        this.serviceInstaller1});   }}

To build your service project

1. In Solution Explorer, right-click your project and select Properties from the shortcut menu. The project's Property Pages dialog box appears.
2. In the left pane, select the General tab in the Common Properties folder.
3. From the Startup object list, choose MyNewService. Click OK.
4. Press Ctrl+Shift+B to build the project. 

Now that the project is built, it can be deployed. A setup project will install the compiled project files and run the installers needed to run the Windows service. To create a complete setup project, you will need to add the project output, MyNewService.exe, to the setup project and then add a custom action to have MyNewService.exe installed.

To create a setup project for your service

1. On the File menu, point to Add Project, and then choose New Project.
2. In the Project Types pane, select the Setup and Deployment Projects folder.
3. In the Templates pane, select Setup Project. Name the project MyServiceSetup.

A setup project is added to the solution. Next you will add the output from the Windows service project, MyNewService.exe, to the setup.

To add MyNewService.exe to the setup project

1. In Solution Explorer, right-click MyServiceSetup, point to Add, then choose Project Output. The Add Project Output Group dialog box appears.
2. MyNewService is selected in the Project box.
3. From the list box, select Primary Output, and click OK.

   A project item for the primary output of MyNewService is added to the setup project. Now add a custom action to install the MyNewService.exe file.

To add a custom action to the setup project

1. In Solution Explorer, right-click the setup project, point to View, then choose Custom Actions. The Custom Actions editor appears.
2. In the Custom Actions editor, right-click the Custom Actions node and choose Add Custom Action. The Select Item in Project dialog box appears.
3. Double-click the application folder in the list box to open it, select primary output from MyNewService (Active), and click OK. The primary output is added to all four nodes of the custom actions — Install, Commit, Rollback, and Uninstall.
4. Build the setup project.

To install the Windows Service

Browse to the directory where the setup project was saved, and run the .msi file to install MyNewService.exe.

To start and stop your service

1. Open the Services Control Manager by doing one of the following:
   • In Windows 2000 Professional, right-click My Computer on the desktop, then click Manage. In the Computer Management console, expand the Services and Applications node.

     - Or -

   • In Windows 2000 Server, click Start, point to Programs, click Administrative Tools, and then click Services.

     Note: In Windows NT version 4.0, you can open this dialog box from Control Panel.

2. You should now see MyNewService listed in the Services section of the window.
3. Select your service in the list, right-click it, and then click Start.

Right-click the service, and then click Stop.

To verify the event log output of your service

1. Open Server Explorer and access the Event Logs node. For more information, see Working with Event Logs in Server Explorer.

   Note: The Servers node of Server Explorer is not available in the Standard Edition of Visual Basic and Visual C# .NET.

   

To uninstall your service

• On the Start menu, open Control Panel and click Add/Remove Programs, and then locate your service and click Uninstall.
• You can also uninstall the program by right-clicking the program icon for the .msi file and selecting Uninstall.

NOTE: Ok, I am being lazy here. The project name in this sample code is mcWebService which is a spell mistake. I meant to put mcWinService. And now I don't want to change all the screen shots and code all over again. I hope it won't confuse you :). 

Ok, its time for one more tutorial. This times pick is Windows Services. Creating Windows Services is not a big deal using Visual C#. Just follow few simple steps and you are all set to run and test your first Windows Service.

Windows Services is new name for NT Services you used to develop in previous versions of Visual Studio. This tutorial walks you through how to create and use your Windows Services. This Service writes some text to a text file when stop and start the service. The base idea is taken from MSDN but its more elaborated. You can modify it according to your needs.

Step 1. Create Skeleton of the Service

To create a new Window Service, pick Windows Service option from your Visual C# Projects, give your service a name, and click OK.

The result look like this. The Wizard adds WebService1.cs class to your project.

Set your ServiceName to your own name so it would be easier to recognize your service during testing OR you can set this property programmatically using this line this.ServiceName = "mcWinService";

This is the name you will be looking for later :).

The default code of WebService1.cs added by the Wizard looks like here

Step 2. Add functionality to your service

As you saw WebService1.cs, there are two overridden functions OnStart and OnStop. The OnStart function executes when you start your service and the OnStop function gets execute when you stop a service. I write some text to a text file when you start and stop the service. 

Step 3: Install and Run the Service

Build of this application makes one exe, mcWinService.exe. You need to call installutil to register this service from command line. 

installutil C:\mcWebService\bin\Debug\mcWebService.exe

You use /u option to uninstall the service. 

installutil /u C:\mcWebService\bin\Debug\mcWebService.exe

Run the application

Step 4: Start and Stop the Service

You need to go to the Computer Management to Start to start and stop the service. You can use Manage menu item by right clicking on My Computer.  

Under Services and Applications, you will see the service mcWinService. Start and Stop menu item starts and stops the service.

Step 5: Test the Service

Go to your temp directory and see if text file is there with contents or not. 

That's it.

Feedback: Please post all of your feedback on C# Corner discussion forums. 

References:

• MSDN

Difference Between Synchronous and Asynchronous Communication in Network Programming

The key difference between synchronous and asynchronous communication can be explained with an example.

Consider a server application that is listening on a specific port to get data from clients. In synchronous receiving, while the server is waiting to receive data from a client, if the stream is empty then the main thread will block until the request for data is satisfied. Hence, the server cannot do anything else until it receives data from the client. If another client attempts to connect to the server at that time, the server cannot process that request because it is blocked on the first client. This behavior is not acceptable for a real-world application where we need to support multiple clients at the same time.

In asynchronous communication, while the server is listening or receiving data from a client, it can still process connection requests from other clients as well as receive data from those clients. When a server is receiving asynchronously, a separate thread (at the OS level) listens on the socket and will invoke a callback function (specified when the asynchronous listening was commenced) when a socket event occurs. This callback function in turn will respond and process that socket event. For example, if the remote program writes some data to the socket, a "read data event" (callback function we specify) is invoked which knows how to read the data from the socket at that point.

Even though this could be achieved by running multiple threads, the C# and .NET frameworks provide us with a rich set of functionalities to do asynchronous communications without introducing the complexity of threading.

Socket Class

The Socket class (System.Net.Sockets.Socket) provides a set of synchronous and asynchronous methods for synchronous or asynchronous communication. As per the .NET naming convention, all the asynchronous method names are created by prefixing the words "Begin" or "End" to the name of the synchronous methods. The methods prefixed with "Begin" and "End" represent a pair of asynchronous methods corresponding to a single synchronous method, as shown in the following table.

Connect()

BeginConnect()
EndConnect()

Receive()

BeginReceive()
EndReceive()

Example Application

The example shown in this article has two classes, one implementing the Socket Server and the other implementing the Socket Client.

Socket Server Implementation

The Socket Server application is implemented in the SocketServer class (file name SocketServer.cs). This class has a main Socket object (m_mainSocket) and an array of worker Socket objects (m_workerSocket) as members. The main Socket object does the listening for the clients. Once a client is connected, the main Socket transfers the responsibility to process the transactions related to that particular client to a worker Socket. Then, the main Socket goes back and continues listening for other clients.

BeginAccept() and BeginReceive() are the two important methods in the Socket class used by the Socket Server application.

The BeginAccept() method has the following signature:

public IAsyncResult BeginAccept( AsyncCallback callback, // (1) Function to call when a client  // is connected  object state // (2) State object to preserve socket  // info ); 

Essentially, after calling the Listen() method of the main Socket object, we call this asynchronous method and specify a call back function (1), which we designated to do the further processing related to the client connection. The state object (2) can be null in this particular instance.

Because this is an asynchronous method, it will return immediately and the server main thread is free to process other events. Behind the scenes, a separate thread will start listening on that particular socket for client connections. When a client requests a connection, the callback function we specified will be invoked.

Inside the callback function (in our example, the function is named "OnClientConnect()"), we will do further processing related to the client connection.

public void OnClientConnect(IAsyncResult asyn) { try { // Here we complete/end the BeginAccept() asynchronous call  // by calling EndAccept() - which returns the reference to  // a new Socket object  m_workerSocket[m_clientCount] = m_mainSocket.EndAccept (asyn); // Let the worker Socket do the further processing for the  // just connected client  WaitForData(m_workerSocket[m_clientCount]); // Now increment the client count  ++m_clientCount; // Display this client connection as a status message on the GUI  String str = String.Format("Client # {0} connected", m_clientCount); textBoxMsg.Text = str; // Since the main Socket is now free, it can go back and wait  // for other clients who are attempting to connect  m_mainSocket.BeginAccept(new AsyncCallback ( OnClientConnect ),null); } catch(ObjectDisposedException) { System.Diagnostics.Debugger.Log(0,"1","\n OnClientConnection: Socket has been closed\n"); } catch(SocketException se) { MessageBox.Show ( se.Message ); } } 

The first thing we do inside the "OnClientConnect()" function is to call the EndAccept() method on the m_mainSocket member object, which will return a reference to another socket object. We set this object reference to one of the members of the array of Socket object references we have (m_workerSocket) and also increment the client counter. Now, because we have a reference to a new socket object that now can do the further transaction with the client, the main Socket (m_mainSocket) is free; hence, we will call its BeginAccept() method again to start waiting for connection requests from other clients.

On the worker socket, we use a similar strategy to receive the data from the client. In place of calling BeginAccept() and EndAccept(), here we call BeginReceive() and EndReceive(). This, in a nutshell, is the Socket Server implementation. While we are sending out data to the clients, the server simply uses the specific worker socket objects to send data to each client.

Socket Client Implementation

(Full Size Image)

The Socket Client application is implemented in the SocketClient class (file name SocketClient.cs). Compared to the server where we have a main Socket and an array of worker Sockets, here we only have a single Socket object (m_clientSocket).

The two important methods in Socket class used by the Socket Client application are the Connect() and BeginReceive() method. Connect() is a synchronous method and is called to connect to a server that is listening for client connections. Because this call will succeed/fail immediately, depending on whether there is an active server listening or not at the specified IP and Port number, a synchronous method is okay for this purpose.

Once a connection is established, we call the BeginReceive() asynchronous function to wait for any socket write activity by the server. Here, if we call a synchronous method, the main thread on the client application will block and we will not be able to send any data to the server while the client is waiting for data from the server.

When there is any write activity on the socket from the server end, the internal thread started by BeginReceive() will invoke the callback function ("OnDataReceived()" in our case), which will take care of the further processing of the data written by the server.

When sending the data to the server, we just call the Send() method on the m_clientSocket object, which will synchronously write the data to the socket.

That is all there is for asynchronous socket communication using multiple clients.

Limitations/Possible Improvements

• Up to 10 simultaneous clients are supported. You can easily modify and support unlimited number of clients by using a HashTable instead of an array.
• For simplicity, when the server sends out a message, it is broadcast to all the connected clients. This could easily be modified to send messages to specific clients by using the Socket object pertaining to that particular client.
• When a client is disconnected, proper action is not taken; the client count is not decremented. The correct way would be to reuse or release resources for other client connections.

Downloads

A QueryResults object that contains up to three result sets. When no user-defined data types, defaults, or rules are contained in the dependency tree, a single result set is returned, defined by these columns.

When the dependency tree contains defaults, rules, or user-defined data types, one or two additional result sets are returned by the EnumDependencies method. When rules or defaults are contained, a result set is returned, defined by these columns.

When user-defined data types are contained in the dependency tree, a result set that enumerates the data types is returned. The user-defined data type result set is defined by these columns.

소개

COM+ 코드를 "원시" Visual C++ 또는 Visual Basic 6에서 관리되는 .NET Enterprise Services 구성 요소로 이동할 것을 고려 중인 개발자는 다음과 같은 고민 사항이 있을 수 있습니다.

• 왜 관리되는 코드로 전환해야 하는가?
• 코드를 얼마나 변경해야 하는가?
• Enterprise Services 구성 요소는 어떻게 수행되는가?
• COM+ 및 .NET Enterprise Services가 제시하는 미래는 어떠한가?

이 문서에서는 특히 성능에 대한 질문을 위주로 위 주제를 다룰 것입니다. 이러한 주제에 대한 자세한 내용은 부록 4: 참고 자료에 있는 리소스를 참조하십시오.

이 문서는 COM+ 구성 요소를 개발하고 코드를 .NET Enterprise Services로 마이그레이션할 것을 고려 중인 개발자와 설계자를 대상으로 합니다.

관리되는 코드로 마이그레이션해야 하는 이유

개발자가 .NET에서 코드를 개발해야 하는 이유는 여러 가지입니다. 다음은 코드 개발의 몇 가지 이점입니다.

• 향상된 개발자 생산성: 개발자들은 종종 .NET을 사용하여 개발할 때 작성해야 하는 "통로 코드"가 훨씬 적기 때문에 응용 프로그램 논리를 작성하는 데 더 많은 신경을 쓸 수 있습니다. 또한 대부분의 개발자는 .NET에서 제공하는 명확하고 일관되게 구성된 풍부한 리소스 라이브러리 덕분에 다른 기술과 비교하여 훨씬 빨리 배울 수 있습니다.
• 향상된 코드 안정성 및 보안: 개발자는 원시 코드보다는 .NET을 사용할 때 안정적이고 보안된 코드를 더욱 쉽게 작성할 수 있습니다. 그 이유는 코드 액세스 보안 및 CLR(공용 언어 런타임) 같은 기능 때문입니다. 이러한 기능은 NET 코드가 다른 실행 중인 코드에 의도하지 않은 영향을 미치는 것을 방지하고 해커가 .NET 코드를 사용하여 환경을 방해하거나 제어할 수 있는 기회를 줄이는 데 도움이 됩니다.
• 향상된 성능 및 확장성: 개발자는 .NET으로 마이그레이션할 때 코드의 성능과 확장성이 향상되는 것을 알 수 있습니다. 모든 .NET 언어가 다중 스레딩 같은 기능을 지원하고 활용하기 때문입니다.
• XCOPY 배포: 대부분의 .NET 응용 프로그램에서는 필요한 파일을 하드 드라이브의 폴더로 복사하고 공유 구성 요소를 운영 체제에 선택적으로 등록하기만 하면 배포가 이루어집니다. 이는 다른 응용 프로그램에서 일반적으로 사용하는 것보다 훨씬 명쾌한 배포 전략입니다.

개발자가 .NET으로 마이그레이션하기를 원하는 10가지 이유에 대해서는 Top 10 Reasons for Developers to Use the .NET Framework 1.1 을 참조하십시오.

.NET은 시스템 관리자에게도 이점을 제공합니다. 관리자가 .NET으로 이동하기를 원하는 10가지 이유가 기록된 목록을 보려면 Top 10 Reasons for Systems Administrators to Use the .NET Framework 1.1 을 참조하십시오.

일반 C++ 코드를 관리되는 C++로 마이그레이션하는 방법에 대한 소개는 Managed Extensions for C++ Migration Guide의 Introduction to Wrapping C++ Classes 를 참조하십시오.

코드 변경 정도 지정

대부분의 경우 COM+ 코드를 .NET Enterprise Services에 연결하려면 COM+ 구성 요소가 어떠한 언어로 개발되었는지를 비롯한 다수의 요인에 따라 몇 가지 수동 작업이 필요합니다. 예를 들어, Visual Basic 6 개발자는 앞으로 나올 Visual Studio 2005의 도구에서 서브루틴 및 함수의 본문을 수정하지 않고도 클래스 정의 및 메서드 서명을 변환할 수 있는 몇 가지 지원을 받게 됩니다(다른 변환된 메서드에 대한 호출은 제외).

C++ 개발자는 COM+ 코드에서 .NET 코드로 변환하는 작업을 대부분 수동으로 수행해야 하지만, 대부분의 통로가 ATL(Active Template Library) 같은 클래스 라이브러리 대신 CLR에 구현되기 때문에 변환된 코드가 좀 더 간결해지는 것을 확인할 수 있습니다. C++ 개발자는 응용 프로그램을 연결할 언어를 선택할 수도 있습니다. 예를 들어, 기존 코드 기반을 최대한 활용하기 위해 관리되는 C++를 선택하거나, 더욱 간결한 코드를 위해 C#을 선택할 수 있습니다.

.NET Enterprise Services에 COM+ 구성 요소 연결

기존 COM+ 코드를 Visual Basic 6 및 Visual C++ 같은 원시 프로그래밍 언어와 도구로부터 마이그레이션하는 개발자는 .NET 코드로 완벽하게 변환하기 위해 몇 가지 기존 코드를 수정해야 합니다. 여기에 동반되는 작업 양은 사용할 수 있는 기존 코드 기반 및 도구에 따라 다릅니다. 다음 표에는 코드를 .NET으로 마이그레이션할 때 고려할 옵션이 요약되어 있습니다.

.NET 특성

COM+ 구성 요소를 설치한 후에는 구성 요소 서비스 스냅인 도구를 사용하여 수동으로 구성하거나 스크립트 또는 코드를 통해 구성해야 합니다.

예를 들어, 구성 요소에 트랜잭션 지원이 필요하다고 표시하고 각 구성 요소의 AddSale() 메서드가 오류 없이 완료될 경우 트랜잭션을 자동으로 커밋하도록 지정하는 상황을 가정합니다. 그러기 위해서는 구성 요소 및 필요한 메서드의 속성을 COM+ 구성 요소 서비스 관리 콘솔에서 수동으로 구성해야 합니다.

1. 구성 요소 서비스 관리 콘솔을 열고 올바른 응용 프로그램 및 구성 요소를 탐색합니다.

   

2. 이 구성 요소의 속성을 열고 트랜잭션 탭을 클릭한 다음 필수를 클릭합니다.

   

3. 확인을 클릭하고 구성 요소 탐색기를 통해 ATLPerfTests 개체의 AddSale() 메서드를 찾습니다.

   

4. AddSale() 메서드를 마우스 오른쪽 단추로 클릭하고 메서드의 속성을 연 다음 이 메서드가 반환하면 자동으로 이 개체 비활성화 확인란을 선택합니다.

   

관리자는 일반적으로 보안 및 ID 설정 같은 배포 지향 설정이나 역할 구성원 및 재활용 같은 런타임 지향 설정을 구성합니다. 개발자는 트랜잭션 지원과 같은 구성 요소의 개발 지향 기능을 구성합니다. 그러나 COM+에서는 개발자가 코드 내에서 구성 요소의 구성 방법을 지정하기가 어렵습니다. Visual Basic 개발자는 구성 요소에 필요한 트랜잭션 지원을 어느 정도 지정할 수 있지만 C++ 개발자는 그렇지 못합니다. COM+ 구성 요소를 안정적이면서 반복적으로 설치하기 위해서는 스크립트, 설치 관리자 응용 프로그램 또는 설치 지침을 작성해야 합니다.

.NET은 개발자가 구성 요소의 코드 내에서 구성 요소에 필요한 서비스와 해당 서비스의 구성 방법을 지정할 수 있도록 함으로써 구성 요소 구성을 단순화합니다. 구성 요소가 설치되면 플랫폼에서 구성 설정을 자동으로 구성하지만, 이러한 구성 설정은 설치 후에 변경할 수 있습니다.

COM+에서는 설치 후에 구성 설정을 변경할 수 있기 때문에 이러한 속성을 다수 변경할 때는 매우 주의를 기울여야 합니다. 예를 들어, 보안 설정을 변경하면 개체를 인스턴스화하고 개체의 메서드를 호출할 수 있는지의 권한 지정에 영향을 미칠 수 있습니다. 반면에 트랜잭션 지원을 제거하면 구성 요소가 안정적이지 못하고 예측 불가능해질 수 있으며 구성 요소의 데이터가 손실되거나 손상될 수도 있습니다.

개발자는 특성(C# 및 C++에서는 [attribute]와 같이 대괄호 안에 표시되고, Visual Basic .NET에서는 <attribute>와 같이 꺾쇠괄호 안에 표시됨)을 사용하여 어셈블리, 응용 프로그램, 구성 요소 또는 메서드의 요소를 구성합니다. 예를 들어, 아래 코드에서는 SimpleTest 구성 요소에 트랜잭션이 필요하며, AddSale() 메서드가 오류 없이 완료될 경우 트랜잭션이 자동으로 완료된다는 것을 보여줍니다.

C#

   [Transaction(TransactionOption.RequiresNew)]   public class SimpleTest: ServicedComponent   {      ...      [AutoComplete]public void AddSale(int orderNumber, int storeID, int titleID, int qty)      {         ...      }      ...   }

Visual Basic .NET

<Transaction(TransactionOption.RequiresNew)> _Public Class VBTestObject : Inherits ServicedComponent      ...<AutoComplete> _Public Function Sum(ByVal number1 As Integer, ByVal number2 As Integer) As Integer         ...      End Function      ...   End Class

다음 표에는 Enterprise Services 구성 요소에 적용할 수 있는 주로 사용되는 특성이 들어 있고, 설치 후에 특성을 안전하게 변경할 수 있는지 여부가 표시되어 있습니다.

특성	범위	기본 소유자	실행 중에 안전하게 수정 가능한지의 여부
ApplicationAccessControl	어셈블리	개발자	아니요. 개발자가 응용 프로그램의 보안 방법에 대한 하드 종속성 또는 묵시적 종속성을 사용하여 코드를 작성했을 수 있습니다. 액세스 제어를 낮추면 시스템 보안이 손상될 수 있습니다.
ApplicationActivation	어셈블리	관리자	예. 그러나 주의해야 합니다. 라이브러리 또는 서비스로 변경하거나 이로부터 변경하면 성능에 영향을 미칠 수 있으며 대기 중인 구성 요소가 손상될 수 있습니다.
ApplicationID	어셈블리	개발자	예. 그러나 주의해야 합니다. 이 특성을 변경하면 하드 코딩된 구성 요소 등록 도구에 영향을 미칠 수 있습니다.
ApplicationName	어셈블리	개발자	예. 그러나 주의해야 합니다. 이 특성을 변경하면 하드 코딩된 구성 요소 등록 도구에 영향을 미칠 수 있습니다.
ApplicationQueuing	어셈블리	개발자	아니요.
AutoComplete	메서드	개발자	아니요. 아래의 "Transaction"을 참조하십시오.
ComponentAccessControl	클래스	개발자	아니요. 개발자는 구성 요소의 보안 방법에 대한 하드 종속성 또는 묵시적 종속성을 사용하여 코드를 작성했을 수 있습니다. 액세스 제어를 낮추면 시스템 보안이 손상될 수 있습니다.
ConstructionEnabled	클래스	관리자	예. 생성자 문자열을 변경할 수는 있지만, 설정/해제 상태를 전환하지는 마십시오.
Description	어셈블리 클래스 메서드 인터페이스	관리자	예.
EventTrackingEnabled	클래스	관리자	예.
InterfaceQueuing	클래스 인터페이스	개발자	아니요.
JustInTimeActivation	클래스	개발자	아니요.
MustRunInClientContext	클래스	개발자	아니요. 구성 요소가 클라이언트의 컨텍스트와 호환되지 않을 수도 있습니다.
ObjectPooling	클래스	개발자	예. 풀 설정은 변경할 수 있습니다. 구성 요소가 손상될 수 있기 때문에 개체 풀링 설정/해제 상태를 전환하지는 마십시오.
PrivateComponent	클래스	개발자	아니요. 이 구성 요소를 공개적으로 호출할 수 없도록 개발자가 특별히 지정한 것입니다. 구성 요소가 알 수 없는 사용 패턴을 지원하는지에 대한 테스트를 받지 않았을 수도 있습니다. 공개되는 경우 심각한 보안 위협을 초래할 수 있습니다.
SecurityRole - 역할 이름	어셈블리 클래스 인터페이스	개발자	아니요. 역할을 제거하지 마십시오. 개발자가 지정된 역할에 대한 명시적 종속성 또는 역할 존재에 대한 묵시적 예외를 사용하여 코드를 작성했을 수 있습니다.
SecurityRole - 역할 구성원	어셈블리 클래스 인터페이스	관리자	예. 그러나 주의해야 합니다. 액세스 제어를 너무 광범위하게 공개하면 시스템의 보안이 손상되고, 너무 제한되게 공개하면 액세스가 과도하게 제한될 수 있습니다.
Synchronization	클래스	개발자	아니요.
Transaction	클래스	개발자	아니요. 구성 요소의 트랜잭션 지원을 수정하면 시스템의 안정성과 무결성이 손상될 수 있습니다.

위 표는 구성 요소 개발자가 기본적으로 소유하는 구성 요소와 관리자가 기본적으로 소유하는 구성 요소도 보여 줍니다. 코드에 미치는 영향을 자세히 알고 있는 경우가 아니라면 개발자의 설정을 변경하지 않는 것이 좋습니다. 개발자가 지정한 보안 관련 특성을 관리자가 변경할 수는 있지만, 이 경우에는 구성 요소 또는 응용 프로그램에 대한 액세스를 충분히 제한하되 너무 과도하게 제한하지는 않도록 주의를 기울여 보안을 구성해야 합니다.

특성을 통해 개발자는 자신의 구성 요소에 대한 구성 요구 사항을 간단하고 효율적으로 지정하면서 설치 후에 관리자가 구성 설정을 변경할 수 있도록 합니다. Enterprise Services가 제공하는 특성에 대한 자세한 내용은 .NET Framework Class Library 를 참조하십시오.

.NET Enterprise Services와 COM+ 성능 비교

Enterprise Services의 성능을 COM+와 비교하여 측정하기 위해 다음 언어로 구성 요소를 만들었습니다.

• Visual C++ .NET 및 ATL COM+
• Visual Basic 6 COM+
• C# 및 .NET Framework 1.1 Enterprise Services
• Visual Basic .NET 및 .NET Framework 1.1 Enterprise Services

각 구성 요소에는 두 개의 공용 메서드가 포함되어 있습니다.

• Sum(): 이 간단한 메서드는 두 숫자를 합해 디스크 또는 데이터베이스 액세스 작업을 수행하지 않는 간단한 작업을 시뮬레이트합니다.
• AddSale(): 이 일반적인 메서드는 트랜잭션되며, 테이블에 레코드를 삽입하고 반환 전에 트랜잭션을 완료하는 개인 메서드인 InsertSale()을 호출합니다. 이 메서드는 일반적인 비즈니스 응용 프로그램 작업을 수행하는 "실제" 메서드의 성능 특징을 보여 줍니다.

그 다음에는 각 구성 요소에 대해 다음 테스트를 수행한 테스트 프로그램을 만들었습니다.

• 반복적인 만들기/호출/릴리스: 이 테스트는 개체를 만들고 호출하고 릴리스하는 과정을 반복적으로 수행합니다.
• 만들기/반복 호출/릴리스: 이 테스트는 개체를 인스턴스화하여 수천 번 호출한 다음 마지막에 개체를 릴리스합니다.

테스트 프로그램에서는 각 구성 요소에 대해 두 가지 테스트를 모두 실행했으며 결과를 쉼표로 분리된 파일에 작성하는 고해상도 타이머를 사용하여 각 테스트를 수행하는 데 걸린 시간을 측정했습니다. 이 파일의 결과를 Microsoft Excel로 가져와서 분석했습니다. 각 구성 요소에 대한 코드 목록은 부록 5: 성능 테스트 소스 코드를 참조하십시오.

테스트는 다음 표에 표시된 구성으로 설정된 컴퓨터에서 실행되었습니다.

다른 하드웨어에서 테스트 응용 프로그램을 실행할 때 나타나는 특정 결과는 아래에 보고된 결과는 물론, 서로 간에도 다를 수 있습니다. 그러나 각 결과는 여기에 소개된 결과와 비례해야 합니다.

테스트 결과 및 분석

다음 절에서는 이전에 논의한 코드에 대해 실행한 성능 테스트의 결과를 분석합니다. 이 결과는 위에 나열된 하드웨어와 소프트웨어에서 테스트를 실행하여 얻은 것입니다. 모든 결과의 목록은 부록 6: 테스트 결과에 포함되어 있습니다.

결과를 보여 주는 다음 차트에서 차트 막대 길이가 길거나 숫자가 클수록 성능이 뛰어난 것입니다.

개체 활성화 및 삭제 성능

먼저 C++ 및 Visual Basic 6을 사용하여 개발한 원시 COM+ 구성 요소의 성능을 통해 COM+ 인프라가 어떻게 수행되는지를 살펴보겠습니다. 아래 차트는 개체 만들기, 간단한 메서드 호출 및 개체 릴리스를 반복적으로 수행함으로써 얻은 초당 호출 수를 보여 줍니다.

MTS(Microsoft Transaction Server) 1.0의 원래 디자이너는 이와 비슷한 데이터를 보고서 호출을 배달하는 데 필요한 인프라, 즉 프록시, DCOM(또는 프로세스간) 채널, 스텁 및 컨텍스트를 설정함으로써 프로세스 간 및 컴퓨터 간 활성화 시간에 큰 영향을 미칠 수 있다는 것을 깨달았습니다. 이 점이 다음을 수행하는 JIT(Just In Time) 활성화를 디자인하게 된 기본적인 동기였습니다.

• 서버 구성 요소가 반환 이전에 SetComplete() 또는 SetAbort()를 호출하여 자체 수명 주기를 제어할 수 있도록 합니다.
• 여러 메서드 호출을 사용하여 DCOM 통로를 설정하는 부담을 줄입니다.

다음 차트는 JIT 활성화를 활용하는 수정된 테스트를 단일 개체를 만들고 두 숫자를 합하는 간단한 메서드를 반복적으로 호출한 다음 마지막에 개체를 릴리스하는 방법으로 실행할 경우 발생하는 상황을 보여 줍니다.

이 결과는 JIT 활성화를 사용할 때 초당 호출 수 면에서 성능이 크게 향상되는 것을 보여 줍니다. JIT 활성화 및 Visual Basic 6을 사용하면 JIT 활성화를 사용하지 않는 C++보다 거의 33배 빠른 결과를 얻을 수 있습니다. JIT가 활성화된 Visual Basic 6에서는 초당 호출 수가 약 8600인 반면 JIT가 활성화되지 않은 Visual C++에서는 초당 호출 수가 약 261입니다.

작업을 수행하는 데 필요한 통로를 설정한 이후 컴퓨터 간 호출을 수행하면 네트워크가 성능에 큰 영향을 미치게 됩니다. 이 경우 Visual Basic 6 및 C++는 성능이 거의 비슷하지만, 그래도 Visual Basic 6가 C++보다 88% 빨리 수행됩니다.

Enterprise Services에서는 필요한 통로를 설정하는 추가 작업이 수행됩니다. 특히 개체를 생성하고 릴리스하기 위한 추가 호출이 필요합니다. 따라서 개체에서 아무런 작업을 수행하지 않고 단순히 개체를 만들었다 제거하는 경우를 비교할 때 이러한 추가 왕복 부담이 성능 비교에 큰 영향을 미치게 됩니다. Visual Studio 2005에서는 Enterprise Services가 향상되어 이러한 활성화 왕복 중 하나가 제거되었기 때문에 "활성화/단일 호출/릴리스" 패턴을 사용할 때 .NET Framework 1.1과 비교하여 성능이 20-30% 향상됩니다. 그러나 가능하면 이러한 패턴은 사용하지 않는 것이 좋습니다.

JIT 활성화를 사용할 때 C++ 및 Visual Basic 6의 성능이 비슷하다는 것을 고려하면 C# 및 Visual Basic .NET을 사용하는 Enterprise Services도 대략 같은 성능을 보일 것으로 예상할 수 있습니다. 아래 그림은 간단한 메서드를 호출하는 위 테스트를 실행한 결과를 보여 줍니다.

이 데이터는 단순히 두 정수를 합하고, 개체의 컨텍스트에 SetComplete()를 호출하고, 결과를 반환하는 간단한 메서드에 대해 수행한 초당 호출 수를 보여 줍니다. 개체를 활성화하고 릴리스하는 부담은 거의 사라졌지만 버퍼를 마샬링하고 호출 스택으로 변환하는 등의 작업으로 인해 호출을 수행하는 부담은 아직 남아 있습니다.

이처럼 매우 간단한 메서드에서도 프로세스 간 호출의 경우 Enterprise Services는 Visual Basic 6과 성능이 거의 비슷합니다. 컴퓨터간에 호출할 경우에는 모든 언어의 성능이 거의 비슷합니다.

그러나 일반적인 비즈니스 응용 프로그램은 메서드에서 이보다 더 복잡한 작업을 수행합니다. 다음 차트는 일반적인 메서드를 호출하여 분산 트랜잭션 내에서 데이터베이스 연결을 열고 간단한 SQL 문을 실행하는 동일한 응용 프로그램을 네 가지 언어로 작성했을 때 각각의 상대적인 성능을 보여 줍니다.

앞의 결과는 메서드 내에서 많은 작업을 수행할 경우 모든 언어의 결과가 실험 오차 범위 내에서 동등하다는 것을 보여 줍니다. ADO를 사용하는 C++ 및 Visual Basic 6을 통해 작성한 COM+ 원시 응용 프로그램은 Enterprise Services를 사용하는 C# 또는 Visual Basic .NET 응용 프로그램과 동일한 속도로 수행됩니다. 프로세스 간 작업을 실행하거나 컴퓨터 간 작업을 실행하는 경우 성능 면에서는 거의 차이가 없습니다.

결과 요약

위 결과는 구성 요소를 최대한 효율적으로 수행하는 데 있어서 JIT 활성화 및 "만들기/반복 호출/릴리스" 패턴이 매우 중요하다는 것을 보여 줍니다.

결론

코드를 .NET으로 마이그레이션하는 것이 유리한 몇 가지 주요 이유를 설명했습니다. 다른 활성화 및 호출 패턴에 적용될 때의 원시 COM+ 및 .NET Enterprise Services 구성 요소 성능에 대해서도 논의했습니다. 또한 지침을 따라가면서 .NET Enterprise Services 구성 요소가 C++ COM+ 구성 요소만큼 빨리 실행된다는 것을 보여 주었습니다. 부록 1: 성능 권장 사항에는 고성능 .NET Enterprise Service 구성 요소를 만드는 데 도움이 되는 주요 권장 사항이 나와 있습니다.

여기에 설명된 기술을 일관되게 적용하면 기존 COM+ 코드를 .NET Enterprise Service 구성 요소로 바로 변환하고 아무런 성능 저하 없이 .NET Framework의 사용성, 보안 및 개발자 생산성 등의 이점을 누릴 수 있습니다.

지금 COM+ 구성 요소를 Enterprise Services 구성 요소로 변환해 놓으면 나중에 코드를 "Indigo"로 더욱 쉽게 마이그레이션할 수 있다는 점도 중요합니다. 부록 2: "Indigo" 및 .NET의 동향에서는 이 주제에 대해 간략히 논의합니다.

부록 1: 성능 권장 사항

다음 절에서는 높은 수준의 성능을 제공하는 빠른 COM+ 및 Enterprise Services 구성 요소를 만드는 방법에 대한 팁과 안내를 제공합니다. 대부분의 제안은 .NET Enterprise Services 구성 요소와 원시 COM+ 구성 요소에 동일하게 적용됩니다.

해당하는 경우 개체 풀링 및 JIT 활성화 사용

위의 테스트 결과가 보여주듯이 메서드 호출이 구성 요소 활성화보다 빠르며 관리되지 않는 구성 요소의 활성화가 Enterprise Services 구성 요소의 활성화보다 빠릅니다. 따라서 구성 요소 기반 응용 프로그램의 속도를 최대한 높이려면 코드에서 구성 요소 활성화 및 삭제의 수를 최소화하는 것이 중요합니다.

COM+에서는 개체 활성화를 최소화할 수 있는 두 가지 서비스를 제공합니다.

1. 첫 번째는 앞에서 설명했듯이 호출자가 개체에 대한 활성 참조를 보관하고 있는 동안 해당 개체를 원활하게 비활성화할 수 있는 COM+ 서비스인 JIT(Just-in-time) 활성화입니다. 클라이언트가 개체에 메서드를 호출하기만 하면 COM+가 개체의 할당을 동적으로 관리하여 요청을 처리합니다.
2. 두 번째는 해당 형식의 구성 요소 인스턴스를 요청하는 클라이언트가 바로 사용할 수 있도록 개체를 풀에서 활성 상태로 유지하는 개체 풀링입니다. COM+는 풀을 자동으로 관리하며, 개체 활성화 정보를 처리하고 사용자가 지정한 기준(예: 풀 크기)에 따라 다시 사용합니다.

풀링된 구성 요소 및 JIT 활성화된 구성 요소에 대한 참조를 보관하고 다시 사용함으로써 구성 요소 활성화 및 삭제를 최소화하고 높은 수준의 성능을 얻을 수 있습니다.

COM+ JIT 활성화 및 개체 풀링에 대한 자세한 내용은 Platform SDK: COM+ (Component Services) 설명서 를 참조하십시오.

왕복 회피

COM+ 구성 요소의 성능을 최적화하려면 호출자와 구성 요소 사이에 수행되는 프로세스 간 또는 컴퓨터 간 호출의 수를 최소화하는 것이 중요합니다. COM+ 구성 요소에서 만들어진 모든 메서드는 프로세스 간 호출 전환은 물론 컴퓨터 간 호출 전환도 초래하며, 매번 전환할 때마다 시간이 걸립니다. 따라서 COM+ 개체에서 만들어지는 메서드 호출을 최소한으로 유지하는 것이 필수적입니다. 그러기 위해 단일 호출에서 최대한 많은 작업을 수행하는 메서드를 사용하여 COM+ 구성 요소를 디자인하는 것도 좋은 방법입니다. 단, 이 경우에는 순수 아키텍처에서 변형된 구성 요소도 디자인해야 합니다.

COM+ 서비스 사용 최적화

COM+가 중요한 서비스를 다수 제공하기는 하지만 이러한 서비스를 현명하게 사용하는 것이 중요합니다. COM+가 구성 요소에 필요한 서비스를 제공하는 경우에는 대개 이 서비스가 가장 높은 성능을 제공하므로 반드시 사용하도록 하십시오. 그러나 서비스가 필요하지 않은 경우에는 구성 요소가 불필요한 작업을 수행하여 실행 속도도 느려질 수 있으므로 해당 서비스를 사용할 필요가 없습니다.

COM 마샬링 가능 매개 변수 사용

호출자가 데이터를 전달할 때 사용하는 매개 변수를 Enterprise Services 구성 요소의 메서드가 받아들이는 경우 다음과 같이 COM과 .NET 사이에 쉽게 마샬링할 수 있는 형식을 사용할 것을 매우 강력히 제안합니다.

• Boolean
• Byte, SByte
• Char
• DateTime
• Decimal
• Single, Double
• Guid
• Int16, UInt16, Int32, UInt32, Int64, UInt64
• IntPtr, UIntPtr
• String

이러한 형식만 사용하고 다른 복잡한 형식(예: 구조 또는 배열)은 전달하지 않으면 .NET serializer가 호출 처리 스택을 최적화하고 호출을 유선(RPC의 경우) 또는 가상 유선(LRPC의 경우)에 일렬로 직렬화할 수 있습니다. 그러면 호출이 더욱 빨리 실행됩니다. 그러나 메서드에 복잡한 형식이 필요한 경우에는 코드가 일반 DCOM 호출 스택을 통해 호출되므로 추가 처리 과정이 발생합니다.

파이널라이저 사용하지 않기

Enterprise Services 구성 요소에서 파이널라이저(C# 및 C++의 ~Classname() 소멸자)를 구현하지 마십시오. 파이널라이제이션은 가비지 수집기의 단일 스레드 작업입니다. Enterprise 구성 요소를 파이널라이제이션할 경우 완료되는 데 상당한 시간이 걸리므로 가비지 수집기 성능이 저하됩니다. 가비지 수집기 엔진이 실행 중인 동안에는 응용 프로그램에서 다른 작업을 수행할 수 없으므로 가비지 수집기가 완료되는 데 오랜 시간이 걸리면 전체 응용 프로그램의 성능이 저하됩니다.

대신 개체에서 Dispose(bool)을 재정의하고 Dispose(true)가 호출될 때 파이널라이제이션 형식 작업을 수행하는 것을 고려해 보십시오. 또한 이러한 종료 코드를 최대한 정돈되고, 안전하고, 간단하게 유지하도록 하십시오.

단일 스레드 COM+ 구성 요소 만들지 않기

여러 스레드의 동시 액세스를 지원하지 않는 개체는 STA(단일 스레드 아파트) 기능을 지원하는 것으로 표시되어 있습니다. 여러 스레드가 같은 인스턴스에 동시 액세스할 수 있도록 지원하는 구성 요소는 MTA(다중 스레드 아파트) 인식으로 표시되어 있습니다.

.NET Enterprise Services 구성 요소는 항상 STA 및 MTA를 모두 지원하는 것으로 표시되어 있기 때문에 더 이상 이 논의에 포함시키지 않겠습니다.

모든 Visual Basic 6 COM+ 구성 요소는 STA입니다. C++ COM+ 개발자는 구성 요소를 STA, MTA 또는 둘 다로 표시할 수 있습니다.

STA COM+ 구성 요소의 잠재적인 문제는 개체가 단일 스레드에서만 실행될 수 있으므로 해당 스레드가 개체의 메서드를 실행하는 유일한 스레드라는 것입니다. 이 직렬화를 통해 개발자는 STA 구성 요소를 더욱 쉽게 작성할 수 있지만, 도메인 간 마샬링이 종종 필요해서 성능이 저하되고 STA에서 한 스레드만 계속 실행됨으로 인해 확장성이 떨어지는 것은 피할 수 없습니다.

가능하면 STA 구성 요소를 만들거나 사용하지 않을 것을 제안합니다. 특히 확장성이 중요한 곳에서는 더욱 그렇습니다. 구성 요소가 다른 COM+ 구성 요소를 호출하는 경우 특히 STA 스레딩을 피해야 합니다. 이러한 호출에는 종종 스레드 전환이 필요한데, 스레드 전환은 해당 아파트에 있는 다른 모든 COM+ 구성 요소를 차단합니다.

설상가상으로 가비지 수집기의 파이널라이저도 개체를 소유한 STA 스레드를 호출할 때 차단됩니다. 그러면 파이널라이제이션 프로세스가 단일 스레드에 직렬화되며, 이는 이전 주제에서 설명했듯이 시스템 성능을 크게 저하시킬 수 있습니다.

부록 2: "Indigo" 및 .NET의 동향

Microsoft에서 현재 개발 중인 연결된 응용 프로그램을 위한 새로운 플랫폼, 코드 이름 "Indigo"에 대해 들어 보셨을 것입니다. 그렇다면 "Indigo"란 과연 어떤 제품일까요?

"Indigo"는 서비스 지향 연결 응용 프로그램을 위한 Microsoft의 전략적 기술 플랫폼으로서, 로스앤젤레스에서 개최된 2003 PDC(Professional Developers Conference)에서 소개되었습니다.

"Indigo"는 다음 기술의 개념, 특징 및 기능을 하나의 기술 스택으로 통합합니다.

• COM
• DCOM
• COM+/Enterprise Services
• ASMX/Web Services
• .NET Remoting
• 향상된 웹 서비스
• MSMQ의 요소

"Indigo"는 서비스를 호출자에게 노출하는 데 필요한 프로토콜 및 전송으로부터 서비스의 개념을 추상화하는 다계층 플랫폼입니다. 최대한 많은 시스템과 상호 작동하기 위해 "Indigo"는 HTTP, TCP 및 IPC를 통한 고급 웹 서비스(WS-*)를 완벽하게 지원합니다. 현재 Microsoft는 코드 이름이 "Longhorn"인 Microsoft Windows의 출시 시기에 맞춰 "Indigo"를 배포할 예정입니다. Windows XP 및 Windows Server 2003에 대한 "Indigo" 지원도 함께 배포될 것입니다.

향후 "Indigo"가 발표된다고 하니 .NET Enterprise Services(또는 이 경우 ASMX 및 Remoting) 같은 기존 기술이 오늘날의 연결된 응용 프로그램을 개발하는 데 아직 유효한 것인지 걱정할 수도 있습니다. ASMX & WSE, Enterprise Services, Remoting 및 MSMQ는 오늘날의 엔터프라이즈 수준 솔루션에 가장 적합한 기술입니다. 적절하게 사용하면 "Indigo"가 릴리스되고 널리 사용될 때까지 훌륭한 응용 프로그램 개발 플랫폼을 제공해 줄 것입니다.

.NET을 사용하여 새 응용 프로그램을 작성하고 기존 응용 프로그램을 .NET으로 마이그레이션하면 향상된 보안, 안정성, 관리 및 확장성의 혜택을 누릴 수 있습니다. 또한 "Indigo"로 업그레이드하는 것이 원시 코드보다 훨씬 쉬워질 것입니다. 응용 프로그램의 "Indigo" 업그레이드를 준비하는 방법과 기존 기술을 사용하여 "Indigo"와 상호 작동하는 방법에 대한 자세한 내용은 나중에 MSDN을 참조하십시오.

"Indigo"에 대한 자세한 소개는 MSDN Magazine 기사, Code Name Indigo: A Guide to Developing and Running Connected Systems with Indigo 를 참조하십시오. 이 기사에 제공된 아키텍처 개요를 통해 이후의 Microsoft 응용 프로그램 플랫폼을 미리 살펴볼 수 있습니다.

"Indigo"에 대한 일반적인 내용은 Microsoft "Indigo" Frequently Asked Questions 를 참조하십시오.

부록 3: 분산 트랜잭션이 성능에 미치는 영향

위 테스트를 진행하면서 "COM+ 분산 트랜잭션이 이러한 구성 요소에 얼마나 많은 영향을 미칠까?"라는 질문이 생길 수도 있습니다. 이 질문의 답을 찾기 위해 각 구성 요소에 대해 COM+에서 "트랜잭션 필요" 설정을 끄고 테스트를 다시 실행해 보았습니다. 그 결과는 다음 차트에 표시되어 있습니다.

위 차트에서 볼 수 있듯이 COM+ 트랜잭션 지원이 없는 구성 요소의 성능과 트랜잭션이 켜져 있는 구성 요소의 성능은 거의 동일합니다. 이 결과는 테스트에서 COM+ 트랜잭션의 영향을 무시해도 상관없다는 것을 분명하게 보여 줍니다.

부록 4: 참고 자료

Upgrading Microsoft Visual Basic 6.0 to Microsoft Visual Basic .NET 

Visual Basic 6.0 응용 프로그램을 Visual Basic .NET으로 업그레이드하는 내용을 다루며 프로그래밍 팁, 요령 및 단계별 코드 비교 내용을 함께 제공합니다.

Programming with Managed Extensions for Microsoft Visual C++ .NET 

Visual C++ .NET 2003에 맞춰 업데이트된 이 책은 개발자를 위해 컴파일러의 새 기능과 언어에 대한 링커 확장을 심층적이고 전문적으로 다룹니다.

.NET Enterprise Services and COM+ 1.5 Architecture 

Microsoft .NET 및 Enterprise Services가 어떻게 조화를 이루는지 보여 주고 COM+/Enterprise Services 구성 요소를 빌드, 제어, 관리 및 보안하는 방법을 설명합니다.

.NET Framework Developer Center의 Performance 페이지 

고성능 코드를 작성하는 방법과 발생하는 문제를 진단하는 방법에 대해 심도있게 다루는 여러 링크와 리소스가 제공됩니다.

Performance Tips and Tricks in .NET Applications 

.NET 응용 프로그램이 제대로 수행되도록 하기 위한 팁과 힌트를 모아 놓았습니다.

Writing Faster Managed Code: Know What Things Cost 

.NET 코드에서 다양한 작업이 시스템에 어떤 부담을 주는지 자세히 분석한 내용입니다.

Garbage Collector Basics and Performance Hints 

가비지 수집기의 작동 방법, 가비지 수집기가 코드에 미치는 영향, 가비지 수집의 영향을 최소화하도록 코드를 작성하는 방법 등에 대해 설명합니다.

Performance Considerations for Run-Time Technologies in the .NET Framework 

가비지 수집 및 메모리 사용, JIT, 스레딩, .NET Remoting, 보안 등의 주제를 다룹니다.

공유하기

게시글 관리

Handling exceptions

Java나 c# 프로그래밍을 해 보신 분이라면 익숙한 방법이라 생각됩니다.

2005에서는 에러 처리 부분을 try catch 구문을 통해 처리할 수 있도록 지원합니다.

Error handling function

Catch 절 안에서 사용할 수 있는 함수들입니다.

-         ERROR_NUMBER() : 에러 번호

-         ERROR_SEVERITY() : severity (?)

-         ERROR_STATE() : 상태 번호

-         ERROR_MESSAGE() : 에서 메시지

-         XACT_STATE() : 트랜잭션의 상태 (return 1, 0, -1)

Common table expressions (CTE)

새로 추가 된 TSQL 구문 중 꽤나 강력한 구문이 아닌가 싶네요.

-         CTE is temporary named resultset. CTE는 임시로 명명된 결과셋이다.

-         CTE는 저도 많이 다뤄 보지 않아 뭐라고 딱 설명드리긴 좀 어려운 부분이 있지만, 재귀 쿼리를 가능하게 해 주는 문법입니다. 물론 재귀 쿼리 외에도 사용은 가능하지만…

-         자세한 내용은 다른 자료를 참고사시고..

Pivot

제일 처음 피봇이라는 용어를 들은게 농구에서가 아니었나 싶은데요.^^’’ 맞나??

피봇에 대한 설명은 말 보다는 테이블 예를 하나 보는게 가장 좋을 듯 싶네요.

행으로 되어 있는 레코드를 열로 바꿔 준다고 말하면 될지…

위 두 테이블을 아래와 같이 쿼리 하고 싶은 경우 사용할 수 있습니다.

SELECT * FROM properties

PIVOT( 

MAX(value)

FOR name IN ([color], [type], [amount]))

AS P WHERE id IN ( SELECT id FROM products WHERE name = ‘swish’)

Ranking and Windowing Functions

가뭄에 단비와 같은 함수들이 아닌가 싶네요… 이건 정말로 백문이 불여일견입니다.

예를 보시죠~

-         ROW_NUMBER : identity 값이라고 보시면 되고요. 일렬번호를 붙인 거죠

-         RANK : 이건 순위를 매긴 건데… 같은 등수가 있으면 다음 등수는 skip합니다.

-         DENSE_RANK: 역시 순위를 매기는데 같은 등수가 여러명 있어도 다음 등수는 그대로

-         NTILE(n) : 이건 전체를 n등분 하겠다는 거죠.

아주 유용한 함수들이 아닌가 싶습니다. 특히 ranking을 자주 매기는 사이트에선..

Windowing

이것 역시 판타스틱한 기능이 아닌가 싶네요 ^^’’

특정 컬럼을 기준으로 분할해서 랭킹을 매깁니다.

예를 들어 지역별 랭킹, 나이대별 랭킹 등…

Cross apply

Inner join과 동일

그냥 사용하면 일반적인 inner join과 동일하지만 UDF와 함께 사용할 경우 좋은 성능을 발휘한다.

Outer Apply

Left outer join과 동일

Apply와 동일하게 UDF와 함께 사용할 때 좋은 성능 발휘

아래의 세개의 구문 중 위 두개는 동일한 결과를 나타내고 맨 아래 쿼리는 보다 적은 필터링의 일반적인 쿼리이다.

SELECT * FROM invoice CORSS APPPLY greater(amount, 1500)

SELECT T1.*, T2.amount v

FROM invoice T1

             JOIN invoice T2 ON T1.amount > 1500 AND T1.id = T2.id

SELECT * FROM invoice WHERE amount>1500

이 세 개의 쿼리의 실행계획을 살펴보면 beta1에선 각각 (30%, 40%, 30%)의 성능 비교가 됐고, beta2에선 각각 (22%. 57%. 21%)의 성능 비교가 됐다. 절대적 이진 않지만 UDF와 CROSS APPLY를 사용한 경우의 성능이 T-SQL의 join을 사용할 때보다 성능이 좋았다.

이 차이는 beta3, RTM이 나오면서 바뀔 수도 있다고 하니 참고바람.

TOP Query

드디어 TOP 뒤에 변수가 들어오거나 일반적인 쿼리를 넣을 수도 있게 됐다.

DECLARE @top as int

SET @top = 10

SELECT TOP @top * FROM authors

시간이 없어 이 정도로 정리..

Large Object data types

SQL Server 2000에서는 varchar 같은 경우는 사이즈에 제한이 있었습니다. 2005에서는 그 제한이 2G로 늘어나 사실상 무제한이나 다름이 없게 되었습니다.

-         VARCHAR(MAX), NVARCHAR(MAX)

-         VARBINARY(MAX)

와 같은 것들입니다.

또한 기존의 text data type의 경우는 concatenation이나 len, substring과 같은 작업이 불가능했지만, 새로 나온 데이터 타입들은 모두 지원합니다.

Snapshot Isolation

Isolation level에 대한 사전 지식이 있어야 할거 같은데…

2005에서 새로 등장한 isolation으로, 자질구래 한 설명 보다는 MSDN의 표를 참고하는 게 나을 거 같습니다.

단.. Snapshot Isolation을 사용하려면, DATABASE의 SNAPSHOT_ISOLATION을 Allow하겠다고 속성 변경을 해 줘야 합니다.

‘ALTER DATABASE pubs SET ALLOW_SNAPSHOT_ISOLATION ON’ 입니다.

Snapshot Isolation은 Serializable 레벨과 동일하게, 각종 폐해(dirty read, Phantom read, repeatable read)를 막아주지만, 병행제어(concurrency control) 방법이 낙관적이라는 차이만 있습니다.

낙관적 병행제어, 비관적 병행제어는 데이터베이스 수업이나 교재를 참고하시면 보다 자세한 내용을 아시겠지만… 간단히 설명 드리자면 명칭 그대로입니다. 낙관적은 병행제어를 낙관적으로 하겠다. 즉, 양쪽에서 같은 데이터를 서로 update해서 발생하는 문제는 많이 없을 거라고 가정하고 충돌 검사를 하는 방식이고, 비관적 병행제어는 update로 인한 충돌이 많이 발생할 것이라는 가정하에 충돌을 검사하는 방식입니다.

Snapshot Isolation level에서는 데이터를 versioning하여 세션 별도의 데이터를 control하게 됩니다. Copy set이 생기는 거죠. 그래서 한쪽 세션에서 update완료 후 commit해도 다른 세션에선 update된 내용을 볼 수 없습니다. 만약 양쪽에서 update 후 commit을 하면 늦게 commit한 세션에서는 에러 메시지를 만나게 됩니다.

실무에 그다지 도움이 될 만한 기능은 아니라고 생각되는데 혹시 생각이 다르신 분 계시면 덧글을…

Extended triggers

이건 꽤 유용한 기능이 되지 않을까 싶네요.

기존에 DML문장에만 trigger가 걸렸었는데, 이제는 DDL 문장에도 trigger를 걸 수가 있습니다. 뿐만 아니라, 각종 system event에도 비슷한 효과를 낼 수 있습니다.

System event는 기존의 create trigger를 통해 만들 수 있는 것은 아니고, event notification이라는 걸 이용하게 됩니다.

이 정도만 알고.. 자세한 내용은 추후 BOL이나 기타 자료를 참고하시기 바랍니다.

BULK INSERT simplification

BULK INSERT 같은 경우 제가 거의 이용해 본 적이 없어, 정확히는 잘 모르겠지만…

Query문을 이용해 외부 파일의 내용을 BULK INSERT할 수 있습니다.

자세한 설명은 없어서.. 걍 예제 구문만 소개하고 이만..

BULK INSERT AdventureWorks.Sales.SalesOrderDetail

   FROM 'f:\orders\lineitem.tbl'

   WITH

      (

         FIELDTERMINATOR =' |',

         ROWTERMINATOR =' |\n'

      )