Monthly Archives: July 2005

Mini-Microsoft is the blog of an anonymous Microsoft employee that from time to time spills his guts over how he feels about Microsoft and doesn't hold back. He is not too fond of managed code. Monday's post reveals that one of the high-ranking managers for the Office System product line is not too fond of the CLR either:

"It's interesting to see Mr. Steven Sinofsky's Technical Career Forum blog. Now, I don't know much about Mr. Sinofsky. But earlier in the year I was over in the absolute worst and poorly designed building on campus - #36, the home to just about all things Office - and the discussion about the current and previous releases of Office came up. Mostly around how Windows had screwed Office really really well over constantly slipping and cutting features that Office was trying to synchronize a release with. One thing related to me, that I have great respect for Mr. Sinofsky if true, is that Sinofsky more or less told anyone hawking a .NET CLR integration demand on Office to take that CLR and JIT it up where the sun don't shine. I have great respect for that."

So does this mean we should not have too high of an expectation for better CLR integration with Office 12?

1 Comment

Craig McMurthy has published an essay providing guidance on preparing for Indigo. As Craig mentions, he takes a different approach than two other guidance articles published by Juval Löwy and Richard Turner. Craig says:

"The approach that will be adopted in this document is somewhat different.  It begins not with isolated technical requirements, but with the larger context of a software development enterprise, and then goes on to identify some common application architectures, and to provide suggestions on how to implement those with technologies that are available now."

Craig's approach is interesting. He draws an analogy with a revolutionary new type of vehicle, that unifies the best of public transport, cars and private jets. This new transport will appear next year. It seems obvious to not invest in buying a vehicle that exists today, because that investment will be waisted. With that analogy it seems obvious to wait for Indigo and to not invest in today's technologies: Enterprise Services, Web Services and .NET Remoting.  Craig says:

"Asking which technology for communication among software entities one should adopt today anticipating the forthcoming release of Indigo next year, is about as absurd.  One should naturally begin using the prototypes of Indigo right now, and certainly forego any investment in existing technologies for the time being."

But what if you don't have any transport today and need to go somewhere tomorrow? You can't always wait for next year's promise. Even if you think Indigo Beta 1 RC is solid enough to use, you are not allowed to use it for production systems. It doesn't come with a "Go-Live" License.

I think the situation is not as bad as Craig portrays it to be. You can have your cake and eat it too. Microsoft is making sure Indigo will not completely alienate people using today's technologies. Would it be bad to invest in learning how to drive in next year's transport by driving a transport that has a similar interface? Next year you just swap the engine and chassis for a much more powerful one and you're done. The cockpit you are used to might remain quite similar. Yes, next year's transport provides a brand new and more powerful cockpit, but you are not forced to use it.

Read Juval Löwy's Preparing for Indigo-Choosing the Right Technology Today to decide if you should drive a train, a plane or a car if you haven't decided already. Of course test driving the beta of Indigo is highly recommended. But due to the uncertainty of the release date for Indigo you shouldn't stop thinking about today's technologies. I have been lobbying with Richard Turner to finally get the Proseware sample application created by Clemens Vasters et al released. It showcases a combination of Web Services (with WSE 2.0) and Enterprise Services for a Service Oriented system with a Contract First approach. Even though it was supposed to be released more than a year ago, I think it is still relevant guidance.

What do you think? Should we only focus on Indigo or are today's technologies just as relevant?

