mike's web log

Handling version changes in documentation

Tue, 10 Aug 2010 18:12:27 GMT

Just wondering what sorts of examples people might have of documentation sets that cover multiple versions of the same product. In our doc set in MSDN, we basically republish each complete doc set, but updated for the new version with corrections and new features:

The advantage is you can go right to your version and be assured that what you're reading applies to you. The disadvantage is that the versions pile up (4 versions and counting), with a lot of overlap, which is inefficient in various dimensions.

Are you familiar with a doc set that handles versioning differently than this? (Conceptual or API reference or both.) If so, leave a comment with a link.

Thanks!

WebMatrix and ASP.NET Razor

Tue, 06 Jul 2010 15:06:57 GMT

By now you'll probably know that we released (in beta) a new version, I guess you'd call it, of ASP.NET. It's not really a new version -- same old ASP.NET behind the scenes -- just a new and simpler syntax on top of ASP.NET. There are various ways to think about this, like "MVC for the rest of us" or "ASP Classic done right" or, you know, many others. :-) The emphasis is on reducing the amount of code (indeed, the "concept count") required to do many of the things that people want to be able to do with websites.

I just love this stuff. The Web Forms model was predicated on the idea of making web development something like forms for Windows client apps -- the page is a form, you drop controls onto it, set their properties, and respond to their events. This basically worked, although as many people pointed out over the years, this type of client-forms analogy was a leaky abstraction. There's a certain black-box quality to the Web Forms model, and doing tricky stuff -- perhaps just adding controls on the fly -- tended to make it clear just how much man there was behind the curtain. Plus its 8+ years of development have left it with a certain amont of cruft; even internally we still see questions about how to do things with (e.g.) the DataGrid control.

ASP.NET MVC [more]

Out, damned space

Tue, 09 Feb 2010 02:48:47 GMT

The other day I was doing something where I wanted to display some data as a comma-delimited list, like so:

a, b, c, d

This seemed like a job for the Repeater control. So I created the markup for the control and included a separator template, like this:

<asp:Repeater runat="server" ID="Repeater1" DataSourceID="LinqDataSource3"  >
  <ItemTemplate>
    <asp:Label runat="server" ID="labelCategory" Text='<%# Eval("Category") %>'>
    </asp:Label>
  </ItemTemplate>
  <SeparatorTemplate>, </SeparatorTemplate>
</asp:Repeater>

The result was this:

a , b , c, d

One thing was right (no trailing comma). But there was that silly space between the data item and the delimiter.

I spent as much as a minute looking to see if there was an easy fix for this. Failing in this effort, I invented a solution that seems ... well ... kinda complex, considering. So this is where the Internet tells me that a) I'm using the wrong control and/or b) alls you have to do is set a property, duh.

In the meantime, tho, what I ended up doing was this: I handled the Repeater control's PreRender event, which is well after data binding and about the last time you can go in and mess about with the markup that the control will render. In that event, I walked the contents of the Repeater control to, in effect, trim spaces.

But it wasn't quite as simple as I thought. Instead of being able to grub around directly -- in a simple string that represented the markup being rendered, say -- I was obliged to walk the control tree that was inside the Items [more]

New template for ASP.NET Web site projects

Mon, 18 Jan 2010 17:21:19 GMT

Visual Web Developer has long had a blank-sheet-of-paper issue when you create a new Web site project or Web application project in Visual Studio. As in, you create the project and then you, developer person, get to start adding your own layout (master pages, css), content, and optionally, authentication. Among other things.

In the 2.0 release, we had what were referred to as Starter Kits, which were prebuilt apps for what were perceived to be common tasks -- "personal Web site" (which included a photo album -- this was before Flickr), time tracker, club site, stuff like that. But Starter Kits were, at best, a kind of add-on, and of course assumed that your goal was one of the types of Web sites for which a Starter Kit was available.

