Samer Ibrahim's Blog

Odd behavior in ASP.NET

2004-05-05T03:08:00Z

So after wasting about an hour and a half debugging why in the world I kept getting an invalid cast exception, I discovered a quirk in the way ASP.NET loads assemblies. Apparently, the .NET framework loads everything in the \bin directory that even looks like a DLL. For example, if you have a file called DLL_ the framework will load it anyway. Why the hell it does this I don't know!!! It's not even a DLL for God's sake!

Now you might be wondering why in the world I have a file called DLL_ sitting in my \bin directory but that's easy to explain. Sometimes I want to use a different compilation of a DLL that might contain something like more debugging code, for example, in my ASP.NET application. So instead of moving or overwriting the old version or recompiling my application or even changing which version is redirected to what other version in the config file, I simply change the old DLL to DLL_ or something of the like and drop the new DLL in the \bin directory along side of it. Seems harmless and should work and in fact it does when .NET isn't being stupid and just loads DLLs.

I spent all this time trying to figure out this problem, changing the code I was debugging over and over again, and when I finally said what the hell let me see what the code base is for DLL which contains the class I'm trying to cast to, I saw that it was <Path>\SomeAssembly.DLL_. This is a bug as far as I'm concerned. And as far as I can tell, there is simply no application for this type of behavior so I'll just call it retarded.

By the way when I say ASP.NET, I'm working with SharePoint specifically.

More Training... this time on SharePoint

2004-05-03T00:04:00Z

So after my complaining about SharePoint documentation you might be wondering how to get some good SharePoint training. Well the answer is pretty clear cut. You get training from Barracuda.NET, a company run by Ted Pattison and Jason Masterman both former DevelopMentor guys.

I've been going through their training now but it's clear that they not only wrote a very good training program but are determined to answer all your questions even if that requires offline research. I think this is a quality that is very admirable and is one reason I feel you'll get your money's worth.

Personally my only problem with the class is I think the pace is too slow but I think that has to do with the diversity of the talent pool within the class.

AssemblyResolve event of an AppDomain

2004-05-03T00:04:00Z

I got a comment from a gentleman by the name of Anthony DeRosa asking for more details relating to how to load an assembly from a network location from my earlier post regarding the GAC. So even though I found that this is addressed elsewhere when I googled for it what the heck another entry won't hurt anyone.

Let's start with the Assembly.LoadFrom method which most people are familar with. One can easily load an assembly from a network location just using that method alone which may solve most people's problem. But what if you want to be able to only load the assembly from a location if the .NET framework can't find it on it's own or you need some other algorithm to locate assemblies. Little known to most people, beyond just the simple probing and checking of the GAC that .NET does, there is an event fired before the framework gives up on loading your assembly. The event is AppDomain.AssemblyResolve. You can subscribe to that event and do a simple Assembly.LoadFrom from a location known to you or even do some fancy loading of your own based on some system you engineer. There are also TypeResolve and ResourceResolve events in the AppDomain that let you handle those aspects of resolving the various dependencies of an AppDomain.

Of course if you are loading an assembly off the network you need to make some CAS changes.

Just Googling for resources I found these:

Also just as an FYI, there is also a ModuleResolve event of an Assembly.

SharePoint and EIF: Sore point for Microsoft documentation

2004-04-29T03:20:00Z

So as I've stated before, my new role is partially focused on SharePoint. Coming into this role, I had no experience with SharePoint and I really wanted to hit the ground running when I started my new position because a lot was expected out of me. I quickly learned however that SharePoint documentation is scarce at best. Microsoft has done a simply horrible job providing documentation relating to how SharePoint works beyond just the surface. The documentation that is provided is also incomplete or completely void of any mention of particular topics. They seem to have this completely impractical theory that SharePoint should be treated as a “black box.” I find this to be ridiculous for several reasons, here are just a few but the list goes on:

Not every environment hosting SharePoint is completely Windows based
SharePoint has missing features such as replication, caching, and recovery
Developers should understand what's going on internally so they don't mess things up or cause unnecessary overhead

