Drew's Blog : .NET

VS.NET Add-in Contest Third Place Winner's Entry?

drub0y — Fri, 13 Aug 2004 17:58:00 GMT

Are you serious with the third place winner being "GoogleFind"?

I'm probably gonna come off looking like an ass for even bringing it up, but so be it. I posted a macro that did at the beginning of 2003. Here's the original post on my old Radio weblog dated 1/17/2003 and here's the post when I moved it to weblogs.asp.net and even that's dated 3/6/2003. Not only that, but the winner went way out of the way and forces you to copy an interop dll to your VS.NET installation when he could have just done what I did and called the environment's built in DTE.ItemOperations.Navigate method. No interop, no dll's to copy.

I'm not looking to win the contest or anything, but it seems unoriginal and unfair to the other entries. I mean, do just go search Google itself for "Google Macro" and see what comes up number one. The fact that anyone entering the contest would write something without making sure someone else didn't write it first is kinda sketchy. Not to mention the implementation shows a lack of knowledge of the VS.NET environment, so it's not exactly a poster child for what the entire contest stands for. There has to be more worthy entries in the running.

Finally, I'd like to extend a "sorry, nothin' personal" to Martin up front since I don't even know the guy and I know he didn't do a straight rip of my code, so it's not that bad.

The Future of Scripting?

drub0y — Tue, 30 Dec 2003 16:50:00 GMT

Everyone's blogging about Daniel Boyd's open letter to Microsoft regarding the future of scripting technologies on the Windows platform. Personally, I think that the new Microsoft Shell (MSH) will be the answer to these people's prayers.

Here's a couple of nice articles by Jason Nadal with some specific details and examples. Also, if you're running Longhorn, you can join the MSH beta by going to BetaPlace, entering a Guest ID of "mshPDC" and filling out the survey there.

True Streaming Reads from ASP.NET

drub0y — Fri, 19 Dec 2003 23:44:00 GMT

Simon Fell¹ is venting about the lack of true streaming reads in ASP.NET. I agree, it really sucks that everything gets buffered.

I'm not quite clear why this is the way it is. After all, if you look at what is basically the lowest layer of the CLR based ASP.NET runtime, HttpWorkerRequest, you can see it has a ReadEntityBody method which would appear to enable a streaming read scenario. Underneath the covers, I would imagine Microsoft's concrete implementation could reach back into their native ISAPI extension and leverage IIS' ISAPI server support functions HSE_REQ_IO_COMPLETION and HSE_REQ_ASYNC_READ_CLIENT to get the job of an asycnhronus streaming read done.

Hopefully someone from the ASP.NET team can comment on this. The public, well at least two of us anyway, is dying to get streaming reads within the ASP.NET environment. For now, ISAPI is the only way to go.

¹ Correction, I originally said Sam Ruby, but I meant Simon Fell. For some reason, I have no clue why, I always confuse those two names. Sorry Simon and Sam. ;)

Question For the VSIP Gurus Out There

drub0y — Fri, 12 Dec 2003 23:45:00 GMT

Scenario

Ok, I'm writing an add-in which extends solutions with custom properties. This add-in is written in C#. I've created the extender provider, I'm registering it for the solution object, the properties show up as expected under the properties window in the IDE and all is well. However, for one of these properties I want to provide a custom editor. I've applied the EditorAttribute to my property, but it just seems like the IDE doesn't respect it. Strange thing is, I've applied DescriptionAttribute, TypeConverterAttribute, etc. on all properties and the IDE respects those, so it seems to be a special case related to EditorAttribute.

So The Question Is

What's the trick to get a custom editor to be used for an extended property such that the properties window shows the ellipses (...) box and my custom editor gets displayed when it's clicked?

ASP.NET PartialCaching Problem: A Hacked Solution

drub0y — Wed, 26 Nov 2003 20:52:00 GMT

Ok, I needed to prove to myself that my theory of being able to just use the built in PartialCachingControl would work if it's constructor were just public. So, I resorted to a little hackery and fell back on our friend System.Reflection to instantiate an instance of the class. Here's what I ended up with:

// 23.5-hour cache lifetime, shared across all pages PartialCachingAttribute cacheAttribute = new PartialCachingAttribute(84600, null, null, null, true); PartialCachingControl cacher = (PartialCachingControl)Activator.CreateInstance(typeof(PartialCachingControl), BindingFlags.NonPublic|BindingFlags.Public |BindingFlags.ExactBinding|BindingFlags.Instance, null, new object[] { typeof(StandardFooterCachedInnerControl), cacheAttribute, this.ID }, CultureInfo.InvariantCulture); this.Controls.Add(cacher);