For ASP.NET 4, they've decided that pretty much all apps needed a certain core set of functionality. So for ASP.NET 4, when you create a Web project, you get certain functionality out of the box. The exception is if you explicitly choose to create an empty Web site (thusly named), which is about as empty as you can get. (You get a skeleton Web.config file and that's it.)

What you get
Here's what Visual Studio 2010 builds for you when you create a new Web site/application project:

Web site folder structure.
A master page.
A Menu control (tabs) on master page that link to individual content pages.
A CSS file (Styles folder).
2 free-form content pages (Default, About).
jQuery (Scripts folder).
Routing (which is basically just enabled by default).
A Web.config file.
A Global.asax file.
[more]

ASP.NET page life cycle

Fri, 15 Jan 2010 09:51:21 GMT

Just a quick note to draw your attention to an updated ASP.NET page life-cycle diagram that my colleague Tom has done for the docs:

ASP.NET Page Life Cycle Diagram

Here's a little peek (I don't want to steal his thunder, so I won't show the whole thing):

Documentation survey!

Fri, 30 Oct 2009 14:35:27 GMT

Do you use our documentation? (Golly, hope so. :-) ) Give us some feedback -- take the survey that's posted here:

https://www.surveymonkey.com/s.aspx?sm=qQnlYIN2D5gQH7UhLrQyuA_3d_3d

This asks some basic information, like where you get your technical information and how you go about finding it, as well as how best to get your feedback, what type of development you do, etc.

I can assure you that we look at this stuff intently, we really do. I encourage you to go through the survey. It's only 11 questions, and it will help us out.

Thanks!

New location (and look) for ASP.NET documentation

Mon, 19 Oct 2009 10:41:18 GMT

ASP.NET documentation actually has a couple of homes. There's the grab-bag of articles, tutorials, and videos about ASP.NET that's posted on the http://asp.net site. And the official documentation -- the stuff I work on -- lives on MSDN, the gigantic library of Microsoft information.

We released Beta 2 of the .NET Framework 4 and Visual Studio 2010 today. As part of the docs push, we managed a change that we've actually been wanting to make for a long time. Since approximately forever, our stuff has been part of the overall Visual Studio documentation, and it's taken some digging to find it:

Whereas all this time we've had this other node in MSDN that seemed like it would make a good home for our docs. And as of today, that's where you'll find our stuff:

The new organization reflects a couple of things. One, obviously, is that if you're scanning the MSDN table of contents (TOC) looking for ASP.NET stuff, a pretty likely place to look is in a node that's about Web development. We wanted to reduce the clicking required to get to the doc, of course. Another change is that because the docs are not tied specifically to versions of Visual Studio, you can see that we can keep ASP.NET 4 and ASP.NET 3.5 documentation close to each other in the TOC.[1]

[more]

Foiled attack

Thu, 15 Oct 2009 14:07:51 GMT

Earlier today, someone left the following "comment" on an entry in the blog:

<% foreach (var x in ConfigurationManager.ConnectionStrings){%><%= x.ToString() + "<br />" %><% } %>

This is an attempt, obviously, to get connection information about any and all databases that the blog has access to.

In this particular case, the attack was not successful because I encode stuff in comments, so it was just passed through as text. I sure hope that I've anticipated other, relatively straightforward attacks of a similar nature. But as we know, hackers are wily. And I am not particularly so, alas.

It goes to show that no matter how trivial your site, someone is interested in hacking it. Security: It's not just for commercial web sites.

If you can't say something nice ...

Thu, 02 Jul 2009 11:18:53 GMT

At work, we write documentation for programmers, so our docs include many code examples[1]. We should comment our code, right? Of course. However, a discussion broke out in our ranks yesterday about the whole idea of commenting the example code. The discussion arose out of the complaint that a lot of comments in a lot of code (not just ours) are actually lame. This was an observation made in a recent blog entry, which used the following as an example:

