It’s rare that a Microsoft announcement excites me, but since I do spend a lot of my time coding in, around and for their products, I am excited about the DLR — particularly IronRuby — maturing.

Share/Bookmark

In a typical fashion, Microsoft spent a lot of effort integrating a variety of it's new technologies in Dynamic AX 4 (nee Axapta). Often these additions are of questionable benefit to the end-user/customer -- but, the ability to make direct calls to the .NET/CLR from AX's built in X++ language is pretty handy for the developer.

The process is pretty simple. Add a reference in the AOT to your CLR assembly -- or a reference to .NET's "System" namespace is already available. Assert permissions to access the bridge (just a wrapper for Window auth), then make your calls.

You declare your variables in their native CLR types, and use the methods of the CLRInterop class in AX to caste to AX data types. Here's an example to build an AX container of file names in a directory, something trivial in .NET that's actually a bit of a pain with AX's limited built in file/directory methods.

Share/Bookmark

Since I have not yet passed out from beating my head against the wall, I'd thought I'd report an interesting finding regarding the Microsoft Word object model. The object model includes methods to access content based on embedded XML, but you don't really get a DOM to manipulate those nodes so you have to rely on selections/ranges and cut/paste operations to move around the data.

It's a little tricky to figure out exactly how it's going to treat the XMLNode object ranges, however. For example, the XMLNode has a "Cut" method that selects the node and cuts it to the clipboard -- including the surrounding XML element. The XMLNode also has a "Range" property to determine Start/End points, or select content of the node. The area of the "Range" on a node does not include the node XML element, however. So the results of the code lines below are not the same:

node.Cut(); // entire node w/ element tag in clipboard

app.Selection.SetRange( node.Range.Start, node.Range.End );
app.Selection.Cut(); // xml element tag still in document and not in clipboard

As if this is odd enough, the XML element tags are treated differently depending on whether they are currently displayed in the View ( the "Show XML Tags" checkbox on the XML structure Action Pane in Office 2003 or greater ). So you need to write your code to test for whether they are displayed or not before you start to move things around and determine your selection offsets appropriately.

The documents that I'm generating for this application using the new OpenXml formats are easy to create and manipulate -- but I'm still stuck having to work inside the Word application via an Add-In to provide some user tools to alter the documents, and it's painful to say the least. Ah, just to get back to some plain old HTML!

Share/Bookmark

Since I seem to stuck in .NET land a lot these days, I think I'll be looking at the Castle project a bit more closely. It has implementations for .NET that mimic the MVC and ActiveRecord setup in Rails.

Share/Bookmark

Ok, just to followup, I figured out the deal with Word and FileSystemWatcher that I posted about the other day. Don't know why this wasn't obvious to me, but Word, rather than saving a file like 99.9% percent of the applications on the planet do, instead works on a hidden temp file, saves it, then renames it to replace the original.

I wasn't trapping for "renamed" events in my FileSystemWatcher, so I was missing out on all the fun! I've corrected this, while, of course, also having to filter out the rename events triggered by the temp file, and I'm back on track. Joy.

Share/Bookmark

How do you know when your XML format is too complex? When you are trying to get your data out and your XPath expressions look like:

/w:document/w:body//w:customXml[@w:element = 'WorkOrderQuote']/w:customXmlPr/w:attr[@w:name = 'RecId']/@w:val

Share/Bookmark

Development can be great fun. Can be. Right at the moment, I feel like I'm beating my head against a wall. I've put together a nice little app to monitor a directory for file changes using .NET's System.IO.FileSystemWatcher.

Works great, mostly. I've been testing all along using "touch" at the command line to trigger updates to files, and the FileSystemWatcher events trigger just as they should. I can open files in the directory in a text editor, call "save" on them, and the events fire just fine. But, if I open a file in Word 2007 (which is the host app for the OpenXML documents I actually need to monitor), altered them and "save", the events aren't fired. The file is saved. It's attributes are updated. But the FileSystemWatcher never hears about it. Gack. Soooo annoying.

Share/Bookmark

Or not. Wow. Something like this has got to be a wake up call to somebody around there that they're technology roadmaps are a friggin' mess!

It's the "Developer Map for the 2007 Microsoft Office System," or, to summarize, a poster which is designed to accomplish a total of 10 goals, including explaining which "extensibility technologies" can and cannot be used it which applications in the Office suite and make "clear distinctions between all Office products and technologies (programs, servers, tools and services)."

Share/Bookmark

This post has gotten me a number of queries over the last couple years, including another today, from people curious about using the GFI Faxmaker COM API. GFI's API is pretty simple, but is unsupported, and compiled in a .exe file that you can't reference from Visual Studio. When the client software is installed, the COM interface is registered, and works. But, since you can't reference it, you can't browse it in VS or get intellisense to work.

You also can't use it in C#, because it likes to be able to reference things. To work around that, I wrote a VB.NET wrapper class for the API. At any rate, I decided to upload the file here, so people can find it and use it. Hope it come in handy for someone.

Share/Bookmark

I'm currently working on a project generating OpenXml documents. OpenXml is Microsoft's new default file format for Office 2007. The format, in general, is a great step forward. For those who haven't looked at it, it's a combination of a packaging standard, and several app specific schemas, WordprocessingML, SpreadsheetML, etc. So, a "docx" (the new word extension) file is actually a Zip file, with several XML files inside it. It can also contain other embedded documents, such as images, in their original form. This opens up the opportunity to easily programmatically generate documents for Office without interacting with Office at all.

