Microsoft Corp.'s wooing of developers to build custom applications by extending its Office "12" platform is as crucial as any such campaign in the company's history.

Microsoft can reasonably hope to engage application developers with core technologies such as its WWF (Windows Workflow Foundation), with obviously useful ideas such as shareable repositories of PowerPoint charts and other data, and with the strikingly fresh combination of a reinvented user interface and a more robust model of extensibility for its productivity applications.

Developers must wonder, though, if any such flowers-and-candy pitch should be gently turned down in favor of the low barriers to deployment, the negligible administrative workload and the ease of access to emerging non-PC client devices that developers can enjoy with Web-based models for their custom applications.

Office 12 might be the best thick client ever conceived, but perhaps a compelling thick-client solution is no longer conceivable.

Developers have become accustomed to sitting at a table that's set with a variety of tools, including everything from agile scripting languages to mature and vendor-neutral database languages, as well as a variety of ways to implement core business logic. Microsoft proposes to replace that place setting with the spork of managed code in its .Net Framework.

Click here to read about Microsoft offering developers a simpler, more efficient licensing scheme for its Shared Source program.

Like that ingenious and convenient box-lunch or backpacker's utensil, managed code (chiefly the C# language, in practice) lets its users do many things without having to put down one tool and pick up another. Microsoft's integration of database access with its LINQ (Language Integrated Query) technology and its seamless drill-down into the code that does the low-level work offer substantial productivity benefits.

It would be difficult to overstate the opportunities, subject to the constraints of choosing a single thick-client platform, that come from combining LINQ with Microsoft's deep-dyed embrace of XML. Pieces of data from anywhere in the enterprise, along with accompanying behaviors likewise rendered as XML strings, will afford developers the easy inspection and mutability of text—while manifesting themselves to users with only their relevant properties exposed. An object on a form, for example, might look like a mere static graphic to an artist using one tool but might offer drill-down access into underlying code to a developer—while both would be working with the same XML entity behind the scenes.

Microsoft's Office 12 developer technologies look good in demonstrations, with their ease of transforming a sketch of an idea into a working application. But it remains to be seen whether developers will choose these technologies in spite of concerns about the performance, flexibility, ability to deploy their work to new environments and cost-effectiveness of reaching any user with an Internet connection, as future applications will demand.

This article was originally published on eWEEK.com.