Back to Blog index.
The so-called "enterprise" applications are hip nowadays. To build them properly, you need to be aware of the known obstacles, and preferably use time-tested patterns to solve the problems.
Microsoft is active in defining and developing solution patterns for .NET application, and one of the fruits of this work is called the "Enterprise Development Reference Architecture", or EDRA for short. The codename for this project is ShadowFx.
EDRA has its own GotDotNet workspace, from which you can download all the releases (meaning sample code and documentation).
For instance, you can download PowerPoint files to give you an overview of the architecture, and the 500 page PDF file describing it in full. Note that the PDF file can be a bit difficult to find, but you can use this direct link to get to it. And no, the PDF isn't part of the 5 meg .MSI file, even though it is useful otherwise. Note that you will need the .NET 1.1 SDK installed to install the .MSI file. This bite me at least.
To promote .NET development and real-world usage, Microsoft has developed several (fun) technology demonstrations applications. These applications demonstrate the latest technologies, and can be found at the Learn 247.net web site.
I have the WeFly 247 .NET DVD in my hands, but haven't yet got a chance to look at it much. However, it seems interesting.
Go check out the site yourself. You can also download good presentations and source code. For example, go to the weRock247.NET site, and browse for technology.
Sometimes, people ask me how range checking in .NET works. And also, if range checking is different in Delphi for .NET and C#.
Indeed, there are slight differences, but they really don't matter much. A demonstration is in order here. Let's assume a simple application that creates and array with two elements, and then tries to access the third and non-existing element.
For instance like this:
Delphi code: ------------ SetLength(Arr,2); Arr[1] := 123; Arr[2] := 234; Arr[3] := 345; C# code: -------- int[] ints = new int[2]; ints[0] = 123; ints[1] = 234; ints[2] = 345;
And the results in MSIL (from the C# compiler):
IL_0001: newarr [mscorlib]System.Int32 IL_0006: stloc.0 IL_0007: ldloc.0 IL_0008: ldc.i4.0 IL_0009: ldc.i4.s 123 IL_000b: stelem.i4 IL_000c: ldloc.0 IL_000d: ldc.i4.1 IL_000e: ldc.i4 0xea IL_0013: stelem.i4 IL_0014: ldloc.0 IL_0015: ldc.i4.2 IL_0016: ldc.i4 0x159 IL_001b: stelem.i4
When this code is run, the application raises an exception of type System.IndexOutOfRangeException with the message "Index was outside the bounds of the array.".
In .NET, there isn't much you could do to disable array bounds checking, since setting an array element is done my the "stelem" MSIL instruction. And according to the SDK docs, the instruction always raises an exception if the index is out of bounds.
Surely, C# has the "checked" and "unchecked" keywords, but these only help in overflows in integer arithmetic, not when accessing arrays. So, it seems you just cannot disable array bound checking.
But in Delphi, we have the {$R} compiler directive (or {$RANGECHECKS} if you with to use the long name). Can this directive be used to control range checking? Unfortunately, the answer is "No."
A simple test is in order:
{$R-}
SetLength(Arr,2);
Arr[1] := 123;
Arr[2] := 234;
Arr[3] := 345;
{$R+}
Indeed, we still get the same IndexOutOfRangeException error message. Turning the checks on instead causes the error message to change:
{$R+}
SetLength(Arr,2);
Arr[1] := 123;
Arr[2] := 234;
Arr[3] := 345;
{$R-}
Now the error message simply becomes this: "Borland.Delphi.ERangeError: Range check error".
So, changing the range checking option in Delphi simply changes the type of the exception thrown. But just like in C#, one cannot circumvent the checks. This could be bad for performance, but very good for delivering quality code. I always suggest people compiling their code with range checks on in Win32.
If you don't believe me and are using Delphi to develop Win32 applications, check out Dan Miser's post about Delphi's range checking in his blog.
Continuing yesterday's rant: if there's one thing I would fix in .NET, it is the deployment phase. That is, if I have an assembly that references others, why on earth doesn't the default error message show which DLL it is missing?
Today, I tried to fix a ASP.NET web application that couldn't connect to a database. The thing worked on my development PC, but not on the production server.
Yes, I figured out early that this is a deployment issue, but I just couldn't figure what I was missing. And naturally, the error message was very helpful indeed: "The specified cast is not valid." Great!
Finally, after wasting more than an hour with the issue, I checked my connection strings. And there the problem was! Again! Why do I need to specify the assembly version in a connection string? I want to use the latest and nothing else! Damn.
There are now three updates available for Delphi 2005, and I chose to install them all. So far, I haven't installed any updates because all has been working well without.
To get to the latest Update 3, you will fist need to install the cumulative Update 2, and then Update 3 on top of that.
Having done that I wondered why my .NET applications wouldn't start anymore. As the default error messages given by .NET applications aren't very helpful ("Application has generated an exception that could not be handled"), I spent a while figuring why this happened. At last I figured out it must be a DLL problem (I tend to copy the Borland.Delphi.* DLLs to the GAC (Global Assembly Cache).
And indeed, there the problem was. I had read through the Update 3 ReadMe file, but I should have known that this file didn't mention the changes in the previous updates. And, it said in the ReadMe of Update 1 that the DLL versions had changed.
So I checked the GAC, and Delphi 2005 without any updates required the version 9.0.1761.24408 of the Delphi assemblies (like Borland.Delphi.dll) and since Update 1, the version had changed to 9.0.1882.30496.
Luckily, GAC supports multiple versions, and so the problem was solved. Later, once I have all my apps recompiled, I could get rid of the old DLLs. Actually I could do that even sooner, but I don't have the time to test for compatibility.
Mobiform Software Ltd. has developed an application called Aurora. It is a tool for developing XAML forms and graphics.
As the XAML graphics engine "Avalon" is still at beta stage, you cannot expect Aurora to be a final released version either, but the beta is a free download.
As Glenn Frey put it, "the heat is on", it seems.
The production release of .NET 2.0 is nearer day by day, and thus it is now a good time to prepare for breaking changes.
There's a public document available that lists all these changes and more. To my surpirse, the list of breaking changes is very small, and for my own applications I can say that I'm probably not affected.
Web applications are often attacked, and unless you are careful, your ASP.NET application might be hacked despite the defensive barriers built into the framework.
MSDN has a good article about how to find potential security threats in your application and how to solve them with a better architecture.
The article is part of the Microsoft Patterns & Practices Library. Every web developer should be aware of these threats.
I wanted to beef up some of my Delphi and C# application to take advantage of the Windows XP visual styles (the "Luna look"). I recalled from old that one should write an XML based manifest file, and I also found good info from 2002 how to do just that.
Luckily, there's an easier way as well: the Application.EnableVisualStyles method. There are many reports on the 'net that this method doesn't work properly, but I got it working easily -- until one point in time. That is, suddenly the visual styles didn't work at all. It seems to me that the method works well on very small applications, but not on larger ones.
However, there is an easy fix for this: just call the DoEvents method of the same class. This should fix the problems you have. Maybe in the final version of .NET 2.0 you don't need to do even that!
I noticed today that the summer issue of the Finnish Prosessori magazine has my embedded Linux article.
If you are interested in embedded Linux distributions and their development tools, grab your copy of the magazine. I must say I'm impressed by some of the dev tools that are available.
Two of my recent C# articles have been published. The first one is "Understanding the PropertyGrid Component", which appeared in the June 2005 issue of the Visual Studio .NET Developer from Pinnacle.
The second article is a Finnish freebie I sent to Codezone Finland (hosted by Microsoft). It is titled "Käteviä pikkurutiineja C#:lle ja .NET 1.1:lle". This is actually my first post to Codezone.
Enjoy!
Microsoft's Avalon graphics engine interests me, since I'm looking a way to get nice graphical UIs to my applications.
Since getting access to MSDN, I also started studying Avalon and the XAML files, among other things.
After you download and install the WinFX SDK and the Avalon technology preview, it is simple to develop Avalon applications using Visual Studio 2005. However, compiling the XAML files seems like magic, and I wanted to repeat this process outside VS2005.
This proved to be somewhat difficult. I found references to the XAML compiler (xamlc.exe), but I couldn't find this executable from my installation of the WinFX SDK and .NET 2.0 Beta 2.
So, I ended studying the new MSBuild engine and it's XML configuration files. Since MSBuild is also new to me, this took some time, but finally I found a way to do what I wanted.
To summarize, the MSBuild executable is part of the .NET Framework installation, and resides in a path like this:
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50215\MSBuild.exe
I won't be going into details about MSBuild here, but to operate and compile XAML files, MSBuild needs access to "target" files, and the WinFX SDK installation installs a target file like this:
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50215\Microsoft.WinFX.targets
This file defines the tasks needed to compile XAML files, among other things. Now, you can command the MSBuild engine using .PROJ files, which -- you guessed it -- are also XML files.
To build a XAML file named Test.xaml, I wrote a .PROJ file like this:
<Project
DefaultTargets="Build"
xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import
Project="$(MSBuildBinPath)\Microsoft.WinFX.targets" />
<PropertyGroup>
<IntermediateOutputPath>.</IntermediateOutputPath>
<AssemblyName>Test</AssemblyName>
<Language>C#</Language>
<OutputType>winexe</OutputType>
</PropertyGroup>
<ItemGroup>
<ApplicationDefinition Include="Test.xaml" />
<Page Include="Test.xaml" />
</ItemGroup>
</Project>
Next, I opened the SDK Command Window (from the Start menu group created by the .NET Framework 2.0 installation), and executed the following command:
msbuild /t:CodeGeneration
If you don't specify any filename, then MSBuild will look the current directory for a .PROJ file. As a result the task named "CodeGeneration" is the one that is able to generate a binary BAML file from a XAML file.
So in the end, this command took my Test.xaml file, and compiled it to these files:
Test.baml Test.g.cs Test.Main.g.cs
This way, you can build your XAML files manually, and also easily examine the generated intermediate files. You can see these using Visual Studio 2005 too, but it's not the same thing.
I just noticed that I can use a simpler URL for my site that I thought wasn't possible.
That is, for a very long time my site has been at the address "http://www.saunalahti.fi/~janij/" (note the tilde).
Now, I found out that the tilde character isn't anymore necessary, so I recommended that you update your bookmarks to point at this address instead:
http://www.saunalahti.fi/janij/
Earlier this week, Apple announced its switch from PowerPC processor to Intel processors. Hopefully, they will be of the x86 series.
I've always liked the Mac graphics, so maybe soon we will see a .NET framework for Mac. That way, I could start using Delphi/C# code on a Mac, and still enjoy the visual goodies Macs have. I'm waiting for that day to arrive.
Dr. Dobb's Journal published lately an article by Herb Sutter about the future of the software development.
Sutter's idea is that up to today, the processor technology has leaped forward performance wise, and by writing software just as we have always done, we as application developers have gotten better performance for free.
Now all this is coming to an end, says Sutter. Instead, developers need to focus on real concurrency in the future to see better performance from their hardware. This is because it isn't anymore easy to just increase the clock speeds, among other things.
So what to do? Concurrency is the key here, and it should get mainstream. Just like OOP did in the 1990s.
This is all well, but to program for concurrency, you need to have better tools and also better frameworks. Will we get those is to be seen.
Oh, speaking of performance, I also recommend checking out Yaniv Pessach's article on the June 2005 issue of MSDN Magazine about hyper-threading. This article is very good reading.
I got my hands on the Microsoft SQL Server 2005 Beta, or more specifically the April CTP (Community Technology Preview).
One of the new features for clients in this release is the SQL Native Client, which is a new client library for unmanaged (native) Win32 applications.
This new feature combines the OLE DB provider and the ODBC driver into a single DLL, and to update it, you don't need to update the whole MDAC library.
The DataWorks WebLog describes this new client nicely.
To summarize for application developers:
For Delphi programmers this new client is easy to use, you just need to change your TADOConnection component's connection string to point to the new native client.
Earlier this week, Borland announced the future roadmap for its Java development environment, JBuilder.
JBuilder has been selling briskly during the .COM years, but not much so lately. The IBM-homed Eclipse project is probably one key component to this, as the Eclipse platform has been gaining a lot of momentum.
Now, Borland announced the forthcoming codename "Peloton", which is basically JBuilder for Eclipse.
What does this mean? To me it seems that all Java development will be soon made with open-source tools, and also the platform will becode more or less open-sourced itself.
So the development world could be more and more bi-polar: open-source Java and Eclipse on the other side, and .NET and Visual Studio .NET on the other.
Who will eventually win, I'm not sure. Personally, I wouldn't mind if the world would say bye-bye to Java. I never learned to like it.
I needed to get a Word document with several logos printed today, but the simple thing proved to be pretty difficult since I wanted to keep the text sharp and the colors in the logos correct.
First lesson: Word won't support certain EPS format images, so I printed a PDF document from Word, and then sent that PDF to the printer. The text appeared a bit blurry compared to the Word original. The solution: make sure no scaling options are set. PDF printers often scale the page to something like 98% of the original, which combined with anti-aliasing can make the text blurry.
Second lesson: Black is not always just black. If you have material (like images) that are in RGB format, the printer drivers can make less than perfect choices when priting out the page. This can happen because of a poor RGB -> CMYK conversion. So, if your text looks like it has a small shadow in it, the changes are your text is being printed with the subcolors combined. This wastes the printing colors, and doesn't produce full black.
To summarize: Watch out what you print!
› Blog Archive