As I work with WordprocessingML, however, I wonder why they had to make it so odd. I've done a lot of work in the past with XSL:FO, the page layout markup language. I like it. It accomplishes the job well, and intelligently leverages other standards, particularly in it's use of essentially the same property set as CSS.

CSS's property attributes are easy to use. WordprocessingML's approach is all element based, not attribute based. So, to get bold text you end up with something like this:

<w:p>
  <w:pPr><w:b/></w:pPr>
  <w:r>
    <w:t>Bold Text</w:t>
  </w:r>
</w:p>

The equivalent in XSL:FO would be:

<fo:block font-weight="bold">Bold Text</fo:block>

Both entirely workable solutions, but, add all that extra up over a long document, and try to write the XPath expressions to data mine it, and you'll find the later much simpler. I'm sure there are logical explainations of MS's approach that haven't occurred to me, but those are my impressions.

Share/Bookmark

Werner Moise has some interesting comments on LINQ, Microsoft's proposed query language integration effort announced at the PDC. I look forward to this functionality being baked into C#. It will make code a lot more compact and readable.

Share/Bookmark

Interesting detail on how Enums are treated by the CLR and C#.

Share/Bookmark

I've been developing a large new project using DeKlarit, a RAD database tool for .NET. I love it! It's a tool for visually modelling your business objects, which automatically takes care of the nitty-gritty of building the database, reorganizing it for updates, maintaining relational integrity, etc. In fact, it does the lion's share of the data normalization based in inferring structure from the components and attribute names you use.

The components carry business logic in the form of declarative rules you define on components, you can configure Enterprise Library compatible permissions and roles on components and individual attributes, and it support caching and easily configurable levels.

DeKlarit also had a template based code generation engine to output different types of libraries, or presentation layer applications from metadata you configure in your components.

For those familiar with the Enterprise Object Framework in WebObjects, this takes a lot of the ideas there to another level of developer convenience.

All told, for a developer working alone to develop and maintain large db applications for a business environment, it's a killer tool.

Share/Bookmark

Expert C# Business Objects is the best technical book I've read in quite a while. A lot of technical books these days seem like they were rushed to press, or are not very well thoughtout...or are simply reference books. The reference books are very useful in their own way, but rarely help you accomplish specific tasks or design good applications.

At the other end of the spectrum, I find the conceptual books to generic -- a la Design Patterns, which is also useful in it's own way, but rarely helps you put together all the pieces in a practical way.

Expert C# is right in the middle. It's a very practical application of .NET in a framework for 3-tiered business applications, that covers the concepts and the details from design, to implementation and even deployment. Of course, if you don't have a need to design .NET business applications, this is not the book for you...but I do.

Share/Bookmark

The new version of website/webstore that I've been doing for work is now "live." It's been largely done and in-use by a handful of customers for several months, but we finally flipped the switch and moved it over the "www" address. It's a custom .NET site, all written in C# that fully integrates with our Axapta ERP backend. Unfortunately, much of the fun stuff is not public as we're only using the webstore features for select customers right now -- stuff like order status, shipment tracking, saved carts, etc.

I am, however, pretty proud of the X-HTML valid, pure CSS layout and printer-friendly product guide that's fully updated daily from our ERP ( with live customer pricing for logged in customers ).

Share/Bookmark

Mono has gone 1.0. Looking forward to trying it out. I do a lot of .NET work, and like the APIs and C# -- just not too fond of the lock-in.

I've been watching Mono, but haven't had time to dig into prerelease versions. Now that it's final, I'm more interested.

Share/Bookmark

The two languages I'm currently writing most of my code in at work are C# and X++ (proprietary Axapta language). One thing about the base datatypes is driving me nuts, however. In C#, strings are "string" and booleans are "bool". In X++, strings are "str" and booleans are "boolean".

Doesn't that seem a bit odd? In both languages, one is an abbreviation, the other is the full word...but they are reversed! What's the point? I'm lost on what the language designers were thinking. Why abbreviate? And if you are going to abbreviate, I guess to save typing, why only one?

At any rate, switching back and forth between the languages, this little quirk is leading to a lot of compiler errors...and it's annoying.

Share/Bookmark

Well, after some investigation, it seems the COM API for GFI Faxmaker ( our fax server at work ) isn't terribly well crafted, and doesn't have the necessary component structure to allow it to be introspected by Microsoft's development tools.

So what, you say? Well, then I guess you aren't trying to automate Faxmaker in C#, are you? C# is strongly typed, and needs to know the COM library's API at compile time to use it.

Well, after some playing, I've now experienced some of the benefits of the Common Language Runtime of .NET -- because I was able to write a VB.NET class ( not strongly typed ) that wrapped all methods and properties of the Faxmaker API, compile that as a DLL, and then put it in my C# project and inherit from that class in a C# class. Yea! Back in business.

Share/Bookmark

Just spent a little time reviewing the Microsoft ASP.NET docs at gotdotnet.com. I'm surprised to say that it looks like a pretty attractive development platform. They've really addressed a lot of the horrible clumsiness that is ASP, and provide much better abstraction, and thankfully, non-VB language choices. C# looks like a pretty nice language to work in, I believe.

Share/Bookmark