Daniel Cazzulino's Blog

Note: this entry has moved.

Every since the CodeDom saw the day of light, I've been wondering when it'll be the time that VS throws away the ugly vb-like CodeModel and fully embrace the CodeDom for representing .NET code inside the IDE. Looks like at least one other company is doing what I believe is the right thing.

While I don't like the way they mix static members to access IDE features with IServiceProvider-based service retrieval (see the example that accesses BorlandIDE.ModuleServices.CurrentModule and then calls CurrentModule.GetService(typeof(IOTACodeDomProvider))), an obvious inconsistency, I love the idea of doing addins/VSIP packages that can play with/refactor code using CodeDom... Now I only have finish my radically different to that alternative to generating CodeDom, and coupled with the MsilCodeProvider you can kiss Reflection.Emit bye bye!!!

Note: this entry has moved.

For quite some time now, I've been trying to raise developer's (and MS) awareness of how an unbelievable bad idea it is to remove an amazing feature in ASP.NET v1.x and replace it with a bad, already tried and failed one in v2. Even given the overwhelming feedback (151 voters with an average of 4.7 over 5), Microsoft decided not to fix it, but they gave the wrong reasons for it.

The main reason was that "the existing model in VS 2003 was prone to bugs and code-loss and as such we've removed the functionality of a designer tray for components defined in InitializeComponent.". I reopened the bug and added:

"The Windows Forms designer keeps supporting the Component Tray just as it used to, so I think they somehow solved the "prone to bugs and code-loss" nature in it, right?

I can't see how given that it's working on WinForms, you can't take advantage of it. It's a very important feature to be able to develop components that are reusable across view technologies. This is the last time I'll reopen the bug. I just want an answer and if you're planing to put it back as it was (that is, 100% compatible with the WinForms support and codegen features) or if you're going to break the model anyway."

I'll keep bothering these guys until they give us component developers a satisfactory answer. If you agree, you should definitely make your voice loud and clear.

Note: this entry has moved.

If you're developing with Whidbey betas, and you happen to have setup projects, beware when you upgrade the project to newer versions. The .NET Framework launch condition doesn't get updated and points to the previous .NET version you were using (the one used to create the project, more properly), and causes the ugly error at setup time (no compile-time error is generated :S:S).

So make sure you specify the appropriate Version property for the launch condition. Repro steps and solution are described in the MSDN product feedback bug. Feel free to vote for it!

Note: this entry has moved.

If you're looking after an exciting and cutting-edge job, keep reading!

Note: this entry has moved.

In case you didn't noticed (I realized today :o)), the best browser ever was released as v1.0. I thought it was going to be mainly bug fixing since the last version I installed (0.9.3), until I noticed a red icon at the bottom-right of the screen while I was reading a webblog post, with the following tooltip: "Add Live Bookmark for this page's feed".

They add a bookmark that acts as a bookmark folder (with the title of the weblog by default), and update the entries in the folder directly from the RSS feed!!! Now THAT's what I call to evolve the browsers! Meantime, IE team is trying to come up with a release that tightens security... there's an abismal difference that would take much more investment from MS to catch-up again, although I doubt they want to... My guess is they'll bet everything to Avalon, and try to get rid of IE with it by offering richer user experience for sites Avalon-aware (not that I like the idea at all....)

Note: this entry has moved.

With the advent of XML, each and every piece of software is configurable with it, from Virtual PC to IIS to log4net to Shadowfax and all the Application Blocks released from PAG ... you name it.

If you think about it, however, it's quite easy to realize that what those XML files are actually, is nothing more than a text-based representation of the concepts in the particular domain of the tool/app. So, log4net has the concepts of Appenders, Filters, Object Formatters, and so on, while Shadowfax (as most SOA frameworks) has the concepts of Pipeline, Handler, Service Action, and so on. Therefore, XML is just a means to express the particular layout/behavior you want these tools/frameworks to have at run-time. It's not about XML, stupid! It's about the Domain Specific Language (DSL) expressed in (serialized into) those tags.

A very important step forward to make these languages first-class citizens in the developer's minds and programming experience has been made by Microsoft with the release of the tools necessary to build your own DSL editors/designers. With these specialized editors, the need for a generic XML editor (when used to edit configuration) will dissapear. How many people do you think is using generic XML editors to create instance documents that are used as input for an application (other than just for testing purposes)? My bet: NONE (InfoPath doesn't count, as it's not an XML editor but a forms tool, which just happens to use XML as the underlying store). Generic XML editors, instead, have been primarily used to configure the myriad of tools/blocks/frameworks that you need to use to get your application up and running fast and with minimal effort (other than the one needed to configure it in the first place, an increasingly complex one indeed!). It's time to move forward.

That's why I think any effort put in creating generic/customizable XML editors is futile. I believe the future is a multitude of specialized designers for the different aspects of an application (their DSLs). I hope sooner than later we'll see an editor like this for tools like UIP, and we'll have nothing to envy the Eclipse guys...