Xml Diff and Patch tools redux

by Matt 28. April 2007 17:13

If you fancy saving yourself a small world of pain, you can get Microsoft's xml diff and patch assembly simply by installing Microsoft's Xml Notepad 2007. Works fine on Vista.

Now, you only get the assembly and not the command line executables or the source, but if you need a copy to use programmatically, this is the way to go.

The whole point of getting that thing installed was to evaluate the sample which created a html representation of the diff. To add insult to injury, it's built into Xml Notepad.

I'm still not decided on if it was worth the effort. More later.

Tags:

.net tools

Turn off system restore for .msi files

by Matt 26. April 2007 08:01

I've just spent far too long looking for this, so here's my note to self for future reference.

When installing a .msi file, you might have noticed your system freezes for a short while. This is Windows Installer saving a System Restore point. Generally, this is good and we like it. When you're developing a .msi file, it's more than a little inconvenient.

Fortunately, you can disable it by setting a policy registry key, as documented here at MSDN.

Normal caveats apply - only do this if you know the consequences (no sorcerer's apprentices, please). Unless you're actually installing and uninstalling products literally all day, every day, don't set this.

Tags:

Jon Udell: Rewriting the enriched web

by Matt 26. April 2007 02:19

Bingo. Jon Udell's been joining the dots. He's made the connection between Silverlight's script-accessible object model and Javascript. In fact, he ratchets it up a notch - Greasemonkey scripts modifying Silverlight controls on a 3rd party site. That's really very powerful.

Is it actually Silverlight's secret weapon? Well, maybe not. Adobe has the Flex-Ajax Bridge, which exposes Flex and swf ActionScript to a hosting web page's Javascript. It's not as deeply integrated as in Silverlight, where it seems more of a philosophy than an implementation/component (and it looks like it's still a beta).

So, perhaps this isn't Silverlight's unique selling point, but I still think this is a great development model, and Silverlight may well prove the tipping point for this kind of design.

Tags:

Silverlight

So why does Silverlight need the CLR?

by Matt 23. April 2007 17:21

Ah. Good question. If Silverlight's "killer feature" is its Javascript accessable object model, why would Microsoft embed a .net CLR in the control?

Well, there's only so much you can do in Javascript and a browser. You don't get xml parsing support (otherwise JSON wouldn't exist). You can't call web services without a lot of pain, and lack of encryption means WS-* is just out of the question.

Imagine adding support for zip. Mix in a decent xml parser, and all of a sudden, you can now process XPS or Office 2007 files in the browser. That'd make Google Docs more interesting.

Javascript doesn't give you access to the local file system, and for very good security reasons. But given a sandbox with finer grained security permissions, and the file system might come into reach.

I keep thinking that this could be the next evolutionary step for the browser. I think we've all but hit the glass ceiling of what the browser will allow us to do. We need more client side capabilities (local storage, network connectivity, encryption, you name it). Does this come from objects exposed by the browser, Javascript libraries (which would have to be in source format) or pre-parsed/pre-compiled IL libraries?

Embedding the CLR, and especially elements of the Base Class Library could actually see Microsoft doing ActiveX properly; a secure, powerful binary extension mechanism.

And seeing how grandiose this is all getting, how about open-sourcing the whole thing and getting Firefox and Apple to buy into it?

Tags:

Silverlight

Silverlight doesn't *need* http capabilities

by Matt 22. April 2007 18:12

Jeff Atwood's just taken to task some bloggers that haven't done their homework. Personally, I'd have taken them to task for writing in all-caps bold, but that's just me.

I know this is completely orthogonal to Jeff's point, but I'd like to tackle the Silverlight complaints. These were simple - you can't download from a Silverlight control, and there's no databinding or controls. The latter one I can't argue with (although there are hints that there will be a large announcement at mix07 - I'm thinking either controls or tiny CLR support), so let's look at the first.

Saying that Silverlight can't make http requests really misses the point. As Jeff points out, it does actually support a "downloader" object that is very much like XmlHttpRequest; it just adds progress notifications. Ok, that solves the problem, but it ignores the bigger picture - the reason Silverlight is not your traditional browser plugin.

Compare it to Flash (but not in the obvious way). Flash is (mostly) very self contained. You create a .swf file that contains graphics, sound, layout and script. It uses the capabilities of the Flash virtual machine to do anything it needs to do. Silverlight approaches this from the other direction. You give it a loose XML based XAML file. Silverlight downloads whatever resources you reference in it. If you want any logic, you write Javascript in your page, not in the control. You want to download more stuff? Use XmlHttpRequest.

This is a brilliant, simple and very effective idea. We've seen huge advances - and takeup - in the use of Javascript and XmlHttpRequest. Why reinvent the wheel?

Silverlight's secret weapon is its browser-scriptable object model.

Tags:

Silverlight

Xml Diff and Patch tools

by Matt 16. April 2007 17:35