In the wake of this, a semi-unserious proposal was made that because most comments are dumb, we should just strip all comments from the example code. Because code examples are not translated, we have to explain the code in the text of a topic anyway.

Hmmm. This type of proposal is useful for goading me into thinking through our policy. Herewith my thots:

Having decent comments in a snippet is useful for the person who copies and pastes an example into their application, even if the code is explained in the topic.

As with member descriptions, descriptions in orientation topics, UI reference topics, and other such, it takes time and thought to create a comment that is actually useful to the reader. All of these types of text share the characteristic that they are often written as an afterthought, in a hurry, only to fulfill a general requirement, or while the writer's attention is focused elsewhere.

[more]

Why not link to Wikipedia?

Thu, 07 May 2009 22:07:40 GMT

An issue that has come up a number of times at work is the question of linking to articles in Wikipedia. It's not terribly unusual for us to link from the documentation set to non-Microsoft resources. A common example in my world is linking to the W3C site. For example, in the topic (article) ASP.NET and XHTML, we discuss how we implement (or don't) XHTML standards, but we refer you to the W3C site for actual standards.

Other examples where we've linked to external sites:

The Section 508 site for information about accessibility.
The IANA site for a reference of MIME types.
The Mozilla developer site for information about the document object model (DOM) supported in the Gecko browser rendering engine.
The Unicode site for (duh) information about Unicode.

There are more, but you get the idea. The thought here is that these sites provide information that is not specific to our product but that is useful to our audience. It would be silly for us to copy this info or (god forbid) rewrite it so it could be part of our documentation site.

You will probably note that sites have certain features in common. They are:

Authoritative. Many of our links are to the sites of standards bodies.
Commercially neutral, at least for the purposes for which we are linking. For example, the Mozilla site could be thought of as a competitor to, say, Internet Explorer, but from our perspective (server-based Web coding), it's just another client.
[more]

My poor memory for old technology

Wed, 14 Jan 2009 21:53:41 GMT
I've been in this industry a long time. This doesn't make me smart, just ... old. Being old, I find that my memory just isn't what it once was (which wasn't much). So for example ...