So I find myself now relying on learning from trial and error and the expertise of those around me, which thank God is phenomenal. The truth is I don't so much mind all this because I think I'll learn a lot from writing test code to discover how SharePoint works and it will make me a better programmer in general, but from a company's perspective it's retarded. I should be spending time solving business problems not trying to decipher what is going on in SharePoint.

Same story with the Enterprise Instrumentation Framework (EIF). I'm trying to find documentation or even a whitepaper on it just to answer the simple question of whether or not I have to restart my ASP.NET application to turn on logging via EIF. I believe the answer is no but I can't be positive unless I write my own code to figure it out. This one in particular annoys me because EIF is a framework which makes documentation even more important!!! Developers need documentation that is readily available via the internet. Many companies have download policies so if the documentation needs to be downloaded it's useless. Employees need to be able find out about what they want to download first so they can make a valid plea to the appropriate people. Not having documentation for EIF makes me question whether Microsoft actually wants you to use it or if they are going to stop supporting it.

Ok I could go on about this ad nauseum but I'll spare you and quit whining about it (for now) even though it's really annoying....

Mythical Man-Month, The: Essays on Software Engineering, Anniversary Edition, 2/E

2004-04-29T02:48:00Z

I finished reading Mythical Man Month (aka MMM) recently and quite honestly I was amazed at how a book that was originally published in 1975 can be so on target with so man aspects of software development. Obviously not everything in the book is so pertinent however his foresight is amazing. The MMM is in a nutshell about debunking the theory that if you add more people to a project then you can speed the project up in a linear manner. The book makes quite a bit of sense. When you add in communication factors, learning curves, and the other items Brooks brings to light in the book you quickly see where he is coming from. Funny thing is the place we are in software development now might also brings an additional factor to the table. Offshoring brings even more of a communication gap. Both time zone gaps and language differences come into play. But I digress. In truth, I think the book has survived this long because Brooks focused more on the human aspect of development than on the actual programming piece. People don't change quite as rapidly as software so it makes sense that the book would still be applicable in today's environment. People are still a limited and valuable resource and it will probably remain that way. (Moore's Law is there for machines but not for people.)

For managers, I think the book is must read. For everyone else, the book is easy reading so if you have time I would recommend you read it. The first 17 chapters of the anniversary edition are the most worthwhile. I think the other chapters are really him just defending himself against criticism and not really as important to read (but hell that leaves only 3 chapters and like I said it's easy reading).

Validator Control that will validate all Controls on a section of a Page

2004-04-22T03:04:00Z

Ever find yourself creating an input form in ASP.NET that required a lot of Controls to be validated?

Well, I have. It's tedious. You have to add at least one validator to each Control you wanted validated. Apparently after discussing this with other people I've found that I'm not the only person who was wishing at the time that they could just add one Control that would validate all the Controls on the Page. What's the solution? To create a Control on your own to do just that and that's what I did.

Here's how you use it:

You add the Control to your page (sorry no “drag and drop” stuff I don't believe in drag and drop so I didn't find the need to write that kind of code but be my guest). You set my Control's ControlToValidate property to a server Control containing all Controls you want to validate, eg. the DIV containing your let's say TextBox Controls. That's it.

Magic huh? Not really, here's how it works:

My Control gets the ControlToValidate's Controls collection. It goes through the Controls collection and checks for controls that can be validated [0] and adds a validator control [1] to the ControlToValidate's Controls collection [2] immediately following any control that can be validated.
[0] To check for Controls that can be validated it uses the BaseValidator's GetValidationProperty method. Now my control doesn't inherit from BaseValidator so I have an internal class that does and exposes a function the just returns the value of BaseValidator.GetValidationProperty().
[1] The type of validator that is added is determined by you. I really wrote an abstract class that you must inherit from and implement one method that returns a validator. I've written the first one for you so you have an example. It adds RequiredFieldValidators.
[2] Controls don't have access to manipulate each other's Controls collection so I had to kind of hack my way around this. I used reflection to change a private field in the ControlToValidate so that it would allow me to modify its collection. Don't worry I change it back when I'm done :).

How do you get a hold of my Control:

You download it from my perpetually under construction homepage. The code isn't elegant or well documented nor does it provide you with all the other nice things Andy Smith's MetaBuilders website Controls provide you with but it works. Feel free to modify it as you will. If you feel like you've modified it and created something of value all I ask is that you share it.

The one caveat is that my Control has to be before the ControlToValidate in the Page (or user control, custom control, composite control, etc)'s Controls collection. The performance hit for using reflection was about 5% from my calculations on a Page with three Controls to validate however my testing environment was bad so I decided to quit testing. I really don't think it will really affect your performance that much though. Feel free to test it yourself and let me know the results.

One last thing just in case USE AT YOUR OWN RISK. Oh and I guess people always say don't redistribute so don't do that either (I don't quite know why but still).

Great article to get you up to speed on SharePoint and WebParts

2004-04-22T02:17:00Z

I finished training and started new position. My official title is “SharePoint Developer” but I knew nothing about SharePoint coming into this job. My boss therefore sent me this article to get my SharePoint knowledge to a working level. I hightly recommend this article to anyone who needs to work with SharePoint or WebParts for that matter. Since Whidbey is on it's way I think that makes everyone :).

Done training, real coding starts Monday... I love my job

2004-04-09T04:14:00Z

It's not everyday that I feel confident in my career decision. Many days I question why I'm chose to be a programmer. My family wanted me to be a doctor and on those days that I doubt my career choice I'm often wondering what stopped me from going to med school. I was a Molecular Biology and Biochemistry major (it's one track not two) as well as a Computer Science major. I had gone so far as to take my MCATs and even started filling out applications. The health care industry doesn't suffer from offshoring (well for now although some would argue otherwise [0], [1], [2]) and it could not care less about how the economy is doing. I still can't put my finger on what did it but I had a sudden change of mind and those applications never went out.

The pressures of being in IT surround me everyday. Sometimes I'm almost ashamed to say I'm a programmer because of the stigma that goes with it. Programmers are looked upon as dorks, geeks, or whatever you want to call them. In many ways I don't feel like much respect is given to programmers. While maybe I didn't save someone's life today, quite honestly neither did most doctors. (Not to equate the two which I think are very, very different.) I work for an organization where IT is a cost center for the most part, which is sometimes a scary thought. As nice as they want to be about it and as proactive about technology as they want to be, with few exceptions, the truth is technology is not a direct source of income. The fact that may companies would cease to be competitive without us, however, is one of the many ways that illustrate how dependent daily life is on programs. Everyday we hear about offshoring or something else that threatens our industry and we're in a cyclical field. My brother insists that what is happening with programmers today is exactly what happened to the engineers of yesterday. A big boom, then a big burst, followed by offshoring, and then ended with salaries dropping and being worked raw. I'm no expert about what happened to the engineers but I can say so far he has been striking fear into my heart.

Despite all this, every once in a while something happens that makes me think, “Man! I love my job.” Today was one of those days. Several things happened each resulting in me repeating that phrase. I'll just give you a couple of examples.

Today was my last day in training. So we had a farewell event of sorts for our training class and an officer in the company came in with his son to show him what technology can do. That kind of wowed me and made me feel at ease about the companies direction with technology. If he was wanted his son to think more about technology as a career decision surely he was confident about its place within the organization. Next, after the event I went and I spoke to my manager to check in and see if he wanted me to prepare in any way for my scheduled Monday start. To begin with, as we were just chatting I couldn't help but think “what a cool guy” and his manager is amazing too. I keep finding myself saying that at this organization which is the real kicker. Normally I'm not quick to say things like that so when I do I mean it. But more on the technical part of my job, I found out Rob Howard is coming to meet with us soon. Stuff like that just gets me very excited about my job.

Also, I never realized how much I love to code until I went through this two month training program. Don't get me wrong, I love learning about technology as well but it doesn't quench my need to code. I'm dying to start my new position and start coding. I'm really hoping I can make an impact. I'll try my best.

So really I have no idea where I'm going with this all. I'll probably never know whether I made the right choice or not but days like today me feel a lot more comfortable with my decision. I just hope one day, when people think about all the ways computers have changed their life, they think a programmer wrote it and the respect for our field grows. For now, I just have to feel fulfilled without recognition from the general public.

The Practice of Programming

2004-04-08T01:50:00Z

So as I mentioned before, I was reading The Practice of Programming. I just finished the book today so I figured I'd give you guys some feedback of how I felt about the book.

Unfortunately, I felt the book was a waste of time. The Art of UNIX Programming I felt covered the topics in a much better and much more generic way that is far more applicable for today's programming environment. The Practice of Programming might be nice for a beginners book but for someone with any experience I think it is pretty much useless. My feeling is the gist of the book is well summarized by the Appendix. If you read that you don't need the book. Look up the concepts in the Appendix that confuse you but otherwise the book is out of date for the programmers of today.

I can see the book being a great resource maybe for hardcore low level C/C++ programmers but otherwise I'd skip it.

The newest book I'm reading is The Mythical Man Month. The book was quoted in both The Practice of Programming and The Art of UNIX Programming and some of the speakers during my training at my new position referenced it so I got really curious about it. While I'm still on page 13, I can tell you I only expect this book to wow me more and more as I go on. The book was originally written in 1975 or so but as you read it you feel like the issues the book speaks about are those that you see every day!!! I can't believe it. Maybe it's because I'm still starting the book but I can say so far it's well written. We'll see how I feel as I go on I'm sure :)...

