.NET Framework Tools

Its quite amazing Microsoft has provided so many .NET framework tools, the question comes then in my mind how many we know or how many we have used. My answer was ignorance. So decided to list some of the tools that framework provides. In some of next posts I will try to elaborate some of these once I really understand how to use them. The complete list can be find in the following link
http://msdn2.microsoft.com/en-us/library/d9kh6s92(VS.80).aspx

1. ASP.NET Compilation Tool
2. ASP.NET IIS Registration Tool
3. Assembly Cache Viewer
4. Global Assembly Cache Tool
5. Installer Tool
6. Native Image Generator
7. XML Serialization Tool Generator
8. WSDL tool
9. XML Schema Definition tool
10. MS CLR Debugger Tool
11. SOS Debugging Extension
12. Strong Name Tool
13. MSIL Disassembler
14. MSIL Assembler
15. Resource File Generator tool

Manipulating managed data using unsafe

 While exploring the GC classes got a idea can we access a managed data using unmanaged code. So tried the following and got excited so here is the code

class Program
{void Main(string[] args)
{
int a = 0;
unsafe
{
int *p = &a;
Console.WriteLine(“the value of a thru p={0}”,*p)
(*p)++;
}
Console.WriteLine(a);
}
}

Guess the output
The o/p is
the value of a thru p=0
1

It works fine with value type. I’m still struggiling to do the same for reference type. Looking for some hack…

Business Rules in Devloper’s life- II

This post is dedicated to my friend who have taken great effort to add many business rules that she thinks should be added in my earlier post of Business Rules in Developer Life.

Customer Support
1. QA scripts and tools must be updated as per any fix/bug, as a followup to customer support.
2. Whether the fix have been migrated to all the latest versions.

Technical Front
1. Awareness of latest technolgical advance around us.
2. Identifying what is relevant for a developer.
3. Learning the new stuff.
4. Applying the new stuff.

Thanks to her…

Business Rule’s in Developer Life

As a developer writing code for many years may be more than a decade(including college and school days), I never thought of that I may be working with a set of business rules coincidently but today while going through a book on Business Rules by Tony Morgan they seems all to be Business Rules. So I decided to list them all.

Writing Code

1. Naming Convention for file.
2. Writing Code in a particular namespace.
3. Following Coding Guidelines.
4. Compiling the code and remove all errors.
5. Follow Source Safe guidelines before check-in the code.

Customer Support

1. Acknowledgment to customer.
2. Analysing the support case.
3. If its critical then respond immediately.
4. If its not critical then schedule the fix and release.
5. Communicate to the customer.

The last but not the least sending the status report on every Friday to the Manager :).

Business Rules are everywhere whether we acknowledge them or not, they are just their. We just need to open our eyes and started recognizing them.Life is full of Business Rules so lets start recognizing them and start making them better and efficient.

[**Let me know if you guys think there are items other then listed….]

Sending Data using SOAP Header in Web Service

While writting Web Service in ASP.NET for our Business Layer, I came across a pattern where I found developers sending house keeping data as part of the method signature.

For e.g

CreateStockItem(int SessionID, int UserID, String StockItemXML)

I had a intution there will be better way of sending these data instead of the way we are sending and I came across the SOAP Header.

The following is the manner I implemented

1. Create a class derived from SoapHeader. The namespace is System.Web.Services.Protocols
public class InternalData:SoapHeader 
{
    public int SessionID;
    public   int UserID;
}

2. In the Web Service class create a object of above derived type. This should be public.
public class MyWebService: WebService
{
   public InternalData Header; 
}

3.  Add a SoapHeader attribute for a WebMethod indicating that the web method should be passed the SoapHeader data. Passed the name of the variable which will be filled by ASP.NET runtime
[SoapHeader(“Header”)]
[WebMethod]
public string CreateStockItem(string StockItemXML)
{
     SessionID = Header.SessionID;
    UserID      = Header.UserID;
}