A little while ago, AJAX took the Web-development world by storm. So cool! So interactive! You could do so much in the browser by using this JavaScript thing. Now, my memory is so faulty that I distinctly remember that around 1999 or so, JavaScript was the bane of Web development. It was for, you know, Web developers. Scripters. Markup people. Not Professional Programmers. Real programmers used C. (Unbelievable how bad my memory is, don't you agree?)

And you know, speaking of Web development, when AJAX came out, another thing that people were excited about was that you could do everything in the browser! No more of those round trips to the server and that annoying browser "flash" on postback that users all over the world were so up in arms about. (Some were refusing to use the Web at all, I heard, unless this was fixed.) And again, my memory is so wretched that I could have sworn that when ASP.NET 1.0 came out, putting all the processing on the server on a browser-independent platform was considered a big step forward. Obviously, I'm totally remembering that wrong.

Dynamic languages. Typeless variables, interpreters, extensible objects -- so flexible and convenient! This was very confusing to me, because I seemed to remember -- dang, the tricks that the aging brain plays on you -- that there was a time when type safety and compilation and all that OOP stuff were things that we wanted for coding.

And just recently, my mind has again been leading me astray. I've been reading about ASP.NET MVC and all its great features like the advantages of having complete control [more]

Docs for creating custom controls

Mon, 08 Dec 2008 13:40:02 GMT
This is a question about the documentation on MSDN. There's a section on how to create custom ASP.NET controls, which starts at Developing Custom ASP.NET Server Controls:

We're looking at maybe updating this, so we'd like to know from you:
Have you used these docs?
If so, what information did you not find?
If you tried using them but gave up, what was missing?
Any feedback you might have about this section of the ASP.NET docs would be very welcome.

Thanks!

Can you use Web Forms controls with MVC?

Fri, 05 Dec 2008 12:07:11 GMT
As more people delve into ASP.NET MVC, we see more questions from people who are used to the Web Forms model and are curious where these technologies overlap. We have noted in the docs that views can be .aspx pages. Ok, that being the case, can you use normal Web Forms controls on an .aspx page that is being used as V in MVC? Someone posed the question on an internal list this way: "Which existing controls can you safely use in MVC? Can you use the GridView control? Can you use the TextBox control?"

This is one of those deals where the answer is "No. Yes. Maybe." In response to the internal query, Eilon Lipton explained:
In general, from a very technical perspective, no controls at all are "safe" to use in MVC except for ones that have to do with page structure: Page, UserControl, MasterPage, ContentPlaceHolder, and Content.

Even controls that might appear to be "safe," such as Panel, are not as safe as you think. There are many features of the Panel control that won’t work in MVC view pages. Having said that, almost any control can be used in an MVC ViewPage as long as you constraint yourself with regard to which features of that control you use.
The problem is that most Web Forms controls rely on postbacks and on viewstate; neither of those things obtains in MVC. When Eilon says "if you constrain yourself," he is effectively saying if you're not counting on viewstate or postback. And although you yourself might not be explicitly using these features, behavior that's cooked into the Web Forms controls often is. For example, an ASP.NET Button control raises its server-side Click [more]

When do you use Design view?

Mon, 10 Nov 2008 18:09:00 GMT
At PDC2008, Jeff King demonstrated features and improvements that his team is proposing for the next release Visual Web Developer. Among them are lots of tweaks to HTML editing. This got me thinking about my own use of Design view and Source view, and when and why I use each.

From one narrow perspective, the history of the Visual Studio tools for creating Web pages -- starting with Visual InterDev (remember him?) through Visual Studio 2008 SP1 -- has been a history of improving Design view. If you remember that far back, in Visual Studio .NET (for versions 1.0 and 1.1 of ASP.NET), the page you edited in Design view and the page in Source view were related but separate; when you switched views, each view recreated the page from scratch. Lots of people did not like how switching views could hose up your formatting. Plus the editor inserted some Visual Studio-specific (and of course non-standard) attributes into the page to give itself some formatting clues, and that likewise was not popular in certain quarters.

In Visual Studio 2005 and beyond, it was a priority to make sure that when you switch views, Source view formatting is maintained scrupulously. And (AFAIK) thus it is: what you do in Design view is persisted in Source view, and in addition any custom formatting you've done in Source view is retained. We don’t mess with your markup. (Selection is maintained between views as well.)

And yet I spend most of my time in Source view. Partly this is because Source view itself has gotten more and more capable. You can drag from the Toolbox and you can use the Properties window. IntelliSense now works with pretty much everything. You can set options for how the editor formats tags and code.

I thought about it, and here's when I do use Design view:
[more]

Engineers who write/Writing for engineers

Sat, 08 Nov 2008 18:39:37 GMT
In the latest MSDN magazine Richard Ward has a column titled "Engineers Who Write." It might also have been titled "Writing for engineers." Ward's thesis is that engineers need to be able to communicate in writing, and that this is harder than being able to communicate in person. One of things he sees in engineering documents, he says, is this:
A precise model helps, for example, when specifying the interactions between two instances, such as a network protocol. These forms can express the how of a design very effectively because they are, in a sense, only one step removed from the actual code expressing that design. They do not, however, explain the why of a design.
Emphasis mine. I have seen this approximately one (1) million times. Not unexpectedly, I almost always see it (don't see it?) in feature specifications, where (as Ward says), you find lots of detail about how to implement the feature, but very, very rarely do you find an answer to the question "What problem does this feature solve?" To the author of the document, and presumably to the immediate intended audience, this question has already been answered.

Ward makes a particularly salient point about how this type of information becomes less obvious, hence more necessary, as a document goes out to a wider and wider audience:
As the design trickles out from the original conception to the organization as a whole, the requirements for communicating with each new audience become broader. It is rarely necessary to take a low-level design document to a customer, but it is often helpful to have the requirements in a form that is both understandable to a diverse audience and written in a way that can appeal to the audience at many levels.
[more]

How I broke my app with UpdatePanel controls

Thu, 30 Oct 2008 22:24:15 GMT
As with so many things, it also started out so simple. I wanted to use UpdatePanel controls to throw a little AJAX-ification onto one of my blog management pages. (Specifically, the blog entry page.) In fact, it started even simpler than that.

I wrote my blog-entry page as a quick-and-dirty, and in the way long-ago days before we had again learned to love JavaScript. I enter text in the textbox. When I want to see what it will look like, I click a Preview button. This hides the textbox, copies the text from the textbox into a Label control (after some formatting), and then displays the label. When I want to edit some more, I click an Edit button, the label is hidden, the textbox is rediplayed, and I bash on. In each case, I enable and disable the appropriate button -- for example, when in Preview mode, I disable the Preview button. (Don't need it, right?) A poor man's Tab control, is what it is.

Edit mode:

Preview mode:

This was all happening via postbacks. As a result, when I would switch to Preview mode and back, I'd lose my place in the textbox. If the post was long (me? long posts!?), I'd have to scroll down and find my place again. Annoying.

I thought that by doing asynchronous postbacks, I'd solve this problem -- no full-on re-creation of the page each time I clicked a button. So I put an UpdatePanel control around the TextBox and Label controls. Like this:

The buttons are not in the UpdatePanel control, because there's other junk in the way. So I specified them as triggers, like this:

<asp:UpdatePanel runat="server" ID="updatePanel1">
<Triggers>
[more]

Lack of practice makes imperfect

Tue, 28 Oct 2008 23:32:45 GMT
Apparently it's been too long since I've played with SQL Server databases. I say this because I made a boneheaded mistake today that obliged me to spend some quality time in the debugger.

Someone asked me whether I could convert the good ol' cascading drop-down example from using an Access database to using SQL Server. My first reaction is "C'mon, how hard can it be? You just swap data sources."

This is like a teenager in a horror film asking "Hey, I wonder what's in the basement?" Cue the ominous music.

The hard-won wisdom of experience stays my hand from actually replying "C'mon, how hard can it be?" I have to assume that if it were easy, the person wouldn't have contacted me.

So I set about converting. Within seconds I see that it isn't just a matter of swapping data sources. There is the small matter of actually creating the SQL Server database to match the Access one. There are only a few tables, so it's not hard. Dee-dee-dee, zip thru that little exercise, take a bunch of defaults, there, done.

Then into the code to set up new SqlDataSource controls to match the Access ones, point the drop-down list controls to the new data sources, and tweak some code.

Ready? Test. Bam. YSOD. Fail.

(Update 28 Oct I updated the screenshot -- was showing the wrong error, oops. Error about the error.)

I eventually track this down to a problem in the markup, here:

<asp:DropDownList ID="DropDownList1"
runat="server"
AutoPostBack="True"
DataSourceID="ManufacturersDataSource_SQL"
DataTextField="Manufacturer"
DataValueField="Manufacturer"
[more]

Stack Overflow and developer documentation

Tue, 16 Sep 2008 08:24:03 GMT
Stack Overflow, the much-anticipated project put together by Jeff Atwood and Joel Spolsky, went live a couple of days ago. The site brings the known vectors for crowdsourcing to developer documentation, combining traditional support forums with wikis and social bookmarking to produce "a collaboratively edited question and answer site for programmers — regardless of platform or language."

Based on the sorts of discussions that have already been posted, it seems that the likelihood of me being able to answer an actual programming question is slim. The level of discourse is not, as yet anyway, equivalent to the sprawling playground that is the ASP.NET forums, whose (currently) 2,166,075 posts include a sizable number of discussions by and for newbies -- often, in fact, including some of those proverbial stupid questions that your teacher said did not exist.[1] And thank goodness, beacuse some of those I can actually respond to.

But I am taking an interest in posts that bear the tag documentation, of which there are about 50 to date.

It is gratifying, for a start, that there are questions about which is the best documentation (sort of), and better yet, quite a few questions about how to create documentation.

Some threads that I am particularly interested in right now are these:
[more]

MSDN search upgrade

Tue, 09 Sep 2008 11:51:20 GMT
Excellent. Announcement today when you do an MSDN search:

More on MSDN

Tue, 12 Aug 2008 08:49:07 GMT
In the wake of my recent yackery about undocumentation on MSDN, Seth drew my attention to some comments on a mini-microsoft blog post. As usual, the comment threads, which are huge, veer far, far off topic. Interspersed among all the other sniping, the comment thread in question addresses the usefulness of documentation on MSDN.

This is the initial complaint:
... the MSDN documentation continues to be so thunderingly useless. A 10-second Google search almost always finds blogs or articles far superior to the cruft in MSDN.
Another commenter joins the fray:
MSDN is the sole reason why Open Source hasn't yet completely taken over as a development platform. They don't have proper documentation for stuff and we do, so when you develop something you KNOW you'll be able to figure things out quickly, either from MSDN or from people who have read MSDN and created their own samples (where else do you think they got their knowledge from?).

I could name quite a few things Microsoft puts out that are "useless", but MSDN is not among them.
There is some back-and-forth about MSDN, which mostly gets into the search capabilities of MSDN. Returning to content, someone who is probably a writer in the Developer Division observes:
... when a single writer is responsible for maintaining 3500 pages of documentation, content will usually suck to one degree or another. Pick about 10 tech books on your shelf. That's the amount of text some writers are responsible for keeping up to date.

They'd love to write samples or dig into obscure failure modes of APIs, but just don't have the time.
This is answered by the now-familiar request to make documentation into a wiki:
[more]

Docs, undocumentation, and the DailyWTF

Wed, 06 Aug 2008 14:37:12 GMT
An ignominious appearance on the DailyWTF recently got one of our documentation topics some undue attention. Alas. The topic in question pertains to what around here we call an "internal only" type or member. Or as is stated more formally, it's a topic about a class that "supports the .NET Framework infrastructure and is not intended to be used directly from your code." This is boilerplate, and many topics feature this fascinating information. In this particular case, tho, and for reasons not entirely clear, someone added the text "This type does nothing meaningful." Result: mockery. Ouch.

Couple of things here. First and most general, why do topics like this even exist? They obviously have very little useful information. Scott Swigart once memorably called this sort of thing "undocumentation." (This would be amusing, other than that I don't think Scott was particularly amused at the time.)

The short answer is: because they must. We are obligated to have at least some documentation (or undocumentation, if you will) for every single type and member that is not explicitly set to private. To put it another way, if you can use .NET reflection to see that a member exists, we have to have something in the docs for it. Why? Well, think back on history and imagine the consequences if we didn't [more]

Tag cloud control

Tue, 08 Jul 2008 23:37:27 GMT
I recently decided to implement a tag cloud. I'm not quite sure why this grabbed me; I don't pay that much attention to them my own self. But the idea of how to do it interested me, so I gave it a bash as an ASP.NET custom Web server control[1]. I don't need a tag cloud control, and I bet that if you need one, you already have one. Basically, this was just a fun exercise for me.

Demo here: Tag Cloud Control Demo
Source code here: TagCloud control source code

In a tag cloud, the various tags are displayed in a font size that's proportional to how many times the tag is used. A tag that's used a lot is big; a tag that's seldom used is small. Who knew, there are various ways to calculate this spread of font sizes. I ended up using an algorithm that I think (?) I found on a PHP site, I forget exactly.

This is what it looks like. This isn't live; to see a live one, go to the demo.

The control feeds off a list of items that contain a tag name and a tag count. How this list is generated would be, as they say, left as an exercise for the reader. I wrote the code so that it expects something that can be cast to IEnumerable. I played with it two ways. One was to create instances of a TagItem class (conveniently provided by myself) and stick them into a List<T> generic list (VB: List (Of T)) or an ArrayList object, both of which worked. I also was able to successfully give it a DataView [more]

A slightly less trivial browser history example

Thu, 03 Jul 2008 15:52:13 GMT
One of the ASP.NET features that will be officially mainstreamed in the .NET Framework 3.5 SP1 release is browser history. (Video) (The feature has been available in Futures releases and in the SP1 beta for a while.) In my editing role I keep crossing paths with the browser history feature, and in my limited exposure to it, I kept thinking that the examples I was seeing were sort of trivial.[1] In particular, the examples I was seeing either a) showed history for a single state change or b) in worse cases, were examples that didn't really require the feature at all. So I played with it a while until I was satisfied that I got the gist of it.

Lightning explanation for those who don't know this feature. AJAX-enabled pages usually perform asynchronous postbacks that result in a change to the page. You click a check box; async postback; page changes. Click button; async postback; page changes. However, the browser doesn't know about these async postbacks. If you now click the Back button, the browser unloads the current page, pops a URL off the history stack, and goes to that URL. What you probably wanted, tho, was to just return to the previous state, not to the previous page.

In brief, browser history works like this: during the async postback, you call the AddHistoryPoint method of the ScriptManager control. In the call, you pass a name/value pair, where the value is some value that you want to save. Like this:

ScriptManager1.AddHistoryPoint("ListBox1", ListBox1.SelectedValue, title)
[more]

What version am I using?

Mon, 30 Jun 2008 18:08:37 GMT
I'm running ASP.NET version 3.5. Or am I? The evidence is a little ... confusing. Let's have a look.

If I open VWD 2008 Express and click Help > About, I get this:

The New Web Site dialog box says this:

The Property Pages dialog box for a Web site tells you:

Suppose, however, that I have a peek at the headers sent by ASP.NET when I request a page (thanks here to Fiddler):

That's odd, no?

Or the even-more-confusing issue of where to find the .NET Framework tools. If you read about aspnet_regsql.exe on MSDN, you'll find this:

So we go to %windir%\Microsoft.NET\Framework\:

You can hunt all you want in v3.0 or v3.5, but you won't find aspnet_regsql.exe. I'll save you a teeny bit of trouble and tell you that you will find it, tho, in %windir%\Microsoft.NET\Framework\v2.0.50727.

So am I running ASP.NET 3.5 or ASP.NET 2.0?

Yes.

The issue of what version of the CLR is running has been addressed before (more [more]

Caching rendered control output

Sat, 31 May 2008 21:25:39 GMT
During the recent discussion here about view state errors, I examined the view state that was being saved for the very page you're looking at. It was running about 7K, which actually isn't that terrible. But I wondered how much I could reduce that.

You don't need to save view state if you're going to regenerate the control state on each postback anyway. So for my first effort, I disabled view state for a couple of the boxes you see on the left (they're user controls) -- the blog roll and the 25-most viewed entries. I also commented out the If Page.IsPostBack test in the logic for those so that they'd rebind on every postback.

At that point, I'd made a questionable tradeoff. I whacked about 50% off the size of view state, that's good. But I'd added a, you know, cognitive load onto server processing by making the user controls do all their data query and binding each time. To mitigate this somewhat, I cached the data that these guys display; this at least eliminated database access on each postback (for these controls).

It's not at all clear to me that this is a good exchange. I don't have (I don't think I have) a precise way to test the effect of this change. I think the real test would need to put the server under load, because it's at least partly a question of scaling -- by adding processing overhead to the server, I've reduced its ability to respond. How much? That's the question, innit.

[more]