Microsoft's Matt Warren gives us a glimpse into the design process of C# 3.0 in a post titled XML Generics in C# 3.0. We're still left guessing (of course, it's not September yet 😉 to what the syntax will be, but I have the feeling it's going to be something good.

Matt has a very nice writing style, with a good touch of irony, so check out some of his other posts. Especially his post on C# 4.0. A quote:

"Too soon, you say?  Are you kidding?  Of course not.  Look, the design staff here has to keep planning far in advance of the development juggernaut.  If we were not constantly leaping ahead into product plans n-versions out, the developers might start to think that the ship was drifting off course and that everyone was asleep at the helm. If that ever happened, the negative impact to employee morale would be devastating, sending productivity into the toilet, initiating a downward spiral of fear, uncertainty and drunken binge programming that we might never recover from. "

And Drug Induced Dreams. That one (from January 2004) contains the following hilarious segment:

"So Bill's updated his character sheet.  I'm not quite sure, does Knighthood count as an epic level paladin or a prestige class?  I was thinking about this last night while I sat playing a game at a friends house.  It's my once a week get-away from the family.  Not that I don't enjoy my wife and our son, but everyone needs to have at least one night off.  I encourage everyone new to parenthood to do the same.  It keeps me from burning out from too much stress.  Work can be stressful and so can kids."

I don't know much about parenthood, or if BillG reads his blog, but I instantly believed Matt.

1 Comment

This entry is a reply to the request from comments from Steve Main on "On the Utility of .svc files".

In my opinion the .svc file for an Indigo service hosted in IIS only has value if it contains substantial content and not just one line.

In ASP.NET 1.1 .aspx, .asmx and .ashx files can contain code that is just-in-time compiled when the corresponding URL is first requested. But when you have a complete code-behind model having that physical file serves almost no purpose and I would prefer the config approach to map URLs to classes that handle the HTTP request.

In my current ASP.NET project we use some .ashx files that have no code-behind (despite total lack of support in VS .NET 2003 for the non code-behind model). The reason for doing is that keeping everything in one file eases deployment and maintenance over several servers. But that said, these .ashx files have less than 100 lines of code and almost no dependencies. I wouldn't use this approach for anything bigger.

I dislike the strong coupling that IIS mandates between file extensions in physical file names and URLs to decide what ISAPI extension to use. Similarly I dislike how ASP.NET almost completely forces you to use the extension to decide which type of HTTP handler (factory) to invoke. Having this mapping in a configuration file instead of depending on extensions of physical files would be great. At my current project we go through great lengths to hide the .aspx and .ashx extensions from the URLs. I developed a custom HttpHandlerFactory to do this and I had to enable a wild card mapping in IIS to the ASP.NET ISAPI DLL. 

But please don't implement this config approach only for Indigo. Please make sure IIS, Indigo and ASP.NET will have a consistent model for mapping URLs to handlers. I don't know what IIS 7.0 will do in this respect, but I guess it's too late to enable this for ASP.NET 2.0. And of course Indigo goes beyond HTTP. I guess even when hosted in IIS, so it supports other types of URIs for service endpoints in the configuration file.

To conclude: I would say go for the config approach for mapping URLs to handlers (like Indigo services or ASP.NET pages) without relying on file extensions. But keep the possibility of optionally using a .svc file that contains code. So as to not alienate the quick-and-dirty coders that are used to how things work in ASP.NET.

Workflow will be a hot topic at the upcoming PDC. Already a whopping amount of nine sessions have workflow in the title or the description. Michael Herman has a listing of these sessions. He questions if there is one common workflow strategy behind this or if it is just a "technology fair". Michael says:

Is the PDC going to be one large Microsoft "technology fair" with no strategic intent other than giving each product group a venue to promote their own technology bits?

At PDC 2003 I was amazed at how Microsoft was able to present a coherent vision on the three pillars of Longhorn: Avalon, Indigo and WinFS. So Microsoft is likely able to present a coherent vision on workflow.

But of course that vision for one managed API, dubbed WinFX, that would replace Win32 fell apart after 2003. Longhorn will add several managed APIs with Avalon and Indigo. But internally Longhown will be primarily unmanaged code.

For example the Aero shell will not be written in managed code and will not use the managed Avalon API. But graphically Aero will be nothing like the current Explorer though. It doesn't use GDI32/GDI+. Instead it takes advantage of the Unified Composition Engine (DirectX based) through MIL (Media Integration Layer), which underlies Avalon.

1 Comment

Microsoft's Luca Bolognese has a nice overview of PDC sessions related to the .NET Language Integrated Query Framework.

Luca says he has been working on this for over a year. In October 2003 I went to his PDC 2003 talk on ObjectSpaces. ObjectSpaces was a O/R-mapper framework related to Yukon and WinFS. ObjectSpaces was originally scheduled to be released with Whidbey and WinFS with Longhorn. Both were postponed and will not ship in the form presented at PDC 2003. Robert McLaws published an article in May 2004 that gives some inside into Microsoft's decision to put off ObjectSpaces.

ObjectSpaces was meant to be the unified model for accessing data across different data stores and to be used by several Microsoft products. In the 2003 incarnation the query language was OPath. OPath was inspired on XPath. But like using XPath from C#, OPath didn't really give you a statically typed programming model. Look at some of the complaints in the comments of this blog entry on OPath by Matt Warren. Because of the importance of ObjectSpaces as an underlying technology for several other technologies, it was very import to get right at V1. And not at V3 as is rumored to be common for Microsoft products.

So, the spirit of ObjectSpaces is back, albeit in a completely different form in C# 3.0 and VB.NET 3.0. We'll have to wait till September to see the new form, but it is bound to be better than the OPath syntax (which was already very nice).

The marriage of objects, XML and relational data has been long in the making at Microsoft. When googling for X# (later to be called CĪ‰) I found a Microsoft Watch article from December 2002 that contains:

 Box went on to call the development of a "data-oriented language" one of the "most interesting areas for innovation in the next five years." He said that Microsoft and other software development houses were beginning to explore this area.

Since C# 2.0 is yet to be released, it may very well take until 2007 before C# 3.0 is released. So Don Box's prediction is accurate: 2002 + 5 = 2007.

[Update: Microsoft Watch published a very interesting interview with Anders Hejlsberg last Friday]

As you may know the PNG file format for pictures has excellent support for alpha transparency. But you may also know that Internet Explorer 6.0 does not support alpha transparency for PNGs. You can notice this if you look at some of the PNGs I published in my image gallery.

The thumbnails really look bad! This has to do with how Community Server generates JPG thumbnails from the original PNGs.

If you view the original version (i.e. the unscaled version as published) you can sometimes see that the background color of the picture changes. In Internet Explorer 6.0 the outcome is unpredictable and the image generally still looks bad. But in FireFox (and presumably in Opera and Safari) they will look great. The pictures will blend in nicely with whatever background color you have set (default color is white).

Microsoft has confirmed that Internet Explorer 7.0 will finally support alpha transparency in PNGs. There is a blog entry that details how difficult it was to implement this.

What is really beyond me is why PowerPoint was able support this feature starting from version 2000, yet IE 6.0 released in 2001 did not support alpha transparency! Couldn't the IE guys have borrowed the code from the PowerPoint guys?!

To show off that the alpha transparency really works in PowerPoint, I created a overlay picture of three PNGs and a background picture and made a screenshot. This image also shows that the three PNGs have a proper alpha channel.

PNG overlay

1 Comment

Two weeks ago I blogged about strong naming Enterprise Library 1.1 assuming the procedure would be identical to what I did with version 1.0. Well last Friday I went ahead and repeated those steps for version 1.1.

Unfortunately I hit a snag. The compiler complained about "Referenced assembly 'Interop.MSDASC' does not have a strong name". I knew that strongly named assemblies cannot reference assemblies that don't have a strong name, so I went looking for this assembly. The reason the compiler complained was that the Configuration.Design project of EntLib references the COM Type Library MSDASC. If you reference a COM type library, Visual Studio .NET will create an interop assembly on the fly. Searching through the registry revealed that the type library MSDASC is located in oledb32.dll. I looked through the command line switches of the command line tool TlbImp to see if it would be able to create strongly named interop assemblies. It can, but it is a hassle.

So, I googled the compiler error and found a Spanish blog entry of "El Bruno". I can't read Spanish, but it had a link to the KB article with the title "PRB: "Assembly Generation Failed" Error Message When You Try to Build a Managed DLL Without a Strong Name".

This KB article contained the steps to let VS.NET do the dirty work:

1. In Microsoft Visual Studio .NET, open the properties of the Visual C# project in which you want to reference the COM component.
2. In the tree, click Common Properties, and then click General.
3. In the Wrapper Assembly Key File field, add the key file.
4. Rebuild the project.

Instead of using the Wrapper Assembly Key File field I used the Wrapper Assembly Key Name field so that VS uses the private key in the key container (imported using sn -i). Done!

Too bad that this information isn't included in the EntLib 1.1 documentation. Has nobody ever tried strong naming EntLib at Microsoft and/or Avanade before releasing version 1.1?!

1 Comment

It looks like C# is indeed going to gain support for additional/alternative forms of typing. I blogged about static vs dynamic typing and speculated on some of this. The following abstract has appeared on the PDC session list:

C#: Future Directions in Language Innovation from Anders Hejlsberg
Join Anders Hejlsberg, Distinguished Engineer and chief architect of the C# language, for an in-depth walkthrough of the new language features in C# 3.0. Understand how features like extension methods, lambda expressions, type inference, and anonymous types make it possible to create powerful APIs for expressing queries and interacting with objects, XML, and databases in a strongly typed, natural way.

I will definitely attend that session.