Decided to start fresh...

2004-04-02T02:01:00Z

I stopped reading the blogs and mail groups I subscribe to several months ago but now I'm back in gear. I think the reason I stopped was because I felt overwhelmed. I missed a couple of days of reading and found myself several hundred messages behind. Not wanting to miss any exciting news, I tried reading more messages each day to catch up. But then another day went go by where I couldn't read the messages and I found myself several hundred more messages behind. Eventually, I gave up on reading blogs and mail groups all together and decided to just stick with books. I thought to myself "There is too much noise on those things mediums anyway and I can probably get more out of a well written book." To be honest, I still agree with that reasoning (I'll get back to this) but blogs and mail groups do have something special to offer that books can't. Blogs and mail groups give you perspective and connect you with your peers. The give you the benefit of thousands of eyes scouring different sources of knowledge then pointing you in the direction of the good resources. They give you an understand of what people are doing that's different than you and how people are going about doing the same things you do. Also, books are usually pretty far behind the times by the times when they come out compared to the information that's readily available to you online. All this is very valuable so I decided to do something Brad Wilson recommended I do several months ago when I complained about how far behind I was... I deleted everything and started fresh. I'm really glad I did too because now I've been pretty good about my reading of blogs and mail groups and I don't feel *as* overwhelmed by messages. Should have listen to Brad from the get go but oh well.

Getting back to the topic of "blog noise" however, I still think a well written and concise book can give you more bang for your time. The problem with blogs is that everyone and their mother has a blog!!! And people blog even with they have nothing to say just for the sake of keeping their blog active. I subscribe to a different view of how a blog should be run and I try to keep my blog up to those standards. I only blog when I have something decent enough to waste my time and other people's bandwidth (both in the literal and metaphorical sense). I hope I've been doing a good job of that. For a while, I had nothing that interesting to speak about so my blog went pretty quite. Now, however, because I changed jobs, I am getting many new perspectives on technology and I find myself wanting to share my thoughts about them more and more. It's interesting working in a place where there are far more Unix developers than Microsoft developers because my mind is being opened to new worlds in terms of my own thoughts of technology. That is something I love so there is a possibility, but don't hold me to this, that you'll see a lot more blogging out of me in the near future.

One last thing before I leave you, while I was deleting the old messages I decided to delete some blog subscriptions that I no longer was a fan of and add some new ones. One of the new one's I've added is Chris Pratley's blog as per Tim Marman's recommendation to me while we were getting a couple of drinks. Highly recommend it, high quality, low noise, just what I like :).

