Joshua Flanagan

My first custom .Text skin is largely based on the work of RoudyBob.  I'm going to try and collect a list of resources for skinning.

• Mark Wagner's .Text Skinning 101

At DevDays-Austin, Stephen Fulcher said “Code Access Security is the most least understood part of .NET”.  I agree.  Especially after reading this article by Keith Brown in the latest MSDN Magazine.

So what is the second most least understood part of .NET?  My vote would be the Global Assembly Cache.  It seems pretty straightforward on the surface: it is a central location to store assemblies shared by applications across your machine.  Ok, so the answer to my title question is easy: use the GAC when you have an assembly that is used by more than one application.  Not so fast.  There are a couple reasons I can think of off the top of my head why this might be a bad idea:

1) To install an assembly in the GAC, it must have a strong name.  When an assembly has a strong name, it is locked down to a specific version number.  Every client application that uses that assembly will be compiled to use that specific version number.  So how do you release a bug fix for your assembly, without having to re-compile all of your client applications?  Not very easily.  In fact, I don't know how to do it.  But I'm pretty sure it can be done.  I vaguely remember reading something about editing an assembly's manifest so that it only requires a “minimum” version number, instead of a specific version.  I will have to research further (feel free to aid my research by letting me know if you have the answer).

2)  Once you start sharing “bits“ between distinct applications, you create a superficial inter-dependency.  If you make a change to the common assembly, it will be reflected in each of the dependant applications.  Put another way, if you wish to make a change to the common assembly, you will have to TEST each of the dependant applications - even if only one of the applications cares about the change.  With the price of hard drive space so low these days, there seems little reason to share actual bits and therefore increase your regression testing responsibilities.  Sharing code is great - designing assemblies to be reusable is great.  But why not store the bits in the private directory of each application and save yourself the testing headache?

3) This may not be a valid reason, as it is purely gossip at this point... but during his DevDays presentation, Michaels Stuart, of Application Block fame, mentioned that he has heard rumors that the GAC will be deprecated in future versions of .NET.  How far in the future isn't clear.  I don't expect it to be gone with Whidbey, since it has already shown evolving signs of life in the PDC builds.

I understand that these are not rock-solid arguments for avoiding the GAC.  You might be able to offer me a rebuttal for each of them.  My point is there is “doubt” about its usefulness, or rather when it should be used.  Others have doubts about it too.  So does anyone have a good answer?  When should I use the GAC?

I finally got around to checking out the DevDays DVD today... wow!  This disc alone is worth the price of admission.  Each of the sessions is availbe in video form, with a synchronized “agenda” that lets you easily jump around to various topics.  You can also pull up the PowerPoint slides locally to follow along.  And did I mention the complete, very well-documented, source code?  These guys are good.

Apparently, all of the sessions were designed and written by Vertigo Software.  These are some sharp guys (and gals).  I saw their CEO, Scott Stanfield, speak at TechEd 2003, and he was great.  Up there with Scott Guthrie for best of show.  It's funny, because when I first started reading Scott Hanselman's blog, I thought he was Scott Stanfield.  You see, Scott Hanselman is ALSO a great speaker on .NET technologies.  I haven't seen him speak in person, but I've seen the movie.  As it turns out, there are actually 3 distinct people named Scott that are really worth listening to if you get the chance.  As luck would have it, they've all been guests on .NET Rocks, so you DO have a chance.

Anyway, I was saying, the presentations on the disc are really worthwhile.  One of the speakers at DevDays - Austin commented on how all the presentations were pre-written, which put the speakers in a rare situation where they had to present material that they didn't create.  I can understand how tough that would be, since we all have our own personal coding styles, and you would be up there in front of an audience promoting someone ELSE's coding style, while constantly fighting back the urge to say "actually, I would have done it THIS way".  To their credit, I only heard that phrase 2 or 3 times.

Speaking of coding styles and the DevDays code: I couldn't help noticing the use of "type prefixes" in some of the code - a la Hungarian notation.  A practice specifically discouraged in the .NET design guidelines.  Actually, the prefixes were only used in a few places, and it is a practice I am guilty of myself.  For example, the DataAdapters are named daIssues, daIssueTypes, etc.  And the UI components are named txtUsername, txtPassword, etc.  I recently worked on creating a C# Coding Standards document at work, and we added an explicit exception to the “no type prefixes“ rule for UI components.  Is that normal, or are we all just a little weak willed about breaking the habit?  Do you still use type prefixes ever in your .NET code?

I think people can put to bed their “VB is Dead” theories.  I didn't see a single line of C# code at DevDays 2004.  Every session was presented in VB.NET.

I was a big fan of VB 3-6.  I loved how easily I could be productive.  I taught myself the .NET framework writing VB.NET code with the SDK's.  But when my company decreed that all .NET code must be C#, I reluctantly made the transition (case-sensitivity is such a pain! I don't want to use my shift key while writing code!).  Of course, within a month of using C#, I became a complete convert, and would never want to write VB.NET again.  I don't miss it.  In fact, it really turns me off from projects when I discover they are written in VB.NET.

