Thursday, September 22, 2005

Visual Studio .NET 2003: resx files ...

I have a project containing custom pipeline components. Each component has its own .resx-file. For some reason the .resx-file for ComponentA was included in the project as a seperate file and the .resx-file for ComponentB was only visible if you clicked the [+]-sign left of my component.
I had no idea why there was a difference between the visualization for both .resx-files. When I edited the .csproj-file, I saw why it happened:

RelPath = "ComponentB.resx"
DependentUpon = "ComponentB.cs"
BuildAction = "EmbeddedResource"
If you remove the DependentUpon property, the file becomes visable in your project.
Dunno how to do it without editing the project file though ...

Tuesday, September 20, 2005

Biztalk 2006 on Linux ... yes, it's possible (2)

So I finally installed the second Biztalk 2006 beta on my Ubuntu Linux box. My machine is a Pavilion with 1GB of RAM. I thought running VMWare and Windows 2003 Server would really slow the machine down ... but it didn't.
In the above screenshot you can see my first flow (ProcessOrder) I've developed in Biztalk 2006. Let's start doing some more advanced things ;)

Tuesday, September 13, 2005

Biztalk 2006 on Linux ... yes, it's possible (1)

I'm currently running Ubuntu Hoary on a custom 2.6.13 kernel. I will be using this to run Windows 2003 Server and Biztalk 2006.
To be able to run Windows on Linux (Ubuntu), you'll need VMWare. Apparently the most recent version (5) is having problems on kernels later than 2.6.11. The VMWare network modules causes the network to lock up from time to time. You can read all about it and how to solve it here. Right now, I've managed to install 2003 Server, SQL Server 2000, Analysis services and Visual Studio 2005 beta. Later this week, I'll be installing the second Biztalk 2006 beta. Very exciting stuff ...

Excel ... aaaargh ...

I am working for a client that is using a lot of automated B2B scenarios. These include, next to normal EDI (Edifact and X12), ordering by mail. My client’s client sends orders as mail attachments. This has been working for quite some time, until recently, I got a phone call. Apparently, something was wrong in _my_ code because the requested delivery date was wrong by a day.
The requested delivery date is, well, quite special. It is an integer indicating the number of days that passed since 01/01/1900. “Why?” you might ask. No idea. But hey, no problem, I can count.
So this is the code that was parsing the “number of days passed since 01/01/1900” to a real date:

            DateTime baseDate = DateTime.ParseExact("01011900", "ddMMyyyy", null);

            int days = int.Parse(numDays);

            return baseDate.AddDays(days - 1).ToString("yyyyMMdd", null);

I didn’t quite understand why this code could lead to a wrong requested delivery date. So I asked the client’s client how I was supposed to parse this date. They provided me with a sample in Excel. Indeed the date was wrong by a day, but why. I created the following table in Excel:
This is what I call: "The AHA effect". When looking at the above table, the only thing you can say is: "AHA", and after a while "WTF". Anyway. It seems that our nifty spreadsheer cannot count. It "thinks" that 1900 is a leap year, but this is not the case. That's why my code's parsed date was different by a day.
Apparently Microsoft knows about this bug. It's not even a bug, it's a feature.
Really? I call it plain wrong. It seems that Lotus-1-2-3 was having this bug to, so Microsoft copied the bug for compatibility reasons.
OpenOffice does not have the above feature.
Because my client was not expecting any orders before 28/02/1900, I changed the above code to:

            DateTime baseDate = DateTime.ParseExact("01011900", "ddMMyyyy", null);

            int days = int.Parse(numDays);

            return baseDate.AddDays(days - 2).ToString("yyyyMMdd", null);

Plain stupid, I know, but what can I do ...

Monday, September 05, 2005

Linux: Swap, file systems and such ...

Just found this interesting read on KernelTrap, posted by Mr Z.

Allow me to elaborate. UNIX filesystems have a concept of "inodes" that store the body of the file, its permissions and its ownership. The inodes get linked into directories via names--aka. directory entries. The same inode can be linked into the filesystem in multiple places. (Hence the concept of a "hard link.") The filesystem keeps track of how many links an inode has, and the kernel keeps track of how many processes have opened a given inode. This concept is important, and I will come back to it.

When an executable runs, the executable's file as well as the files for all the libraries it depends on get opened. The pages for these files get mmap()'d into the process' address space as file-backed virtual memory. The memory gets marked copy-on-write, so that any changes to the mmap()'d code result in a fault, and break the file backing. In any case, the file-backed portions are backed by the contents of the inodes themselves.

Under virtual memory pressure, the kernel will have to deallocate physical pages of memory from some processes in order to allocate them to others. There are two strategies available here: Write dirty pages to swap, and discard clean pages. Clean pages are pages which have either an explicit file backing (such as program executable pages), and pages that were previously swapped, brought back in, but still have an equivalent copy in the swap partition. (This is sometimes refered to as the "swap cache," though I don't know if that designation is accurate.)

So yes, under memory pressure, some pages of an executable might get discarded and will need to be brought in later from the original executable. The grandparent wonders how that works if a user upgrades a binary while the executable runs.

Recall that there's the separation between the file's contents (the inode) and the name given to it in the file system (hard link to the inode). File descriptors are bound to inodes, not directory entries. When you "rm" a file, you remove the link between the directory and the inode. When you replace a file, say with "cp," the existing inode gets unlinked and a new inode gets linked in its place. When you "mv" a file, it gets linked in its new location, and unlinked from its old location.

The filesystem code does not reclaim the space allocated to the inode until all references to the inode drop. This includes all filesystem links and open file descriptors. Thus, when you replace a program's executable while it executes, the currently running program continues to see the old executable, even if the inode doesn't have a visible link in the filesystem. The inode will remain allocated until all of its open file descriptors get closed. Then and only then will the filesystem reclaim the storage associated with the inode.

In fact, it is this property of UNIX derived filesystems that leads to all the orphaned inodes you find in "lost+found/" after a fsck if your system gets shut down abruptly. Any inodes that were open at the point of the crash, but which did not have a hard directory link end up here.

In my experience, the NTFS file system is not as advanced as explained in the above. If you develop in M$ Visual Studio and mess a bit with the copy local setting, you'll see referenced files get locked and there's no way to overwrite them. You can somehow simulate the Unix/Linux behaviour by renaming the referenced file. If for example c:\test\a.dll is locked, just rename it to c:\test\b.dll and copy the new version of a.dll to c:\test

Friday, September 02, 2005

Biztalk: Explorer

Just found this nifty tool to manage and configure your Biztalk server running in production. It's called Biztalk Explorer and allows you to configure/manage a Biztalk 2004 without having Visual Studio installed. So this tool is ideal for administrators configuring production/QAS environments.
I know you should use binding files, but if you want to change something quickly, this is the tool you need.

Thursday, September 01, 2005

Firefox: Figures on MSDN not showing ...

When browsing some articles on Biztalk on the MSDN sites, figures were not showing (e.g.: in Firefox.
I was wondering why the figures were showing in Internet Exploder and not in Firefox. Seems that Firefox is having problems with the back slashes. Well ... problems ... shouldn't be back slashes in the first place (damn Micro$ofties), right? The solution is to install Slashy.

Look mom, I can now read MSDN articles too ;)