Ages ago, I found Microsoft's xml diff and patch tools on gotdotnet. Dead useful little package - it does exactly what it says on the tin, diffs and patches xml files.

I went looking for it again today, and of course, link rot had set in. Microsoft is phasing out gotdotnet, so when you head on over to http://apps.gotdotnet.com/xmltools/xmldiff/ you get an "Unspecified error" page, with no helpful links. Bit of a shame, that, seeing how loads of pages around the web point you there.

Fortunately, there are a couple of msdn articles. The first gives a nice overview of using the xmldiffpatch assembly in your own code, but not of the tools. And the link to download the tools returns an out of date 1.0 version.

But, that download has a sample to generate a html file from two differing xml files. And this second msdn article creates a Windows Form app over the top of this sample to generate and display the differences in a hosted browser window. Again, this uses an out of date 1.0 version.

Finally, I look at the home page of www.gotdotnet.com (which still has people uploading samples even though it's being decommissioned) and find a link to the XML tools page on msdn. Now, we get the newer 1.1 version. (There's also a link to the quite useful Xml Notepad on that page.)

And it doesn't install on Vista.

It's demanding .net 1.1 to be installed.

Keep me covered, I'm going in.

First, we need to open the executable in Visual Studio. This should display the resource view. Expand the RCDATA node, and right click on "CABINET". Export this data as "cabinet.cab". Switch back to explorer, and double click on the .cab file. You can now copy out setup.exe, setup.ini and XmlDiffPatch.msi. In fact, we're just interested in the .msi file. If you double click on it, you get an error message that .net 1.1 isn't installed.

I can't find a way to fix this easily. The msi file has a custom action that checks for the installed .net framework versions, and compares them against a property it has stashed away. It would be nice if we could have just changed the SupportedRuntimes value in the setup.ini, or passed in an override value for the VSDSupportedRuntimes property on the command line, but no. We have to edit the .msi file. You'll need Orca installed (I think it comes as a .msi in the Windows SDK). Open the .msi file, scroll down to "CustomAction" and delete the VSDCA_VsdLaunchConditions custom action. Save the file and exit.

Double clicking the .msi will now allow you to install the software. Phew.

It seems to work, but bizarrely, the XmlPatch.exe file gains the Vista UAC shield. I guess because it's got the word "patch" in the name (and because it's in the Program Files directory. Copy it out, and it's fine). That's a bit pants. To fix that, you'll need to copy the following into a file called XmlPatch.exe.manifest:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> 
  <assemblyIdentity version="1.0.0.0" processorArchitecture="X86" name="XmlPatch.exe" type="win32"/>
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel level="asInvoker"/> 
      </requestedPrivileges>
    </security>
  </trustInfo>
</assembly>

Then drop to a command prompt. Seeing how you've already got the Windows SDK for Orca, you'll also get mt.exe from there. It should be the latest version (there are bugs in previous versions which can cause blue screens!). Run the following command line, using the mt.exe from the SDK:

mt -manifest XmlPatch.exe.manifest -outputresource:XmlPatch.exe

Finally, we've got a version of the xml diff and patch tools, ready to use. And it even comes with source. Installed to Program Files so that you can't compile it without moving it, but you've got source code. You can now build the all important dll, the XmlDiff and XmlPatch command line utils, and there's that sample that generates a html diff view for you. This was the sample I wanted to build, and what caused all of this pain. It'd better be worth it.

Tags:

Vista | .net tools

Now that explains the "ag"...

by Matt 16. April 2007 16:30

WPF/e is now called Silverlight. Quite a nice name, perhaps a little cold, doesn't exactly roll of the tongue, but it's better than Microsoft's usual overly descriptive attempts.

More importantly, it joins the dots on why the scripts and mime type where referencing "ag" (agHost, ag-plugin, etc). Isn't it nice when loose ends get tidied up like this?

Tags:

Silverlight

Vista's UIPI. Mostly compatible

by Matt 15. April 2007 18:04

We all knew Vista's security changes were going to be far reaching. UAC is controversial, and big, but even if you've made bad assumptions in your code, it still has a good compatibility story. UIPI has a much more interesting acronym and the potential for some much more interesting edge case incompatibilities.

In case you're wondering, UIPI is User Interface Privelege Isolation - it limits the windows messages a low level integrity process can send to a high integrity level process. It's designed to stop Shatter attacks, and is a major part of IE7's protected mode.

Not even Microsoft are above falling for this.

When Explorer starts up, or restarts after a crash, it broadcasts a registered windows message of "TaskbarCreated", so all the little applets can add themselves back into the notification area (system tray).

Can you see where this is headed?

Bingo. Programs running as admin don't get the "TaskbarCreated" message.

Now, AIUI, you can get round this by allowing the "TaskbarCreated" message to be received, using the new ChangeWindowMessageFilter function. But the bigger question is why do have an admin privelege program running permanently in the notification area?

(For what it's worth, I wanted to call this post "UIPI-kay-ay mother f****r", but didn't really have the bottle.)