But I have to admit, after seeing VB.NET in action again at DevDays, I started to miss it.  Pull down menus for overrides and events!  Auto-capitilization!  On-the-fly compilation warnings/errors!  I don't even want to consider the jealousy I'll feel when/if VB.NET has “edit and continue” while C# does not.

What's really cool about the way Microsoft is handling this:  they aren't treating VB.NET programmers like VB programmers.  Ok, they're obviously recognizing the fact that “the masses” feel more comfortable with VB syntax.  But they are not going to let the masses continue to code in their old VB ways.  This was most evident by the focus on design patterns in the Smart Client track sessions.  Design patterns were traditionally the domain of OO fanatics and enterprise focused technologies - something you would hear about when talking to a J2EE programmer, not a VB programmer.  I understand that .NET fits into that world perfectly, I just didn't expect it to be so prominent in sessions aimed at the masses.  I think the first session spent more time talking about the design patterns than the technology that Microsoft was showing off.  Kudos to MS for pushing us all to be better developers, not just by giving us great tools, but by promoting valuable “platform agnostic” best practices.

Although, I'm not really doing any Smart Client development yet, I chose to follow that track.  Mostly because I think I've heard all of the Microsoft security sessions at least 3 times each over the last year -- OK! I'll never build SQL queries through string concatenation again!  Actually, I shouldn't complain, it's surprising how many of my colleagues are still unaware of SQL injection vulnerabilities.  In that sense, it is good that Microsoft continues to build awareness on these issues, I would just rather learn something new.

I am genuinely interested in trying my hand at Smart Client development.  I just wonder how long it will take to be accepted in the (our) corporate environment.  It seems just a few years ago we had to convince everyone that our Windows apps should be converted to web apps.  Now I'd like to convince them that some of our web apps really should be “smart client” apps.  Actually, what I'd REALLY like to convert to a smart client is all of the Visual Basic Document apps we have.  Man, Microsoft really snowed us on that one.  Luckily, they seemed to kill it after only one version of VB.  Unluckily, it seems my company did a lot of new development that year, and decided to use the “latest and greatest”. Sigh.

I thought the keynote for DevDays 2004 - Austin was a bit underwhelming.  Jay Skelly ran through quick demos of InfoPath, BizTalk 2004, and SQL Reporting Services.  I've seen the InfoPath demos before, and I don't think this one really demonstrated its power from a developer's point of view.  It was more like “hey look, you can draw a form and fill in data”, which might lead someone to think “I guess its Microsoft Access for Web Services”.  Maybe that's the intended effect, but I think it really undersells its potential.

The BizTalk demo was semi-interesting, as it demonstrated orchestrating a distributed transaction system through a slick GUI... but I was left thinking there must have been a lot of preparation beforehand to get the demo to the state it was in, and therefore, could not get a good feeling for what it might really be like to work with the product.

And I'm still not sold on SQL Reporting Services.  It looks like a replacement for Crystal Reports.  Crystal Reports is the product that they have been bundling with Visual Studio for a few years, but has yet to gain the utilization you might expect from a bundled product.  I was never sold on Crystal Reports, and I don't personally know anyone that was.  So, why should I be interested in SQL Reporting Services?

Steven Fulcher the showed a glimpse of “Whitehorse”.  Now you've got my attention!  It looks like Whitehorse will finally put VS.NET in the hands of system architects, in a way that Visio was never able to.  I'm not an expert in this field, its possible that other products, like Rational's XDE, may already provide this functionality, but I have never seen them presented so “approachable”.  A co-worker was disappointed in the fact that Microsoft is creating their own graphical representation of systems and integration points, instead of using common UML symbols.  Funny, I think that's exactly why I liked it.

J Sawyer ended the keynote with an overview of XP SP2.  It was all material that has been online for a while now, but I understand not everyone follows MSDN as rabidly, and it is important to get the word out on the major changes.  And it reminded me that I really should grab the beta soon and start testing my apps.

I arrived at DevDays Austin about 5 minutes before the scheduled start of the keynote, so I was rushing around the convention center looking for the auditorium.  I instinctively headed in the direction of the exhibition hall that hosted every other Microsoft event I've attended.  As I got closer, there was a noticeable difference in the attire of the people around me.  For one, there was a much higher than average number of cowboy hats (as a relocated New Englander, I've finally gotten used to the idea that a small number of cowboy hats is to be expected).  I finally found a woman wearing a black DevDays 2004 shirt, she immediately recognized my confusion, and directed me to the top floor on the complete opposite end of the convention center.  Huh, why are we being “hidden away” in such a remote location?  That's when I noticed the large banner announcing the “Texas & Southwestern Cattle Rancher's Assocation” convention.  Aha.

I hope this post doesn't get aggregated anywhere.  I know how tiring it is to read a stream of “Hey, I'm gonna try out this blogging stuff” posts.  If it does get picked up, consider this my apology.  Move along now.

I'm looking forward to my first DevDays event tomorrow.  I plan to post my thoughts after I return (I'm not planning to lug a laptop, and stylus entry to my Axim would be painfully slow).  Mostly, to see if I find personal value in blogging about an event.  But also, I figure I can help contribute to Austin's chances at the DevDaysBloggers contest.