November 2007 - Posts
I've been giving this some thought.
As previously mentioned, it's not practical to modify framework code because it's awkward to use with the VSIDE and it's essentially undeployable because the security system is specifically designed to prevent deployment of unsigned third party modifications to signed assemblies.
Also previously mentioned is the probability that it can be done on your local system, where you can run with full authority. Presumably people at Microsoft even know how to do this, otherwise it would be a devil of a job debugging new versions of the framework.
Anyhow, you still wouldn't be able to distribute hacked versions of framework assemblies, and quite right too. So, supposing I've figured out a bugfix, how do I contribute this change for consideration?
Microsoft would be very silly to ignore this opportunity to get the many-eyeballs effect without having to GPL anything.
I think the best answer is to put a copy of the the source in a source control system like Subversion and have interested parties sign up for respository rights. Subversion's branching cost for both time and storage is O(1), so when my repository rights application is processed what actually happens is I get a login and a branch to play with. This means contributors can commit changes without affecting one another. The fact that individual contributors will not generate large quantities of modified code conbined with the delta storage approach of Subversion means that storage requirements will be quite moderate.
Why Subversion rather than the Team System version control software? Not everyone has the TS software. It's not free. Microsoft could choose to hand it out to parties who sign up but this seems unlikely.
I don't know whether to say "congratulations on a brilliant move forward" or "about time, took you long enough". Microsoft has pinched every other bright idea out of Java and done it better. Hopefully that grand tradition will not falter here.
To the nay-sayers I reply that the source is revealed, therefore it is open-source on account of not being closed-source.
I'd like to see Microsoft go all the way and set up a mechanism for direct feedback.
Irrespective of the rantings of the open-source faithful, no-one is going to fiddle with code that works. But here and there, there are bugs. Not many, which is a tribute to the framework builders, but every now and then you find one.
The big problem is that you really can't change framework code. Extensions are fine, they don't change signed code. CodeProject is already going great guns. But you can't change framework code because from a runtime perspective it lives in signed assemblies in the GAC. I suppose you could put updated framework binaries in the application folder and get them used that way, but how would you persuade the Visual Studio IDE to use your own version instead of the one in the GAC? Presumably it can be done - the IDE team surely has some procedure that allows them to test combinations of framework and IDE. Perhaps someone from Microsoft can cast some light on this.
From my own point of view the value of the source-code is twofold. First, it's one big how-to. Second, it can be very instructive to see what the framework does with the parameters you pass it. When the documentation is unclear on the meaning of parameters this will be a godsend.
Custom datasets are evil. No custom datasets in my code thank you very much.
The alleged benefits of these abominations are
Point-and-click UI databinding is ok I suppose, but if you're going to remember what and where to point and click, you may as well remember how to code them up yourself - which gives you a variety of other options. For that matter you can do point and click UI databind with generic (standard) datasets if you use the IDE to create them at design time.
The really appalling thing about custom datasets is the heavy coupling they produce between code and database. The moment you use the horrible things, you get scads of nearly-unreadable machine-generated code that is incredibly sensitive to changes in corresponding database schema. Certainly there is IDE support for regenerating it, but firstly it can be difficult to persuade the IDE to notice the schema changes, and secondly when two people do this things can get very messy in a concurrent versioning system because it looks like they've both made elaborate conflicting changes.
Custom datasets may present dataset columns as typed properties but you still have to do type conversion to marshal values to and from textual presentation in editors, so explicit typing isn't the boon you might think. Typed values such as the Checked property of a checkbox can be handled directly, but these are by far the lesser portion, and require only casting. Custom datasets increase compile times and pollute the toolbox. If you commit to using them you end up with quite large numbers of the horrible things. This is bad because the moment you open a form designer the whole IDE locks up while the toolbox flickers madly.
Strong typing does give you static type-checking. To this I blow a big raspberry because trivial regression testing catches this stuff immediately, and it is very useful to be able to ignore it yet still compile and run while you resolve other issues.
Computed columns are a convenience at best. There are no circumstances under which they are necessary. If you want one because you are binding a grid and you want to display a derived value then be advised that you can do this quite conveniently in the IDE binding editor using a binding source. You could implement a computed column using SQL but this approach can severely hamper query optimisation. A binding source will recompute the value of a computed-column every time it is requested, and for every row from which the column value is requested, but only those rows.
If you're looking for somewhere to put custom logic pertaining specifically to the data, try the database. If you simply cannot live without some sort of post-processing then maybe it's time to write some stored procedures - possibly in managed code - or even start designing your data warehousing system.
The long and the short of it is that custom datasets are high maintenance with limited benefit. Best to ignore them completely.
Another election looms. Finally one of the parties has pledged to take significant and unilateral action to set up large scale desalination facilities nationally. Unfortunately, it was the Labor party. The Labor party is endlessly keen to demonstrate its utter incomprehension of basic economics. For me it isn't about ideology or social politics, they're all detestable. It doesn't matter who I vote for, a political party will gain power.
Labor is a pack of incompetent ninnies who think you can fix a fiscal shortfall by printing money. Most of them (I kid you not) have direct trade union afiliations that constitute gross conflicts of interest.
The Libs seem to understand economics (except that they don't seem to understand that emergent systems change). They have ties to business. These are conflicts of interest just as much as union afiliation but at least we can trust them to manage the economy well for the same reason you can trust a farmer to take good care of his stock.
So it's a choice between bumbling thieves and competent thieves, and the bumbling thieves have promised to do something that really really needs doing. What a choice!