Snooping WPF applications

by Matt 29. May 2007 17:42

Rob Relyea has just posted a couple of links to WPF utilities to check out.

Firstly, there's a debugger visualiser for the element tree. Haven't tried it yet, but I do like the idea of these kind of visualisations.

The one I did try was Snoop, which is a very impressive tool to interrogate the visual tree of a running application, and display the tree, plus properties and events. Dead useful - think Spy++ for the 21st century. It's a little intrusive (it injects itself into the application being viewed), but I can live with that.

And that took me on a nice little stroll to see how WPF draws the navigation UI for the Frame class. Starting with this incredibly in-depth article (far too good to be simply a blog post) from the always brilliant Ian Griffiths on how WPF defines the default Template for a control, which then took me to the BAML decoder plugin for Reflector, which showed me the XAML for the resources in PresentationFramework.Aero.dll, which opened my eyes to the very nifty way that WPF handles resources and Templates and how a control's visuals can be made up with other controls. I like this WPF thing.

Tags:

EV cert support for Firefox

by Matt 29. May 2007 04:10

IE7 introduced support for Extended Validation SSL certificates (aka High Assurance certificates). Any time you hit a site with one of these certs, the address bar changes colour to green. I've previously posted links to a couple of sites Microsoft host that allows you to test this.

