Yariv Hammer's Code Site

Deploying Your .NET Application Using Inno Setup

noreply@blogger.com (Yariv Hammer) — Thu, 04 Jan 2007 18:17:00 +0000

Introduction
I deployed my application using Inno Setup. It is a free and very intuitive installation engine.
You can download it free here.

Basically you create a script that ends with an .iss extension using the Inno-setup editor, which is much like a Notepad, but colors the script words. The syntax of the script is very much like an ini file. There is a very good help.

In this article I will demonstrate how to create a good installation to your application.

The General Section
Use the Inno Setup help to figure out what each command do. But this is what I use:

[Setup]
AppName=My Application - Proffesional Edition
AppVerName=My Application - Proffesional Edition v0.95
OutputBaseFilename=My Application - Proffesional Edition
OutputDir=.\
AppComments=The Proffesional Edition is intended for computers in off-line environment.
AppContact=My Name and Phone
AppPublisher=My Company
AppPublisherURL=www.MyCompany.com
AppVersion=0.95
VersionInfoVersion = 1.0
DefaultDirName={pf}\My Application
DisableDirPage=yes
DefaultGroupName=My Application
AllowNoIcons=no
Compression=lzma
SolidCompression=yes
AllowUNCPath=no
UserInfoPage=no
AppCopyright=Copyright © 2007 My Company.
AlwaysRestart=yes

Of course replace your name, application, and company.
Notice the AlwaysRestart flag.
The {pf} is a short for Program Files.
It will create the installation file in the same folder as the iss file (you can change that of course).

The Tasks Section

[Tasks]
Name: "desktopicon"; Description: "{cm:CreateDesktopIcon}"; GroupDescription: "{cm:AdditionalIcons}"; Flags: unchecked
Name: "quicklaunchicon"; Description: "{cm:CreateQuickLaunchIcon}"; GroupDescription: "{cm:AdditionalIcons}"; Flags: unchecked
Name: "DotNetFramework"; Description: ".NET Framework 1.1"; GroupDescription: "If .NET is NOT installed:";
Name: "MDAC"; Description: "Access, OleDB and Jet Providers"; GroupDescription: "Access, OleDB and Jet Providers";

During the installation the user will have a screen where he will be prompted to check various installation tasks. In this case he will be prompted to select a Desktop Icon, a Quick Launch Icon, a .NET Framework, and an MDAC.

You must install the .NET Framework on the client's computer, or he will not be able to run your .NET assembly. Here I show how to install .NET 1.1, but you might need to install .NET 2.0 as well. You also must install MDAC if you are using OleDb providers, Access databases and so on (In Windows XP you don't need to install this). You might decide to install those things without prompting the user (if they are already installed no harm can be done).

Of course you can add more tasks of your own.

The Dirs Section

[Dirs]
Name: "{app}\bin"
Name: "{app}\bin\DB"
Name: "{app}\bin\Config"
Name: "{app}\bin\Resources"
Name: "{app}\bin\DB\Xml"
Name: "{app}\DotNet"; Flags: deleteafterinstall; Tasks: DotNetFramework
Name: "{app}\MDAC"; Flags: deleteafterinstall; Tasks: MDAC
Name: "C:\Temp\"; Flags: uninsneveruninstall ;

Each directory will be created during the installation. {app} is a short for the installation folder, that is equivalent to te DefaultDirName attribute in the Setup section.

The Tasks flag is used to associate a line with a task. The task will be executed ONLY IF the task is selected by the user.
The deleteafterinstall flag makes the folder disappear after the installation. The user will not even be aware of this folder creation. I will this soon.

I also create the Temp folder just in case (some applications might depend on it).

The Files Section
This is probably the most important section. Here you list all the files you want to install.
Here are some examples:
First I install My application exes and dlls. After that I install the App.Config files. Then I install the Database and the Xml files. Then I install the resources. Last I install third-party dlls (simply copy the files).

[Files]
; MyApplication.exe
Source: "C:\Projects\My Application\bin\MyApplication.exe"; DestDir: "{app}\bin"; Flags: ignoreversion overwritereadonly uninsremovereadonly;Attribs: readonly;
Source: "C:\Projects\My Application\bin\MyApplication.tlb"; DestDir: "{app}\bin"; Flags: ignoreversion overwritereadonly uninsremovereadonly regtypelib;Attribs: readonly;
Source: "C:\Projects\My Application\bin\MyApplication.xml"; DestDir: "{app}\bin"; Flags: ignoreversion overwritereadonly uninsremovereadonly;Attribs: readonly;
Source: "C:\Projects\My Application\bin\configuration.tbs"; DestDir: "{app}\bin"; Flags: ignoreversion overwritereadonly uninsremovereadonly;

;Basic Software
Source: "C:\Projects\My Application\bin\Server.exe"; DestDir: "{app}\bin"; Flags: ignoreversion overwritereadonly uninsremovereadonly;Attribs: readonly;
Source: "C:\Projects\My Application\bin\BusinessObjects.dll"; DestDir: "{app}\bin"; Flags: ignoreversion overwritereadonly uninsremovereadonly;Attribs: readonly;
Source: "C:\Projects\My Application\bin\CommonControls.dll"; DestDir: "{app}\bin"; Flags: ignoreversion overwritereadonly uninsremovereadonly;Attribs: readonly;
Source: "C:\Projects\My Application\bin\Forms.dll"; DestDir: "{app}\bin"; Flags: ignoreversion overwritereadonly uninsremovereadonly;Attribs: readonly;
Source: "C:\Projects\My Application\bin\BasicForms.dll"; DestDir: "{app}\bin"; Flags: ignoreversion overwritereadonly uninsremovereadonly; Attribs: readonly;
Source: "C:\Projects\My Application\bin\Grid.dll"; DestDir: "{app}\bin"; Flags: ignoreversion overwritereadonly uninsremovereadonly; Attribs: readonly;

;Module1
Source: "C:\Projects\My Application\bin\Module1Manager.exe"; DestDir: "{app}\bin"; Flags: ignoreversion overwritereadonly uninsremovereadonly;Attribs: readonly;
Source: "C:\Projects\My Application\bin\Module1Viewer.exe"; DestDir: "{app}\bin"; Flags: ignoreversion overwritereadonly uninsremovereadonly;Attribs: readonly;

;Applications Configuration Files
Source: "C:\Projects\My Application\bin\MyApplication.exe.config"; DestDir: "{app}\bin"; Flags: ignoreversion overwritereadonly uninsremovereadonly;Attribs: readonly;
Source: "C:\Projects\My Application\bin\Module1Manager.exe.config"; DestDir: "{app}\bin"; Flags: ignoreversion overwritereadonly uninsremovereadonly;Attribs: readonly;
Source: "C:\Projects\My Application\bin\Module1Viewer.exe.config"; DestDir: "{app}\bin"; Flags: ignoreversion overwritereadonly uninsremovereadonly;Attribs: readonly;
Source: "C:\Projects\My Application\bin\Server.exe.config"; DestDir: "{app}\bin"; Flags: ignoreversion overwritereadonly uninsremovereadonly;Attribs: readonly;

;Additional files
Source: "C:\Projects\My Application\bin\DB\Database.mdb"; DestDir: "{app}\bin\DB"; Flags: ignoreversion overwritereadonly uninsremovereadonly
Source: "C:\Projects\My Application\bin\Config\ConfigurationFile.xml"; DestDir: "{app}\bin\Config"; Flags: ignoreversion overwritereadonly uninsremovereadonly;Attribs: readonly;
Source: "C:\Projects\My Application\bin\Resources\*.bmp"; DestDir: "{app}\bin\Resources"; Flags: ignoreversion overwritereadonly uninsremovereadonly;Attribs: readonly;

;Additional Dlls
Source: "C:\Projects\IOS\STU\bin\AxInterop.SHDocVw.dll"; DestDir: "{app}\bin"; Flags: ignoreversion overwritereadonly uninsremovereadonly;Attribs: readonly;
Source: "C:\Projects\IOS\STU\bin\Interop.SHDocVw.dll"; DestDir: "{app}\bin"; Flags: ignoreversion overwritereadonly uninsremovereadonly;Attribs: readonly;
Source: "C:\Projects\IOS\STU\bin\Nini.dll"; DestDir: "{app}\bin"; Flags: ignoreversion overwritereadonly uninsremovereadonly;Attribs: readonly;

In addition I need to Install several MFC dlls, because one of my apps is from MFC in VC6. In that case I add the following section:

;System Files
Source: "C:\WINNT\system32\MFC80d.dll"; DestDir: "{sys}"; Flags: allowunsafefiles
Source: "C:\WINNT\system32\msvcr80d.dll"; DestDir: "{sys}"; Flags: allowunsafefiles
Source: "C:\WINNT\system32\MFC42d.dll"; DestDir: "{sys}"; Flags: allowunsafefiles
Source: "C:\WINNT\system32\MSVCRTD.DLL"; DestDir: "{sys}"; Flags: allowunsafefiles
Source: "C:\WINNT\system32\MFCO42D.DLL"; DestDir: "{sys}"; Flags: allowunsafefiles
Source: "C:\WINNT\system32\MFCN42D.DLL"; DestDir: "{sys}"; Flags: allowunsafefiles

The {sys} folder is the System32 folder on the client's machine. It will not replace the files if newer versions exist.

Next, we need to prepare the .NET Framework and MDAC installations. We will put the files in the folder of the iss file, pack the files to the installation file. When the client will run the setup, we will unpack the installation files into the folder we marked earlier to remove after installtion. This is simply to copy the installation file. It will NOT run the setup files:

;.NET Framework
Source: "C:\Share\installs\Developer\ Installation\dotnetfx.exe"; DestDir: {app}\DotNet; Tasks: DotNetFramework; Flags: deleteafterinstall;

;MDAC
Source: "C:\Projects\IOS\STU\ Installation\MDAC_TYP2.8.EXE"; DestDir: "{app}\MDAC"; Tasks: MDAC; Flags: deleteafterinstall;

Notice the Tasks attribute - we only unpack the files if the user asked us to. The installation files will be deleted after the installation as well. You can download those executables free from the internet.

Last, note that if you need to register a COM dll, or an OCX, you should use the regserver flag.

Icons Section
This will create the relevant shortcuts and icons on the client's computer.

[Icons]
Name: "{group}\My Application - Proffesional Edition"; Filename: "{app}\bin\MyApplication .exe"; WorkingDir: "{app}\bin"
Name: "{group}\{cm:UninstallProgram,My Application - Proffesional Edition}"; Filename: "{uninstallexe}"
Name: "{userdesktop}\My Application - Proffesional Edition"; Filename: "{app}\bin\MyApplication .exe"; Tasks: desktopicon ; WorkingDir: "{app}\bin"
Name: "{userappdata}\Microsoft\Internet Explorer\Quick Launch\My Application - Proffesional Edition"; Filename: "{app}\bin\MyApplication .exe"; Tasks: quicklaunchicon ; WorkingDir: "{app}\bin"

Registry and Environment Variables
Here is an example of how to install an environment variable on the client's machine. The same way applies to all registry keys.

[Registry]
Root: HKLM ; Subkey: "SYSTEM\CurrentControlSet\Control\Session Manager\Environment"; ValueType: string; ValueName: "VARNAME"; ValueData: "VALUE"; Flags: uninsdeletevalue

Note that the running application will not be notified of the new environment variables, and will need to restart (there is a way to solve this issue).

Installing the .NET Framework, MDAC, and other installations
The Run section allows you to run additional installations. We need to run the installation of the .NET Framework, and MDAC. We use certain flags to make this a Silent Installation.
[Run]
;.NET Framework 1.1
Filename: "{app}\DotNet\dotnetfx.exe"; Parameters:"/q:a /c:""install /q""" ;StatusMsg: "Installing Microsoft .NET Framework (this may take a few minutes)"; Flags: skipifdoesntexist; Tasks: DotNetFramework; WorkingDir: {app}\DotNet; Description: Installs the DotNET Framework

;MDAC
Filename: "{app}\MDAC\MDAC_TYP2.8.exe"; Parameters:"/Q:A /C:""dasetup /Q:D /N"""; WorkingDir:"{app}\MDAC"; Flags: skipifdoesntexist; Tasks: MDAC; StatusMsg: "Installing Access, OleDb and JET Providers (MDAC) (This may take a few minutes)"; Description: Installs MDAC

Testing your install file
After the script is done, we can compile it using Inno Setup. A setup executable will be generated for us, which we should ship to the client and he should be able to install and run your application.

Great, huh? Well, imagine a client installing your application only to find out that it doesn't work because you forgot a dll? What would happen if you by mistake ruined the Client's registry, or deleted his Environment Variable? What about when uninstalling you by mistake deleted the Windows folder?