So, this logic is in the constructor of my “outer” control which is responsible for always being in the code tree and overrides Control::OnPreRender to emit the stylesheet link in the <head> of the page it is contained on. Then, as the code demonstrates, in that “outer” controls constructor I construct an instance of the PartialCachingControl using the PartialCachingAttribute data to specify the cache rules it should follow (in my case, I just need to cache the data for 23.5 hours and want it shared across all web pages) and specify the type of my inner control (i.e. StandardFooterCachedInnerControl) that actually does the rendering when the data is not cached.

As expected, this works flawlessly. This is a good enough solution for me since I always control the servers on which my control will be installed. However, it is not guaranteed to work for anyone writing third party server controls, since they might be installed with lesser code access preventing them from being able to use reflection. I can only hope that the ASP.NET team will respond to my bug report and properly expose these currently hidden little features in Whidbey for those of us who are writing more complex controls.

ASP.NET PartialCaching Problem Part 2

drub0y — Wed, 26 Nov 2003 16:07:00 GMT

Ian Griffiths wrote the following in the comments section of this previous post:

Can't you make the cached control the child of an uncached control? The uncached control wouldn't contribute anything to the output - it just wraps the cached control. That way you can put your behaviour in the uncached control, but still get caching for its child.

That would totally make sense, except that the only way to get a partially cached control into the control tree is to either:

Statically declare it in the ASPX. In this case when the ASPX is parsed, the parser substitues a StaticPartialCachingControl instance in place of your control and then places your custom server control in that as a child. This method won't work unless I want to force my users to declare two controls statically in their ASPX which makes no sense since this is logically one control.
Load it using TemplateControl::LoadControl. In this case when the ASCX is parsed and loaded, the LoadControl method places the resulting custom control as the child of a PartialCachingControl instance. Obviously since I'm not an ASCX this method cannot be applied. However, as your scenario suggests, I should be able to leverage the PartialCachingControl class and add to my “outer” server control's control tree internally and then add my actual cached “inner” control to it as a child. Problem is, PartialCachingControl's only constructor is protected by assembly level access. :(

Next, I thought I could create my own custom class that inherits from BasePartialCachingControl and exposes the features that I need. Then I basically follow all the steps outlined in option 'b' using my custom partial caching control in place of PartialCachingControl and it should work. Problem solved, right? Ummm.... no. While BasePartialCachingControl is public, the method you need to override to return the server control that's wrapped when it needs to be rendered (BasePartialCachingControl::CreateCachedControl) is once again protected by assembly only level access! Bad, bad class design. I slap the ASP.NET developers on the wrist for this. There's no reason that the BasePartialCachingControl class should be public at all if one of its abstract members is marked with assembly level protection. That said, there's really no reason for that member to be marked assembly only... well... except to screw someone like me up.

So, what's left? The only thing I can think to do is manage all the cache work myself. I can create a re-usable control which follows the same wrapping pattern as the partial caching architecture does. You add controls to that re-usable control, then in the Control::Render override I setup my own HtmlTextWriter over my own StringWriter then I pass that to a call to Control::RenderChildren. When RenderChildren completes I take what it wrote through the HtmlTextWriter and stuff it into the standard caching architecture myself.

In closing, I'd just like to say that I really hate it when an API gets something just about right and forces me to re-implement all the work that they've already done, but didn't expose correctly. FYI, this hasn't been fixed in Whidbey. So, Scott, if you're listening, please just change the access level of PartialCachingControl's constructor and BasePartialCachingControl's CreateCachedControl method to public.

ASP.NET PartialCachingAttribute Problem

drub0y — Wed, 26 Nov 2003 00:40:00 GMT

Preface: I've seen this discussed before, but haven't really found a solution through all my searching, so I'm hoping I'm just missing something.

As you may or may not know, if you're creating a server control you can enable that control to be automagically cached by the ASP.NET output caching services by applying a PartialCachingAttribute to it. Once the control is rendered it's output is cached according to the number of seconds specified by the attribute. The control will never be instantiated or called in the rendering tree again until the cache expires. Cool right? Well, it is, but the magic happening here is unfortunately not very flexible.

When a server control is added to the page's control tree, it is checked for the PartialCachingAttribute. If the attribute is present, the control is wrapped with a PartialCachingControl instance. This PartialCachingControl class acts as a proxy for the actual server control in the page's control tree. In the OnRender implementation of PartialCachingControl is where all the magic happens (actually there's a BasePartialCachingControl class under there, but for simplicity we'll ignore that). The magic is the logic I discussed in the previous paragraph:

First, the cache is checked. If the cached output is [still] available (i.e. it hasn't expired) then it is just blasted out to the Response stream and that's that. If the cached output is not available, an instance of the actual server control is created. Next, there's a really nasty internal only hack done to switch the TextWriter for the current HttpResponse object so that it's an in-memory StringWriter instead (check out HttpResponse::SwitchWriter with ILDasm). This is done so that the PartialCachingControl can take the buffer and cache it using the caching architecture before it's blasted out to the HttpResponse's stream. Once this bit of trickery is completed, the original TextWriter is replaced on the HttpResponse and normal processing continues.

Ok, so with that dissection/explanation out of the way, the real problem is this. What if my cached server control needs to perform non-render time logic? In my specific case, I always need to emit a to a stylesheet. Well, it looks like I'm SOL and can no longer use the partial caching architecture anymore.

Has anyone solved this problem elegantly? My only option now seems to be to stop using the partial caching feature and basically do all the cache work manually within my server control's Render override. :\ I'd need to sniff the HtmlTextWriter type being used for the scope of the request, instantiate my own version of it with all the proper settings over my own StreamWriter, use that to write all my content, then get the text from the underlying StreamWriter, manually stuff it in the cache and then manually blast it out to the actual response stream.

I can't understand why PartialCachingControl doesn't at least instantiate your server control and, at the bare minimum, pass on the OnInit phase of control activation. :(

WinFS != ObjectSpaces

drub0y — Sun, 23 Nov 2003 17:56:00 GMT

In Luca Bolognese's PDC presentation on ObjectSpaces, he stated in a diagram that you should use ADO.NET's objects DataSets/DataReaders if "You require maximum control/performance/functionality" That seems to indicate that we should not use ObjectSpaces if performance, funcationality and control are a requirement. If this is the case, it would seem that using ObjectSpaces in WinFS is very contrary. WinFS has to be quick...not just fast...lightning fast. We are talking about impatient users.

I think it is important that we get Mike Deem to respond to this in his Blog. I am going to forward this to him and post it up on the newsgroups, but maybe I am missing something.

[Shawn Wildermuth]

It's easy to see why Shawn's concerned about this. WinFS looks so much like ObjectSpaces it's scary. However, what I think is important to realize is that the ObjectSpaces API is designed to be abstract and work over any possible datastore that might be backing your object data. The WinFS API on the other hand is designed and implemented to work with a very, very specific datastore. Truthfully we have no idea what the implementation of that datastore is, but we've been told emphatically by Microsoft reps that it is not just SQL server. With that in mind, there probably isn't much in the way of mapping/data translation as opposed to ObjectSpaces which does everything using XmlSerialization to get the data out of the object instance and ultimately into a DataSet which can then be persisted to the backing datastore.

As for the performance comments, remember ObjectSpaces is intended to be used in enterprise applications where you may be fielding 100[0]s of requests per second. With that in mind there's no doubt that using DataSets/DataReaders would be more performant since you would factor out all that mapping/translation logic. WinFS, in this first incarnation anyway, is being designed as a client technology. There is no “server story” for WinFS yet according to Microsoft reps. Considering the facts though, WinFS should theoretically outperform ObjectSpaces hands down by RTM.

My PDC Calendar

drub0y — Sat, 25 Oct 2003 01:25:00 GMT

In case anyone's interested. Here's what my PDC Calendar is looking like so far. Of course I might change things on the fly depending on how I'm feeling about certain subjects, but probably not too drastically. You'll notice it consists mostly of Indigo sessions with sprinklings of Avalon and Longhorn.

PDC Bound

drub0y — Fri, 24 Oct 2003 17:18:00 GMT

Welp, I depart Newark airport tommorrow at 3PM to head for LA. I'm really excited that I'm going to be there to experience the first major step in the revolution of Windows programming since Win32.

I'm really looking forward to finally being able to talk about Whidbey in public. The few things Scott has leaked about ASP.NET are but a taste of what you can expect to see once you get Whidbey up and running. I'm also looking forward to finally getting my hands on Longhorn, Avalon and Indigo. So little is actually known at this point about them, but all will be revealed starting Sunday. Being able to actually sit down and experience the technologies first hand is the best way to learn and understand them. So

Saturday night is going to be like xmas eve for PDC attendees. I don't know if I'll even be able to fall asleep. ;)