PostSharp, very cool!

I got this interesting link to PostSharp for tracing code execution from my friend Marcus.
It's really worth to take a look at it.

.NET managed printing - a real slug

At my work we have had a document rendering and printing service for a while.
The service first renders those Reporting Services reports in a queue and then prints them out when needed.
The printing classes of the service I wrote in 100% managed C#. At that time I was not aware of the peroformance penalties that the PrintDocument class had.
Everything began when my boss assigned me a task for implementing new features in our existing printing service for the newly purchased and very advanced printers. Firstly, the users should have a "follow me" function. Then, the serive must handle to printing to pre-defined media type(s), rather than to a specific paper tray.

The .NET framework does not provide the posibility to print to a specified media type since that functionality is device-dependent, so I started my research work by contacting Ricoh, the printer manufacturer. I got the API and the device driver to communicate with the printer devices.
After translating thousands of lines of code from C/C++ to C# I could build an assembly that I could use to select the Ricoh user defined media types. Partial success! But I would be dissapointed by the way .NET differs between managed Enhanced Metafile handles from unmanaged ones. Just EMF handles, I thought. Soon I realized that I could not use the Enhanced MetaFile handle, obtained by a call to the GetHenhmetafile method of the MetaFile class to be passed as a parameter to the PlayEnhMetaFile API function. By the way, I discovered a bug in the MetaFile class and submitted it to Microsoft.

Finally, in order to get my new classes work properly I had to make several calls to undocumented GdiPlus functions, mix some data in unsafe contexts and wrap some API native functions. After all, a document that took 113 seconds to be printed is now ready after 11 seconds. Unbelievable, 10 times faster!!!

Now we have a printing service that works in turbo mode and Ricoh will get the complete API code for the .NET framework free of charge so other developers rapidly can use it in their .NET projects.

C# or VB.NET?

Yesterday I met the development chief for an IT department of one of the biggest insurance companies of Sweden. We discussed a lot of things and among them, their language choice when they decided to concentrate all future development on the .NET framework.
She told me that they have an architecture group that is responsible for taking strategical decisions and for guidelines that their developers should follow.
What surprised me was just their language choice: VB.NET instead of C#. Having access to an own group of architects they should have known better. But why surprisingly?

Before I continue I must make it clear: I'm married to C#. I have a long experience of C and C++ and a movement to C# was for me a natural step forward. To this I can add her beauty and elegance and the flagship status.

Many developers consider that everything that can be done in C# is possible to achieve even in VB.NET or any other language supported by the framework. They are right from some point of view.
In fact, any language that compiles to MSIL has access to the same framework libraries. The resulting code will perform almost equivalently. The limitations start with the development environment support. The intellisense doesn't work in VB.NET as it does in C#. Neither the Refactor does.

New features are implemented firstly in C#. Most of those news are supported only by C#. This because C# was born with the framework itself. In contrast, VB.NET and all other languages have been adapted to fit in the platform. Generics, Lambda Expressions are examples of new features that when they was implemented they were supported exclusively by C#. In order to take advantage of those funtionalities in other languages such as VB.NET, programmers must wait until Microsoft releases the following Visual Studio version that maybe will support them.
So, if you want to be on the development frontline of the .NET framework, the only choice is C#. All other languages are at least one step behind.

LINQ - got a lot done for free?

Many software developers, including myself, working with Microsoft's tools today feel that it is getting more difficult to follow the giant's steps, at least for us who have some system responsibility. We have a large business system and just when we have evaluated and taken the decision to move from Visual Studio 2003 to Visual Studio 2005 and .NET 2.0, Microsoft announces the Visual Studio 2008 beta 2. The same is valid for our database server, MS SQL Server, we are about to upgrade our 40 GB database to SQL Server 2005 and Microsoft has already announced the news in SQL Server 2008. The life cycle of development has definitly become shorter.

In the 2008 release of Visual Studio there are news such as C# 3.0, see the C# 3.0 language specification and LINQ.
Right now I'm too busy to get an idea of the possible improvements it could give us at work. So far, I've understood that LINQ is a kind of bridge between the programming and data domains and making it data model independent. Too often Microsoft architects and developers think more widely that we would admit and for that reason I would not say as I did once that this new technology will not be as useful as Microsoft expects. But I see, with a little bit of worry, some behaviour similarities between LINQ and the Delphi TTable component back in old days. Classes that generate SQL code behind the scenes leaving the programmer without any control over them are not much appretiated by me. Of course I hope I'm wrong about this ;-)

But, for those who like such a stuff, there is an interesting article about the impact of LINQ on the C# design can be found here.

Regarding C# 3.0, I will read the news in the language specification and maybe write about some of them.