The Art of UNIX Programming

2004-04-02T01:17:00Z

I recently finished reading a book called The Art of UNIX Programming (here for purchase, here for online reading) by Eric Raymond. The book was provided to me by my employer so I thought I would be a good trainee and read it. I had seen references to it before in places like JoelOnSoftware.com so it also had some good endorsements. More motivation for reading the book came in the form of my own personal curiousity about the entire Linux revolution and what the big deal was.

My personal assessment of the book was it was pretty good, not great. I think there was much to learn from the book for any programmer because the book speaks about thing like writing orthogonal methods, why text files are a good way to store things, what format to store text files in, how to implement your own mini-language, etc. In those respects, I was pleased with the book. I gave me insight into things that I've never thought about and things about which I've always wonder why.

So the question is why don't I completely say the book is better than just pretty good? Well several reasons and here goes my list:

His writing style is terrible therefore it's annoying to read
Too much of his own belief system floating around in the book
He's a hypocrite

Let's start by addressing the first point. The author's writing style is all over the place. He changes his mannerism so often that it forces you to reread sentence all the time. I find that very annoying when I'm reading books. I don't mind it in articles and blogs but in books I believe it's necessary to find a writing style and stick with it for your readers' sake. I've found another person who completely agrees with me about the style in the book. Personally, I feel like the author is trying to prove himself to be a great writer and therefore attempts to demonstrate the different styles he's mastered. Please don't do this!!