4. Program that consume web Service will create an instance of the Header

      InternalData myHeader = new InternalData();
      myHeader.SessionID = 12233;
      myHeader.UserID = 122;

5. Now create the object of the MyWebService

    MyWebService wsObj = new MyWebService();

6. Set the HeaderValue property of Webservice object to myHeader

   wsObj.HeaderValue = myHeader;

7. Call the Web Service method.

This will send the data in the header.

Rule Engine: The Inevitable

It was a hurricane task coming to an end when we finished the framework of our product. It was a project that we started two years and was able to finish with almost all the features that we thought of. This was a framework on top of which all business layer will be developed. The great thing was any new business layer(BL) development will not take much time to develop as they will all follow a similar pattern.

This thought of similar pattern really strike me. If all BL will follow similar pattern why we need to program every time why we can’t write a rule engine which will read rules written by developer and then execute methods on the framework. My intention was

1. Developer now need to express BL methods in the form of XML.
2. A tool can be developed which will allow business analyst or external project manager to write such rules or customize existing BL methods.

When I presented this to my CEO he had reservation and he said the following

1. Developer will need to learn a new language instead of C#.
2. The Rule Engine will be very complex and will require lot of development and maintenance effort.

Although he rejected my idea but he agreed that the product need a Rule Engine as the product caters to a market where business rules keeps on changing and embedding these in code really makes the product rigid. It can become a USP of the product as it will allow us to market product where we can claim “Change Business Rule without any cost…”

Recently I joined a leading BRMS vendor. Before joining this firm I really started thinking whats the future of the entire domain and why we required such thing. What I came with a statement

“In next ten year every Enterprise software system should be Rule Engine based .”

The reason for my above belief

1. Business Rules change are inevitable.
2. Enterprise system are based on Business Rules.
3. Change in Business Rule causes triggering of Change Management which involves cost and more important time.
4. The factors above may lead to work with old system which may be inefficient.
5. Having a Rule Engine based system where Business Rules are captured outside an enterprise system will empowered enterprises to go ahead with efficient process improvement without thinking of time and cost.
6. Enterprise system’s will invoke the rules using the Rule Engine based on certain well defined interface.
7. This will Enterprise’s IT department to manage all Business Rules in a single repository in more efficient manner.
8. The IT department can generate all sort of analytics about the Business Rules currently in use or Business Rules which are no longer is in practice or history of Business Rules within an enterprise.

Troubleshooting Application Server

It was the same client that I discussed in the previous blog Troubleshooting Server Crash that we encountered another server crash related issue long back this issue occurred. The issue was our Application Server was crashing once sometimes twice in a day and the resolution was restart the Application Server. The Application Server was a Windows Service and the backend database was SQL Server 2000.

This problem almost run for months. We initially start speculating the problem to be related with number of database connection in the pool so as a first step we increased the number of database connection. But this didn’t helped us. So we started the usual process of instrumenting the application code and checking the log files. It took us sometime to come with a clear picture. The reason for the crash was identified. The reason was the Application Server used to send mails as part of some workflow process, so while sending the mail it used hung up and caused the database to go into a blocked state i.e. the tables used by that particular request’s database connection were locked. Slowly slowly all the database connection used to wait for the tables locks to be released.

There were two solution we could suggest

1. Have a dedicated process for sending mails.
2. Close the database connection before sending mails. So that tables are not locked even if there is an issue while sending mails.

After lot of thoughts the first solution was used for the following reasons

1. Restart of application server is much more expensive then the restart of Mail Service.
2. The logic of the program for some reason required the connection to be open while sending mails, so we could not close the database connection while sending mails.

After the changes were send to the production server we didn’t face the issue again as while writting the new mail service we created Watcher thread that will monitor the mail sending process. If the mail sender thread doesn’t return in a configured amount of time we killed that thread and start the mail sender again. this was quite useful as it really helped us to solve the issue.