Philip Rieck

Blog goes dark, comes back with amnesia

Philip Rieck — Wed, 06 May 2009 17:26:00 GMT

My blog (such as it is) went unreachable for a while. I apologize for that. In addition, I've managed to lose some posts - about two years worth. Given the rate I post, that worked out to 8 entries. Of course, they were my best entries ever.

So back up and running, and may have a post or two this year.

It also seems as though many of the posts got reordered and re-dated. All of these issues are attributable to my horrible backup policy of "occasionally backup, never verify"

More asp.net Viewstate filters ...

Philip Rieck — Sat, 23 Feb 2008 04:29:32 GMT

The background:

I've seen a lot of articles lately about viewstate (well, in the last two weeks or so. I'm bad about keeping up with the rss) . Scott Mitchell recently published one article on MSDN all about the viewstate, and (among other things) showed how to send less viewstate. In it he also mentioned that Scott Galloway blogged on viewstate compression using bzip2. Also of note is the Flesk viewstate optimizer. All of these allow you to send less viewstate to the client, which means that you're saving bandwidth twice -- since the browser sends the viewstate back with the next request. For large pages with lots of viewstate, this can make a difference even on a LAN -- let alone those poor 56K modem users.

Now, I love these articles (and that looks like a good product), but they all take the same approach. While that's probably because it's the best one, I decided to try for the same result and take a different tack.

All of the above work by either having you override your page's “PersistViewStateToFileSystem” and call a method, or have you derive your page class from a base object they provide. All well and good, eh? Hey, the support is built into the framework!

The divergence:

I like a declarative approach. That is, I want to take an existing site, add on line to the web.config, and have it do what I want. After all, this is not per-page functionality I'm talking about here... it's a cross-cutting concern. Why modify all my pages to do it?

So I wrote one that just requires you to add an HttpModule (which takes copying a dll to your /bin dir, then adding three lines to your web.config. The module also requires just one more line to configure it). While this doesn't satisfy my "add one line" need, four lines is pretty close. And I don't have to modify anything else.

Presto! Add a module, and your viewstate shrinks. What could be easier? Now, before the parties start, let me warn you -- this is no magic bullet. GZipping the viewstate takes some time that could be used to download the viewstate... so where's the happy medium? Using a file store means you have lots of files and increased disk I/O. Using the Session or Application object mean more memory. And I can't generalize your database.