Second problem is here I am trying to keep an open mind being primarily Windows developer by reading book called "The Art of UNIX Programming" meanwhile I have to endure the author's comments about how terrible Windows is here and there and so on. To be expected to some degree but come on this was extreme. Plus, on top of that, he's got his “Zen of programming” ideas spread throughout the book. Now granted he warns you about this but quite honestly it's still annoying. When I read a technical book I really want the point with the information I need to understand it and no fluff. I have tons and tons to read so don't clutter the pages with noise.

Both points one and two bring me to point number three. At the end of the book the author goes off about what problem exist in the Unix community and how to overcome them. One of the things he points out is the Unix developers see themselves as elite and that puts them at a disadvantage when trying to preach the benefits of the Unix platform. However, throughout the book the author himself is constantly saying how much better Unix programmers are etc etc. My feeling about his writing style exhibit, in my eyes, his elitist ways in that he's trying to prove he's smart but in turn he's frustrating his readers.

In any case, I don't regret reading the book and I did take away quite a bit so I'd recommend reading it if you have the time but I wouldn't call it a must read.

I'm now about half way done with The Practice of Programming so far the sentiment is I don't like it. Feels way to out of date so far...

I also ordered the GoF book and The Mythical Man Month yesterday.

Global Assembly Cache (aka GAC) is a Misnomer: How "global" is it?

2004-03-12T02:29:00Z

In every .NET programmer's life, he/she must come to terms with (at least one would hope) the Global Assembly Cache, aka the GAC. Simply put, the GAC is place for strongly named .NET DLLs to be placed so that they may be shared across multiple applications. This provides developers a way to place their DLL once on a machine and have multiple applications using it without the fear of name conflicts or problems with different versions of the DLL. In theory, the GAC should also help avoid Windows programmers every having to remember the days of “DLL Hell” although the term “Assembly Hell” has already been dubbed.

Problem is how global is the GAC anyway? Well there's a simple answer to that question; not global at all. The GAC is only appropriate for machine-wide distributions of DLLs which still makes it a problem for deployment on a enterprise-wide level. In some ways I think that the Global Assembly Cache was named as such because Microsoft is still not over their fixation with workstations being isolated. In today's work place environment however calling anything that only scopes a single workstation “global” is a major lack of understanding of what is going on around you. Maybe I'm paying too much attention to a name which maybe a marketing department made up but in truth this leads to the bigger issue of deployment.

How can one deploy an assembly network-wide? Bad new is it's not “built in”; good news is it's possible albeit jumping through some serious hoops. I think this is something that Microsoft should really consider further development in. Enterprise-wide deployment doesn't seem to be a forte of the Windows platform in general but I think it's in .NET's best interest to find a way around it. Most companies with a reasonable sized network would prefer single point of deployment rather than having to contend with deploying DLLs to each and every machine. .NET doesn't make it easy to deploy your shared DLLs to a shared network drive where they can truly be more global.