While scouring the net looking for ways of integrating this into a project that hosts IE's web browser, I came across this article on Wikipedia, which contained this link to a plugin to enable the nice green address bar in Firefox. And it's written by VeriSign, which is nice of them (considering other CA's certs are going to be in competition with them).

Unfortunately, its support is not as complete as IE7. Currently, it only knows about EV certs from VeriSign, Thawte and GeoTrust. (Wikipedia lists 7 other CA's that support EV.) But it's a good start.

And if you're interested in how EV certs are implemented, just download the Firefox .xpi file and change the extension to .zip. You can see it's got a certs folder, containing various new root certs for the CAs. I don't pretend to know why they need new root certs, or why the old ones can't be used. The chrome folder has a .jar file, which can again be renamed to .zip and extracted. This contains a bunch of css files, some images and some Javascript.

evcextension.js is the file with all the goodies. And it's here where you can really see how messy the EV implementation is. Each CA has their own OID that marks a cert as being EV. (OID is an object identifier. Think of it as the way a cert identifies each of it's properties.) And since each CA has their own, they're all different. So, the process is to walk the certificate chain. If the certificate contains one of the recognised OIDs, the hash of the chained root cert must match the expected hash of the OID matching CA's root cert.

Fairly simple process, but messy - the addin must know about all CAs, all of their root certs and the OID they choose to identify their version of EV. (And there are other parts to implement too, such as changes to the revocation list checking.) So any change to a CA root cert, or adding new, known CA's requires an update to the addin.

The above linked Wikipedia article lists 10 CA's. Theoretically, it should be easy to add support for all of them. Just add the OID's and the matching root certs. Of course, finding all the root certs might be a bit tricky, especially when there looks like there are new ones that need to be downloaded and installed. I wouldn't like to mess here - just leave it to the people who know about this stuff.

Of course, the nice test site run by Microsoft doesn't work because the Firefox addin doesn't know about Microsoft's test root cert. That is something that I wouldn't mind hacking.

So, now we know how to support EV certs. We've got to do a lot of leg work and find out all the CA's that support it, what their OID's are and what their root certs are. If any of them change, we won't get notified. If we do find out they've changed, it's an update to our implementation (and we'd have to be careful about putting that data in config - we don't want it hacked so that any cert can be labeled EV).

Wouldn't it be nice if Internet Explorer exposed its implementation for the rest of us to hook into, especially when hosting the WebBrowser control?

Tags:

The Dynamic Language Runtime

by Matt 28. May 2007 18:06

How cool is the DLR? Go and read that link; read the code and understand what it does. I'll be here with a paracetamol and a cup of sweet tea. Seriously fruity, isn't it?

Yep, that's the Dynamic Language Runtime announced at Mix 07. (We've already covered that I'm late with the Mix analysis. Get over it.) I like this. A lot. It's perhaps a shame then that I don't actually get dynamic languages (or perhaps - get the need for dynamic languages). But that's another post.

This eweek article is a good introduction, but briefly, consider this a set of BCL extensions to simplify lightweight dynamic code generation and dynamic dispatch - true late binding languages.

We're getting a few new languages out of this. IronPython's been the driving force behind all of this, and 2.0 now uses it. IronRuby is coming. The current plan for Visual Basic is to use it for VBx (VB 10). (That's a big statement, so also read the announcement from the VB team and this post clarifying future plans.) This can only be a good thing. I think we need a bit more diversity between VB and C#. More interestingly, there's also a DLR version of Javascript in the pipeline (this isn't JScript.net, just to confuse things - oh, and it's implemented in Visual Basic to boot).

(And doesn't that just make you wonder if the IE team are going to pick up managed Javascript to replace the aging ActiveScript based implementation? It's slow and prone to circular memory leaks, and .net has garbage collection and a 1000x performance increase. Yeah. 1000x.)

Did I mention it was available on Codeplex? It's currently a part of IronPython, which is some flavour of open source. This means Mono can just use it, legally. And in just 16 days, technically.

Speaking of Mono, Miguel de Icaza has had a run of blog posts about a compiler workshop Microsoft has been running on the DLR (yeah, that's the Mono guys working with the Microsoft guys. You know, cats and dogs, living together, that kind of thing). And he's looking at a Linux version of Silverlight, currently codenamed Moonlight. (Mono is an interesting project. I like the idea of .net on Linux and Mac et al, but it just makes me feel sorry for them that they have to constantly chase Microsoft's libraries - WCF, WPF, Silverlight, etc.)

But surely the most intriguing part of the DLR is the delivery mechanism. Why Silverlight? This library has the potential to have a huge impact on the ecosystem of .net. If Microsoft get it right, it's going to open the runtime up to a whole heap of developers who wouldn't otherwise have gone near .net.

And it's being delivered as a browser plugin.

Now, it does have a hosting model so that it can be integrated with the desktop CLR, but it's a bit of a surprise that this isn't being packaged in with .net 3.5. Perhaps it's just a question of timing? Is it too late in the day, and the DLR too immature? An alpha technology might very well be a better suited home. Or perhaps it's the cross platform nature of Silverlight; couple this with open-sourced dynamic language support and you've suddenly got a number of things to get the alpha geeks interested.

Either way, Microsoft are moving in some impressively different directions with this. I'm going to keep an eye on this one.

Tags:

Silverlight

Ubiquity of WCF

by Matt 27. May 2007 17:08

I got kind of excited to see that Silverlight has support for WCF (although I don't know exactly what parts). Having a browser based plugin that can use the WS-* stack, especially WS-Security, is a big deal.

I haven't yet seen the light, REST-wise. Currently, my thinking of what REST is to WS-* pretty much echoes what I think JSON is to XML. That is, it seems like a great idea because it strips out all the complexity, but as soon as you have greater requirements (description of contracts (WSDL), message level security (WS-Security), authentication (WS-Trust), reliable messaging, etc), the complexity starts to creep back in. For your Googles, your del.icio.us's, your Yahoo's, REST is enough. For a bank, probably not.

You could say REST is Reach, and WS-* is Rich.

And of course, my company is building in WS-*. This might colour my judgement a little.

All of this is a reasonably long winded way of saying that it's nice to see an RIA technology that supports WS-*. And to add to the ubiquity of WCF, the .net compact framework 3.5 supports it too. So now I can make WS-Security based web service calls from the desktop, the browser and mobile.

Tags:

.NET Micro Framework

by Matt 24. May 2007 17:52

This is what I was expecting Silverlight would be based on, not the CoreCLR.

So that gives us desktop CLR 1.0, 1.1, 2.0 and 2.0 for Vista (not that you'd notice by looking at the version numbers, but 2.0 on Vista has changes e.g for ASP.NET to support IIS7). .net 3 doesn't touch the CLR, but I'm not sure about 3.5.

The .net Compact Framework has gone through a couple of versions, and even has a subset for the Xbox 360. I've no idea how many versions of the .net Micro Framework there are (does this power those SPOT watches?) And now we've got the CoreCLR, which is cross platform. Oh, and Rotor and Mono, too.

Not to mention all the various service packs.

That's an awful lot of .net.

All the more reason for Microsoft to ensure that the CoreCLR is a true subset (I'm talking common code base), and is strictly compatible with the desktop CLR. I'd hate to have to work up a compatibility matrix for that lot.

Tags:

Silverlight and the CoreCLR

by Matt 23. May 2007 17:57

So I'm only really just catching up with the fun and games of Mix07. (The kitchen has a lovely new coat of paint, the holiday was nice, but plagued with minor illness and my work project has just been put on hold. I've been busy, alright?)

I don't really want to simply regurgitate the list of new products here, but there are a few things of interest I'd like to comment on. I have a feeling I'm going to be using the word "interesting" a lot...

Of course, Silverlight was the star of the show. They've revved the beta version and apart from the rebranding, one thing to catch my eye was the use of the ASP.NET AJAX style of JavaScript (namespaces, classes, etc) in the launcher scripts. Reinforces that it's an integral part of the ASP.NET family. Nice.

But who's looking at the 1.0 beta? It's already old news - Microsoft have taken the very interesting step of also releasing an alpha version of 1.1. Is this a good way to stop the "waiting for SP1" mentality? (If so, they're using the same tactic with Expression Blend - releasing the RTM of v1 and the beta of v2 on the same day.)

Yeah, 1.1 is where it's at. I don't think anyone was really surprised with the CLR in the browser. No, I think the big surprise is that's it's not the tiny CLR - it's the real deal. It's a slimmed down version of the .net 2 runtime engine. Aside from BCL changes, I think the main thing that's missing is the CAS security model and P/Invoke and COM interop, but essentially, it's the desktop CLR. It can run side-by-side in-process with the desktop version (which could mean scary things when both CLRs want to suspend threads for garbage collection). I'm also wondering what the ramifications of this refactoring will be on the desktop version. Will any of these changes filter back up? Will the CoreCLR be a true subset of the desktop version? Or will it become like the .net Compact Framework, where classes don't have all the same methods and properties, making compatibility a bit of a challenge.

Just to show how cutting edge it is, it's based on .net 3.5 - it's got some LINQ stuff in, but no heavy duty implementations, just LINQ over objects, with LINQ over xml coming soon. Microsoft have posted a very useful little diagram with the supported namespaces and classes which shows the ambitious scope for this. The System.Windows.Browser namespace looks fun - another API for accessing the DOM? But the best bit of the diagram is support for WCF. A client side WS-* stack (hopefully with CardSpace support) in a cross platform (ah, probably not with CardSpace, then) browser plugin for just a couple of meg? I'm pretty close to thinking that's the holy grail.

I'm really looking forward to playing with Silverlight. There's a huge amount of technical innovation going on here that deserves a lot of study and comment.

Not the least of which is the Dynamic Language Runtime...

Tags:

Silverlight

Project: On Hold

by Matt 22. May 2007 03:05

The project that's been consuming oh-so-much of my time for the last 3 months has just been put on hold.

It's not canned, not yet. The Powers That Be need to re-evaluate the business case. A lot has happened since the project started. The company has new owners for one thing. And we've got a new CIO, and the old one just happened to be the project sponsor. So you can kind of understand the need for a review.

It's just a shame we have to down tools for four weeks for that to happen.

It's not good for morale, or velocity, and will cost more for us to get back up to speed when it starts again - even more if we can't get the original people back.

What's worse is that this is a great project. It's all very forward focused. It intends to be our first consumer facing desktop application. An exciting project for an internet bank, and pretty much the raison d'etre of my team.

On top of that, it's using all the latest technologies; a veritable alphabetti spaghetti of new-ness. We've got .net 3, WCF, WPF and my personal favourite, CardSpace. In fact, this project is less about the actual business functionality, and more about getting this technology live. It's a huge stepping stone for the kinds of projects I want to see delivered.

So if this project does go the way of the dodo, it's going to be not getting CardSpace live that will upset me most. After all, we're going to need it for the next project that needs to talk securely with web services. Not having it takes us back to square one.

It's hard not to feel a little fatalistic right now. But I've got my fingers crossed.

Tags:

LINQ to just about anything

by Matt 3. May 2007 18:11

I've just stumbled across a useful post on Microsoft's Data Team's blog. It's an elevator pitch of their strategy, and is perhaps the best and simplest explanation I've seen of what's coming down the pipe for data in .net 3.5. I'm particularly thinking about the alphabet soup of different LINQ implementations. I haven't touched Orcas at all, so it's not been very clear what all the various flavours of LINQ are all about; there seemed to be a lot of overlap. Simply seeing them listed together, along with a brief explanation of the Entity Framework's abstraction layer, makes everything click into place.

What is LINQ?

Microsoft’s new Language Integrated Query (LINQ) is a set of extensions to the .NET Framework that provide common capabilities within the programming language for querying against in-memory data as well as external data sources. LINQ complements our vision for an Entity Data Platform by providing language extensions for querying data as objects within the programming language.

LINQ will ship as part of the next version of Visual Studio and the .NET Framework, codenamed Orcas. At the time that Orcas first ships, the .NET Framework will include support for LINQ over in-memory objects, LINQ over XML (XLINQ), LINQ over ADO.NET DataSets (LINQ to DataSet), and LINQ queries directly mapped to Microsoft SQL Server schemas (LINQ to SQL).

A few months after the shipment of Orcas, and within the first half of 2008, Microsoft will release the ADO.NET Entity Framework as an extension to the Orcas version of the .NET Framework. The ADO.NET Entity Framework will fully support LINQ through a feature known as “LINQ to Entities”. LINQ to Entities combines the developer experience of having query integrated into the programming language and the richness of being able to define an Entity Data Model with flexible mapping to relational stores.

Of course, MIX07's announcement of Project Jasper adds another dimension to all of this. I'm still digesting that one.

Source: Data : Microsoft’s Data Access Strategy

Tags:

Month List

RecentComments

Comment RSS