OOP - There It Is

Sharpening Knives

2008-06-10T20:24:01.0142478-07:00

The Resharper cult members already know this, but for those who haven't joined yet, version 4.0 released today with VS 2008 support -- huzzah, huzzah. No longer able to resist the chanting and promises of eternal coolness I donned my robe and installed my free copy.

I clearly should have joined sooner. Resharper has already changed my life. First it pointed that I had redundant overrides in the control I was working on, which I had really meant to delete.

Then it reminded me about the new implicit type declaration keyword var, so this...

XmlDocument SomeDoc = new XmlDocument();

becomes...

var SomeDoc = new XmlDocument();

Granted, that's not too exciting, but if your type declaration is something like...

Dictionary SomeDictionary = new Dictionary();

with var it becomes...

var SomeDictionary = new Dictionary();

Then Resharper pointed out something I didn't realize was available in C#, the object intializer?? VB.NET has long had something similar with the With statement (now with object initializer goodness too). What's nice about this is that it saves repeating the instance name in front of the properties. So this...

var MenuBinding = new MenuItemBinding();
MenuBinding.DataMember = MenuItemElementName;
MenuBinding.TextField = DisplayTextAttribute;
MenuBinding.NavigateUrlField = NavigationUrlAttribute;
MenuBinding.Depth = Depth;

becomes...

var MenuBinding = new MenuItemBinding
{
     DataMember = MenuItemElementName,
     TextField = DisplayTextAttribute,
     NavigateUrlField = NavigationUrlAttribute,
     Depth = Depth
};

I was staring at this new construct when I realized that -- it shouldn't work. The project I was working on was a Framework 2.0 project and these things were in 3.0 syntax. But the darn thing compiles and works. Not even a single warning. WTF? It turns out that since 3.0 and 3.5 are based on 2.0, these are simply compiler tricks -- there is nothing fundamentally different about the types. Here's a blog post that explores in more detail what is happening under the covers.

Not bad for 15 minutes of tooling around. Guess I am an official member. Where's the Koolaid?

For Pete's Sake -- Just Try It

2008-06-05T17:59:09.19775-07:00

Every month or so, someone posts a question on one of the .NET forums I frequent asking if such and such will work, or if you can do so and so. The post will detail the background of the issue, including theoretical approaches, possible drawbacks, imaginary contingencies and tangential concepts. Invariably the poster wants to know the "proper way" to code something, and yet 6 paragraphs later hasn't shown what he or she has already attempted.

Why?

Because the poster hasn't written any code yet.

Philosophical development discussions can be fun. Reviewing fundamental design issues, or exploring the possibilities of a new technology or entering a new problem space beg for "what if" questions. It's good to have an idea where to go, a vague notion how to get there and to find out how others attempted the journey. Those are fun questions to answer.

Another excellent time to ask "what if" questions is when facing an irrevocable upgrade or configuration change. When a wrong step can wreak havoc it wise to ask for advice. That's what a forum is for -- to get pointed in the right direction or pushed back on course or to be told to hurry back to shore.

No, what makes a coding "what if" question a total waste of time and bandwidth is when it asks how to write a relatively small amount of code. The post itself is longer than the most convoluted possible solution. To put it programmatically...

if(Post.Length > Code_Needed_To_See_If_It_Works.Length)
WasteOfTimeAndBandwidth();

In other words, if the poster had actually tried to code one of the carefully penned theoretical approaches, he or she would have ended up typing a lot less and would have discovered the solution without a trip to forum land.

Some examples (and I wish I were making these up):

Is it possible to set SomeObject.SomeProperty = SomeValue?
Can I put this control inside this other control?
How long will SomeObject.SomeMethod() take to run?

Programming is a wonderfully empirical undertaking. With IDEs (Integrated Development Environments such as Visual Studio) it is easy to create code and test it. At the level of of a function or even a web page or windows form, there is no need for thought experiments or theoretical ponderings -- the code either does what it is supposed to or it doesn't. There is no need to write about it -- just write it. If it doesn't work, then you can post a question that is based on something real.