This also brings me to the point that the publisher policy that .NET enforces seem somewhat flawed. Who should have the final say in what version of a DLL which I wrote is used by an application, me or the application developer? While I can argue both sides of the coin, I think the real answer is it depends. If I'm using a third party DLL and I don't want to break my application, I should be able to use any version of the DLL I damn well please. If I want to take the risk of having using a buggy old version well that's my prerogative. Maybe I'm not using any feature effected by the bug fix and maybe I just don't have the time to get my code to work with the new version. But what about the corporate world? If one team releases a new version of Foo.DLL which other developers in the enterprise use, shouldn't they have the ability to say "you can't use my old DLL any longer"? A good example of the need for this is if the new Foo.DLL now enforces something such as a fix to a bug that runs the possibility of bringing the network down. This issue came to mind when I first read Applied Microsoft .NET Framework Programming by Jeffrey Richter (if you haven't read it yet stop reading my blog and go buy yourself a copy). At the time I thought “oh well it doesn't effect me” and moved on but I think I'm now seeing why I had to reread the publisher policy section to believe that the author of a DLL had no power in this matter.

These are arenas which I now consider to be a strong weakness in .NET and issues which are important for Microsoft to address. For .NET to ever be a real enterprise application contender deployment and policy issues cannot be thought of as secondary. Smart clients are not the solution for everything and neither are web apps.

Hardware-based Byte-code Interpreters: Are they all they are cracked up to be?

2004-03-11T04:30:00Z

Today I was made aware that Intel is amidst an initiative to create chips capable of interpreting Java byte-code in the same way a normal ship would interpret assembly. Now I really don't know much about chips but upon hearing this I thought to myself "Wow... that's really going to make Java's performance skyrocket past .NET's." I mentioned this to one of my trainer instructors (I'm still in training at work) who in turn told me he didn't believe this was such a big deal or a big gain for Java. I was shocked to hear that but I listened to his justification which makes sense but again I don't know much about chips. His basic concept was two-fold: 1) What's the performance gain over having the byte-code compiled to native code at install time? 2) Any performance gain that the JITter might introduce with runtime optimization would be missed. Another training instructor put his two cents in as well but he was more on the side that having hardware capable of bypassing the JITter would improve performance.

I was under the impression that having hardware with these capabilities would unquestionably make Java's speed a force to be reckoned with. I do however see the point that it really doesn't seem to buy you much over having byte-code compiled down to native code at install time.

Does anyone know if there are any initiatives of this kind for IL? Does the skeptical instructor have a valid point? General feedback anyone?

Off-Shoring comments from Jim Fawcette... worth a read it's short

2004-02-25T04:00:00Z

http://www.ftponline.com/weblogger/forum.aspx?ID=1&DATE=02/23/2004

Got the article through a great friend. Don't know if he wants his name here so he'll remain nameless. However, it is worth mentioning my friend's argument which is the strongest I've heard. His arguments are:

“What does that teach children? Go to college and come out with lots of debt and no job?!?!”
“Where does it stop? Accounts abroad can learn US tax laws and do your federal income taxes....” etc

ASP.NET DataGrid's AutoGenerateColumns doesn't add the BoundColumns to the Columns collection... WHAT!!

2004-02-13T23:13:00Z

While I ordinarily set AutoGenerateColumns = false on ASP.NET DataGrids, I finally found a pretty good use for them. I had a result set that was coming back with a variable number of columns all of which need to be display. I thought what a perfect use for the auto-generating columns but low and behold I discovered the documentation says:

Note Explicitly declared columns may be used in conjunction with auto-generated columns. When using both, explicitly declared columns will be rendered first, followed by the auto-generated columns. Auto-generated columns are not added to the Columns collection.

The hell kind of garbage is that?!?! Why aren't Auto-generated columns added to the Columns collection?!?!? Shouldn't they abide by the same rules other columns do? After all, aren't they just BoundColumn's? All I wanted to do was simply set the DataFormatString property on them. What an annoyance! Instead I had to check the number of columns in the IDataReader using the FieldCount property and then programmatically creating each column and set the format. But then what is the point of the AutoGenerateColumns property? Has anyone ever used it in a real world application? Oh well.....