Tags:

Vista

Signing app.config

by Matt 10. April 2007 17:16

The System.Configuration.ProtectedConfigurationProvider class conceptually allows you to "protect" a node in a .net config file. The quotes here are important if I'm going to weasel my line of thinking in.

Of course, ProtectedConfigurationProvider is an abstract class. The two implementations shipped with .net include DpapiProtectedConfigurationProvider and RsaProtectedConfigurationProvider, the first using DPAPI to "protect" a node using a key which is specific to a particular machine. The second uses rsa keys, which can be installed on different machines.

Here we see the first problem. This technique is really intended for machines that you have control over, i.e. web.config files. In fact, the way you set up protection is with aspnet_regiis.

But what if you want to protect config files on the client - app.config files? You can't use the DPAPI class, because you need to encrypt it on the machine and for the user who's going to use it. You could use the rsa class, but then you need to install rsa keys; not necessarily a bad thing, but potentially inconvenient.

Let's look at those quotes around "protect". Clearly, in the classes that are used, protect means encryption. What if all we want to do is sign a node? We might have information that isn't sensitive, but that we don't really want changed - WCF configuration perhaps, and the security settings of a service. Or even something as prosaic as how often to call a web service. We probably don't want to have that hard coded, but we don't want just anyone to change it. (Of course, these examples are just to stop casual hacking (in the old skool use of the word) and changing the behaviour of our app, rather than have them develop something that could attack us.)

This does kind of subvert how the ProtectedConfigurationProvider is currently used, but does fit with the name - we are protected the node, after all. It doesn't necessarily help that the methods on PCP are Encrypt and Decrypt, but we can quite happily look the other way for something like that. At least we'd be safe in the knowledge that we're not subverting it as much as this Wrox article, which uses a custom protection provider to redirect config to a database.

This codeproject article is the only link I've found about protecting application config files. It highlights some interesting problems, not least of which is having to distribute the config file unprotected, and protecting it at install time.

I reckon I could write a custom provider that would be able to sign a configuration node. It'd still need a public key, but perhaps that could be embedded in the (signed) executable, rather than needing to be installed in the Certificate Store. The node would be wrapped in an XML-Signature envelope, the Decrypt method would just check the signature, throw a ConfigurationErrorsException if it's invalid or return the inner xml if everything's ok. Of course, since the content is in there in plain text, it would be dead easy to remove the signature envelope and the provider attribute and just have an unprotected node. The way round this is to have the code check that certain nodes' SectionInformation.IsProtected property is true, and fail if not.

I've still not 100% convinced this is actually worthwhile. Would it be simpler (if overkill) to just encrypt the sections? Is there a way to do this without using a protection provider, such as signing the entire file (I don't know where the signature would live in this case, or how to canonicalise the file)?

And the 64 million dollar question - am I just being paranoid about the need to sign config files? Is there any real config that I wouldn't want a customer to change? Is there actually anything you can set in the WCF config that would give me problems? Do I really want to have a config file that the customer can't configure?

Tags:

Notification icons in Vista. Popup UI?

by Matt 9. April 2007 16:56

I've just hit the msdn page for NOTIFYICONDATA, the structure passed through to Shell_NotifyIcon. It's been updated with Vista information. There have been a few changes, mostly quite dull, but check out this teaser for a new value for flags (red text emphasis mine):

NIF_SHOWTIP

Windows Vista and later: Use the standard ToolTip. When uVersion is set to NOTIFYICON_VERSION_4, the standard ToolTip is replaced by the application-drawn pop-up user interface (UI). If the application wants to show the standard tooltip in that case, regardless of whether the on-hover UI is showing, it can specify NIF_SHOWTIP to indicate the standard tooltip should still be shown. Note that the NIF_SHOWTIP flag is effective until the next call to Shell_NotifyIcon.

So, is this "application-drawn pop-up user interface" what's providing the fancy images for the battery, network and volume icons?

And if so, how do you actually draw it? That's not mentioned anywhere. (Well, it does say "application-drawn", so perhaps the question should be where? And how big? And do I have to do it all myself?)

One indication that this is what is being referred to is that these three icons don't actually appear in the normal notification area in Vista. Fire up Spy++ and it shows that these icons live in a window with a caption of "System Control Area" rather than the normal "Notification Area". This is mentioned in the NOTIFYICONDATA docs:

These icons are scaled down when they are displayed in the System Tray or System Control Area (SCA).

But that raises the question about how to add something to the SCA. Is that the guid is for in the struct?

PS. It's worth reading the remarks section for NOTIFYICONDATA; there's more going on with notification icons than you might first think. Balloon tips are queued. They display between 10 and 30 seconds, and this time doesn't start if you're not using your machine, or the screen saver is running. With Vista, they also don't appear when you're in in presentation mode. Shame you have to remember all of that when you need to roll your own.

Tags:

Vista

Month List

RecentComments

Comment RSS