Unless you are doing something silly like working on a production system, the cost for trying something out is minimal. In the worst cases, bad code throws an error or just doesn't work. Things don't explode, no one dies. With source code/version control (which everyone should get into the habit of using), it is trivial to roll back to a previous working version.

So please, for your sake and Pete's, try it first. See what happens. You'll save some time and might be pleasantly surprised.

More Navel Gazing

2008-05-29T18:31:20.63-07:00

Received a surprised IM this morning from Jeff Schoolcraft, Code Camp Organizer Extraordinaire and sometime blogger. He was struck dumb by the fact that I actually used the online editor to pen my blogs. He tried very hard not to question both my sanity and intelligence when I told him that the #2 pencil was my first choice but it only updated my monitor.

He patiently explained to me that there was a pretty nifty desktop tool available and it was free. He even sent me a link to download it.

So I installed Windows Live Writer and am taking it for a spin. So far, so good. Much more space to work with, a nice clean interface and no worries that my connection is going to die or my blog app is going to recycle while I am writing an overlong post.

If you are reading this, it means that it posted successfully.

Something (Kinda) New

2008-05-28T19:22:05.333-07:00

I hate upgrades. I usually put them off until:

Something (someone) puts a gun to my head
There is a compelling feature available
I'm feeling lucky

Case 1 is the usual situation. When things won't work any more, I'll bite the bullet. If things are working, I have a tendency to leave them alone because vast experience has taught me that the Law of Unintended Consequences usually makes itself known whenever something gets upgraded. I don't care how many versions behind it is. I don't like to blow half a day getting back to where I was before the upgrade.

Case 2 actually popped up twice in the last month. I moved to Vista finally because I wanted to play with the new PeerToPeer.Collaboration namespace in 3.5. It hasn't been too horrible, (except for the file search function which is even more obtuse than it was in XP -- which I thought was an impossibility). It was also just a move to a fresh machine. I also upgraded my SecretServer install, because I wanted to take advantage of the ActiveDirectory feature. I was only 3 major versions, 2 minor versions and 30 revisions behind, but with some help from the good support folks at Thycotic I was able to get it current without too much hassle.

Case 3 is something I should avoid. I should know better, but it happened while I fooling around with this blog last week. I realized that the blog software (dasBlog) was many versions behind and I figured the last upgrade hadn't been too bad. There were also a couple quirks I figured would be handled by the new version. So I downloaded all the new stuff, merged my web.config file, made the few other changes and pushed everything up. Worked, mostly. I couldn't edit or enter new entries. The FreeTextBox component was displaying a "was not installed correctly" error. Hours of googling, typing, begging and swearing later still no luck.

So tonight I decided it was time to move on. dasBlog supports other editors, and John Forsythe has created a lovely little addin for the TinyMCE rich text editor. I downloaded, uploaded, recycled the app, changed the configuration and behold my dasBlog install once again is back where it was a week ago -- I have a text editor to create entries.

On the positive side, TinyMCE is has more features and the new dasBlog goodies are nice, so I guess it was a worthwhile exercise. I'm just posting this to remind myself that I should "never feel lucky" when considering an upgrade.

UPDATE: Just discovered Comments weren't working because I had the Resolve IP Setting turned on. Looks good now. Not that I get lots of comments, but I would like to provide the outlet.

Making Like Martha Stewart

2008-05-19T09:52:34.76-07:00

While crawling around in VS 2008 to work on the P2P presentation for RockNUG and the NOVA Code Camp, I stumbled upon a lovely little feature under Intellisense on the Edit menu called Organize Usings. A simple click can remove unused using statements, sort the statements or do both. Cleans up code faster than a life style diva on a nicotine binge.

Visual Studio has default templates for all project items and they frequently includes using statements for namespaces, that well, never get used. The class template, for example really, really wants you to use the LINQ and the System.Text namespaces. If you haven't gotten around to modifying the default templates, you'll have lots of unneeded using statements cluttering up your code. The Organize Usings feature can help save other developers (or the future you) from wondering, "Where the heck did he use LINQ in this class?".