Don't send it anywhere until you test it. The best way to test it is by using a Virtual PC. Create yourself one Virtual PC of Windows 2000, and one for Windows XP. Create a backup before you play with it. Then run the installation on the Virtual PC. Don't forget to uninstall and see the results. You get several benefits by applying this method:
1. You can be 100% sure that you cannot do any damage, and that everything work.
2. If something went wrong you can fix it, delete the VPC, and try again (don't forget to backup the original VPC).

A Deployment Issue: "the application has generated an exception that could not be handled."

noreply@blogger.com (Yariv Hammer) — Thu, 04 Jan 2007 17:47:00 +0000

Introduction
I built an application on my computer using .NET Framework 1.1, and it worked. This was a complicated application with a bunch of exe and dll files, app.config files, xml files. I had a server, clients, an MS-Access mdb file. I had GUI libraries, and Data access libraries.

I supplied an installation file, that installed .NET Framework 1.1, MDAC 2.8, my application, and several MFC files. It worked on other machines as well.

Then I had an update. I created a new installation file and shiped it to another computer.
One of the .NET applications crashed, and gave me the very intimidating MessageBox: "the application has generated an exception that could not be handled. Process id=0xFFFF Thread id=0xFFFF. Press OK to terminate the application, and CANCEL to debug the application.".

Of course I had no debugger on that machine, and basically I was stuck!

First Tries
At first I thought it was a .NET Framework installation issue. So I uninstalled .NET Framework on the other computer, and re-installed it. It did not solve the issue. I checked the versions of the .NET Framework (using Administrative Tools), and it was the same as in my computer.

Second, I checked that the App.Config file existed oin the folder of installation. It was there.

Third, I installed Dependency Walker on the other computer, open my exe with it (no red signs appeared), pressed F7, but could not make sense of the output. It did not smell like a problem with dependencies or other dlls.

The Solution
I added to the application the following code (I made it start from the Main method):

-------------------------------------------------
<STAThread()> _
Public Shared Sub Main()
Dim currentDomain As AppDomain = AppDomain.CurrentDomain
AddHandler currentDomain.UnhandledException, AddressOf UnhandledExceptionOccured
Application.Run(New Form1)
End Sub

Public Shared Sub UnhandledExceptionOccured(ByVal sender As Object, ByVal e As UnhandledExceptionEventArgs)
Dim ex As Exception = CType(e.ExceptionObject, Exception)
MessageBox.Show(ex.Message & vbCrLf & ex.StackTrace)
End Sub
-------------------------------------------------

This catches any Unhandled Exceptions, and shows a message with the stack trace.

I compiled and installed this exe in the client's computer.

I was amazed: There was a bug involving DBNull in one of my dlls, a bug that I have just added to my application. I could have never guessed that the problem was in that place!

My Lesson
From now on I put this code in all my applications! When there is such a bug I must at least know what happened!

I advice you to do the same.

Creating a general delegate using Generics

noreply@blogger.com (Yariv Hammer) — Mon, 04 Sep 2006 17:26:00 +0000

Introduction
I recently worked on a heavy UI application, with a client and a server. The thing that I encountered is that I often tried to access the UI from the thread of the remoting instead of the thread of the GUI. Of course I recieved an exception for that, because you must handle all the controls and graphics from the GUI thread.

This made me program a lot of code like this:
------------------------------------------------------


if (myControl.InvokeRequired)
myControl.Invoke(new SomeDelegate(SomeUIMethod),new object[] {parameterToPass});
else
SomeUIMethod(parameterToPass);

------------------------------------------------------
Of course I had to create both the method that handles the UI, and the delegate that accept the exact same parameters as the method.

This created a very messy code. The above code appeared in many places, and I had to create many small methods to handle small operations in the UI, and a delegate fro each method.

A Solution
A very pretty solution was suggested to me by wildfrog in CodeGuru (here), and I must put it in my blog.
He suggested to use generics in order to eliminate the need to use delegates for each method.
Here is his solution:
---------------------------------------------------------
public delegate void GeneralDelegate();

public delegate void GeneralDelegate<T1>(T1 t1);
public delegate R GeneralDelegate<R, T1>(T1 t1);

public delegate R GeneralDelegate<R, T1, T2>(T1 t1, T2 t2);
---------------------------------------------------------
And so on you can continue to create overloads for the delegate. You must create different delegates if you need to use void as return value. And the compiler will shout at you if you do not declare an appropriate delegate.

In order to use this GeneralDelegate, I write for example:
--------------------------------------------------------


public char test(bool b, int i)
{
return 'c';
}

new GeneralDelegate<char, bool, int>(test);

---------------------------------------------------------

This is absolutely great, and saves me a lot of coding.
I must emphasize that I only use this when I need to invoke a small method, and I do not use this in all the places I need a delegate (in fact I try to use this as little as possible, just when I feel that putting the typed delegate seems unnecessary).

Generating a DataSet From an Xml Schema in 2005

noreply@blogger.com (Yariv Hammer) — Tue, 29 Aug 2006 19:09:00 +0000

Introduction
In Visual Studio 2003 the DataSet designer and the Xml Schema designer were the same. In order to generate a Typed DataSet from an Xml Schema, you had to right-click on the Xml Schema designer, and check the Generate DataSet option. Everytime you saved the schema, the DataSet was redrawn for you.

In Visual Studio 2005 we have two seperate designer - one for Typed DataSets and one for Xml Schemas. The option to generate a Typed DataSet from an Xml Schema disappeared from the menus.

How To Generate the DataSet
In the Xml Schema designer, right-click on the designer surface and select Properties (or press F4).
At the Property Grid find the CustomTool property and type MSDataSetGenerator.
The typed dataset will be generated for you when you save the schema. You can see the files in the Solution Explorer.

Thoughts
I have no idea why Microsoft removed the option to generate the DataSet from the menu. The new interface for it is very uncomfortable in my opinion.

Loading the Entire Database Into a DataSet, Including Relations

noreply@blogger.com (Yariv Hammer) — Mon, 28 Aug 2006 19:35:00 +0000

Introduction
Ironically, it is hard to load the entire database into a dataset. You either need to use many command objects, or TableAdapters/DataAdapters.
The ralations are even harder to get from the database. You need to manually create them on the DataSet.

In this article I give code to load the entire MS-Access database into an Untyped DataSet, with the relations. You can easily adapt this to SQL Server database. The code is in VB.NET.

The Code
----------------------------------------------


Function getDataSetAndFill(ByRef connection As OleDb.OleDbConnection, Optional ByVal isExportSchema As Boolean = True) As DataSet       
Dim myDataSet As New DataSet       
Dim myCommand As New OleDb.OleDbCommand      
 Dim myAdapter As New OleDb.OleDbDataAdapter       
myCommand.Connection = connection       
'Get Database Tables       
Dim tables As DataTable = connection.GetOleDbSchemaTable( System.Data.OleDb.OleDbSchemaGuid.Tables,   New Object() {Nothing, Nothing, Nothing, "TABLE"})       
'iterate through all tables       
Dim table As DataRow       
For Each table In tables.Rows          
 'get current table's name           
Dim tableName As String = table("TABLE_NAME")           
Dim strSQL = "SELECT * FROM " & "[" & tableName & "]"           
Dim adapter1 As New OleDb.OleDbDataAdapter(New OleDb.OleDbCommand(strSQL, connection)) 
adapter1.FillSchema(myDataSet, SchemaType.Source, tableName)
           'Fill the table in the dataset           
myCommand.CommandText = strSQL           
myAdapter.SelectCommand = myCommand           
myAdapter.Fill(myDataSet, tableName)       
Next       

'Add relationships to dataset
'First, get relationships names from database (as well as parent table and child table names)       
Dim namesQuery As String = "SELECT DISTINCT szRelationship, szReferencedObject, szObject FROM MSysRelationships"       
Dim namesCommand As New System.Data.OleDb.OleDbCommand(namesQuery, connection)       
Dim namesAdapter As New System.Data.OleDb.OleDbDataAdapter(namesCommand)       
Dim namesDataTable As New DataTable       
mesAdapter.Fill(namesDataTable)       
'Now, get MSysRelationship from database       
Dim relationsQuery As String = "SELECT * FROM MSysRelationships"      
Dim command As New System.Data.OleDb.OleDbCommand(relationsQuery, connection)       
Dim adapter As New System.Data.OleDb.OleDbDataAdapter(command)       
Dim relationsDataTable As New DataTable       
adapter.Fill(relationsDataTable)       
Dim relationsView As DataView = relationsDataTable.DefaultView       
Dim relationName As String       
Dim parentTableName As String       
Dim childTablename As String       
Dim row As DataRow       
For Each relation As DataRow In namesDataTable.Rows           
relationName = relation("szRelationship")           
parentTableName = relation("szReferencedObject")           
childTablename = relation("szObject")          
'Keep only the record of the current relationship           
relationsView.RowFilter = "szRelationship = '" & relationName & "'"           
'Declare two arrays for parent and child columns arguments           
Dim parentColumns(relationsView.Count - 1) As DataColumn           
Dim childColumns(relationsView.Count - 1) As DataColumn           
For i As Integer = 0 To relationsView.Count - 1               
parentColumns(i) = myDataSet.Tables(parentTableName). Columns(relationsView.Item(i)("szReferencedColumn"))
childColumns(i) = myDataSet.Tables(childTablename). Columns(relationsView.Item(i)("szColumn"))
Next           
Dim newRelation As New DataRelation(relationName, parentColumns, childColumns, False)           
myDataSet.Relations.Add(newRelation)       
Next       
If isExportSchema Then           
Dim schemaName = GetXmlSchemaFileName()           
If File.Exists(schemaName) Then File.SetAttributes(schemaName, FileAttributes.Normal)
myDataSet.WriteXmlSchema(schemaName)       
End If       
Return myDataSet   
End Function

------------------------------------------

Loading a class dynamically

noreply@blogger.com (Yariv Hammer) — Mon, 28 Aug 2006 18:40:00 +0000

Introduction
When you write software that can be extended, you have to allow othe rprogrammers to write their own classes, and then load those classes to your application and use them.
For example, let's assume you program a graphical tool, and you prvide square, circle and triangle shapes. You want other users to provide any other shapes, so you let them program the shapes in their own class library and then you load the shapes into your application.

Loading classes from different assemblies
The line of code needed to load a class that you don't know is:
---------------------------------------------------


object objectFromOtherDll = Activator.CreateInstance ("assemblyName", "Namespace.DllClass").Unwrap();

--------------------------------------------------
assemblyName - The name of the class library where the class is stored (without '.dll').
Namespace - The full name of the namespace.
DllClass - The name of the class you want to load.

Note - A file with the name assemblyName.dll must be placed in the same folder as the executable.
Activator is a class in the System namespace. CreateInstance has other overloads. You might want to look in http://msdn2.microsoft.com/en-us/library/system.activator.createinstance.aspx

But how can we know which assembly did the user provide, and what class name to use? As you saw those are strings that you need to put in your code, so it's definitely an issue. The best way is to place them in the App.Config file (or other configuration file). The programmer who supply the extension should put the names of the classes, with their namespaces and assembly names in the configuration file that you provide for your application. You will need to read the configuration file (should be easy with the System.Configuration namespace), and load the classes that were provided in the configuration.

Invoking a method of the unknown class
Now we have an object that we know nothing about. We want to call a method of the object. We must know the name of the method. In the example of Shape, we have the Draw method.
We can use reflection to invoke the method. First we need a using directive to the System.Reflection namespace.
Then we need to invoke the method like this:
--------------------------------------------------


objectFromOtherDll.GetType().InvokeMember("methodName", BindingFlags.DeclaredOnly BindingFlags.Public BindingFlags.NonPublic BindingFlags.Instance BindingFlags.InvokeMethod, null, objectFromOtherDll, null);

------------------------------------------------
More information about InvokeMember can be found here: http://msdn2.microsoft.com/en-us/library/de3dhzwy.aspx

objectFromOtherDll is the object we created with Activator. It appears twice in the statement (once as a parameter) so pay attention.
methodName is a string containing the name of the method to invoke.

How do we know the method name? We could use a configuration file.
How do we know that there is a method called methodName? For example, the programmer might not have implemented the "Draw" method of the Shape class. We could know that by catching exception, or by using reflection to find a method called "Draw".

Using Interfaces
A better way, in my opinion, is to use interfaces instead of reflection. The idea is that you supply a class library with all the interface that you require the programmer to supply to you. The programmer must implement the interface if he wants his object to be loaded in your framework.

For example, in a class library called Interfaces, I add an interface called IShape.
--------------------------------------------


public interface IShape
{
void Draw();
}

-------------------------------------------

The programmer need to refernce to the Interface.dll you gave him, and each Shape must implement the IShape interface:
-----------------------------------------


public class Ellipse:IShape
{
public void Draw()
{
//Do Whatever
}
}

---------------------------------------

The programmer will put in your configuration file the class Ellipse, and place his assembly in the folder of your application.

You will load his class in the following way:
---------------------------------------------------


IShape shape = Activator.CreateInstance("assemblyName", "CustomShapes.Ellipse").Unwrap() as IShape;

if (IShape == null) throw new Exception("Illegal class");

shape .Draw(); //No reflection needed

--------------------------------------------------

Summary
In this article I showed how to use Activator to load classes that you don't know about in advance.
I showed how to use reflection in order to invoke a member.
I showed how to use interfaces to help the programmer supply the right code for you.

MultiThreading Without The Thread Class

noreply@blogger.com (Yariv Hammer) — Fri, 03 Mar 2006 15:49:00 +0000


public void myMethod(object obj)
{
//Do something
}

public static void Main()
{
Timer t = new Timer(new TimerCallBack(myMethod), anyObject, 0, 1000);
Console.ReadLine();
}

---------------------------------------------
The timer can work on any method that receives an object. The second parameter will be passed to the method as a parameter (pass null if you don't need it). The Thirs argument is how much time (in milliseconds) to wait before starting the timer, and the last parameter is the period of time between to invokations.
The threads are taken out of the Thread Pool, and they run in the background.
When you are done ith the timer, Dispose it.

Using the ThreadPool
If you need to perform a lot of short tasks (a worker thread for example), and then get rid of the threads you can use the ThreadPool to improve performance. When you start your application Windows generates 25 threads for you to use (Actually sometimes, as in timers, the CLR will use threads from the pool). The number of threads in the pool cannot be configured in 2003, so be careful not to use too many threads. If you use a thread from the ThreadPool you save the time of creating and destroying the thread. You just ask for a free thread, and when you are done it goes back to the pool.

Whenever you need to call the QueueUserWorkItem static method to start a thread from the thread pool.
For example:
------------------------------------------


public void myMethod(object obj)
{
//Do something
}

public static void Main()
{
ThreadPool.QueueUserWorkItem(new WaitCallback(myMethod), anyObject);
Console.ReadLine();
}

---------------------------------------------
Like in the timer, you should pass a method that receives an object, and that object as second parameter.
For another example look at MSDN.

Those threads are intended for short actions, that run in the backgroound, with normal priority (you cannot change any of it). You might want to pass a ManualResetEvent as the parameter to the method if you want to be able to synchronize the thread.

Asynchronous Delegates
A reminder about the usage of delegates:
---------------------------------------------------


class Class1
{
public static void f1(int x)
{
for (int i=0; i<x; i++)
{
Console.WriteLine("f1: " + i);
Thread.Sleep(300);
}
}
public delegate void Fptr(int x);
static void Main(string[] args)
{
Fptr p1 = new Fptr(f1);
p1(50);
Console.WriteLine("Main End");
Console.ReadLine();
}
}

----------------------------------------------------
You call the delegate as you call a normal method in order to invoke it. This is called Syncronous Invocations.

Instead we could call the BeginInvoke method of the delegate:
---------------------------------------------------


static void Main(string[] args)
{
Fptr p1 = new Fptr(f1);
p1.BeginInvoke(50,null,null);
Console.WriteLine("Main End");
Console.ReadLine();
}

----------------------------------------------------
You will see that the Main End will ve written as the program starts, to indicate that f1 runs on a different thread. This thread is taken from the Thread Pool.

If we want to return a value from the method f1, we will need to use EndInvoke:
-------------------------------------------------------


public static int f1(int x)
{
for (int i=0; i<x; i++)
{
Console.WriteLine("f1: " + i);
Thread.Sleep(100);
}
return x;
}
public delegate int Fptr(int x);
static void Main(string[] args)
{
Fptr p1 = new Fptr(f1);
IAsyncResult ar = p1.BeginInvoke(50, null, null);
Console.WriteLine("Main Sleeping");
Thread.Sleep(1000);
int res = p1.EndInvoke(ar);
Console.WriteLine("Main End " + res);
Console.ReadLine();
}

------------------------------------------
The method f1 now returns an int. When we call BeginInvoke we are returned with an object of type IAsyncResult. We pass that object to the EndInvoke method and then we wait until the method f1 is done (If it is over when we get to the line we don't wait at all), and we receive the return value. The use of IAsyncResult is because we may start p1 many times, and the EndInvoke should know which time we want to end. The IAsyncResult uniquly identifies the invocation.
Note that EndInvoke blocked the code. A nice propery of IAsyncResult is the IsComplete property which can be called in a loop to know if the method is over (A polling approach).

Another approach might be to receive an event when the method is done. This is the best approach because the code will never be blocked.
For example:
------------------------------------------


public static void f1IsCompleted(IAsyncResult ar)
{
Console.WriteLine("F1 is done");
}
static void Main(string[] args)
{
Fptr p1 = new Fptr(f1);
p1.BeginInvoke(50, new AsyncCallback(f1IsCompleted), null);
Console.WriteLine("Main Sleeping");
Thread.Sleep(1000);
Console.WriteLine("Main End");
Console.ReadLine();
}

--------------------------------------------------------
The method f1IsCompleted receives the IAsyncResult as a parameter. It is called automatically when the f1 method is completed.

The last thing to see is how to retrieve the return value of the method f1. Here is one way to do it:
----------------------------------------------------------


public static void f1IsCompleted(IAsyncResult ar)
{
int res = ((Fptr)ar.AsyncState).EndInvoke(ar);
Console.WriteLine("F1 is done: " + res);
}
static void Main(string[] args)
{
Fptr p1 = new Fptr(f1);
p1.BeginInvoke(50, new AsyncCallback(f1IsCompleted), p1);
Console.WriteLine("Main Sleeping");
Thread.Sleep(1000);
Console.WriteLine("Main End");
Console.ReadLine();
}

-------------------------------------------------
The last parameter of BeginInvoke can be any object. This object can be retrieved as the IAsyncResult.ASyncState property in the callback method. We use this mechanism to pass the delegate, in order to call the EndInvoke after the callback is raised.
Another way to do it was to place the Fptr p1 as a member of the class, so the f1IsCompleted method can access it.

Using Threads With User Interface
Here is a rule: Never access the GUI from any thread other than the GUI thread.
Lets have an axample: We have a form with a ListBox and a Button. We write the following Click event handler for the Button:
---------------------------------------------------


private void button1_Click(object sender, EventArgs e)
{
for (int i=0; i<10000 ; i++)
listBox1.Items.Add(i);
}

-------------------------------------------------
If you run the program and press the button you will see that the form gets stuck until the ListBox is filled with numbers. You might even get a (not responding) in the title of the form.
The reason for this is that if you perform a long task in the event handlers of the form, you are performing it in the GUI thread. No Windows messages can be handled when the GUI thread is working on something else. For that reason you should only perform short taskd in event handlers. Long tasks should be performed in different threads.

Lets look at the following fix:
---------------------------------------------------


private void GenerateNumbers()
{
for (int i=0; i<10000 ; i++)
listBox1.Items.Add(i);
}

private void button1_Click(object sender, EventArgs e)
{
Thread t = new Thread(new ThreadStart(GenerateNumbers));
t.Start();
}

-------------------------------------------------
If you run the program and press on the button you get a respons from the form while the ListBox is filled.
You should never do it this way!!! We are accessing the GUI from different thread. In 2005 you will even get an exception.

The correct way of doing this is by calling the Invoke method of the form. This will call a method in the GUI thread:
---------------------------------------------------


private void GenerateNumbers()
{
for (int i=0; i<10000 ; i++)
{
this.Invoke(new Fptr(InsertNumberToList), new object[] {i});
Thread.Sleep(10);
}
}
public delegate void Fptr(int n);
private void InsertNumberToList(int n)
{
listBox1.Items.Add(i);
}
private void button1_Click(object sender, EventArgs e)
{
Thread t = new Thread(new ThreadStart(GenerateNumbers));
t.Start();
}

-------------------------------------------------
The Invoke method receives a delegate (any delegate) and an array of parameters to pass to the delegate. We are guaranteed that the method will be executed in the GUI thread. However, without the Sleep call the GUI would be frozen, because the loop constantly updates the GUI. The Sleep will make sure that the user gets enough time to interact with the form while the loop is running.

If you run the program you will notice that the ListBox is updating much slower than before. The Sleep we placed is the cause of that. This is the tradeoff we get by performing long tasks which interacts with the UI: Good response from the UI vs. Time it takes to complete the task.

By the way, this method is useful while updating ProgressBars from worker threads.

In 2005 we have a BackGroundWorker control that we can drag to the component tray of the form. This control can manage tasks in backgorund threads for us in a much more user-friendly way.

Summary
In this article I showed how to perform asyncronous operations in a MultiThreaded environment without actually using the Thread class. I showed how to use timers, how to call asyncronous delegates, how to call Invoke in UI applications, and how to use the ThreadPool.

Synchronizing Threads in .NET

noreply@blogger.com (Yariv Hammer) — Fri, 03 Mar 2006 13:58:00 +0000


class A
{
public void f1()
{
Delay = 300;
for (int i=0; i<10; i++)
{
Console.WriteLine("f1: " + Delay);
Thread.Sleep(Delay);
}
}
public void f2()
{
Delay = 500;
for (int i=0; i<10; i++)
{
Console.WriteLine("f2: " + Delay);
Thread.Sleep(Delay);
}
}
public static int Delay = 500;
}
class Class1
{
static void Main(string[] args)
{
A a = new A();
Thread t1 = new Thread(new ThreadStart(a.f1));
Thread t2 = new Thread(new ThreadStart(a.f2));
t1.Start();
t2.Start();
Thread.Sleep(1000);
Console.WriteLine("Main End");
}
}

-------------------------------------------------
Delay is a static member of A. If you will run this you will see that the last thread to change Delay will change it both for f1 and f2. The thing is that both threads share the same member, and the last one to change it wins it all.

What we want really is to have one Delay for the first thread, and another Delay for the second thread. There is a built-in mechanism for that in Win32 called Thread Local Storage, and the way to do it in .NET is by using the [ThreadStatic] attribute before declaring the static member.
[ThreadStatic] public static int Delay = 500;

As you can see we initialized the Delay member with a value. This initialization only applies to the main thread. Each thread must set a value in the entry point method, or the value will be 0.
If you run the program now you will see that each thread has its own delay.

Synchronization Mechanisms
Two threads want to access the same variable, or the same code. Context switches can occur at any time, so if the context switch occur in a critical point, the threads can cause unexpected results. An example could be when a thread tries to decrease a variable by one, so it places it in a register, and at that point a context switch occur, another thread decreases the variable, if a context switch occurs again the variable will be decreased only once instead of twich.

There are declerative ways and coding ways to perform synchronization in .NET.
The WaitHandle class is an abstract class which provides a way to signal other threads. Three classes derive from the WaitHandle class: ManualResetEvent, AutoResetEvent and Mutex.
The AutoResetEvent class involves cases in which we want to make sure that threads will sleep until another thread finishes a task. It has two states: Set and Reset. The Set state is signalling one thread to stop waiting, and then automatically goes back to Reset state. A thread can call the WaitOne method of the AutoResetEvent object, and then it is blocked until someone calls the Set method.
Here is an example.

The ManualResetEvent is similar to AutoResetEvent. When a threads wants to block all other threads it calls the Reset method. If any other thread calls the WaitOne it will be blocked until someone calls the Set method. All the threads will be released, and the state will remain Set, until someone sets the state again to Reset.

The Mutex class is used when we want to protect a resource or a critical code. We call the WaitOne at the beginning of the section, and the ReleaseMutex at the end of the section. If one thread called the WaitOne method, other threads will be blocked on that line until the thread calls the ReleaseMutex class. You should perform the ReleaseMutex operation in the finally clause. For a short and nice example look at MSDN .
In 2005 a Semaphore class was added to the framework. There are also named mutexes, and there is an Access Control List feature.

Race Conditions
The class Interlocked provides methods to perform operations as atomic. This will prevent race conditions between threads on variables. In the 2003 version this class provides Increment, Decrement,Exchange (switches two variables), and CompareExchange. In the 2005 version other features were added.

Using Attributes to Synchronize Classes
A class that derives from ContextBoundObject (such as ServicedComponent) can be assigned with the [Synchronization] attribute. No more than one thread will be able to access the class methods and properties. This will not block static methods and members. This is a very easy but strict mechanism. It is not suitable in many cases, for example when there is a Read and Write method. Only one thread can access the Write method, but few threads can access the Read method. This will not work with this attribute.
The class is in the System.Runtime.Remoting.Contexts namespace.

There is a way to protect a method from getting accessed bymore than one thread. Add the following attribute to the method [MethodImpl(MethodImplOptions.Synchronized)].

Locks
C# has a built-in locking mechanism. The lock is per object, so if you want to prevent two threads from executing critical sections together, they should lock on the same object:
---------------------------------------------



public void f1()
{
lock(x)
{
for (int i=0; i<10; i++)
{
Console.WriteLine("f1: " + i);
Thread.Sleep(300);
}
}
}
public void f2()
{
lock(x)
{
for (int i=0; i<10; i++)
{
Console.WriteLine("f2: " + i);
Thread.Sleep(500);
}
}
}
object x = new object();

--------------------------------------------
Only one method can perform the loop at the same time. The ither thread will have to wait until the lock is freed. You can lock on any type of object.

Behind the scenes .NET uses the class Monitor.
If you want to lock a critical section in the context of the object, you can do lock(this).
This will prevent two threads from accessing the critical section only when accessing the same object.

If you want to lock a section in a static method, you might use lock(typeof(MyClass)) .

A nice class to perform read and write operations is the ReaderWriterLock, which lets aquiring a number of reader locks, and only one writer lock.

Summary
In this article I showed a number of ways to synchronize threads using Locks, Mutex, Manual/AutoResetEvent, and attributes. I also showed how to use the Thread Local Storage.

In the next article I will discuss timers, ThreadPool, and Asynchronous delegates.

Asynchronous Programming in .NET

noreply@blogger.com (Yariv Hammer) — Thu, 02 Mar 2006 20:06:00 +0000

In this serie of articles I show a lot of the mechanisms we have in .NET to program MultiThreaded applications and to perform asynchronous operations.
Here are the articles in this serie:
Asynchronous Programming in .NET
Synchronizing Threads in .NET
MultiThreading Without The Thread Class

Introduction
Here are four important classes regrading the mangement of processes and threads in the operating system:
- AppDomain - A class that represent a .NET process, in the context of the CLR. Each .NET application is opened as an AppDomain, and later on can open several other AppDomains.
- Thread - A class that represents a managed thread.
- Process - A class in the System.Diagnostics namespace that represents the process from the Win32 point of view. It is mainly for monitoring process information.
- ProcessThread - A class that represents a thread from Win32 point of view, and is used to monitor thread information.
Each .NET application starts 9 thread normally on startup. Only one of them is the managed thread where your code runs. A .NET thread is a Win32 thread, but the other way is not true always. The following line will show you the exact number of threads in your application:
Console.WriteLine(Process.GetCurrentProcess().Threads.Count)
You use the Process class in order to start new processes (by calling the Start method) or to receive information about other processes. The Threads property return a collection of ProcessThread objects. The mthod EnterDebugMode for example can perform the same operation as the TaskManager. ProcessThread for example can set the Processor Affinity.

AppDomain contains several properties regarding the .NET running assembly, and enables to communicate between several AppDomains. We use AppDomains when we want to wrap the environment with security. It is a virtual environment to which we load assemblies and run them. We do not need to worry about releasing resources on exit (The CLR takes care of that for us). We pay with performance of copying data between the AppDomains.

The Thread Class
The Thread class contains static and member methods. We use it when we want to do things in parallel or asynchronously. The threads, unlike AppDomains, share a memory space and resources. Each thread has an entry point, which is a method without parameters which returns no value.
Here is a small example to demonstrate:
---------------------------------------------------


class A
{
public void f1()
{
for (int i=0; i<10;i++)
{
Console.WriteLine("f1: " + i);
Thread.Sleep(500);
}
}
public static void f2()
{
for (int i=0; i<10; i++)
{
Console.WriteLine("f2: " + i);
Thread.Sleep(700);
}
}
}
class Class1
{
static void Main(string[] args)
{
Thread t1 = new Thread(new ThreadStart(A.f2));
A a = new A();
Thread t2 = new Thread(new ThreadStart(a.f1));
t1.Start();
t2.Start();
Console.WriteLine("Main End");
//Console.ReadLine();
}
}

--------------------------------------------------
We have three threads opened: t1, t2 and main. The output starts with the "Main End" message, because the t1 and t2 threads runs in parallel to the main method. The Thread.Sleep method applies to the current thread, and stops the thread for a while. The ThreadStart is a delegate to a void method without parameters. (In 2005 there is an option to pass an object). The thread can have a priority, Which is one of 5 levels. Normal is the defaut.

BackGround Threads
The application will not finish until all threads are over. If you wish the application to end when the main thread is over, you should set the IsBackGround property of the thread to be true:
--------------------------------------------


static void Main(string[] args)
{
Thread t1 = new Thread(new ThreadStart(A.f2));
A a = new A();
Thread t2 = new Thread(new ThreadStart(a.f1));
t1.IsBackGround = true;
t2.IsBackGround = true;
t1.Start();
t2.Start();
Console.WriteLine("Main End");
}

--------------------------------------------
The main method will stop right away, and with it the whole application.

Join
We can use the Join method in order to wait for the thread to end:
--------------------------------------------


static void Main(string[] args)
{
Thread t1 = new Thread(new ThreadStart(A.f2));
A a = new A();
Thread t2 = new Thread(new ThreadStart(a.f1));
t1.Start();
t2.Start();
t1.Join(); // Don't continue until t1 is done
Console.WriteLine("Main End");
}

--------------------------------------------
We can pass an timeout parameter to the Join method. This way we can avoid deadlocks. This overload also return the success status of the thread.

Passing Parameters
When we wish to pass a parameter to a thread we need to add a variable which is shared by the caller and the thread:
--------------------------------------------


class A
{
public int Delay = 500;
public void f1()
{
for (int i=0; i<10; i++)
{
Console.WriteLine("f1: " + i);
Thread.Sleep(Delay);
}
}
}
class Class1
{
static void Main(string[] args)
{
A a = new A();
a.Delay = 1000;
Thread t2 = new Thread(new ThreadStart(a.f1));
t2.Start();
Console.WriteLine("Main End");
}
}

--------------------------------------------
In the example above we passed the Delay variable to the thread. We can use any variable that is acessible to the thread in order to pass parameters to the thread.

Changing Thread State
The Abort method will recommend for the thread to stop by throwing an exception in the thread.
--------------------------------------------


static void Main(string[] args)
{
Thread t1 = new Thread(new ThreadStart(A.f2));
A a = new A();
a.Delay = 1000;
Thread t2 = new Thread(new ThreadStart(a.f1));
t1.Start();
t2.Start();
Thread.Sleep(1000);
t1.Abort();
Console.WriteLine("Main End");
}

--------------------------------------------
Only the t2 thread will finish gracefully.

The Interrupt method, similar to the Abort method, throws an exception to the thread. The only difference is that after the thread handles the exception it continues to work.

In both cases the exception is asynchronous (you cannot deterministically determin the exact time the thread will catch the exception). You can pass an object (StateInfo) to the exception, and the thread can use it if necessary. Here is how you catch the event in the thread:
--------------------------------------------


public void f1()
{
try
{
// Do stuff here
}
catch (ThreadAbortException ex)
{
// you can use ex.ExceptionState in order to get the object passed in the Abort method.
}
finally
{
}
}

-----------------------------------------------------
If in the catch clause we write Thread.ResetAbort() we can bypass the Abort command and cancel the abort (in Interrupt we have it automatically).

It is not recommended to stop a thread by using Abort if the thread handles resources. The problem is that the exception can be caught at any time, and if it were cought in the finally clause, the exception will not be handled at all, and the thread will be stopped without freeing the resources.

A solution to this problem could be to use a public volatile member flag in the object, which is checked by the thread, and when set to true, the thread exits gracefully:
---------------------------------------


class A
{
public volatile bool ThreadStop = false;
public int Delay = 500;
public void f1()
{
for (int i=0; i<10; i++)
{
if (ThreadStop)
return;
Console.WriteLine("f1: " + i);
Thread.Sleep(Delay);
}
}
}

class Class1
{
static void Main(string[] args)
{
A a = new A();
a.Delay = 1000;
Thread t2 = new Thread(new ThreadStart(a.f1));
t2.Start();
Thread.Sleep(1000);
a.ThreadStop = true;
Console.WriteLine("Main End");
}
}

----------------------------------------
We use a volatile member in order to instruct the garbage colector not to do any optimizations on this member, and to pass it to a register. This will make sure that a concurrent method that wants to stop the thread will not have a context switch problem when registered are restored.

Suspend and Resume can help external threads to control the state execution status.

Appartment State
If you want call a COM component from the thread you should know whether it runs in a Multi Threaded Appartment (MTA) or Single Stated Apartment (STA). The Thread class has an ApartmentState property, that you can set to MTA (default) or STA. If the COM and the thread appartment state do not match you might get performance issues (because of extra marshaling between apartments).
You might have noticed that the automated Main method has an attribute called [STAThread]. This means that the main thread will always work with STA appartments. The question that comes to mind is why not just write "Thread.CurrentThread.ApartmentState = ApartmentState.STA;" in the first line of Main. The answer is that the Main is not the first command the application does. There are many operations that happen when the application loads before Main is called, and in these operations there might have been calls to COM.

Summary
In this article I introduced some classes in .NET that represents units of run-time environment in the CLR and in Win32. I covered some of the capabilities of the Thread class. I showed how to run threads in the background, how to wait for a thread to end, how to make a thread sleep, and how to tell a thread to end.
In the next article I will discuss other issues regarding threads.

Transactions in Enterprise Services

noreply@blogger.com (Yariv Hammer) — Tue, 28 Feb 2006 20:11:00 +0000

Introduction
One of the most important features in COM+ is distributed transactions. A local transaction is a transaction in which we open a connection, perform a series of actions, and close the connection. In a distributed transaction we have several connections we need to synchronize in order to be able to perform several related actions simultaneously.
An example: We have two bank accounts. We need to move 100$ from one account to the other. In order to achieve that we need to decrease the amount of money in the first account and increase the amount of money in the second account. But what if one of the operations fails? There could have been a network problem, an electrical power interruption or a malfunction in the database. If we managed to increase the money in the second account but failed to decrease the money in the first account, we will loose money. We need a way to perform both operations as one unit - if one of them fails - they both fails. Only if both succeeds - they all succeed. Transactions can help in those situations.

Two Phases Commit
DTC of Microsoft works in an algorithm called Two Phases Commit. In a One Phase Commit we will perform some operations in a serial way, and at the end, if we succeeded, we commit the changes. In our case, each transaction is split into sevral local transaction. At the first action COM+ handles the transaction. First we perform the Prepare Phase - each component must indicate that it is prepared to commit. There is no actual Commit yet. If one of the component aborted the transaction, we do not even enter the second phase. If all the components voted that they are prepared, we perform the Commit Phase. The DTC waits for a vote of Commit from all the component. After Fail or Timeout, all the components are told to Roll-back the transaction, and return to the state from before the transaction.

In COM+ we use DTC. SQL Server and MSMQ are examples for services which support Two Phase Commit, and thus are considered as valid Resource Managers. For other systems, such as Oracle, which doesn't support Two Phase Commit, we have the CRM (Compensating Resource Manager) mechanism in COM+. It helps us to implement a class that will manage the resource in the COM+ way.

The Requirement of Transactions - ACID
Atomicity - The transaction perform several operations that are considered as one unit - all succeed or all fail.
Consistency - Information is not lost during the transaction. If the transaction was commited, we are at a stable consistent state. If the transaction rolls-back we are at the state prior to the transaction.
Isolated - There are no outside interference during the transaction. Components which do not participate in the transaction cannot access the resources while the transaction is in action. In order to achieve this, we must of some synchronization mechanism (we have COM+ of course for that too).
Durable - Failures can be recovered. In case of a failue the system, once working again, should be at a consistent state. DTC uses a logging mechanism in order to achieve that.

Setting Up Transactions Using COM+ Configuration Tool
Each component, in the Transaction tab, has the following options:
Disabled - The component is not built in a technology in which transactions are supported.
Not Supported - The component does not participate in any transactions.
Supported - The component will participate in a transaction only if the creating component is in a transaction
Required - The component will always participate in a transaction. If the calling component is in a transaction, the component will exist in that transaction. If the caller do not participate in a transaction, the component will start its own transaction.
Required New - The component always start a new transaction.

When you program a transaction, the first step would be to take a pen or pencil (or your favourite case tool), and draw the components and their relation. Lets do an example: We have a BankManager which has a method MoveFunds. The method should take money from one account into a second account. So Account will have AddFunds and RemoveFunds methods. We will set the BankManager to be Require New, and the Account to be Supported. This way, whenever we call MoveFunds we start a new transaction. The class will use Accounts, and the AddFunds and RemoveFunds will participate in the transaction. If one of the methods will fail, the whole transaction will fail, and the money will be restored into the first account.

The costs of the transactions are management of flags. JITA (Just-In-Time-Activation) is on if you use transaction. Each objects is created when it is called in the trasaction, and is released when it is not used. This insures isolation. Another mandatory feature is synchronization.
In order to support JITA there is a Done flag. In order to support consistency there is Consistent and Abort flags. There are also costs in performance. It is better not to include too many components in the same transaction.

Programming Transactions
When you want your component to participate in a transaction, you mark it with attribute [Transaction]. The properties of this attribute correspond with the Transaction Tab in the COM+ Configuratin Tool: TransactionOptions contains enumerations of all transaction support section (Requirted, Supported, etc). Take for example the case of RequiredNew: any call to any method of the class will start a new transaction. You can also set Isolation and Timeout.

In the beginning of transaction the Consistent flag of all components is set to true. Once we do a change in state which makes it no loger consistent, we set the flag to false. The Done flag is set to false in every component. Once we call the SetComplete method in the end of the operation the Done flag is set to true. If we call the SetAbort method, the Done flag will be true, but the Consistent flag will be false, and the whole transaction will be rolled back. Once every component called the SetComplete method, the transaction succeeds. It takes only one component to abort for the whole transaction to fail.
We can have an intermediate state, on which there is a problem, but the caller component might be able to fix it. For example, the database failed to respond, but the caller can start it up and the transaction can continue. In this case we can call the DisableCommit which leaves both the Done and the Consistent flags in false. The object still lives, and at any other point the component will be able to call the SetComplete method.

The ContextUtil class has static properties and methods that can help us manage the transactions.
- SetComplete - Done = true Consistent = false. Commit transaction.
- SetAbort - Done = true Consistent = true. Abort Transaction.
- EnableCommit - Done = false Consistent = true. The transaction can be commited. The object cannot be deactivated
- DisableCmmit - Done = false Consistent = false. The transaction should not commit (but it can be changed).
- DeactivateOnReturn - Controls the Done flag
- MyTransactionVote - Controls the Consistent flag

---------------------------------------------------


[Transaction(TransactionOption.Required)]
class Account:ServicedComponent
{
public class AdjustBalance(int account, decimal amount)
{
        try
        {
              PrepareTransfer();
              ExcecuteTransfer();
              ContextUtil.SetComplete();
        }
        catch
        {
             ContextUtil.SetAbort();
        }
}
}

--------------------------------------------------
You can have a shortcut by using the [AutoComplete] attribute. The SetComplete will automatically be called for you when the method is over, unless an exception is thrown, and in this case SetAbort will be called for you:
--------------------------------------------------


[AutoComplete(true)]
public class AdjustBalance(int account, decimal amount)
{
   PrepareTransfer();
   ExecuteTransfer();
   if (fail)
   {
        throw new exception("Insufficient funds");
   }
}

-------------------------------------------------

Any component that is instanciated in the methods PrepareTransfer or ExecuteTransfer with transaction set to Supported or Required will be in the same transaction, need to vote SetComplete in order for the transaction to work, and will be created by the JITA rules.

Summary
I showed how transactions work, what are the costs, how to configure them in the COM+ Configuration Tool, and how to program them.
I showed the Transaction attribute attached to the ServicedComponent. I showed the usage of ContextUtil in order to vote Complete or Abort. I showed the usage of the AutoComplete attribute as a shortcut.

Getting Started With Enterprise Services

noreply@blogger.com (Yariv Hammer) — Sun, 26 Feb 2006 21:16:00 +0000

Introduction
COM+ components are called Serviced Components in .NET.
In this article I will show how to create a very simple Serviced Component, how to use this component from a .NET application, and how to configure the component from the COM+ Configuration Tool.
In addition, I will discuss some of the aspects of the usage of COM+ from whithin the .NET framework.

Your First Enterprise Service
- Open VS.NET 2003.
- Create a new class library (I will use C# in this tutorial), called HelloEnterpriseServices.
- Add a reference to System.EnterpriseServices.dll
- We must sign the assembly with a strong name (it is not mandatory to place it in the GAC):
In the command prompt of .NET, in the foder of the class library, type "sn -k keys.snk"
In the AssemblyInfo.cs file change the following:
[assembly: AssemblyKeyFile("..\\..\\keys.snk")]
Build the class library.
- Add a class called HelloService as follows:
--------------------------------------------------------------


using System.EnterpriseServices;
namespace HelloEnterpriseServices
{
public class HelloService:ServicedComponent
{
public string SayHello(string name)
{
return "Hello " + name;
}
}
}

---------------------------------------------------------
- Build the project.

Congratulations. You have just created your first enterprise service.

Some Explanations:
In our class library we can place as many classes as we want. Some of the classes may inherit from the ServicedComponent class. All the classes are managed, and act the same as any other .NET class. The classes which derive from ServicedComponent will be registered as COM+ components, and the class library will be registered as a COM+ application.

If you will check the COM+ Configuration Tool you still can't see the new application.

Next we will fix some security issues. COM+ provide a service for role-based security. It is a good practice to use it, but if you do not wish to do so, you should open the AssemblyInfo file and add the following:
- Add using System.EnterpriseServices in the beginning of the file.
- Add [Assembly: ApplicationAccessControl(false)] at the end.
- Build again.
In the COM+ Configuration Tool, in the application properties, in the Security tab, you can see a checkbox "Enforce access checks for this application". You don't want this to be checked, unless you set up the security, because the application will throw an exception when loaded by clients.

Consuming the Serviced Component
Add a new Windows Application to the solution, called HelloEnterpriseServicesApp.
First add a reference to the previous HelloEnterpriseServices library. You must also add a reference to System.EnterpriseServices.

Next we will use our HelloService class. It is used as any other .NET class.
- Add a button to Form1. Double-click on it.
- Add

using
HelloEnterpriseServices

to the form code.
- Add the following code to the button click event handler:


private void button1_Click(object sender, System.EventArgs e)
{
HelloService service = new HelloService();
MessageBox.Show(service.SayHello("Jack"));
}

- Set the windows application project to be the startup project of the solution.

Run the solution. The form shows right away. Clicking on the button will take a couple of seconds. At this time the COM+ component is first registered. Clicking again on the button shows the message box much faster. This kind of registration is called "Lazy Registration". I will show another method soon.

If you check the COM+ Configuration Tool (right click and select Refresh), you will see HelloEntrpriseServices. It is a Library application (as you can see by the icon). If you expand the application, and the Components, you will see the HelloService component. Expnad it further, and the Interfaces and you will not find the SayHello method. That is because we did not define a .NET interface for the service.
If you right-click on the HelloService component, and select properties, you will see 2 GUIDs (in the General tab) - one is CLSID and the other is for the Application. You must understand that by using COM+ from whithin .NET you go back to the time of COM and "DLL Hell" - The classes are registered to the registry, you cannot do side-by-side deployment, and cannot easily version the component. The .NET assembly, however, has all the benefits of .NET assemblies.

Improving the Component
Consider the following steps a MUST-DO. You will save yourself some headaches.
First we will add an interface to our component:
------------------------------------------------------


using System.EnterpriseServices;
namespace HelloEnterpriseServices
{
public interface IHello
{
string SayHello(string name);
}
public class HelloService:ServicedComponent,IHello
{
public string SayHello(string name)
{
return "Hello " + name;
}
}
}

---------------------------------------------------
If you wish to do so, you can place the interface in a different assembly. You can also define multiple interfaces to the assembly.

Next step will be to put the GUIDs ourselves. It is a good practice to force COM+ to use our GUIDs, in order to make sure that the applications that are installed are indeed ours.
In Visual Studio .NET, select Tools menu, and Create GUID tool. Select Registry Format, and Copy.
Add the following attribute to the interface:
[Guid("B906C925-D72F-4d8d-B8D5-672D7C2E595A")] .
The GUID here is just an example. Be sure to remove the curly brackets ({})
You can do the same process to add a GUID to the class (A different GUID).

Generate another GUID, and in the AssemblyInfo file add the following attribute:
[assembly: ApplicationID("Guid here")]
This will set the Application GUID.

Other useful attributes you can use:
[assembly: ApplicationName("Hello Application")] - for a user friendly name.
[assembly: ApplicationActivation(ActivationOption.Library)] - To set Library or Server application
[assembly: Description("Here is a nice description you will see in the COM+ Configuration Tool")]

Rebuild the class library.
Before we continue, delete the previous HelloEnterpriseServices application (right-click on it and select "delete").

I will show you how to register the application from command prompt:
go to the folder of the dll (using "cd fullpath") and type
regsvcs .dll
Later, when you update your component, you can call
regsvcs .dll /reconfig
The regsvcs tool wrapps the .NET dll with COM, register it in the registry and creates a tlb file you can call from a native language (as COM)

In the COM+ Configuration Tool (after you refresh) you will see in the application properties the new application ID, the description, and the use-friendly application name. When you expand the interface of the HelloService component, you will see the IHello interface, and underneath the SayHello method.

The attribute we placed in the AssemblyInfo file (such as ApplicationActivation to set Server/Library) are only relevant when we deploy. After deployment anyone can reconfig the application to their choosing (that's the whole point of COM+).

When you create newer versions you do not need to create new GUIDs. Unless of course you change the interface (which is not recommended as you will need to support old clients). Remember that there is no side-by-side activation of com components (unlike .NET assemblies).

Contexts
Each ServicedComponent inherits from ContextBoundObject. When an object tries, for example, to participate in a transaction, it must know the transaction ID. This parameter is a part of the context of the object. Each feature we use in COM+, we make the context of the object more heavy, with more parameters. The object context is the set of services provided by COM+ to the object.
For some objects the context is more similar than other objects. In this case the interaction will be more smooth. In cases where the contexts differ significantly, there will be an interception - a context switch. Your goal is to keep the contexts similar as much as possible, which will cause less interception, and improve performance.

The handling of contexts is completely transparent in .NET. Any interaction you will do inside your code with COM+ is done through a class called ContextUtil. This stateless class has only static methods and properties. You will need to use this class when you will program transactions, object pooling and other COM+ services.

COM+ Applications vs. .NET Assemblies
The COM+ application is a frame for logical management of components. It is not a single unit of deployment, as opposed to the .NET dll. You can create new COM+ applications with components from different .NET assemblies. If you design your component to be reusable blackboxes correctly, you will have a very powerful way of using the same components in different COM+ applications.
In the COM+ Configuration Tool, right click on COM+ Applications, and select New Application. This will start the COM+ Application Installation Wizard. You can install a pre-built application, so you can choose an msi file you exported using the Export option. Or you could create an empty application. You will enter a name "HelloEnterpriseServices2" and select the type of application (server or library). Select InteractiveUser at this point. You will see the empty application under COM+ application. Now you can add a Component (select New Component to show another wizard). You can install new components from dll or tlb files, or you can use one of the components already installed in your computer. When you are done, you can Export it all, and create an msi file to install it on one shot in another computer. Note that you will need to do proper ID management.

There are very few services that will force you to use a Server application (for example: Queued Component must be in a different process). It is usually more efficient to use Library applications.

There might be some issues when using several versions or copies of .NET assemblies. Although it is not mandatory, placing the .NET assembly in the GAC will tell everybody to use the same copy of the assembly, which help might help you when debugging and deploying. You will always know the exact copy of the assembly the COM+ application is using.

Another issue you should consider is the usage of properties. COM does not support properies, as .NET does. So each property will be translated into a get and a set method. I would suggest using Getter and Setter methods in the first lace, so you will not have different interfaces to managed and native components.

Summary
In this article I showed how to build the minimum enterprise service possible. I showed the usage of GUID and interfaces. I showed how to consume the enterprise service in managed code. I discussed some deployment issues.

In the next article I will show how to use transactions in managed code.

Introduction To Enterprise Services (COM+) In .NET

noreply@blogger.com (Yariv Hammer) — Mon, 20 Feb 2006 21:12:00 +0000

Introduction
COM+ is a service provided by Windows (it is not a .NET feature), similarly to other services such as IIS. Despite common belief, COM+ is not COM.
The main goal of COM+ is to provide a management environment for processes. The services provided by COM+ are required in distributed application (such as Client/Server application), especially with numerous calls.
By using COM+ in the .NET environment, or as it is called in .NET - "Enterprise Services", we benefit from the advantages of both the CLR and managed environment and the native environment of COM+, including integration with old legacy applications.

Almost all the services provided by COM+ is not supplied by the .NET framework, and without COM+ you will need to program them yourself. You don't need to know anything about COM development, and the use of Enterprise Services in .NET is quite easy.

A Short History Lesson
COM is a protocol for development component prior to .NET. When needs for distributed application have emerged, it was upgraded into DCOM (Distributed COM), which is a protocol for running in different machines or processes. For example, you could write an ActiveX Exe, which is an application that could be called from remote clients. The interface was done with DCOM. This protocol is lightweighted, in a binary format, without a lot of overhead. It is suitable for local networks, especially when the computers on the network are well known in advance.

However, some new services were required which provide long term stability, correct management of resources, and usage of resources by demand. For example: you could set up a server application, on which every call created a new process in the server - problem with scalability, and the syncronization of clients. Another required service is distributed transactions (For example: The server updates a database in a local transaction. There could be a dependency on another server which updates a database in another local transaction. The problem is that updating a database is an action which strongly depend on a connection, which is a resource the server has no control over. There might be a failure, and both updates should be rolled back to the previous state). Windows has a service called DTC (Distributed Transaction Coordinator), that can be called in order to request the transaction service.

In Win-NT a new service was created, called MTS (Microsoft Transaction Server), that wrapped DTC. On request, MTS supplies a new process, dllhost, that can host other dlls. Instead of writing an ActiveX Exe, we write an ActiveX dll (which is a COM component), and when it is hosted in dllhost process it automatically works in DCOM. It is possible to connect remotely to dll that is hosted by dllhost, and dllhost manages the resources. One of the services is distributed transactions.

In Win2000 the MTS was built-in, and some other services were added, all wrapped together in COM+.

COM+ in .NET
In the .NET environment we create a managed library (dll). If we wish to use COM+ in the dll, the dll is wrapped (automatically) with COM, in order for native components to be able to connect to it.
Note: As I wrote above, you can use COM+ in order to communicate between processes, and even between machines, using DCOM. But in .NET we have other technologies to perform interprocess communications (Remoting, Web Services, etc). It is not recommended to use COM+ just to perform RPC. A good architecture will be to call the server using Web Services (for example), and utilizing the COM+ services in the server locally, without the client knowledge.
In fact, when you call a Web Service, it is hosted in the IIS, which is a server. This is similar to COM+ approach - the application is hosted in the dllhost process. For communication, IIS is a better choice.

In .NET a COM+ component is called a Serviced Component or a Configured Component. When the component is already active, maybe even installed on a client, it can be configured administratively using a user friendly tool, supplied with Windows. For example: COM+ has a feature called Just-In-Time Activation (JITA), and we wrote a Serviced Component using this feature. We installed the software on the client, and now we can configure turn the feature on and off using the COM+ Configuration tool, by checking a checkbox. No code required. No Xml or other configuration files. No registry or environment variables. It all comes in the box.

The COM+ Configuration Tool
Enough with the dry discussions. Time to see it in action.
The COM+ Configuration Tool is located in the Control Panel->Administrative Tools-> Component Services.
On the left tree view, expand Component Services -> Computers -> My Computer -> COM+ Applications.

You can see all the COM+ applications installed in your computer. Soon we will add a component there. Right clicking on any application, and selecting Properties will open the confiduration window. There are many tabs with a lot of configurations you can change, without even knowing what the application does (so be careful!!!). You don't even need to restart the application - clicking Apply will configure the application while it is running.

If you expand the applications even further, you can see Components. Under components you can see all the classes you registered to COM+ (remember that not all the applications here are .NET). Under each component you can see the Interfaces of this component. You can configure a Component, an Interface, and even a Method (by selecting properties).

The data that you configure in the COM+ Configuration Tool is stored in a database called "COM+ Catalog". This database is managed by Windows, and you can even access it programatically. The data that is stored in the COM+ Catalog is the metadata of all the applications and components.

What Services Are Provided By COM+
Lets start to explore the Properties window, in order to better understand what features are supported by COM+. As I describe a feature, try to think how you can achieve it using your .NET programming skills (without COM+ of course).

Application Recycling
The application will be restarted automatically depending on configurable conditions, such as Lifetime Limit (restart every period of time), Memory Limit (protection against memory leaks), Call Limit and more. The recycling is done in a smart way. For example, COM+ waits until there are no more clients to the application. This can be configured in the "Pooling&Recycling" tab.
For more information: COM+ Application Recycling Concepts

Just-In-Time Activation
It happens a lot that a client holds on to an object, it does not need right now. The object may be expensive on resources, so there is a waste of resources. JITA helps manage the resources more efficiently. When the client finish working with the object, COM+ will automatically deactivate the object, freeing all resources. When the client uses the object again, it will be activated once more by COM+. The client uses the object without even knowing that JITA is applied. Notice that the object should be stateless, or it should be able to store and restore its state.
This configuartion is per Component, in the Activation tab, under Activation Context, by selecting Don't Force Activation Context, and checking the Enable Just-In-Time Activation.
For more information: COM+ Just-in-Time Activation Concepts

Please note that some of the services of COM+ depend on other services. For example: When working with transactions we must enable the JITA, in order to support Atomicity.

When we use JITA, we must take into consideration the tradoff: When we call a JITA object, we implicitly activate and deactivate it (time consuming), but we benefit the proper management of resources (the object will not hold unused resources).

Object Pooling
We can have a pool of objects, initialized when the application started. Whenever a client creates a new instance, it gets an object from the pool, without the cost of creating the new instance. When the client releases the object, it goes back to the pool.
You can enable Object Pooling of a compoent, in the Activation tab. Select Enable Object Pooling. You can set a minimum and maximum pool size. The minimum pool size will be created when the application starts (slowing your application startup). When the pool is full, and a new instance is requested it is created and added to the pool. If the pool size approched its maximum size, the creation of new objects would fail (after a timeout - configurable too).
You can configure the object pooling while the application is running of course, and profile the performance in order to fine-tune the startup time, memory usage and performance of the application.
For more information: COM+ Object Pooling Concepts

Notice the possibility to enable both Object Pooling and JITA - whenever an object is used it is activated from the pool, and when finished it is sent back to the pool. This will speed up the activation/deactivation process of JITA.

Transactions
I will not discribe here what a transaction is. I will only give a short and simple example: A starts a transaction, calling B and C. B fails during execution. Even if A and C succeeded they must all fail, and roll-back to the last consistent state.
COM+ handles the transactions for you (using DTC). You will need to perform some actions in code in order for this to work.
For more information: COM+ Transactions Concepts

In order to configure transactions, go to the Transactions tab of your component, and select one of the options for Transaction Support.

Synchronization (Concurrency)
When there are several components sharing resources in a multi threading environment, we must always keep the resources consistent. If our components share one logical activity, we can set up the Synchroniztion service of COM+, so it will lock a component for any component that is not in the activity.
For example: Say we 4 components A,B,C, and D. A starts a thread, and calls B, which in turn calls C. D will not be able to access A,B, or C, and will be blocked until the activity is over.
For more information: COM+ Synchronization Concepts

Note: This is a very heavy mechanism in a multithreaded environment. If B has two methods, and A only calls one of them, D will not be able to call any of B's methods. However, this forces you to design and implement a well behaved multi threaded application, which might be a good thing.

In order to configure Synchronization, go to the Concurrency tab of your component, and select one of the options for Synchronization Support. If you use transactions, you must also use Synchronization (COM+ will configure this for you).

Queued Component
MSMQ is one of the services provided by Windows. MSMQ provides message queueing services, administrated by Windows. There is a good integration between COM+ and MSMQ, in the form of Queued Component service.
COM+ can intercept any call to a method of the component, and serialize (translate) it into a message in a queue. The COM+ component, in its own time, will handle the COM+ call. COM+ will deserialize the message to a proper method call, and the server will be able to perform the action. This mechanism is a good solution in cases of asynchronous method calls. It will not work well with synchronous calls. The server should not return a value, throw exceptions and so on (It is possible, but not trivial).
This mechanism is good when the client should not rely on the service availability.
For more information: COM+ Queued Components Concepts

Note: You can use MSMQ from .NET independently of COM+, using the System.Messaging namespace. For more information: Accessing Message Queues

You can configure Queueing services of an Interface, in the Queueing tab, by checking the Queued option.

Loosly Coupled Events
COM+ introduces a new concept of event handling. Usually a publisher raises an event, and a subscriber's method is executed. This implies a coupling between the publisher and the subscriber. In COM+ publishers provide events, subscribers register for these events, but COM+ is the mediator between the publishers and the subscribers. The benefits of this approach is that the subscribe do not know which publisher raised the event.
The service is good if the publishers and subscribers fdo not know each other (they may not even know that the others exist). It is also good when there are number of publishers for the same event, and it is not important which one raised the event.
For more information: COM+ Events Concepts
The subscriptions for event is configured in the COM+ Configuration Tool.

Role-Based Security
COM+ provides a mechanism in which you can define which user can initializes components, call a method or even perform a custom operation. Instead of selecting users for each task, you define Roles, and assign rules to that role. The users are mapped into roles using the COM+ Configuration Tool, using the Windows built-in authentication system.
For more information: COM+ Security Concepts

Object Construction
You can send a message to a component when it is constructed in the form of a string. This mechanism resembles the command line arguments of an application. For example, you can pass a connection string, or a path, or several arguments. The advantage is that it is configurable from the COM+ tool (in the Activation tab).

Compensating Resource Managers (CRM)
In order to participate in a COM+ distributed transaction, the resources should be managed by a resource manager. For example: SQL Server and MSMQ are both resource managers, so you can handle them from whithin a transaction.
Take for example the case of writing to a file. How can you roll back from that? If you want the writing to a file action to be coordinated in a transaction, you must create a Compensating Resource Manager for that file. COM+ provide the infrastructure to create a class with an interface that supports the CRM. By implementing this class you can add any resource into the transaction.
For more information: COM+ Compensating Resource Manager Concepts

Shared Property Manager (SPM)
COM+ provides a mechanism to share state between components.
For more information: COM+ Shared Property Manager Concepts

Soap
You can create a SOAP WebService Wrapper around your application (you will need IIS installed for this). This feature will automatically create a Web Service facade to be used in order to connect remotely to the COM+ application.
All you need to do is select the Uses SOAP checkbox in the Activation tab of the application.

Server and Library Components
COM+ applications can be in the form of Library applications or Server applications. It is configurable from the COM+ Configuration Tool, in the Activation tab of an application.
All the Server applications has icons shaped as boxes, and Library applications has a round shaped icons.
A Server application will be hosted by a dllhost, and will run as a different process. All the instances will run in the same dllhost. A Library application will run in the process of the client.
You can start a Server application, by right clicking on the application and selecting Start. You can stop the applications in the same way. All the runnning Server applications can be monitored in the Running Processes node, under COM+ Applications. Each running application will have a number in brackets. This is the process ID of the dllhost hosting the application (You can see the process in the Task Manager).

When you use Library applications (the default) you will gain all the non-distributed services of COM+. For example, you can perform transactions from inside the process without the costs of DCOM communication. On the other hand, if you use a Server application you loose performance, because of the inter process communication, but you gain centralization of the services inside one process. For example, you might want to put all the services in the server-side. You can use the Shared Property Manager in order to share data between clients.

If you use a Server application in a remote machine, you must consider the deployment of the components in the clients. It is a good practice to avoid this situation, and to use other, more advanced, technologies, such as Web Services, in order to handle the communication, and to limit the usage of COM+ from whithin the boundaries of the machine.

Exporting the Configuration
For server applications, it is a very important feature to save the current settings in order to load it later on. For that you have the Export options in the context menu of the application. A handy wizard will guide you through the very easy process. You select a path, click OK and an msi file will be generated. By double clicking on it you will install the COM+ component on the machine, and set the configuration as the one that was saved.

A very powerful feature is to save the component as an Application Proxy. This way you can install the application on machines that should connect to the server remotely.

Summary
All of the services which are provided by COM+ are fully documented in MSDN: COM+ Services
In the next article we will create a COM+ component in .NET and deploy it.

Administrative Configuration of Applications

noreply@blogger.com (Yariv Hammer) — Fri, 17 Feb 2006 21:27:00 +0000

This article is one of a series of articles exploring .NET Assemblies.
Exploring .NET Assemblies
Multi-File Assemblies
Strong Named Assemblies
Placing Assemblies in the Global Assembly Cache (GAC)
Administrative Configuration of Applications
The articles are intended for programmers who are using .NET for a while, and wish to know more about .NET assemblies.

Introduction
.NET Applications compile into executable assemblies. The standard way to configure .NET applications is through .NET built-in mechanism of configuration files. Those files are Xml files, with a specific format. The exact structure of those files can be seen here.
.NET configration files holds information about versioning, references, Remoting, and many other, including custom configurations done by the user (Here is a nice tutorial about the subject: Article From CodeGuru

In order to create the configuration file yourself, you add to the project a new item of type Application Configuration File. The item that is added to the project is called App.Config (for web applications it is called Web.Config). When you build your project, the App.Config file is copied into the target directory, and renamed to [exename].exe.config. It must be located in the same directory as the exeutable, with that specific name. When an administrator wants to change edit this file, he can open the application.exe.config file in an Xml editor, and if he knows wht he is doing change the configuration. By the way, Whenever building the application, the settings are overwritten by the original App.Config file.

Administrative Configuration
The problem with letting administrators configure Xml files, is that they must be familiar with Xml in general, and with .NET configuration files in particular. It would have been nice to have a tool that can manage the configuration of the application without the need to open Xml files.

Such a tool exist, and supplied when installing the .NET Framework. In the Control Panel->Administrative Tools->Microsoft .NET Framework 1.1 Configuration, there is a configuration tool. Under the Application section, you can select "Add an Application to Configure", and then choose from the list of applications installed on the computer. By selecting "View the Application's Properties", you can select the Garbage Collector mode, Publisher Policy and the relative search path for additional assemblies. I will not discuss the first two here. By selecting a relative search path you can specify directories where referenced assemblies may be located (this is called "Probing"). For example: You might wish to place all the dlls in a subfolder called "references". In that case put the string "references" (of course you will need to deploy the application in this way). The relative path must be underneath the executable (You cannot put "..\" in the relative search path). As soon as you save your settings, an application.exe.config file is created (if the file already exist it is simply modified).

There is a lot of strength in using this tool. There is a central repositories of all managed application. The configuration can be done by administrators (who know what they are doing of course) rather than the programmer. If the assembly is deployed properly, the configuration cannot impact the application performance and correctness. The deployment can be decided administratively rather than be constant (you might want as a user to place files in a different location).

Note that everything you can configure with the tool, can be configured manually by changing the Xml.

More Configurations
The "Managed Configured Assemblies" link, shows you all the references you can configure. By default no assemblies are seen. By right-clicking ad selecting "Add...", you can select assemblies which are referenced: From the GAC, Framework assemblies the application uses, or manually (by typing the name of the assembly and the public key token you can see in the manifest of the application). Once you select the assembly, you can configure some things about the referencing: Publisher Policy (will not be discussed here), Binding Policy (you can select the version of the reference), and Code Bases (you can select the full path to the assembly, including full URLs).

I would like especially to discuss the Binding Policy. It is often that you diploy an application, and then provide a new version of a dll. You do not need to compile the exe and deploy it again. If you did not change the interface of the dll, then the exe should work fine. When you deploy the new version of the dll, the old version of the dll can coexist with the new version (for example by placing both in the GAC). But you still need to tell the exe in the client to change the binding to the new version of the dll. This is done by using the Binding Policy page. You can tell the version the exe is currently using, and the new version you want the exe to use (You can also set a range of versions).

You can also configure the Remoting (when necessary), but I will not discuss this in this scope.

Machine Configuration
There is a set of Xml configuration files for the .NET framework, located in your Windows folder under C:\Windows\Microsoft.NET\Framework\v1.1.4322\CONFIG.

The file machine.config contains a lot of global configurations, some of which are defaults for applications running on the machine. Avoid changing this file as much as possible. Some of the settings can be overrided in the application configuration files.
Discussing the exact contents of the machine.config file is out of scope in this article.

Placing Assemblies in the Global Assembly Cache (GAC)

noreply@blogger.com (Yariv Hammer) — Wed, 15 Feb 2006 22:07:00 +0000

Strong Named Assemblies

noreply@blogger.com (Yariv Hammer) — Tue, 14 Feb 2006 23:00:00 +0000

This article is one of a series of articles exploring .NET Assemblies.
Exploring .NET Assemblies
Multi-File Assemblies
Strong Named Assemblies
Placing Assemblies in the Global Assembly Cache (GAC)
Administrative Configuration of Applications
The articles are intended for programmers who are using .NET for a while, and wish to know more about .NET assemblies.

Introduction
Digital Signature is the way to ensure that information was not altered since it was signed.
As developers we distribute our compiled assemblies to our clients. Both the developers and the clients want to make sure that the assemblies are exactly the ones that were first distributed. For example, a malicious programmer can hack into the assembly and alter it to his will. The least we can do is make sure that such thing did not happen before loading the assembly. It would be shameful, for example, if we tried to run an assembly signed by Microsoft, which was changed by someone without our knowledge.

An assembly which is digitally signed is called a Strongly-Named Assembly.

The Process of Signing the Assembly
In order to sign an assembly we need to do the following steps:
1. From the command line, run the line sn -k keys.snk where keys.snk is the name of the file with the keys. This step will generate a file containing a private key and a public key.
2. Open the project you want to sign in VS.NET, and in the AssemblyIbfo file, set the AssemblyKeyFile attribute with the path the snk file.
[assembly: AssemblyKeyFile("..\\..\\keys.snk")]
Alternatively you can do this while linking in the command line:
al /out:MyAssembly.dll /keyfile:keys.snk

After building the assembly if we open the assembly with ildasm, and watch the Manifest, we will be able to see the public key. So the public key is stored inside the assembly file.
The signature appears somewhere at the end of the assembly and cannot be seen in the manifest.

The snk file MUST be kept (in a secure way). Without this file you will not be able to sign the assembly with the same key anymore, and if you already deployed your dll, and there are existing executables referencing to this assembly, those executables will no longer work, unless deployed again with the new signed dll. Access to the snk file by malicious user will allow him or her to make changes to the assembly and sign it on your behalf with the same pair of keys. Be careful.

How Do the Signing Process Work
Now that we know technically how to sign the assembly, lets try to understand what exactly happens, and then try to evaluate the costs of signing.

At the compilation of the dll: The dll IL code is hashed in a well known Hashing algorithm (SHA1). The hashing algorithm produces a word of a constant amount of bits. This word cannot be decrypted back to the assembly code. But, it is statistically almost sure that only the dll produced this code (finding another code that will be hashed to the same hash as the original code is not practical).
After we have the hashed assembly we encrypt it in RSA algorithm using the private key from the snk file. Only the assembly knows the private key, so only the assembly can be encrypted using that key. As we saw before the public key is distributed inside the resulting assembly, so it is known to everybody.

At the compilation of the referencing assembly: For every strong named assembly which is referenced the following process is done: The public key of the referenced assembly is hashed into a 16 bit word, which is called the public key token. You will be able to see this in the Manifest of the assembly after building using ildasm. It will appear under the appropriate reference.

So far we discussed compilation time actions done by the compiler. There are no implications to performance so far.
At run-time: Whenever a Strong Named assembly is loaded, the public key of the dll is first Hashed. The result of the hash should be the same as the public key token of that dll. In order to evaluate the signature, we Hash the dll. This will be the expected result after evaluating the digital signature. We take the digital signature of the dll assembly, and decipher it using RSA algorithm with the public key of the dll. The result should be the same as the hashed dll.
If the comparison failed, we have a problem and we know for sure that the dll was tampered with. The CLR will refuse to load the assembly in that case.

Why Do We Sign Assemblies?
The drawbacks of signing the assemblies are obvious. First, there is an overhead every time we load the assembly. The assembly will be loaded more slowly (Although this should not be too long). Second, we need to look after the snk file or we will loose the private key.

The advantage is that by signing the assemblies we provide reliability to the assembly. The client and you will be sure that the assembly was provided by you (of course the signature has nothing to do with certification for the assembly, and the assembly can still be malicious if you programmed it so).

There are cases where you must sign assemblies: If you place them in the GAC, or if you develop an Enterprise Service (COM+). There are more cases.

It is a best practice to always sign assemblies.

Getting Rid of the Snk File
After generating the snk file (by calling sn -k), we can call
sn -i keys.snk AssemblyKey
Now in the AssemblyInfo file, instead of updating the AssemblyKeyFile attribute (leave empty string), we need to update AssemblyKeyName:
[assembly: AssemblyKeyName("AssemblyKey")]
You can see that we can now use a string ("AssemblyKey" in this example) instead of an snk file.
The file snk file can now be deleted from the computer. We don't need it.

The sn application put the keys in the folder
"C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys" .

Delay Signing
In some scenarios, during development, the signing mechanism is unnecessary and inconvenient. In this case we can prepare the assembly for signing eventually, but for the time being tell the runtime not to validate the signature. When the appropriate time comes, and we wish to deploy the assembly, we will enable the signature validating. This process is called Delay Signing.
In order to delay sign the assembly:
1. Create an snk file: sn -k keys.snk.
2. Create an snk file which contains only the public key: sn -p keys.snk publicKey.snk
3. Go to AssemblyInfo file, and change the AssemblyDelaySign Attribute to true.
[assembly: AssemblyDelaySign(true)]
4. Change the AssemblyKeyFile Attribute to the publicKey.snk file
[assembly: AssemblyKeyFile("..\\..\\public.snk")]
5. Remove the request to validate the assembly: sn -Vr MyAssembly.dll

When we wish to stop the delay signing, and return to regular signing:
1. Re-sign the assembly with the original snk file: sn -R MyAssembly.dll ..\..\keys.snk
2. Enable the signature validation: sn -Vu MyAssembly.dll

Multi-File Assemblies

noreply@blogger.com (Yariv Hammer) — Tue, 14 Feb 2006 22:28:00 +0000


using System;
namespace ClassLibrary1
{
public class A
{
public void foo()
{
Console.WriteLine("A.foo()");
}
}
}

---------------------------------------------------
Class B (B.cs)
------------------------------------------------


using System;
namespace ClassLibrary1
{
public class B
{
public void foo()
{
A a = new A();
a.foo();
Console.WriteLine("A.foo()");
}
}
}

----------------------------------------------
As you can see B uses class A.

Now start Command-Line (Start->Programs->.NET 2003->Tools->Command Line Prompt).
Change directory to the folder of the files ( cd MyFolder ).
In that folder we have a.cs and b.cs .
Type the following lines (one by one):
----------------------------------------------


csc /t:module a.cs
csc /t:module b.cs /addmodule:a.netmodule
al /out:MyAssembly.dll /t:library a.netmodule b.netmodule

---------------------------------------------

Lets go over the code line by line:
csc /t:module a.cs
This line will compile a.cs (and any other file you might specify) into one netmodule file.
After the line is executed you can see in the folder a file called a.netmodule.
If you view the a.netmodule using ildasm, you can see that the structure of a.netmodule is similar to a regular assembly.

csc /t:module b.cs /addmodule:a.netmodule
As in class A, cladd B which resides in b.cs is compiled into a netmodule. the /addmodule directive is used to add a "reference" to a.netmodule. The reason we need this is because B used class A, so much like dlls we need a reference to all the netmodules containing classes that are used in the current netmodule we are trying to compile.
Again, a file called b.netmodule now exists.

al /out:MyAssembly.dll /t:library a.netmodule b.netmodule
al is the Assembly Linker. We use it in order to generate our Dll Assembly (using the /out directive). All the netmodules are specified.
After running this code we see a file MyAssembly.dll in the folder. Lets run ildasm on this assembly. There is only a Manifest to the assembly, and no types. Inside the manifest you will see the references to the netmodules. You can see that the dll do not contain the types, but it reference to them. This is important, because now we can replace the netmodules without the need to compile the assembly.

Note: Because the IDE do not support Multi-file assemblies, you will need to create batch files which compile the code for you. This can be quite tedious.

Advantages of Multi File Assemblies
Although the obvious disadvantage stated above, there are some benefits to this kind of deployment:
1. We can use multiple languages inside one assembly. Each language should be compiled in its own netmodule. This can't be done otherwise.
2. Modularity - We can replace netmodules without affecting other netmodules.
3. Late Loading - The netmodule will only be loaded if and when used.
4. Less network traffic while deploying. Only the changed netmodule will be transferred.

Also this can be useful when we have an infrastructure assembly (which is shared by many solutions), with only a subset of classes changing from solution to solution. A netmodule can be useful to compile the changing part, without the need to compile the other parts of the assembly.

Exploring .NET Assemblies

noreply@blogger.com (Yariv Hammer) — Tue, 14 Feb 2006 18:23:00 +0000

Maintaining a List of All Connected Clients - A Remoting Tutorial

noreply@blogger.com (Yariv Hammer) — Sat, 28 Jan 2006 11:55:00 +0000

Introduction
This tutorial continue the the list of Remoting tutorials in this blog. In my last tutorial I showed how to recover from disconnecions both in the server and the client.
Now I am going to demonstrate how to maintain a list of connected clients both in the server and the clients. At the end, we will have a window that looks like a chat room, with all the connected users listed on the form.

The starting point of this tutorial is the end point of the previous one, so be sure to read my previous one first.

Full source code (C#) can be downloaded from here (~350 KB)

Step 1 - Create an IClientsManager Interface
In the Common assembly we will add a new interface called IClientsManager.
Here is the code:
-------------------------------------------



using System.Collections;
namespace Common
{
public interface IClientsManager
{
long RegisterNewClient();
bool NotifyClientAlive(long clientId);
bool IsClientConnected(long clientId);
ICollection GetListOfActiveClients();
}
}

--------------------------------------------------------
The client will be identified by a unique id, given by the server. Later you can extend this to be a full ClientInfo class. For now a number will do.
The interface IClientsManager has 4 methods. RegisterNewClient will be called by the client when it connects to the server. The server will return the new Id.
NotifyClientAlive will be called by the client once a period. When the method is no longer called, the server can know that the client is disconnected and thus notify the other clients.
IsClientConnected will help clients ask the server whether another client is connected.
GetListOfActiveClients will be used by the clients to refresh their list of active clients.

Step 2 - Extending the Messages
Before we jump for the implementation of the new interface we need to do some modifications.
In order to distinguish between custom messages raised by the clients, and system messages such as client disconnections, we will create a new type of message: SystemMessage.

First we will change a bit the Message class (in Common assembly)
--------------------------------------------


[Serializable()]
public class Message
{
public enum MessageType
{
Custom,
System
}
public string _msg;
public Message(string msg)
{
this._msg = msg;
}
public string Text
{
get { return _msg; }
}
public virtual MessageType Type
{
get { return MessageType.Custom;}
}
}

--------------------------------------------------

What I've done here is add an enumeration MessageType. If the message is a string message sent by a client (as before) then the message is a Custom message. If the message is sent by the server to notify about the connections or disconnection of a client then type is System.

Now we will derive from Message to create a new class SystemMessage. I put the class in the Message.cs file right under the Message class.
-------------------------------------------------------


[Serializable()]
public class SystemMessage:Message
{
private SystemMessageType _type;
private long _clientId;
public enum SystemMessageType
{
ClientConnected,
ClientDisconnected
}
public SystemMessage(SystemMessageType type, long clientId, string message):
base(message)
{
_type = type;
_clientId = clientId;
}
public override Common.Message.MessageType Type
{
get { return MessageType.System; }
}
public SystemMessageType SystemType
{
get { return _type; }
}
public long ClientId
{
get { return _clientId; }
}
}

---------------------------------------------------------
The SystemMessageType enumeration contains client connected or client disconnected types of messages. Later we might want to add more system messages. The SystemType property holds this information.
The ClientId property will be used in order to know which client connected or disconnected.

Note: I must say that rethinking about this design, I don't like it. It is very hard to extend the Message using inheritance. I would much prefer to use a pattern such as the Tag property of a Control (extend the message by composition instead of inheritance). But lets leave it like this at this point.

We will return later to modify further the Message class.

Now we add a method, BroadcastSystemMessage to the Broadcaster class in the Server:
--------------------------------------------


[Serializable()]
public class Broadcaster:MarshalByRefObject,IBroadcaster
{
public event MessageArrivedHandler MessageArrived;
public void BroadcastMessage(Message msg)
{
SafeInvokeEvent(msg);
}
public void BroadcastSystemMessage(SystemMessage msg)
{
SafeInvokeEvent(msg);
}
private void SafeInvokeEvent(Message msg)
{
if (MessageArrived == null)
return;
MessageArrivedHandler mah=null;
foreach(Delegate del in MessageArrived.GetInvocationList())
{
try
{
mah = (MessageArrivedHandler)del;
mah(msg);
}
catch (Exception ex)
{
Console.Write(ex.Message);
MessageArrived -= mah;
}
}
}
public override object InitializeLifetimeService()
{
return null;
}
}

------------------------------------------------
The BroadcastMessage and BroadcastSystemMessages are identical. We only make a distinction in order for our code to be more readable. Note that the client cannot invoke this new method because we did not add the method to the IBroadcaster interface. This is good, because only the server should raise system events.
By now you should have guessed that we are going to use our already implemented Broadcaster to distribute the connections and disconnections of clients. Thats the power of a good and solid well-designed system.

Last at this step we need to extend the functionality of MessageBroadcaster in the client. The class will raise the SystemMessageArrived event, so the client's objects can easily distinguish between the two types of events:
---------------------------------------------------------



using System;
using System.Net.Sockets;
using System.Threading;
using Common;
namespace Client
{
public class MessageBroadcaster:IBroadcaster
{
private IBroadcaster _bcaster = null;
private BroadcastEventHelper _eventHelper = null;
public MessageBroadcaster()
{
if (ClientStartup.Connector.ServerAlive)
{
InitializeObjects();
}
ClientStartup.Connector.ServerDisconnected += new EventHandler(Connector_ServerDisconnected);
ClientStartup.Connector.ServerReconnect += new EventHandler(Connector_ServerReconnect);
}
public void BroadcastMessage(Message msg)
{
if (_bcaster == null)
throw new ServerNotAliveException();
try
{
_bcaster.BroadcastMessage(msg);
}
catch (SocketException ex)
{
Console.WriteLine(ex.Message);
}
catch (ThreadAbortException ex)
{
Console.WriteLine(ex.Message);
}
}
private void HandleMessage(Message msg)
{
switch (msg.Type)
{
case Message.MessageType.Custom:
if (MessageArrived != null)
MessageArrived(msg);
break;
case Message.MessageType.System:
if (SystemMessageArrived != null)
SystemMessageArrived(msg);
break;
}
}
private void InitializeObjects()
{
_bcaster = (IBroadcaster)RemotingHelper.GetObject(typeof(IBroadcaster));
_eventHelper = new BroadcastEventHelper();
_eventHelper.MessageArrivedLocally += new MessageArrivedHandler(HandleMessage);
_bcaster.MessageArrived += new MessageArrivedHandler(_eventHelper.LocallyHandleMessageArrived);
}
private void Connector_ServerDisconnected(object sender, EventArgs e)
{
_bcaster = null;
_eventHelper = null;
}
private void Connector_ServerReconnect(object sender, EventArgs e)
{
InitializeObjects();
}
public event MessageArrivedHandler MessageArrived;
public event MessageArrivedHandler SystemMessageArrived;
}
}

--------------------------------------------------------
Step 3 - Implementing the ClientsManager Class
Now we are more than ready to implement the IClientsManager interface. Add a new class to the Server assembly called ClientsManager, derived from MarshalByRefObject and implementing the new IClientsManager interface.
First the code:
------------------------------------------------


using System;
using System.Collections;
using System.Timers;
using Common;
namespace Server
{
public class ClientsManager:MarshalByRefObject, IClientsManager
{
private Timer _aliveTimer = new Timer(1000);
private Hashtable _currentClients = new Hashtable();
private long _currentMaxClientId = -1;
public ClientsManager()
{
_aliveTimer.Elapsed += new ElapsedEventHandler(aliveTimer_Elapsed);
_aliveTimer.Start();
}
public override object InitializeLifetimeService()
{
return null;
}
public long RegisterNewClient()
{
long id = ++_currentMaxClientId;
_currentClients[id] = DateTime.Now.Ticks;
Broadcaster bcast = (Broadcaster) RemoteSingletonObjectsList. Instance. GetRemoteSingletonObject( typeof(Broadcaster));
bcast. BroadcastSystemMessage (new SystemMessage(SystemMessage.SystemMessageType. ClientConnected, id,""));
return id;
}
public bool NotifyClientAlive(long clientId)
{
if (IsClientConnected(clientId))
{
_currentClients[clientId] = DateTime.Now.Ticks;
return true;
}
return false;
}
public bool IsClientConnected(long clientId)
{
return _currentClients.ContainsKey(clientId);
}
public ICollection GetListOfActiveClients()
{
return _currentClients.Keys;
}
private void aliveTimer_Elapsed(object sender, ElapsedEventArgs e)
{
_aliveTimer.Stop();
long now = DateTime.Now.Ticks;
foreach (long id in _currentClients.Keys)
{
long lastTicks = (long)_currentClients[id];
if (now - lastTicks >= 20000000)
{
_currentClients.Remove(id);
Broadcaster bcast = (Broadcaster) RemoteSingletonObjectsList. Instance.GetRemoteSingletonObject( typeof(Broadcaster));
bcast.BroadcastSystemMessage( new SystemMessage(SystemMessage.SystemMessageType. ClientDisconnected,id,""));
break;
}
}
_aliveTimer.Start();
}
}
}

-------------------------------------------------------
_currentClients is a HashTable - the keys are the clients Ids of connected clients. The values are time stamps. The Timer (_aliveTimer) will elapse every second, and check the timestamps. If a client failed to call NotifyClientAlive for more then 20 seconds or so then the server will remove the client from _currentClients and notify everybody using the BroadcastSystemMessage method of Broadcaster.
When a client calls RegisterNewClient, it is added to _connectedClients, and a new Id is returned. The Ids are resources handled by this class. In our case the Ids are sequential, so each client gets an Id larger by 1 than the previous client. This way we ensure that the Ids are unique. A system event will be broadcasted, notifying everybody about the new client.
Last, the NotifyClientAlive should be called by clients, passing their Ids, once in a while. The timestamp will be updated every call. This way if a client fails to notify the server, the _aliveTimer will clean it up.

Next we register the new class for remoting. Open the App.Config of the server and add this line (you should already know where to put the line - in the "service" tag)
------------------------------------------------------------


<wellknown mode= "Singleton" type= "Server.ClientsManager, Server" objectUri= "ClientsManager.soap"/>

------------------------------------------------------------

We also need to register the class in Client's App.Config file. Add this line to the "client" tag:
------------------------------------------------------------


<wellknown type= "Common.IClientsManager, Common" url= "tcp://localhost:16784/ EventServer/ClientsManager.soap"/>

------------------------------------------------------------
Step 4 - Changing ClientConnector Class in the Client
The ClientConnector class was created in the previous tutorial. Its purose is throwing events whenever the client is connected and disconneted to the server.
We will now add more functionality to this class.
-------------------------------------------------------------



using System;
using System.Threading;
using System.Timers;
using Common;
using Timer = System.Timers.Timer;
namespace Client
{
public class ClientConnector
{
public ClientConnector()
{
this.ServerReconnect += new EventHandler (ClientConnector_ServerReconnect);
this.ServerDisconnected += new EventHandler (ClientConnector_ServerDisconnected);
_serverConnectivityTimer = new Timer(1000);
_serverConnectivityTimer.Elapsed += new ElapsedEventHandler(serverConnectivityTimer_Elapsed);
_serverConnectivityTimer.Start();
}
public event EventHandler ServerDisconnected;
public event EventHandler ServerReconnect;
private Timer _serverConnectivityTimer;
private void serverConnectivityTimer_Elapsed(object sender, ElapsedEventArgs e)
{
_serverConnectivityTimer.Stop();
CheckServerConnectivity();
_serverConnectivityTimer.Start();
}
private bool _serverIsAlive = false;
private void CheckServerConnectivity()
{
try
{
if (_serverIsAlive && IsClientIdValid)
{
IClientsManager manager = (IClientsManager)RemotingHelper.GetObject(typeof(IClientsManager));
manager.NotifyClientAlive(this.ClientId);
}
IServerConnector serverConnector = (IServerConnector) RemotingHelper.GetObject (typeof(IServerConnector));
bool isAlive = serverConnector.IsAlive;
if (isAlive && !_serverIsAlive)
SetServerAlive();
}
catch (Exception ex)
{
Console.WriteLine(ex.Message);
Thread t = new Thread(new ThreadStart(SetServerNotAlive));
t.Start();
t.Join();
}
}
private void SetServerAlive()
{
if (!_serverIsAlive && ServerReconnect != null)
ServerReconnect(this,EventArgs.Empty);
_serverIsAlive = true;
}
public void SetServerNotAlive()
{
if (_serverIsAlive && ServerDisconnected != null)
ServerDisconnected(this,EventArgs.Empty);
_serverIsAlive = false;
}
public bool ServerAlive
{
get
{
_serverConnectivityTimer.Stop();
CheckServerConnectivity();
_serverConnectivityTimer.Start();
return _serverIsAlive;
}
}
private long _clientId = -1;
public event EventHandler ClientIdChanged;
public long ClientId
{
get { return _clientId; }
}
public bool IsClientIdValid
{
get { return _clientId >= 0; }
}
private void ClientConnector_ServerReconnect (object sender, EventArgs e)
{
IClientsManager manager = (IClientsManager) RemotingHelper.GetObject (typeof(IClientsManager));
_clientId = manager.RegisterNewClient();
if (ClientIdChanged != null)
ClientIdChanged(this,EventArgs.Empty);
}
private void ClientConnector_ServerDisconnected (object sender, EventArgs e)
{
_clientId = -1;
}
}
}

------------------------------------------------------------
the _clientId property is by default equal to -1. When the event ServerReconnect is raised, we assign the client with a new client Id, by calling RegisterNewClient (See step 3). The server will notify the other clients (Next step). When the event ServerDisconnected is raised we assign the client again with Id -1.
We already had a timer to check if the server is alive (remember the ServerConnector class from the previous tutorial?). We now need to call NoitifyClientAlive in the server (See step 3).
Last I added the ClientIdChanged, because it is a good practice to have <Property>Changed events.

Step 5 - Implementing the Client Side Object
Add a new class to the Client assembly, called ConnectedClients.
------------------------------------------------------------


using System;
using System.Collections;
using Common;
namespace Client
{
public class ConnectedClients
{
private MessageBroadcaster _message = new MessageBroadcaster();
private ArrayList _activeClients = new ArrayList();
public ConnectedClients()
{
_message.SystemMessageArrived += new MessageArrivedHandler(Message_SystemMessageArrived);
ClientStartup.Connector.ServerDisconnected += new EventHandler(Connector_ServerDisconnected);
ClientStartup.Connector.ServerReconnect += new EventHandler(Connector_ServerReconnect);
}
private void Message_SystemMessageArrived(Message msg)
{
SystemMessage systemMessage = msg as SystemMessage;
switch (systemMessage.SystemType)
{
case SystemMessage.SystemMessageType.ClientConnected:
AddClient(systemMessage.ClientId);
break;
case SystemMessage.SystemMessageType.ClientDisconnected:
if (systemMessage.ClientId == ClientStartup.Connector.ClientId) return;
_activeClients.Remove(systemMessage.ClientId);
if (ClientRemoved != null)
ClientRemoved(this,new ClientEventArgs( systemMessage.ClientId));
break;
}
}
private void AddClient(long clientId)
{
if (clientId == ClientStartup.Connector.ClientId) return;
_activeClients.Add(clientId);
if (ClientAdded != null)
ClientAdded(this,new ClientEventArgs(clientId));
}
public ArrayList ActiveClients
{
get { return _activeClients; }
}
public event ClientEventHandler ClientAdded;
public event ClientEventHandler ClientRemoved;
public event EventHandler ClientsCleared;
public class ClientEventArgs:EventArgs
{
public long ClientId
{
get { return _clientId; }
}
public ClientEventArgs(long clientId)
{
this._clientId = clientId;
}
private long _clientId = -1;
}
public delegate void ClientEventHandler(object sender, ClientEventArgs e);
private void Connector_ServerDisconnected(object sender, EventArgs e)
{
ClearClients();
}
private void ClearClients()
{
_activeClients.Clear();
if (ClientsCleared != null)
ClientsCleared(this,EventArgs.Empty);
}
private void Connector_ServerReconnect(object sender, EventArgs e)
{
RefreshList();
}
public void RefreshList()
{
ClearClients();
IClientsManager manager = (IClientsManager)RemotingHelper.GetObject(typeof(IClientsManager));
ICollection clients = manager.GetListOfActiveClients();
foreach (long id in clients)
AddClient(id);
}
}
}

-----------------------------------------------------------
I will now explain the class fully (It is quite long).
First of all we have the ActiveClients property. This property is the whole purpose of this class, right?
The class has 3 events: ClientAdded, ClientRemoved, and ClientsCleared (less important). The ClientEventHandler is defined within the scopr of this class, and the ClientEventArgs as well.
The class uses three events:
1. The SystemMessageArrived (See step 2) of MessageBroadcaster. The event indicate that a client connected or disconnected. In both cases we check that the event is not raised by chance by the client itself. After that we add the client Id or remove it from _activeClients list. Then we raise the ClientAdded or ClientRemoved event.
2. ServerReconnect of ClientConnector. In this case we refresh the list of clients by calling GetListOfActiveClients (See step 3), and adding each client to _activeClients.
3. ServerDisconnected of ClientConnector. We clear the clients list, and raise the ClientsCleared event.

Next, we need to add an instance of the ConnectedClients class to ClientStartup class (same as we did for ClientConnector). Change the ClientStartup class as follows:
-----------------------------------------------------



using System;
using System.Runtime.Remoting;
using System.Windows.Forms;
namespace Client
{
public class ClientStartup
{
private static ClientConnector _connector;
public static ClientConnector Connector
{
get
{ return _connector; }
}
private static ConnectedClients _clients;
public static ConnectedClients ConnectedClients
{
get { return _clients; }
}
[STAThread]
static void Main()
{
InitRemoting();

_connector = new ClientConnector();
_clients = new ConnectedClients();
Application.Run(new ClientForm());
}
private static void InitRemoting()
{
string fileName = "client.exe.config";
RemotingConfiguration.Configure(fileName);
}
}
}

-----------------------------------------
Step 6 - Add a Client Id to the Message
We can now add to the Message the property SenderId in order to know which client sent the message (we did not know this information before). For the special case of the Server sending messages, we will set the SERVER_ID to be -100 (arbitrarily selected).
Change the Message class (in Common assembly) as follows:
-------------------------------------------------------



[Serializable()]
public class Message
{
public enum MessageType
{
Custom,
System
}
public string _msg;
protected long _senderId;
public Message(long senderId, string msg)
{
this._msg = msg;
this._senderId = senderId;
}
public string Text
{
get { return _msg; }
}
public virtual MessageType Type
{
get { return MessageType.Custom;}
}
public static long SERVER_ID
{
get { return -100; }
}
public string TextWithSenderId
{
get
{
if (!IsSenderServer)
return "Client " + SenderId.ToString() + ": " + Text;
else
return "Server: " + Text;
}
}
public virtual long SenderId
{
get { return _senderId; }
}
public bool IsSenderServer
{
get { return _senderId == SERVER_ID; }
}
}
[Serializable()]
public class SystemMessage:Message
{
private SystemMessageType _type;
private long _clientId;
public enum SystemMessageType
{
ClientConnected,
ClientDisconnected
}
public SystemMessage(SystemMessageType type, long clientId, string message):
base(SERVER_ID, message)
{
_type = type;
_clientId = clientId;
}
public override Common.Message.MessageType Type
{
get { return MessageType.System; }
}
public SystemMessageType SystemType
{
get { return _type; }
}
public long ClientId
{
get { return _clientId; }
}
}

------------------------------------------------------
Notice the TextWithSenderId method, which formats the message with the identity of the sender.

Demo
Lets test things. We will modify both ClientForm and ServerForm.

ServerForm:
So far we had a ListBox for messages. We will add another ListBox for the clients list.
This is the code (without theauto-generated code):
------------------------------------------------------



public class ServerForm : Form
{
private ListBox lsbMessages;
private Button btnSend;
private ListBox lsbConnectedClients;

private Container components = null;
public ServerForm()
{
InitializeComponent();
_bcast = (Broadcaster) RemoteSingletonObjectsList.Instance. GetRemoteSingletonObject( typeof(Broadcaster));
_bcast.MessageArrived += new MessageArrivedHandler(bcast_MessageArrived);
}

(...)

private Broadcaster _bcast = null;
public void bcast_MessageArrived(Message msg)
{
if (msg.Type == Message.MessageType.Custom)
{
_msgToShow = msg;
Thread t = new Thread(new ThreadStart(ShowMessage));
t.Start();
}
else
{
HandleSystemMessage((SystemMessage)msg);
}
}
private void HandleSystemMessage (SystemMessage systemMessage)
{
switch (systemMessage.SystemType)
{
case SystemMessage.SystemMessageType. ClientConnected:
lsbConnectedClients.Items.Add("Client " + systemMessage.ClientId);
break;
case SystemMessage.SystemMessageType. ClientDisconnected:
lsbConnectedClients.Items.Remove("Client " + systemMessage.ClientId);
break;
}
}
private Message _msgToShow=null;
private void ShowMessage()
{
if (_msgToShow == null) return;
lsbMessages.Items.Add(_msgToShow.TextWithSenderId);
lsbMessages.SelectedIndex = lsbMessages.Items.Count -1;
_msgToShow = null;
}
private long index=0;
private void btnSend_Click(object sender, System.EventArgs e)
{
_bcast.BroadcastMessage(new Message(Message.SERVER_ID, "Server: This is message #" + (index++).ToString()) );
}

-----------------------------------------------------

ClientForm:
Again, we add another ListBox to show the list of active clients. Here is the code (without the auto-generated code):
----------------------------------------------------------



public class ClientForm : System.Windows.Forms.Form
{
private System.Windows.Forms.ListBox lsbMessages;
private System.Windows.Forms.Button btnSendMessage;
private System.Windows.Forms.ListBox lsbClients;
private System.ComponentModel.Container components = null;
public ClientForm()
{
InitializeComponent();
_messageBroadcaster.MessageArrived += new Common.MessageArrivedHandler(broadcaster_MessageArrived);
ClientStartup.ConnectedClients.ClientAdded += new Client.ConnectedClients.ClientEventHandler (ConnectedClients_ClientAdded);
ClientStartup.ConnectedClients.ClientRemoved += new Client.ConnectedClients.ClientEventHandler (ConnectedClients_ClientRemoved);
ClientStartup.ConnectedClients.ClientsCleared += new EventHandler(ConnectedClients_ClientsCleared);
ClientStartup.Connector.ClientIdChanged += new EventHandler (Connector_ClientIdChanged);
ClientStartup.Connector.ServerDisconnected += new EventHandler(Connector_ServerDisconnected);
ClientStartup.Connector.ServerReconnect += new EventHandler (Connector_ServerReconnect);
if (ClientStartup.Connector.IsClientIdValid)

{
this.Text = "Client " + ClientStartup.Connector.ClientId;

ClientStartup.ConnectedClients.RefreshList();

}
else
this.Text = "Client Not Connected";
}

(...)

MessageBroadcaster _messageBroadcaster = new MessageBroadcaster();
private long _index=0;
private void btnSendMessage_Click (object sender, System.EventArgs e)
{
Thread t = new Thread(new ThreadStart(SendMessage));
t.Start();
}
private void SendMessage()
{
try
{
Message msg = new Message (ClientStartup.Connector.ClientId, "This is message #" + (_index++).ToString());
_messageBroadcaster.BroadcastMessage(msg);
msg = null;
}
catch (ServerNotAliveException ex)
{
lsbMessages.Items.Add(ex.Message);
lsbMessages.SelectedIndex = lsbMessages.Items.Count-1;
}
}
private void broadcaster_MessageArrived(Message msg)
{
lsbMessages.Items.Add(msg.TextWithSenderId);
lsbMessages.SelectedIndex = lsbMessages.Items.Count-1;
}
private void Connector_ServerDisconnected(object sender, EventArgs e)
{
this.Text = "Client Not Connected";
}
private void Connector_ServerReconnect(object sender, EventArgs e)
{
this.Text = "Client " + ClientStartup.Connector.ClientId;
}
private void Connector_ClientIdChanged(object sender, EventArgs e)
{
this.Text = "Client " + ClientStartup.Connector.ClientId;
}
private void ConnectedClients_ClientAdded(object sender, Client.ConnectedClients.ClientEventArgs e)
{
lsbClients.Items.Add("Client " + e.ClientId.ToString());
}
private void ConnectedClients_ClientRemoved(object sender, Client.ConnectedClients.ClientEventArgs e)
{
lsbClients.Items.Remove("Client " + e.ClientId.ToString());
}
private void ConnectedClients_ClientsCleared(object sender, EventArgs e)
{
lsbClients.Items.Clear();
}
}

----------------------------------------------------------

Run the server and few instances of the client. See the Ids of the clients in the header of the form, and the lists update both in the server and the clients form. Try to disconnect the server and the client. Try to send messages.

Summary
This was a tutorial for a fully functional server-client application using Remoting.NET technology. At this point you have a generic Broadcaster for events, a reconnections mechanism, and a list of connected clients. I don't think that I have ever seen such a tutorial for Remoting over the net (you are welcome to correct me on this).

The next step will be the most impressive (in my opinion): a Multicaster class, which will enable distributing events to selected clients instead of all the clients.

Comments
Two things I don't like about the code I have posted. The first is the use of inheritance to create a SystemMessage (you saw at step 2 how much work was involved, and how many layers were effected). The second is the use of long Id instead of a class to represent the Client. It should not be hard to fix the second problem.

I will finish my (very long) article by saying that this was a very complex code to design, program and document. It works as far as I can tell, but if you see a bug, or a better way to do something, you are more than welcome to comment. Any bugs I will try to fix.

DegreesUpDown Control

noreply@blogger.com (Yariv Hammer) — Mon, 09 Jan 2006 20:50:00 +0000

Introduction
The code I will post here is for a custom Control called DegreesUpDown. The control is similar to a NumericUpDown only it shows degrees (from 0 to 359). The nice thing about it is that the degrees are shown in 3 digits (000, 050, 180, etc...).

The Code
You might have thought that the control inherits from NumericUpDown. Well, it does not. It inherits from DomainUpDown which is much more flexible. I cannot format the way numbers look in NumericUpDown, so the trick is to convert strings into numeric values.

------------------------------------------------


Imports System.ComponentModel
Imports CommonControls.CGraphicsCommon
Imports System.Drawing

Public Class DegreesUpDown
   Inherits System.Windows.Forms.DomainUpDown

#Region " Windows Form Designer generated code "
Public Sub New()
   MyBase.New()
'This call is required by the Windows Form Designer.
   InitializeComponent()
   InitializeGraphics()
End Sub

'UserControl overrides dispose to clean up the component list.
Protected Overloads Overrides Sub Dispose(ByVal disposing As Boolean)
   If disposing Then
      If Not (components Is Nothing) Then
         components.Dispose()
      End If
   End If
   MyBase.Dispose(disposing)
End Sub

'Required by the Windows Form Designer
Private components As System.ComponentModel.IContainer
'NOTE: The following procedure is required by the Windows Form Designer
'It can be modified using the Windows Form Designer.
'Do not modify it using the code editor.
<System.Diagnostics.DebuggerStepThrough()> _
Private Sub InitializeComponent()
   '
   'DegreesUpDown
   '
   Me.Wrap = True
End Sub
#End Region

Private Sub InitializeGraphics()
   Me.Font = CommonFont
   Me.BackColor = Color.FromArgb(238, 238, 238)
   Me.BorderStyle = BorderStyle.FixedSingle
End Sub

Private Sub InitValues()
   Me.Items.Clear()
   Dim vals As ArrayList = New ArrayList(360)
   For i As Integer = 359 To 0 Step -1
      vals.Add(ConvertTo3Digits(i))
   Next
   Me.Items.AddRange(vals)
End Sub

Public Shared Function ConvertTo3Digits(ByVal i As Integer) As String
   If (i >= 100) Then Return i.ToString()
   If (i >= 10) Then Return "0" + i.ToString()
   If (i >= 0) Then Return "00" + i.ToString()
   Return "000"
End Function

<Browsable(False)> _
Public Shadows ReadOnly Property Items() As DomainUpDownItemCollection
   Get
      Return MyBase.Items
   End Get
End Property

<Browsable(False), _
Bindable(True)> _
Public Property Value() As Long
   Get
      If (IsNothing(Me.SelectedItem)) Then Return 0
      Return Long.Parse(Me.SelectedItem)
   End Get
   Set(ByVal Value As Long)
      If IsNothing(Value) Then
         Me.SelectedItem = "000"
         RaiseEvent ValueChanged(Me, EventArgs.Empty)
         Exit Property
      End If
      If (Value >= 360 Or Value < 0) Then
         Me.Text = Value.ToString
         FixHeading()
      Else
         Me.SelectedItem = ConvertTo3Digits(Value)
      End If
      RaiseEvent ValueChanged(Me, EventArgs.Empty)
   End Set
End Property

<Category("Action"), _
Description("Raised when the value is changed")> _
Public Event ValueChanged As EventHandler

Private Sub DegreesUpDown_SelectedItemChanged(ByVal sender As Object, ByVal e As System.EventArgs) Handles MyBase.SelectedItemChanged
   RaiseEvent ValueChanged(Me, EventArgs.Empty)
End Sub

Protected Overrides Sub OnCreateControl()
   Me.Items.Clear()
   If Not DesignMode Then
      Dim vals As ArrayList = New ArrayList(360)
      For i As Integer = 359 To 0 Step -1
         vals.Add(ConvertTo3Digits(i))
      Next
      Me.Items.AddRange(vals)
      Me.SelectedIndex = 359
   Else
      Me.Text = "000"
   End If
End Sub

Private Sub DegreesUpDown_Leave(ByVal sender As Object, ByVal e As System.EventArgs) Handles MyBase.Leave
   FixHeading()
End Sub

Private Sub FixHeading()
   Try
      Dim i As Integer = Integer.Parse(Me.Text)
      If i < 0 Then
         Me.SelectedIndex = ((-i) Mod 360) - 1
      End If
      If i > 359 Then
         Me.SelectedIndex = 359 - (i Mod 360)
      End If
      If i < 359 And i > 0 Then _
         Me.SelectedIndex = 359 - i
   Catch ex As Exception
      Me.SelectedIndex = 359
   End Try
End Sub

Protected Overrides Sub UpdateEditText()
Try
   Dim i As Integer = Integer.Parse(Me.Text)
   If (i > 359 Or i < 0) Then
      FixHeading()
   Else
      If Me.Text.Length <> 3 Then _
         FixHeading()
   End If
   Catch ex As Exception
      FixHeading()
   Finally
      MyBase.UpdateEditText()
   End Try
End Sub

<Browsable(False)> _
Public Shadows Property Text() As String
   Get
      Return MyBase.Text
   End Get
   Set(ByVal Value As String)
      MyBase.Text = Value
   End Set
End Property

End Class

------------------------------------------------

Explanations
On initialization, in method InitValues, I create 360 strings (000,001,...,359), and add them to the items collection of the DomainUpDown base. The method ConvertTo3Digits does the convertion from int to 3 digits string.
In order to make the control fill more like a NumericUpDown, I added a Value property, which is numeric. Convertion to string and vice versa is done. The event ValueChanged also emulate the corresponding event of NumericUpDown control.
The Items and Text properties is no longer needed for use, so they are shadowed and marked as Browsable false.

FixHeading method is a nice feature - when the user enters a number out of range 0..359, the control automatically convert the number to the appropriate degree (For example: -90 => 270).

Extensions
You can extend the control by adding an Increment property (pressing on the UpDown buttons as of now only increase or decrease by one).
Also, you can add Maximum and Minimum properties.
In addition, the range -180..180 can be useful.

Print Screen And Save It to File

noreply@blogger.com (Yariv Hammer) — Sun, 08 Jan 2006 18:15:00 +0000

Introduction
A task which is quite common is to press the Print Screen button, and save the screen in Paint application as an Image file.
If you ever wondered how to perform such a task in .NET, here is the solution.

Solution
The following snippet of code does the trick:
------------------------------------------


SendKeys.Send("+{PRTSC}");
if (Clipboard.GetDataObject() != null)
{
   IDataObject data = Clipboard.GetDataObject();
   if (data.GetDataPresent(DataFormats.Bitmap))
   {
      Image image = (Image)data.GetData(DataFormats.Bitmap,true);
      image.Save("image.jpg",ImageFormat.Jpeg); // pick your format and path
   }
}

------------------------------------------

First we use the Sendkeys class. This class is not very famous, but it is quite nice. Whenever you want to emulate a key press you can call the Send method with the key you want to press. In our case we don't want just a key - we want to press the Print Screen key combined with the Ctrl key. "+" stands for Ctrl, and "PRTSC" stands for the Print Screen key.

From here on its all about the Clipboard. A press on Print Screen actually copies the screen image as it is into the clipboard. Instead of pasting it in Paint and saving it, we will use the Clipboard class. GetDataObject is the method to get the object currently in the clipboard. Unfortunately, we only get an IDataObject interface, without any knowledge of the actual type. So we call GetDataPresent to varify that the object is indeed an image. Once we are there, we call the GetData method which finally reveals the Image object. The Save method will store the image in any format we like and in any location.

Using JoinView to Show Queries From Multiple Tables

noreply@blogger.com (Yariv Hammer) — Sat, 07 Jan 2006 18:48:00 +0000

Introduction
In MS-Access there is the possibility to show queries from two tables. Take for example the case of Order and Product tables in the Northwind database. Say we want to show in a grid the amount of items purchased (per Order) with the appropriate product name and price (from the Product table). We are able to do so if there is a relation between the tables, and by using SQL Join clause.
This effect is not available in ADO.NET. Once the data is filled into the DataSet, there is no built-in way to produce this kind of query. Sure, we can show a Master-Detail view of the data. But in order to show data from several tables in one DataGrid at once we will need to work hard. DataGrid can only show data from one DataTable at a time, and DataView can only reflect data of one table.
This is a very big problem. One way of solving it is getting the data into a DataSet from the database itself using a Select Command with Join clauses. The DataSet should have a DataTable with the same schema as the resulting Join query. While this is possible in some cases, other cases require some kind of mechanism to have a joined view without accessing the database.
For example, say I have a server and clients. The server does all the access to the database. The client gets the DataSets from the server. If I want to show the data in a DataGrid in the client, I cannot afford to approach the server again. Not only this is expensive, but it can also cause concurrency problems. I have all the data I need in memory, so why do I need to access the database again?

Solution
Microsoft comes to our aid. Obviously someone understood the problem, so he or she developed a class called JoinView which acts like a DataView class, but handles data with multiple DataTables with DataRelations set between them.
The code for the class (VB.NET), with examples of usage can be found here: http://support.microsoft.com/kb/325682/EN-US/
C# source code can be found here: http://www.valley.ru/~dmoiseev/q325682_csh.html

This class is the ONLY convenient way I could find to show the data from few related tables in one table without getting the data in this structure in the first place.

Disadvantages
Unfortunately, the JoinView class is not as convenient as the DataView class. Here are few of the drawbacks I could find when using this class:
1. You cannot edit the related columns - only the main table columns. The rest are read-only and I couldn't get passed that.
2. You cannot dynamically filter the rows!!! you will need to create a new JoinView whenever the filter is changed. This is a huge drawback, as instanciating a JoinView is probably expensive.
3. Apparently the AllowNew property works well if you you set it BEFORE you assign the JoinView as a DataSource to the grid. If you set the AllowNew property to False after you assign the DataSource, the result is unexpected (I got the Add New Row displayed, and when the user pressed on this line, an exception was thrown, saying: "AddNew is not allowed").
4. It works with column styles, but i needed to make some little changes.

Summary
Basically it was a good experience working with JoinView, although it is not perfect. As I said before, it is currently the only solution i know of to work with Join without getting the data from the database in that structure.

Some Thoughts
Why has Microsoft not provided us a proper way of doing a Join on the DataSet objects in-the-box? We have DataTables and DataRelations in .NET so the JoinView class seems to be a required piece. More importantly - someone realized the need, otherwise the JoinView class would not have been published - so why it is not provided in .NET 2005?

Why can't we use Command objects on DataSets? By allowing us to use SQL commands on DataSets we will have more strength in using DataSets.

Setting the Row Height of the Grid to Fit the Contents

noreply@blogger.com (Yariv Hammer) — Thu, 05 Jan 2006 19:20:00 +0000

Intorduction
It is very hard to set the row height of the DataGrid (Framework 1.1). Actually I was very surprised that it is not a built-in feature. Not only it is not built-in, but also it is a very non-trivial task.

Suppose I have a row with text containing the \n\r characters (meaning new line). In this case I need the row to have multiple lines. Try and put a text with this characters in a normal DataGrid - only the first row will appear, and the other lines can be reached by using the up and down arrw keys. I will show a way of showing all the lines.

The source code in this article was inspired from this article in CodeProject.

The Solution
If you followed my previous articles in my blog, you can guess that the solution involves ColumnStyles. You will need to create your own custom DataGridColumnStyle and use it in order to populate the grid. A reminder of ColumnStyles can be found here.

First, I implement a class called MultiLineColumnStyle derived from DataGridTextBoxColumn. This class has a property MultiLine which when set to true will show all the lines in the cell.
The trick of resizing the height of the row is in the GetMinimumHeight overrided method.
Here is the code
------------------------------------------------------------


public class MultiLineColumnStyle:DataGridTextBoxColumn
{
   public bool MultiLine
   {
      get
      { return _multiLine; }
      set
      { _multiLine = value; }
   }
   private int _currentCell = 0;
   private bool _multiLine = false;

   public void ResetIterations()
   {
      _currentCell = 0;
   }
   protected override int GetMinimumHeight()
   {
      if (!_multiLine)
         return base.GetMinimumHeight();
      // Get CurrencyManager
      CurrencyManager cur = (CurrencyManager)this.DataGridTableStyle.DataGrid.BindingContext[this.DataGridTableStyle.DataGrid.DataSource, this.DataGridTableStyle.DataGrid.DataMember];
      // Rows available?
      if(cur == null cur.Count == 0)
         return base.GetMinimumHeight();
      // Increment counter
      this._currentCell ++;
      // Initialize return value
      int retVal = base.GetMinimumHeight();
      // Calculate height of row at currentIteration 1
      retVal = this.CalcStringHeight(GetColumnValueAtRow(cur,currentCell - 1).ToString());
// Reset when last cell reached
      if(_currentCell == cur.Count)
         this.ResetIterations(); // sets currentIteration to 0
      return retVal;
   }
   private int CalcStringHeight(string s)
   {
      try
      {
         // Create graphics for calculation
         System.Drawing.Graphics g = this.TextBox.CreateGraphics();
         // Do measure, and add a bit (4 pixels for me)
         return (int)g.MeasureString(s,this.TextBox.Font).Height + 4;
      }
      catch
      {
         // Error, return default font height.
         return base.GetMinimumHeight();
      }
   }
}

------------------------------------------------------------
The GetMinimumHeight is called for each cell seperately starting with the topmost cell in the column. So the _currentCell variable is used to run through the cells - each call will increment this (thanks to the above website for the great idea).
Obtaining the CurrencyManager (to get the text of the cell) of the column is another problem, which is solved in a very long and not straight-forward way.
One last problem is the actual calculation of the height of the row which is done in the CalcStringHeight method - by using MeasureString method.

Indeed, very hard work!!!

Demo
Add to the main form of the application a DataGrid. Here is the Form.Load event handler:
---------------------------------------------------


private void Form1_Load(object sender, System.EventArgs e)
{
   DataTable dt = new DataTable("MyTable");
   dt.Columns.Add(new DataColumn("multiline",typeof(string)) );
   dataGrid1.DataSource = dt;
   DataRow dr;
   dr = dt.NewRow();
   dr["multiline"] = "vsvsdfsdf\n\rdfgdfgsd\n\rcvsdvgsf";
   dt.Rows.Add(dr);
   dr = dt.NewRow();
   dr["multiline"] = "gsddg\n\rasfsfswef";
   dt.Rows.Add(dr);

   DataGridTableStyle ts = new DataGridTableStyle();
   ts.MappingName = "MyTable";
   MultiLineColumnStyle cs = new MultiLineColumnStyle();
   cs.MappingName = "multiline";
   cs.HeaderText = "multiline";
   cs.MultiLine = true;
   ts.GridColumnStyles.Add(cs);
   dataGrid1.TableStyles.Add(ts);
}

-------------------------------------------------
Run the application, and you will see that all the rows have appropriate height.

Loading and Validating Xml Files

noreply@blogger.com (Yariv Hammer) — Wed, 04 Jan 2006 18:16:00 +0000

Source code in VB (with demo) can be downloaded from here (~35 KB)

Introduction
An Xml should be Well-Formed:
- must begin with the XML declaration
- must have one unique root element
- all start tags must match end-tags
- XML tags are case sensitive
- all elements must be closed
- all elements must be properly nested
- all attribute values must be quoted
- XML entities must be used for special characters

However, being Well-Formed is not enough. There can still be errors in the Xml. Those errors are in the logical aspects, rather than the syntax. Xml Schemas help us define the business rules of our Xmls. Xml Schemas are written in Xml and they support Data Types.

It is a good practice to use Xml Schemas always. Don't write just Xmls. Use schemas as well!!!

Xml and Xml Schemas In .NET
As you probably know there is a wide support for Xml in the .NET . The class XmlDocument is the DOM implementation in the .NET Framework. This is a very strong class. However, there is no easy support for loading and validating the Xml against its Schema.

Validating Against the Schema
My friend, Dror Givoli, who works with me, supplied a code to a class, ValidatingXmlDocument, derived from XmlDocument, which has a method called LoadAndValidate, with tons of overloads. Here are few:
-----------------------------------------------------------


Public Overloads Sub LoadAndValidate(ByVal filename As String, ByVal Schema As XmlSchema)
   MyBase.Load(filename)
   Validate(Schema)
End Sub
Public Overloads Sub LoadAndValidate(ByVal inStream As Stream, ByVal Schema As XmlSchema)
   MyBase.Load(inStream)
   Validate(Schema)
End Sub
Public Overloads Sub LoadAndValidate(ByVal txtReader As TextReader, ByVal Schema As XmlSchema)
   MyBase.Load(txtReader)
   Validate(Schema)
End Sub
Public Overloads Sub LoadAndValidate(ByVal reader As XmlReader, ByVal Schema As XmlSchema)
   MyBase.Load(reader)
   Validate(Schema)
End Sub
Public Sub LoadXmlAndValidate(ByVal xml As String, ByVal Schema As XmlSchema)
   MyBase.LoadXml(xml)
   Validate(Schema)
End Sub
Public Overloads Sub LoadAndValidate(ByVal filename As String, ByVal schemaFileName As String)
   Dim Schema As XmlSchema = XmlSchema.Read(New XmlTextReader(schemaFileName), AddressOf ValidationEventHandler)
   MyBase.Load(filename)
   Validate(Schema)
End Sub

----------------------------------------------------------
There are more. The Validate method is as follows:
----------------------------------------------------


Public Sub Validate(ByVal Schema As XmlSchema)
   Dim ms As New MemoryStream
   Me.Save(ms)
   ms.Position = 0
   Dim rdr As New XmlTextReader(ms)
   Dim vrdr As New XmlValidatingReader(rdr)
   vrdr.Schemas.Add(Schema)
   AddHandler vrdr.ValidationEventHandler, AddressOf ValidationEventHandler
   While vrdr.Read
   End While
End Sub

Private Sub ValidationEventHandler(ByVal sender As Object, ByVal args As ValidationEventArgs)
   Throw New XmlValidationException(args)
End Sub

--------------------------------------------------
Last there is an implementations of the method SaveAndValidate, again with tons of overloads:
--------------------------------------------------


Public Overloads Sub SaveAndValidate(ByVal filename As String, ByVal Schema As XmlSchema)
   Validate(Schema)
   Save(filename)
End Sub
Public Overloads Sub SaveAndValidate(ByVal outStream As System.IO.Stream, ByVal Schema As XmlSchema)
   Validate(Schema)
   Save(outStream)
End Sub
Public Overloads Sub SaveAndValidate(ByVal writer As System.IO.TextWriter, ByVal Schema As XmlSchema)
   Validate(Schema)
   Save(writer)
End Sub

-----------------------------------------
And there are more overloads.

Demo
Here is an example of how to use this class:
------------------------------------------

Dim vDoc As New ValidatingXmlDocument
Dim xmlFile As String = "c:\MyXmlFile.xml"
Dim schemaFile As String = "c:\MySchemaFile.xsd"
Try
   vDoc.LoadAndValidate(xmlFile, schemaFile)
Catch ex As XmlValidationException
   Console.Out.WriteLine(ex.Args.Message)
End Try

------------------------------------------

Acknowledgment
This code was given to me by Dror Givoli, in order to post it in my blog. Thanks Dror for sharing your knowledge with others.

Xml Schema Reader Application

noreply@blogger.com (Yariv Hammer) — Fri, 16 Dec 2005 16:13:00 +0000

Download XmlSchemaReader.zip from here (~200 KB)

Intoduction
There are several ways to handle Xmls in .NET . My favourite is DataSet.ReadXml method. It is fast, clean, efficient and productive.
Xml files are not that different from databases, although their use is somewhat different. The use of DataSet helps us as developers to use one API (which is ADO.NET) in order to handle both relational data when it is brought from the database or when it is brought from Xml files.

In order to read Xmls into Typed Datasets, or to make them valid, we should use Xml Schemas (xsd files). Now, designing Xml Schemas is a whole new ballgame. We can use the designer of VS.NET to help us, but I personally find it very awkward. Most of the time I know how my Xml file should look. I just don't know how the Schema file should look, and coding (or designing) it is a real pain. I also don't know how the DataSet will look when I import my Xml. Which elements are tables, which are fields, and so on. Sometimes DataRelations will be created for me by the ReadXml method, and primary keys too.

One more case which I find difficult, is when I get an already prepared xsd file, and it can be big. The person who designed the xsd may not even have an Xml file example for me. So it can be very difficult to work with it (I will need few hours spent to investigate the schema).

So here comes XmlSchemaReader for our aid.

The Application
XmlSchemaReader is a simple tool, written in C# by me, which is designed to address these issues. You simply load the Xml or Xsd file (by clicking on xml or xsd button, and then selecting it from the Open Dialog). The application will tell you if it is illegal to read it into a DataSet.

After the file is loaded the DataTables are seen in the ListBox in the left. When the selecting a table, the data is seen in the grid in Data tab. The data can be edited and then saved by pressing the Save button (be careful - it will be saved into the file specified in the TextBox). A neat feature is to attach the schema into an Xml file with data (By clicking Save Schema). So I can write my xml first (outside, in notepad for example), and then generate the schema later.

Two more tabs are Column and Relations. The Columns tab will show you the generated columns for each table, the datatype, and if it is a primary key (+ or -). Last, the Relations tab will show you the generated relations from the Xml.

Best Practice
I suggest you follow these steps:
1. Write the xml in Notepad, as you think it should look.
2. Load the xml to the XmlSchemaReader application.
3. Look at the tables and columns. Add data if you wish and save. I suggest you create a backup before saving.
4. Save the schema into a seperate file, or into the xml file.
5. Edit the schema outside the XmlSchemaReader application. For example, change types of columns.
6. Whenever you need a view, load the file into the application.

It really saved me a lot of time!!!

Last Words
I am giving the XmlSchemaReader for free, without any profit on my part. Please do not distribute it, or use it in production versions. Please use it only for your own use. Read the License file before using it. Feel free to advertise me of course ;)

Obviousely improvements can be made to the interface and capabilities. I will probably get there, but the tool is really helpful even as it is. You may post comments on any failures, bugs, or suggestions you have.

Recovering From Server/Clients Disconnections in Remoting

noreply@blogger.com (Yariv Hammer) — Tue, 06 Dec 2005 22:03:00 +0000

Introduction
In the previous article I showed how to create a Broadcast Event Server. The clients could send messages through the server to all the other connected clients.
One of the problems you have maybe seen is that if the client starts and the server is not working, than you will get an exception: "Additional information: No connection could be made because the target machine actively refused it".
On this tutorial I will show how to improve our Client/Server system by automatically connect the clients to the server once the server starts, get notifications about connectivity problems, and recover the connection.

Download Full Source Code (~300KB)
New: Download the Full Source Code in VB (~22KB)
Step 1 – Create a ServerConnector Class
First we add another interface to Common project. This interface is IServerConnector interface:
------------------------------------------------------------


namespace Common
{
public interface IServerConnector
{
bool IsAlive
{
get;
}
}
}

-------------------------------------------------------------
As you can see the interface has one read-only property IsAlive. This property will be called by the client periodically in order to check if the server is running.
Next we add a class called ServerConnector to the Server project:
-------------------------------------------------------------


using System;
using Common;

namespace Server
{
[Serializable()]
public class ServerConnector:MarshalByRefObject,IServerConnector
{
public bool IsAlive
{
get { return true; }
}

public override object InitializeLifetimeService()
{
return null;
}
}
}

---------------------------------------------------------------
This class will be called remotely by the client once in a while. If the return value is true then all is well. If the client gets an exception, then the server is not functioning.

Step 2 – Create a ClientConnector Class
Now that we have our ServerConnector class, we need to call the IsAlive method. We create a class that will have a Timer, and every period of time we will call ServerConnector. The class will have two events: ServerConnected and ServerDisconnected. This events can be used later by other objects in the client in order to provide functionality in those two states.
Add the following ClientConnector class to the Client project:
-------------------------------------------------------------


using System;
using System.Threading;
using System.Timers;
using Common;
using Timer = System.Timers.Timer;

namespace Client
{
public class ClientConnector
{
public ClientConnector()
{
_serverConnectivityTimer = new Timer(1000);
_serverConnectivityTimer.Elapsed += new ElapsedEventHandler (serverConnectivityTimer_Elapsed);
_serverConnectivityTimer.Start();
}

public event EventHandler ServerDisconnected;
public event EventHandler ServerReconnect;

private Timer _serverConnectivityTimer;
private void serverConnectivityTimer_Elapsed(object sender, ElapsedEventArgs e)
{
_serverConnectivityTimer.Stop();
CheckServerConnectivity();
_serverConnectivityTimer.Start();
}

private bool _serverIsAlive = false;
private void CheckServerConnectivity()
{
try
{
IServerConnector serverConnector = (IServerConnector) RemotingHelper. GetObject(typeof(IServerConnector));
bool isAlive = serverConnector.IsAlive;
if (isAlive && !_serverIsAlive)
SetServerAlive();
}
catch (Exception ex)
{
Console.WriteLine(ex.Message);
Thread t = new Thread(new ThreadStart (SetServerNotAlive));
t.Start();
t.Join();
}
}

private void SetServerAlive()
{
if (!_serverIsAlive && ServerReconnect != null)
ServerReconnect(this,EventArgs.Empty);
_serverIsAlive = true;
}

public void SetServerNotAlive()
{
if (_serverIsAlive && ServerDisconnected != null)
ServerDisconnected(this,EventArgs.Empty);
_serverIsAlive = false;
}

public bool ServerAlive
{
get
{
_serverConnectivityTimer.Stop();
CheckServerConnectivity();
_serverConnectivityTimer.Start();
return _serverIsAlive;
}
}
}
}

-------------------------------------------------------------
The timer elapses every second. A call to ServerConnector.IsAlive is done. If no exception was thrown, the server is connected (we raise the ServerReconnected event only if the state has changed). If an exception was thrown, we know that the server is not connected, and we can raise the ServerDisconnected event (only if soemthing has changed).

We now have a nice generic class to tell us when the server connects and when it disconnects.

Step 3 – Hook things up
First we need to register our remote objects in the configuration file.
Add the following line to the Server App.Config (inside the service tags):
<wellknown mode="Singleton" type="Server.ServerConnector, Server" objectUri= "ServerConnector.soap"/>

Add the following line to the Client App.Config (inside the client tags):
<wellknown type="Common.IServerConnector, Common" url= "tcp://localhost:16784/EventServer/ ServerConnector.soap"/>

Second, we change the ClientStartup class to contain an instance of ClientConnector. This will be the instance that all objects in the client will use:
-------------------------------------------------------------


using System;
using System.Runtime.Remoting;
using System.Windows.Forms;

namespace Client
{
public class ClientStartup
{
private static ClientConnector _connector;
public static ClientConnector Connector
{
get
{ return _connector; }
}

[STAThread]
static void Main()
{
_connector = new ClientConnector();
InitRemoting();
Application.Run(new ClientForm());
}

private static void InitRemoting()
{
string fileName = "client.exe.config";
RemotingConfiguration.Configure(fileName);
}
}
}

-------------------------------------------------------------

Next, we add changes to MessageBroadcaster in the client. We want the class to get the singleton objects from the server when the server reconnects (since we loose them when the server disconnects). Additionally we re-set the events (Once the server disconnects we loose the events).
-------------------------------------------------------------


using System;
using System.Net.Sockets;
using System.Threading;
using Common;

namespace Client
{

public class MessageBroadcaster:IBroadcaster
{
private IBroadcaster _bcaster = null;
private BroadcastEventHelper _eventHelper = null;

public MessageBroadcaster()
{
if (ClientStartup.Connector.ServerAlive)
{
InitializeObjects();
}
ClientStartup.Connector.ServerDisconnected += new EventHandler (Connector_ServerDisconnected);
ClientStartup.Connector.ServerReconnect += new EventHandler (Connector_ServerReconnect);
}

public void BroadcastMessage(Message msg)
{
if (_bcaster == null)
throw new ServerNotAliveException();
try
{
_bcaster.BroadcastMessage(msg);
}
catch (SocketException ex)
{
Console.WriteLine(ex.Message);
}
catch (ThreadAbortException ex)
{
Console.WriteLine(ex.Message);
}
}

private void HandleMessage(Message msg)
{
if (MessageArrived != null)
MessageArrived(msg);
}

private void InitializeObjects()
{
_bcaster = (IBroadcaster)RemotingHelper. GetObject(typeof(IBroadcaster));
_eventHelper = new BroadcastEventHelper();
_eventHelper.MessageArrivedLocally += new MessageArrivedHandler HandleMessage);
_bcaster.MessageArrived += new MessageArrivedHandler (_eventHelper.LocallyHandleMessageArrived);
}

private void Connector_ServerDisconnected(object sender, EventArgs e)
{
_bcaster = null;
_eventHelper = null;
}

private void Connector_ServerReconnect(object sender, EventArgs e)
{
InitializeObjects();
}

public event MessageArrivedHandler MessageArrived;
}
}

-------------------------------------------------------------
Step 4 – Fix the Demo
If you want to see the changes, you need to do the following modification to the ClientForm:
Change the constructor of the ClientForm:


public ClientForm()
{
InitializeComponent();
_messageBroadcaster.MessageArrived += new Common.MessageArrivedHandler (broadcaster_MessageArrived);
ClientStartup.Connector.ServerDisconnected += new EventHandler (Connector_ServerDisconnected);
ClientStartup.Connector.ServerReconnect += new EventHandler (Connector_ServerReconnect);
if (ClientStartup.Connector.ServerAlive)
this.Text = "Client Connected";
else
this.Text = "Client Not Connected";
}

Add the following event handlers to the form:


private void Connector_ServerDisconnected(object sender, EventArgs e)
{
this.Text = "Client Not Connected";
}
private void Connector_ServerReconnect(object sender, EventArgs e)
{
this.Text = "Client Connected";
}

Now you can run the server or the clients in any order you wish. If the client starts and the server is not started you will see it in the Text of the client form. If the server disconnects and reconnects you also see it in the clients. And most importantly – the client and server continue to function as they should.