So this has the shotgun approach -- it can either compress the viewstate and leave it in-page (using #ziplib), it can save it to file, it can keep it in the application or session collections, or you can implement a (very, very simple) interface and do the work yourself.

The goods:
ViewRestate

The caveat:

This may be slow. Test it yourself. It's more of a mental exercise for me. In my Quick-'n-Dirty (tm) tests with a real-life largish site, the speed improved. I didn't run scalability or volume requests. The code has about ninety minutes of effort into it, so it's probably "dirty".

Not waranteed, caveat emptor, e pluribus unum, ipso fatso, etc, ad naseum.

The details:

The module sets up a filter in both the request and the response.

On the first request the response filter does a text search of what the page is writing, and takes whatever is in the viewstate out. It calls into the IViewstateStore.StoreViewstate() method to have whatever storage provider is active store the viewstate. The "token" it returns is then put into the viewstate along with "$filterd$" (yes, I took out the last e. Why not?).

On a post back, the request filter takes the token out of the viewstate, then calls IViewstateStore.RetrieveViewstate(), passing the token in. It takes the returned viewstate and injects it into the request. See the code for more details …

Vista's .net - the same version as XP, but different

Philip Rieck — Thu, 23 Nov 2006 01:07:33 GMT

If you have a .net application running on 2.0, test it on the 2.0 shipped in Vista, even if it has no UI. .Net 2.0 on Vista is not the same as the 2.0 that's available on other platforms right now.

The Synopsis

On Vista (RTM), System.Xml.Dll's file version is 2.0.50727.312.
On XP with either .net 2.0 or .net 3.0 installed, it's 2.0.50727.42
The serialization engine that creates xml serialization assemblies on the fly (via XmlSerializerFactory or XmlSerializer) creates markedly different assemblies
Things that deserialize fine on XP (which may be coded incorrectly, but run and pass all tests and fxcop rules) do not on Vista

Yes, really. No, I don't know why.

The Issue

You can download a very small project that reproduces this issue if you want to follow along. This application will run fine under XP with either .Net 2.0 or 3.0 (which installs .Net 2.0) installed and fully patched. It will not run under Vista.

What it does is read in this XML:

<?xml version="1.0" encoding="utf-8" ?> <DummyType xmlns="tst"/>

Then it tries to deserialize like this:

XmlSerializer ser = new XmlSerializer(typeof(DummyType));
DummyType t = ser.Deserialize(reader) as DummyType;

into this type:

[Serializable]
[XmlType(AnonymousType=true, Namespace="tst")]
public class DummyType
{    
}

That's it. Really. You'll note that in the repro project, I have an app.config with the <requiredRuntime> element. I wanted to; 1. Make sure that there was no version difference in the runtimes I was testing, and 2. point out that you can't future proof your code when people change functionality but leave the version numbers the same.

The background

We had a type that (through the evils of copy/paste) was attributed with [XmlType] instead of [XmlRoot]. But since the 2.0 framework on XP (and even Vista up through RC2) worked as expected, we didn't ever notice. Until we ran it on Vista RTM - an exception is thrown immediately when deserializing from XML.

Trying to track it down, we found out that "sgen.exe /k ..." creates markedly different versions of the serialization code between XP and Vista. I haven't done a full analysis of the differences (and I probably won't - real job and all that), so I don't know what other differences to expect. Hopefully we just ran into an edge case, but like I said the code is completely different.