And just so you don't strain yourself, it is only available for C#.

Camping Out

2008-05-17T18:30:07.098-07:00

Nothing like a code camp to get jazzed about all the stuff I could be working on. It is like a revival meeting; everything is new and exciting and possible.

I took in sessions about making DotNetNuke modules and the new ASP.NET Dynamic Data extensions. Very interesting stuff. The Dynamic Data stuff appears to be a great way to bang out admin pages with minimal effort.

I also presented my little talk about the new Peer-to-Peer Networking goodies in the .NET 3.5 framework. This is stuff that's been possible to do with the Windows API for a long time, but has finally been exposed through the managed classes for access by mere mortals. Here is yet another chat application that demonstrates how it all works.

The real exciting namespace is its child the PeerToPeer.Collaboration namespace. It is a framework for building p2p apps. Didn't have the time to delve into it fully, as it is only supported in Vista. But it did provide the first compelling reason to upgrade, so I finally succumbed.

Just need to invent the 50 hour day to get to try out all the things I'd like to.

Too Much of a Good Thing

2008-03-21T19:06:20.231-07:00

This entry has nothing to do with .NET, OOP or anything related to software. It does mention the number 64, which is a very common thing in programming, but that is coincidental. If development goodies are what you are looking for, you'll have to wait for the next entry when we will resume our irregularly scheduled programming.

No, this is a grumpy old man column. As I do every year in March, I am half watching the NCAA Men's Basketball tournament, which amongst the commercials offers some good games and occasional high drama. The tournament starts with 65 teams and after three weekends of single-elimination contests crowns a single champion.

Now, 65 is a strange number for a single-elimination tournament, which cries out to start with a number that is a power of 2, like 64 perhaps, that will fold evenly down to one. And, in fact, the NCAA, lops off the 65th team in a single game, which is either known as the Play In or Opening Round game depending on how much NCAA kool-aid you've consumed. The reason behind the 65 team start can be found here.

I've made my peace with the 65 team format, since the extra team is so easily lopped off and is pretty much forgotten by the time the real tournament starts. Heck, every tournament pool ignores it; entries don't have to be submitted until just before the first real game starts two days later. It really is only of concern to the two teams forced to play (in Dayton!) for the final spot in the real tournament.

No, what I am trying to forestall is expanding the tournament beyond its current size. This issue arises every year because selecting the teams for the tournament is a partially subjective process. Only the 31 teams that win their conferences are guaranteed a slot, the other 34 at-large bids are chosen by the committee out of the 300+ teams that play Men's Division I basketball. There are no hard and fast rules, and while the committee's decisions are not usually as nutty as the BCS, every year there are a handful of teams who feel slighted by the process. An indignant coach will have a press conference and complain because his team wasn't chosen while Team A was, and everyone "knows" that his team was better than Team A.

A number of these coaches whose teams have been relegated to the NIT (National Invitational Tournament or Not Invited-to-the-real Tournament) argue that since there are so many "good" teams, that the NCAA tournament should be expanded to 96 or even 128 teams, so all the "deserving" teams get a chance to play for the championship.

This is a load of hooey. None of the 32 or 64 teams added to an expanded tournament has a cookie's chance at fat farm of winning the tournament. Heck, 32 to 48 of the teams in the current format don't have a chance. The lowest seed to win the tournament since it expanded to 64 teams was a #8 seed. Given there are 4 #8 seeds (one per region) that's anywhere between the 29th-32nd best team in the tournament. Even given the vagaries of the selection and seeding process and the chance involved in a single-elimination tournament, the best team is going to be found in the top 32 teams, or more likely the top 16. Everyone else is there to enjoy the experience, get on TV, and give the rest of us something to bet on for three weekends.

Expanding the tournament will not end the "we got screwed by the committee" press conference, it will just create an even more mediocre and possibly larger bunch of "slighted" teams. But let's pretend that the NCAA listened to one of these whiners last year and expanded the field to 96. What would the tournament look like?