I'm not sure why, but it seems the 2.0 assemblies shipped with Vista's 3.0 are different than the 2.0 assemblies in either the 2.0 or 3.0 redist available from Microsoft for other platforms. (wheh, this 3.0 versioning is fun, isn't it!)

The Rant

What would a customer think? "This dumb app isn't Vista compatible" or "Stupid Vista broke my applications". If I'm lucky, they'll check for a fix on our website.

Really, I expected some UI problems going to vista, but not XmlSerialization issues.

I insist on compatibility - if 2.0 runs code -even if it's wrong- , then 2.0 should always run that code. I should be able to use <requiredRuntime> to make sure that my code doesn't go into an environment with an untested platform, even one that hasn't been released. Don't break my running and deployed application.

I thought we collectively learned our lesson on this one - A contract is immutable once published. With something like the .net framework, the contract isn't just the signatures of the API! I'm sorry, I know it sucks for the FCL team and makes their lives harder, but for .net the contract includes all of the functionality, quirks, and side effects. If you change anything, change the version number.

The Hope

However, I'll be understanding if compatibility must be broken for a security update. Yes, I'll recommend patching 2.0 even if it breaks my applications when there's no other choice to fix a possible vulnerability. Does Vista have a security patch applied to 2.0 that isn't available yet? That would make me much less angry - So that's what I'll hope.

Glass in Windows Forms

Philip Rieck — Wed, 13 Sep 2006 21:57:17 GMT

[Update - 9/13/06] This seems to not work using RC1 - using DwmEnableBlurBehindWindow seems to work fine creating areas of glass, but DwmExtendFrameIntoClientArea does not - you get nothing but a black rectangle. I'm trying to figure out why and I'll create another post if I do... if you do, please feel free to comment here or point me to your posting!

I've seen a fair number of questions on using Glass in Vista forms, and I've seen a few answers as well. However, the answers I've seen involve using Windows.Forms transparent forms support [1]. There's a big downside to this- when you click a "glassy" area the mouse click is never sent to your form, and is instead passed to whatever's behind it. Not intuitive!

Also, there's more to glass in Vista than allowing the border to creep in - you can have the whole window look like a sheet of glass, or you can even add little interior bits to be glass. Why not take advantage of all of it?

This sample does that, and provides a pre-build assembly you can use as well. If you want to figure out what it's doing, read below and follow along in the source. If you just want to use it to get glass forms, in c# or vb.net, then :

Get the Zip file

Create a new Windows Forms project
Reference the "GlassForms.dll" assembly.
Create a new form and open it in code view (or open Form1.cs in code view)
Change the class it inherits from from "Form" to "GlassForms.GlassForm"
Mess with your form's new properties "GlassFrameInset", "ShowAsSheetOfGlass", and "FullClientBlur"

You can do the last step in code as well. In code, you can also call AddBlurRect and RemoveBlurRect methods to add blurry areas to the interior of your form.

Some important notes!

Windows Forms doesn't really support a non-painted tranparent background to the Form (without specifying TransparancyKey, which has the "click-through" problem). So any controls placed on a glassy portion of your form will probably look funky. No, I don't know how to solve this yet. Yes, I am working on it (but time is limited, so I'm not working on it much). Your best bet is to draw any UI on the glass yourself. It's a pain, I know. For this reason as well, "ShowAsSheetOfGlass" and "FullClientBlur" are of extremely limited usefulness.

Text on Glass

I'd like to add support for DrawThemeTextEx, but haven't. What that would do is allow you to draw text that has that neat white glow around it - making it easier to read on glass against any background. Coming some day.

What's really going on

It's actually pretty easy. Look into NativeMethods, and notice three important calls: DwmIsCompositionEnabled(..), DwmExtendFrameIntoClientArea(...), and DwmEnableBlurBehindWindow(...). That's it! really.

The tricky part in Windows forms is painting the area black you set glass to be in. I do that by keeping a Region around that I fill with black in the OnPaint of the base class.

What, you thought it would be more complicated? It's really not. The dwmapi calls are quite straightforward, and with a bit of p/invoke knowledge, quite easy to use. I hope to find a solution to the windows forms "black paint" problem (see the important notes above), but haven't yet.

[1] Thereby setting the WS_LAYERED attribute.

Leaky abstractions can be great

Philip Rieck — Sat, 15 Jul 2006 08:47:44 GMT

I’m sure you’ve heard the term “law of leaky abstraction”, apparently put forth by Joel Spolsky (if you’re unfamiliar, please go read it – it’s worth your time). Lots of people have blogged about what leaks, what doesn’t leak, why things leak and so on.

To deal with this, people often are in search of creating a “cleaner” abstraction layer that doesn’t leak. And how many times have you seen an internal framework that took way too long to create – time spent refactoring to keep it “clean” by hiding the underlying system ? I think this is a big mistake…

Let’s face it, almost any framework today is built on top of a complex something else. And that something else is probably going to have quirks and limitations. I think the trick to a clean framework isn’t hiding the quirks and limitations – it’s letting the user get to them and work around (or with) them in a layered manner.

Let me use an example (and I’m going to be light on technicalities here… this is just for illustrative purposes) – VB6 (remember that? ). A huge step away from raw C programming for windows. In VB every control (like a list box) that you drag onto a form had listbox functionality. You called methods and set properties, and it behaved list-boxy. Under the covers it was actually still a win32 window using built-in (to windows) functionality, nothing you couldn’t create with C. But VB abstracted away all of the cruft for things like adding a new item – instead of sending a LB_ADDSTRING message with SendDlgItemMessage using the id of the list and encoding the string to add in the LPARAM (whew!)… you just called ListBox.AddItem(“string”).

Great! But what if I want to do something with WM_CHARTOITEM? Or handle odd windows messages sent to to that listbox? Bzzt – no can do without bypassing VB’s listbox control altogether and creating it yourself, and possibly replacing the entire form. Now you basically need to go back and code stuff using a lower level framework (MFC/WTL/Win32/…). The abstraction leaks because I can’t do what I want (sending or handling some special message), and it sucks because I can’t do what I want with this framework at all.

Now along comes Windows Forms – we get an all new listbox. It also abstracts away things like creation, adding an item and all that while still using win32’s listbox. Great! But when I want to send or handle some special win32 message the abstraction allows me to – it may not help a whole lot, but it certainly makes it possible if not simple. This abstraction still leaks because I still can’t do what I want without sending or handling some special message, but it doesn’t suck because I can use the framework and still deal with the underlying system. The abstraction feels “cleaner” because it doesn’t hide the leaks.

For this reason, I love the design of some of WCF - it feels great because it allows you to deal with the underlying system at various layers of abstraction. You choose – highly abstracted, some abstraction, or almost none. If you find the framework is hindering you, you can just jump down a level without abandoning the framework and all its existing code. This abstraction feels even cleaner even though it goes to more lengths to show you the underlying system behind the façade.

So above we have three levels of abstractions letting water into our boat:

VB – There are no leaks, I see no leaks. (gurgle)
Windows Forms – Yes, there’s leaks. (yawn) - If you don’t like them here’s a bucket – bail ‘em out yourself.
WCF – There are no leaks, we’re in a swimming pool – enjoy the water. Here’s a floating chair

Which would you choose? And what’s my point? Embrace the leaks. Don’t hide them in your framework to make it cleaner! Instead, find a way to expose them all, within your framework. Get wet.

Upgrade engine, upgrade frequency

Philip Rieck — Sat, 01 Jul 2006 07:20:15 GMT

I've upgraded from .Text 0.95 (yes, quite old) to Subtext. I had some issues with the .text import where I had to basically do everything manually (yuck) but here I am. The problems were all in the sql script, so I'd advise just running it manually from the get go. However, if you have problems getting my feed or whatever, please let me know. I'm not 100% confident that I got everything over with zero problems.

And, I'm excited to start posting more often. I've had many things lately that I wanted to blog on, but .text issues and time constraints caused me to abort the posting. Hopefully this upgrade will drop the first problem. As for the time constraints, well...

About nine months ago I started working for a startup software company in Redmond, Washington. We're building something that has us quite excited, and I get to work with some great people while doing something both fun and challanging. While overcoming some of the obstacles in our path has provided some good blog fodder, the intense pace of starting something new has kept me from being able to process the ideas and get them pushed up here. I really want that to end, so I'm setting aside some time each week to post

Heartland DC over

Philip Rieck — Sat, 15 Oct 2005 04:20:00 GMT

I'm not dead. I just don't publish many of my posts, becase they seem.... pointless after I write them.

Anyway, I just got back from the HDC, and it was lots of fun. The pre-party the night before, the keynotes by Roky Lhotka and Andrew Troelsen, lots of great sessions, and other cool things. I hope I can make it next year, surely, and for all you people who missed it - sign up next year as soon as it's announced.... this conference has sold out every year, and fast! Joe Olsen told me there were over 100 on the waiting list for this year.

So to those that attended my session and are looking for the HttpModules I spoke of, they can be found here:

ViewRestate (allows moving your viewstate out of page)
Scroll position keeper module
ASPNetSpy (allows you to view user's web activity)
QuickWebGz (gzips pages as asp.net spits 'em out)

And of course, you can find the slides on the HDC slides site. We'll see you next year!

VS.NET 2005 - Now supporting multiple languages... For the first time!

Philip Rieck — Tue, 19 Apr 2005 21:49:00 GMT

Back in February of '04, I posted “.Net says - multiple languages supported. VS.Net says - don't try it“. A quick response by Paul Vick showed that it would probably never be fixed for Visual Studios 2002 and 2003 - but that they'd work on it for Whidbey.

Alas, the beta 1 and multiple CTPs came and went, and the bug continued. However, I am happy to report that in VS.NET 2005 Beta 2, the problem seems to have been resolved. My test case now works, and I'm a happy camper.

Thanks to the background compilation teams for c# and vb.net! While I'm sure this is an edge case, it's an edge that's cut me more than once.

Now if only Paul would allow us to turn off VB.Net default form instance codegen by the compiler, and make lots of friends. (sure - keep the feature, but make it opt-in, or at least opt-out)

C# 2.0's Generics - Are we missing some constraints?

Philip Rieck — Thu, 17 Feb 2005 22:19:00 GMT

I really do like the “Whidbey” generics for both C# and VB.net. In my opinion, they bring a good solution to some problems with gaps in strong typing to the .net family. Great stuff, really.

However, I'm not happy with one of the constraints on constraints. I'll endevor to explain. Hopefully this is either addressed or (at the least) acknowledged by those in the know. (Or, if I'm an idiot, feel free to let me know in comments)

For a good background on C# generics, see this article on MSDN: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvs05/html/csharp_generics.asp

Okay, so let's say I have a generic collection that sorts items:

1public class SortEx<T>
2{
3   ...
4    public void Add(T value)
5    {
6        foreach( T item in m_collection)
7        {
8            if( value < item) { ... }
9        }
10        ...
11    }
12     ...
13}

This won't work. Why? well, because the compiler doesn't know if the line “(value < item)” is valid!. That is, is the “<” operator valid on any and every type that currently exists or will exist? No - so the compiler won't allow you to write this line.

To get around this issue, we use the nifty “constraints” feature:

1public class SortEx<T> where T:IComparable
2{
3   ...
4    public void Add(T value)
5    {
6        foreach( T item in m_collection)
7        {
8            if( value.compareTo(item) < 0)
9             { //... }
10        }
11        ...
12    }
13     ...
14

Note that since we've added “where T:IComparable”, only types that implement IComparable can be used to construct an instance of this generic. So the line “value.compareTo(item)” will be valid for any type that does exist or ever will exist that can be used as the type parameter in this generic class. Very handy.

Now we come to my issue. Note that to allow a comparison (normally done using the type's “<” operator), we had to add a constraint and turn it into a method call on an interface. Why couldn't we say “where T: operator<”? Answer - not supported, and that's the problem.

How is this a problem? After all, we worked around it!  Well, imagine that we want to create a generic that will give us a running total of items added to it. That is, we call totaler.Add(value) for every value we come across, and at any time we can look at the property totaler.Total to get the current running total...

1public class RunTotal<T>
2{
3   private T m_total;
4   public T Total
5   {
6      get{ return m_total; }
7   }
8
9    public void Add(T value)
10    {
11       total += value;
12    }
13}

Okay, again this won't work. The compiler can't ensure that the operator “+” is valid for every type that does exist or will exist. However, in this case, there's nothing we can do about it. There's no way to add a constraint for the operator. There's no interface that will be supported by all addable types in the runtime. There's just nothing.

Now, we could have a big case statement and check if the type is an int, or a string, or a double, or whatever - then cast and add. But that would limit us to known types and not future types that are addable. Really, our hands are tied here and all we want to do is add. Ouch. Back to using Object, boxing, explicit casts and runtime errors instead of compile-time.

So, should the .net creators go about adding either an interface for each operation possible? If they do, it must be done now, or it will be worthless in the future (it may already be too late - if you created your own Complex class, for example, did you put this non-existant interface on it for addition?) However, this means adding a interfaces to a host of types in the runtime and FCL

Or, do they allow for constraints on operators, which may be just as complex? Since operator overloading is done with the specialname attribute and actually handled by compilers, this may just not be possible or at least very difficult.

Either way, I hope this is being addressed somehow. I admit it may be enough of an edge case that it's not important enough to fix, but it seems to me to be a shortcoming in generics that must either be dismissed as acceptable, or fixed right now. Once generics are out there for real, making fundimental changes is going to be that much harder.

Comments moderated

Philip Rieck — Mon, 31 Jan 2005 21:49:00 GMT

Due to mass comment spam, I'm turning on moderation (that I got from Don XML, with his .text moderation modifications entry). I did not enable the CAPTCHA stuff yet (from Miguel Jimenez’s HIP-CAPTCHA Control), because I hate to annoy anyone who may want to comment, but I will turn it on without further hesitation if need be.

However, the thing that's most important to me is now done - I will no longer give Google Juice to spamming losers. (The regular kind of loser can comment here and get juice if they want, as long as it's on topic)