First off, 96 is not a power of 2, we need to get back to 64. We'll do this by expanding the Play In Round to 32 games. The lowest seeded 64 teams in the tournament will have to play an extra game. The winner of each Play In game will move on to the Round of 64 to play one of the highest 32 seeds.

Where do we get the extra teams? We'll steal them from the NIT, which has the next best 32 teams. They are seeded in 4 symmetrically arranged regions of 8 teams each, which is perfect. We'll simply append an NIT region onto the corresponding NCAA region, add 16 to each team's NIT seed to get its expanded NCAA seed. The lowest seed in the expanded NCAA will be a 24 seed. For example here's what the expanded NCAA East region would look like this year....

Is this ugly or what? And it is only one region. The Play In round adds 32 games, but none of them is even mildly compelling. Looking forward to that #14 Boise State vs #19 Dayton match up? Sure there are 32 more games, but due to the tournament format, not one of them features a top 32 team. All the games feature teams that run from the gamut from eh to decent. Cal finished 9th in the Pac 10 for goodness sake! The current 64 team format at least shows the best teams in the first round, and offers the possibility (if seldom realized) of huge upsets. in our hypothetical Play In round the biggest upset would be #24 UNC Asheville knocking off #9 Arkansas. And who cares, really?

Life gets extremely ugly for the #9 seeds. Congratulations, your team gets to play another game, while the team that may be slightly better than yours gets a bye. The #8 #9 seeds are virtually interchangeable -- historically the #9 seeds have actually beaten the #8 seed 54% of the time -- yet #9 has to Play In while #8 enjoys a day off. That's four "the committee screwed up our seed" press conferences a year guaranteed.

Think any of the extra 32 teams can win 7 games to take the championship? Think again. No #16 seed has ever beaten a #1 seed since the arrival of the 64-team format. Adding the Play In Round does give the #16 a chance to win a game against #17. Of course, the winner of the that game is just playing for the right to lose to #1 in the next round. Only four #15 seeds have ever beaten #2 in 88 opportunities, and all four lost in the next round. The lowest seed to reach the Sweet 16 (win 2 games in the current format) is #14, and that has only happened twice. In a 96-team format the extra teams will have to beat one decent team and two good-to-excellent teams just to make it that far.

Yes, it's great to "make" the tournament, but being a #24 seed or even a #17 seed is the equivalent of an honorable mention -- and will result in a quick trip home. Expanding the tournament just dilutes it, renders actually making the tournament less meaningful. The grossly inflated tournament may paradoxically may make it harder on a coach to justify his team's performance every year. Boosters and potential recruits will start asking not only if the team made the tournament, but if it received a bye or made the Sweet 16. Instead of simply having to have one of the top 64 teams, a coach will have to start providing a top 32 or 16 team every year.

So to all the coaches and other supporters of "deserving" teams that missed the cut, if you want your team in the tournament next year -- win more games or make sure and win your conference. For this year, enjoy the NIT, it's a championship your team has a chance of winning.

Leave the tournament as it is. It already contains the teams that have a possibility to win it all and offers compelling games and good teams from the first round on. Best of all, in the current format, the bracket fits on to a single sheet with a type face people over 30 can still read.

The current format is good fun. Expanding to 96 teams or beyond offers a clear example of "more is less".

You Go 64-bits And Whatya Get?

2008-01-08T21:05:38.541-08:00

Headaches. Homicidal thoughts. Horrible alliterations.

All these things happened over the the last few days.

It all started when I needed to build 64-bit versions of a few .NET 2.0 apps (a wep app, a windows service and a passel of supporting libraries). This is actually very simple to do. Visual Studio exposes a platform setting in the build configuration for each project. The default platform is anycpu. Specifying x64 sets the compiler option and instructs VS to build a 64-bit image (even on a 32-bit machine). Of course, doing this for a bunch of projects would be dull. Fortunately, I already have NANT scripts to build everything, so I added a platform parameter to the compiler tasks and voila, a slew of 64-bit assemblies in 194 seconds.

Dropped the gooey mess on the 64-bit machine, and by gosh the web app worked and so did the service. Double checked that the 64-bit system was not running any 32-bit assembly in WOW mode. Nope, all 64-bit baby! Ran the applications through their paces, and they ran perfectly. .NET makes 64-bit apps happen with the flick of a (compiler) switch -- sweet!

Time to build the 64-bit installers for the web app and the service. Now, if 32-bit deployment projects are the 3-eyed, 9-toed, humpbacked, perpetually sniffing step-chilldren of .NET -- and they are -- 64-bit deployment projects make them look like the fairhaired, first born heirs to the kingdom.

Just like any other app, deployment apps can be simply targeted to either platform. But finding the toggle is bit confusing. It is not in the same place as "normal" applications. The platform can't be changed in the build configuration, you must select the Installer in the Solution Explorer and click F4 to expose the properties. Selecting Properties... in the context menu for the installer does NOT expose the same set of properties. OK, a little swearing later, and the web app installer is set to x64 bit and it builds the MSI. Woo hoo, looking good!

Time to test it on the x64 server. An exception! Ugghh. BadFileImageFormat. WTF. Documentation time. The error says I am trying to run a 64-bit image on a 32-bit platform, but, but, but, I'm running a 64-bit image on 64-bit platform. Some googling, some double checking that a 32-bit assembly hadn't somehow screwed up the MSI. More swearing. Finally stumbled across this blog post which pointed me in the right direction.

The cause turned out to be a Custom Action that updates the web.config file, sets some directory permissions and sets up the application in IIS. The Custom Action is an installer class that is kicked off by InstallUtil in the MSI. Worked fine in 32-bit. But, VS embeds the 32-bit version of InstallUtil in the MSI, even when a x64 platform has been targeted, hence the BadFileImageFormat exception.

The workaround required downloading the Platform SDK and installing a tool named Orca. Orca lets you inspect/alter the MSI guts. Pulled the 64-bit version of InstallUtil from the x64 box and sucked it into the MSI using Orca. Saved the MSI and tried it again. And behold it worked, Custom Action and all. Thank you ~~Chuck Norris~~ Heath Stewart.

The service was bit trickier. I kept getting FileNotFound exceptions in the Windows directory. But I wasn't trying to install anything in the Windows directory, which was a bit perplexing. The problem turned out to be the default directory for installing the service had a space in it. Yes, in 2008, this is still an issue. Changed the default directory to something without spaces, and got around this error only to run into the dreaded InstallUtilLib.dll: Unknown Error., (NULL), (NULL), (NULL). More swearing. Well, it turns out that InstallUtil doesn't deal well with the way the installer package escapes path names when sending data to the Custom Action. So I just sent all the properties without the surrounding quotes (since I was no longer allowing paths with spaces anyway) and the darn thing finally worked.

There's got be a better way, the whole MSI process is so cobbled together, it is astounding that anyone can create a usable installer without third party tools (and even they seem hobbled by the Windows Installer determined quirkiness) or weeks of free time.

Now, all of this could have been avoided if I hadn't used Custom Actions. But there are no Standard Actions for:

setting directory or file permissions
setting up virtual directories in IIS
setting the ASP.NET version and application pool
updating configuration files

Also, the VS deployment project relies on a Custom Action to install the service, instead of creating a service table in the MSI. Not sure why this is, but tis annoying to know it's there yet not exposed in the deployment project. If I had wanted to dive into Orca, I could have used to it set up the table in the MSI, but my patience had long since expired.

I'm not holding any hope that the situation will improve in the future. As the software world becomes ever more web-centered, there is even less call for building installers. With FTP and Xcopy it's easy enough to deploy web apps. Setting up an app in IIS manually is trivial and .NET removes most of the need for dealing with Registry foo.

If I have a client ask for install package again, I'm giving them a zip file and a page of instructions. Infinitely quicker than dealing with Misfit Solution Installers.