Oh, while we're at it... I've been experimenting with Subversion support for Visual Studio 2005. Tried these:
AnkhSVN - the "official" plugin, and probably the most advanced of the bunch. Open source, too. Works nicely with two caveats: if you create a new file, it won't allow you to delete it or rename it until you've committed it to SVN. Which is either stupid or I'm unaware of SVN rules (and I am). The second one is that if you rename a file, it will get irretrievably lost, and you'll have to juggle around with SVN just to get the previous version back. I understand that SVN is trying to make the best of its capability of tracking files across renames, and that the error is due to a bug in Visual Studio, but I'd be satisfied to lose the rename capability in order not to lose any files. Also, you should be aware that this is a beta version: you have to use the beta in order to get the plugin working in VS 2005. http://ankhsvn.tigris.org/.
Update (2006-11-22): the cleaning up of bugs in AnkhSVN has gotten into the RC4 phase. It works considerably better, but still has bugs. I'll be keeping an eye on this one for sure.
Visual SVN - this is a proxy between Visual Studio 2005 and TortoiseSVN, and costs $19. It's not very integrated in the Visual Studio. While AnkhSvn shows status icons on all of the files in solution view, VisualSVN does no such thing. And once you click on Commit or Update or whatever you want, it just opens TortoiseSVN with the requested command. So you still have to work with folders, not projects, and add new project files manually to the repository (AnkhSvn does this from the IDE, although I'm not sure whether it behaved strangely or I don't know how to work with SVN). http://www.visualsvn.com/
PushOK's SVN SCC proxy - this one is a bridge between the Sourcesafe API and SVN, so it looks to Visual Studio just like another SourceSafe. I couldn't get it to work, though: it said there has to be a windows service for making the files under source control read-only (I suppose Visual Studio expects that) and that the service should reindex my files in order for the plugin to work. I let the service do its magic, but nothing happened. The other PushOK's plugin, CVS for VS 2003 worked nicely for me, though, so I guess this is not a general quality issue (come to think of it, I haven't checked if the plugin was VS 2005 compatible at all). Oh yeah, this one is not free but almost: it's around $20. http://www.pushok.com/soft_svn.php
Saturday, August 05, 2006
Visual Studio .Net: long-forgotten features
It's an absolute beauty how Microsoft can pleasantly surprise you when you find out that a feature you'd given up long ago has actually started working in a new version. We on the Microsoft platform are humble persons. And we learned to be like that the hard way.
For instance, who other than Microsoft can give you a mail client that doesn't allow you to send or receive any attachment you like? So gradually you give up on even trying to send EXE's, when one day you find out there's a configuration parameter that lets you turn this "feature" off. By then, it's too late, you've already set up your FTP server for sharing files, or whatever ;).
Of course, I'm exaggerating a bit, but it's much worse in Visual Studio world. For example, when you walk through the call stack, does the debugger in VS 2005 display the correct line of code instead of displaying the next one? I haven't noticed: stopped paying attention long ago. Don'trust that mangy debugger no more since the time it used to enter both the if and the else branch (it actually did, in VS 2002).
Hey, there are even new features in this version: press F1 in Visual Studio 2005 and you'll be doomed to biting your nails down to the bone while you watch MSDN explorer reindexing the gigabytes of its documentation for the umpteenth time. I'm stumped as to how they managed to screw up a simple document viewer, at least this should be easy to get right? Nevermind, I'm now using my Firefox for .Net class reference: Google is much better at finding stuff on the MSDN site than MSDN is. I don't know if the MSDN site also reindexes it's contents on every access (it probably does, but they have helluva fast machines there in Redmond, they're high-tech guys). Oh, while we're at it, the MSDN search is one of the dumbest search engines in the universe. I hear they're working on a new super intelligent version. If it will be super intelligent compared to the previous version, then don't bother guys. I'm used to living without it, anyway.
What else is new in Visual Studio 2005. Well... The tool windows sometimes refuse to auto-hide. But that's not new, we had that in VS 2002 beta, only it seemed to have been fixed. How about user-defined controls still not showing up in the toolbox? I don't use the toolbox anymore, just go to the InitializeComponent method and add two lines: new MyControl() and this.Controls.Add(myControl). I don't have time to "Customize toolbox" and wait while VS scans all dll's on my hard drive and do it again when I recompile. Does VS lock the DLL's when you Get Latest from SourceSafe? Glad to say I don't know. I'm using Subversion now. It even has a Visual Studio plug-in which is somewhat buggy (alergic to file renames) but I don't really need it because there's always TortoiseSVN which is great (I'm probably not being fair to Ankh plug-in here, to get something to work right with the Visual Studio add-in API, you need extraterrestrial or para-abnormal capabilities).
So, where's the light at the end of the tunnel? We had Visual Studio 2003 service pack 1 scheduled for june and coming out in august (hopefully), and we had Visual Studio 2005 SP1 scheduled for august (you already guess where this is heading), then scheduled for sometime in the late summer, then not scheduled at all. There's a page at MSDN that says "This service pack is currently targeted for final release in Q3 of 2006. A more detailed schedule of external interim milestones (e.g. customer beta period) will be posted when it has been finalized." Which means there will soon be a beta. Or maybe not. Who cares, by then we'll get used to working without Visual Studio ;).
For instance, who other than Microsoft can give you a mail client that doesn't allow you to send or receive any attachment you like? So gradually you give up on even trying to send EXE's, when one day you find out there's a configuration parameter that lets you turn this "feature" off. By then, it's too late, you've already set up your FTP server for sharing files, or whatever ;).
Of course, I'm exaggerating a bit, but it's much worse in Visual Studio world. For example, when you walk through the call stack, does the debugger in VS 2005 display the correct line of code instead of displaying the next one? I haven't noticed: stopped paying attention long ago. Don'trust that mangy debugger no more since the time it used to enter both the if and the else branch (it actually did, in VS 2002).
Hey, there are even new features in this version: press F1 in Visual Studio 2005 and you'll be doomed to biting your nails down to the bone while you watch MSDN explorer reindexing the gigabytes of its documentation for the umpteenth time. I'm stumped as to how they managed to screw up a simple document viewer, at least this should be easy to get right? Nevermind, I'm now using my Firefox for .Net class reference: Google is much better at finding stuff on the MSDN site than MSDN is. I don't know if the MSDN site also reindexes it's contents on every access (it probably does, but they have helluva fast machines there in Redmond, they're high-tech guys). Oh, while we're at it, the MSDN search is one of the dumbest search engines in the universe. I hear they're working on a new super intelligent version. If it will be super intelligent compared to the previous version, then don't bother guys. I'm used to living without it, anyway.
What else is new in Visual Studio 2005. Well... The tool windows sometimes refuse to auto-hide. But that's not new, we had that in VS 2002 beta, only it seemed to have been fixed. How about user-defined controls still not showing up in the toolbox? I don't use the toolbox anymore, just go to the InitializeComponent method and add two lines: new MyControl() and this.Controls.Add(myControl). I don't have time to "Customize toolbox" and wait while VS scans all dll's on my hard drive and do it again when I recompile. Does VS lock the DLL's when you Get Latest from SourceSafe? Glad to say I don't know. I'm using Subversion now. It even has a Visual Studio plug-in which is somewhat buggy (alergic to file renames) but I don't really need it because there's always TortoiseSVN which is great (I'm probably not being fair to Ankh plug-in here, to get something to work right with the Visual Studio add-in API, you need extraterrestrial or para-abnormal capabilities).
So, where's the light at the end of the tunnel? We had Visual Studio 2003 service pack 1 scheduled for june and coming out in august (hopefully), and we had Visual Studio 2005 SP1 scheduled for august (you already guess where this is heading), then scheduled for sometime in the late summer, then not scheduled at all. There's a page at MSDN that says "This service pack is currently targeted for final release in Q3 of 2006. A more detailed schedule of external interim milestones (e.g. customer beta period) will be posted when it has been finalized." Which means there will soon be a beta. Or maybe not. Who cares, by then we'll get used to working without Visual Studio ;).
Friday, August 04, 2006
Did you also wish for an ObjectBuilder or a Spring or...?
I find it strange how some parts of the infrastructural code I've written in the last couple of years resemble what I see in the Composite UI Application Block. And while I'm looking at alternatives to CAB, I find that many application frameworks have sprouted in the .Net world since the last time I checked (which was around the mentioned couple of years ago). And they all offer similar solutions to the same problems.
One illustration - I had a sort of "deja vu" feeling looking at SmartPartInfo structure, because this is one of the things I felt I successfully resolved while working on my company's application framework: a class that carries enough information to allow the infrastructure to create a control and display it in a standard way: in its own window or as a part of another window. Be honest, how many times have you wished you could display a form within a form? With CAB the programmer has the option to say "I don't care, just show this control, you know, in a standard way".
What depresses me somewhat is the fact that all this time people have been trying to create the same things in a same way. And the reason for this is that the same infrastructural deficiencies were troubling all of them, and that the solutions were obvious enough. I mean, for chrissakes, why do I have to instantiate a container form for to show a control, why can't I just display the control directly? Why can't the infrastructure do this for me? Why can't it track forms and prevent me from opening duplicates? I can easily provide it with an ID to do this. Etcetera. And then you end up with a bunch of forms which all have a single control inside, but if you want to access the control from the outside you either have to make it public (which is Bad Practice) or write accessor methods on the form (which is TEDIOUS).
Depending on your ambition, developing an answer to these questions can be a huge effort (at its simplest form, it's not at all easy), so you're forced to either stamp out mind-bogglingly dumb code or roll up their sleeves and build a solution to it. Oh, yes, but it's not that simple: if you want to instantiate "some control" (e.g. depending on parameters or context), you can't do it in an officially endorsed way. One could use reflection to make things easier - but dey say not to use reflection 'cause it slow and not type-safe. So we obey: but lo and behold, CAB is built on reflection! And it's the only logical solution, if you ask me: you really need to have a way to replace certain types with certain other types (which is effectively overriding whole classes, is it not?) You really need to have automatic coupling of events with event handlers if your code is going to be modular. You really need command objects that can be fired from whatever UI component can fire them. Etc. The problem here is not reflection, the problem is C#, it's stuck trying to be both type-safe and dynamic, and all that using C syntax rules.
I feel we're still using prehistoric mechanisms for validating our code. We have ultra-powerful visual tools that can figure out by themselves what code to generate where, what references we need to compile the code etc, and they tell us of errors in code while we're typing it. Yet, none of these advanced techniques exist in the compiler. I mean, why isn't the compiler aware of the attributes the ObjectBuilder is aware of? Why couldn't the compiler check if I'm using the CAB attributes in a proper way? Why couldn't it emit dependency injection code at compile time, why does the infrastructure need to employ reflection at runtime and slow everything down? And - well, why the syntax with attributes in the first place, why not a real language feature? Attributes are not neraly structured enough to provide really complex metadata we require today. Although the dependency injection attributes look somewhat cool, using strings to identify event topics is really ugly. That's probably because you can't provide anything other than simple data types as attribute parameters.
A case in point:
Now, this is quite cool, having your property automatically bound to a value in the shared state... But it's also contrary to all type safety principles Microsoft boasts with when talking about C#: who is to check if the state really contains a "customers" item of type List? (And what if I wrote "cusomers" here, I'd get a null value and wonder what happened). Remember, this is a highly modular application, and the modules get loaded and bound only when it runs. So it's a unit testing nightmare. Even the tiniest bit of type safety would help greatly.
We either need a programming language that will support CAB-like features from the ground up, or a development environment that will be CAB-aware so we can't make mistakes like mistyping event topics. From what I hear, some such languages exist and are quite popular, but I haven't heard of an IDE (although I didn't look much). Now I'm not being unrealistic here: just like in bridge building (a profession that is very popular lately in the software development comunities ;)), a comprehensive infrastructure makes your job easier, but you have to know how the infrastructure works. We shouldn't expect a magic wand IDE or compiler, but some consistency would make things much more predictable.
I suppose the IDE will be what Microsoft pushes for. Just like the Enterprise Library 1.0 became part of .Net 2.0, the new application blocks will probably be a standard part of a future .Net framework, and one day (hopefully) there will be design-support for them. For example, it would be nice if the form designer could detect ObjectBuilder-aware classes, and generate ObjectBuilder calls to instantiate them. Also, the design-time environment should be coupled with the dependency injection framework so that components could be properly instantiated in the designer.
What I am sure, though, is that Microsoft will never manage to cover all the possibilities for visual tool usages. Look at what they're doing now with windows data grids: they have three instead of one, one of the three is buggy and one obsolete, and in WPF there won't even be a data grid (which is probably good because it would have been the fourth one). Compare this to third-party data grids which look like space shuttles, and you'll see what I'm driving at (ok, data grids are not typical average components, but they're at the extremely successful end of the same category).
So Visual Studio Orcas could be a third-party component developer heaven (that is, if you abstract the terribly buggy Add-in API which will probably stay the same). There we'll have a standard way to represent a database model using LINQ components (which for ex. means that the IDE could automatically generate code for filling all those godawful stupid combo boxes), an ultra-advanced vector and 3D graphics interface (which means an easier way for develping advanced visualisation and an unlimited room for third party controls because WPF will have next to none), and CAB (along with existing data-binding and similar mechanisms) will provide a base framework for integrating various components. And then we'll start waiting for whatsitcalled (Hawaii?) where they'll finally have the tools finished. Are you prepared to wait for 2010? I've already made my own modelling component, and in the next couple of days I'll be using the detected foreign keys to automatically fill the combo box items.
Nevertheless, it will be interesting to see where it all ends. My guess is that all of this is only a prototype for a future environment which will be fundamentally different. We're currently just trying out to see how it all works. Once we have the mechanisms and requirements figured out, we'll see what is the best way to implement them. And at that point we'll be able to take for granted much more than we can now, from a vector-based interface to data-modeling support built into the framework. But will Microsoft be prepared to write Visual Studio from the ground up? I don't think so. So, third party developers, start making your own ultra-futuristic IDEs. But please: this time, don't everyone write the same code ;).
One illustration - I had a sort of "deja vu" feeling looking at SmartPartInfo structure, because this is one of the things I felt I successfully resolved while working on my company's application framework: a class that carries enough information to allow the infrastructure to create a control and display it in a standard way: in its own window or as a part of another window. Be honest, how many times have you wished you could display a form within a form? With CAB the programmer has the option to say "I don't care, just show this control, you know, in a standard way".
What depresses me somewhat is the fact that all this time people have been trying to create the same things in a same way. And the reason for this is that the same infrastructural deficiencies were troubling all of them, and that the solutions were obvious enough. I mean, for chrissakes, why do I have to instantiate a container form for to show a control, why can't I just display the control directly? Why can't the infrastructure do this for me? Why can't it track forms and prevent me from opening duplicates? I can easily provide it with an ID to do this. Etcetera. And then you end up with a bunch of forms which all have a single control inside, but if you want to access the control from the outside you either have to make it public (which is Bad Practice) or write accessor methods on the form (which is TEDIOUS).
Depending on your ambition, developing an answer to these questions can be a huge effort (at its simplest form, it's not at all easy), so you're forced to either stamp out mind-bogglingly dumb code or roll up their sleeves and build a solution to it. Oh, yes, but it's not that simple: if you want to instantiate "some control" (e.g. depending on parameters or context), you can't do it in an officially endorsed way. One could use reflection to make things easier - but dey say not to use reflection 'cause it slow and not type-safe. So we obey: but lo and behold, CAB is built on reflection! And it's the only logical solution, if you ask me: you really need to have a way to replace certain types with certain other types (which is effectively overriding whole classes, is it not?) You really need to have automatic coupling of events with event handlers if your code is going to be modular. You really need command objects that can be fired from whatever UI component can fire them. Etc. The problem here is not reflection, the problem is C#, it's stuck trying to be both type-safe and dynamic, and all that using C syntax rules.
I feel we're still using prehistoric mechanisms for validating our code. We have ultra-powerful visual tools that can figure out by themselves what code to generate where, what references we need to compile the code etc, and they tell us of errors in code while we're typing it. Yet, none of these advanced techniques exist in the compiler. I mean, why isn't the compiler aware of the attributes the ObjectBuilder is aware of? Why couldn't the compiler check if I'm using the CAB attributes in a proper way? Why couldn't it emit dependency injection code at compile time, why does the infrastructure need to employ reflection at runtime and slow everything down? And - well, why the syntax with attributes in the first place, why not a real language feature? Attributes are not neraly structured enough to provide really complex metadata we require today. Although the dependency injection attributes look somewhat cool, using strings to identify event topics is really ugly. That's probably because you can't provide anything other than simple data types as attribute parameters.
A case in point:
[State("customers")]
public List Customers
{
set { customers = value; }
} Now, this is quite cool, having your property automatically bound to a value in the shared state... But it's also contrary to all type safety principles Microsoft boasts with when talking about C#: who is to check if the state really contains a "customers" item of type List
We either need a programming language that will support CAB-like features from the ground up, or a development environment that will be CAB-aware so we can't make mistakes like mistyping event topics. From what I hear, some such languages exist and are quite popular, but I haven't heard of an IDE (although I didn't look much). Now I'm not being unrealistic here: just like in bridge building (a profession that is very popular lately in the software development comunities ;)), a comprehensive infrastructure makes your job easier, but you have to know how the infrastructure works. We shouldn't expect a magic wand IDE or compiler, but some consistency would make things much more predictable.
I suppose the IDE will be what Microsoft pushes for. Just like the Enterprise Library 1.0 became part of .Net 2.0, the new application blocks will probably be a standard part of a future .Net framework, and one day (hopefully) there will be design-support for them. For example, it would be nice if the form designer could detect ObjectBuilder-aware classes, and generate ObjectBuilder calls to instantiate them. Also, the design-time environment should be coupled with the dependency injection framework so that components could be properly instantiated in the designer.
What I am sure, though, is that Microsoft will never manage to cover all the possibilities for visual tool usages. Look at what they're doing now with windows data grids: they have three instead of one, one of the three is buggy and one obsolete, and in WPF there won't even be a data grid (which is probably good because it would have been the fourth one). Compare this to third-party data grids which look like space shuttles, and you'll see what I'm driving at (ok, data grids are not typical average components, but they're at the extremely successful end of the same category).
So Visual Studio Orcas could be a third-party component developer heaven (that is, if you abstract the terribly buggy Add-in API which will probably stay the same). There we'll have a standard way to represent a database model using LINQ components (which for ex. means that the IDE could automatically generate code for filling all those godawful stupid combo boxes), an ultra-advanced vector and 3D graphics interface (which means an easier way for develping advanced visualisation and an unlimited room for third party controls because WPF will have next to none), and CAB (along with existing data-binding and similar mechanisms) will provide a base framework for integrating various components. And then we'll start waiting for whatsitcalled (Hawaii?) where they'll finally have the tools finished. Are you prepared to wait for 2010? I've already made my own modelling component, and in the next couple of days I'll be using the detected foreign keys to automatically fill the combo box items.
Nevertheless, it will be interesting to see where it all ends. My guess is that all of this is only a prototype for a future environment which will be fundamentally different. We're currently just trying out to see how it all works. Once we have the mechanisms and requirements figured out, we'll see what is the best way to implement them. And at that point we'll be able to take for granted much more than we can now, from a vector-based interface to data-modeling support built into the framework. But will Microsoft be prepared to write Visual Studio from the ground up? I don't think so. So, third party developers, start making your own ultra-futuristic IDEs. But please: this time, don't everyone write the same code ;).
Tuesday, August 01, 2006
How to get the type of the component being designed in Visual Studio .Net
What is the proper way to get, from within your designer component, the type of the component being designed? (Hm, if that one is the designer, the other one is surely the designee?)
1. this.Component.GetType() doesn't work because Visual Studio sneakily instantiates not the class you design but the base class (why does it do this? Beats me).
2. Wow, there's a RootComponentClassName in IDesignerHost, beautiful! Or maybe not.
The guys at msdn say that RootComponentClassName "Gets the fully qualified name of the class being designed". Oh, wait... No, they say it's property value is "The fully qualified name of the base component class". On the same page. So which one is it? When you access the property, you discover that the name isn't qualified at all. So you get the unqualified name of the class being designed (not the base one). Super, but what good is an unqualified class name?
3. Ok, so it's an undocumented/badly documented feature. This guy has it figured out:
http://blogs.vbcity.com/hotdog/archive/2006/03/31/5943.aspx
The RootComponentClassName is not initialized until the designer host has completed loading (which means, when IDesignerHost.LoadComplete is triggered). So, that's it: handle LoadComplete, and from LoadComplete get the RootComponentClassName.
1. this.Component.GetType() doesn't work because Visual Studio sneakily instantiates not the class you design but the base class (why does it do this? Beats me).
2. Wow, there's a RootComponentClassName in IDesignerHost, beautiful! Or maybe not.
The guys at msdn say that RootComponentClassName "Gets the fully qualified name of the class being designed". Oh, wait... No, they say it's property value is "The fully qualified name of the base component class". On the same page. So which one is it? When you access the property, you discover that the name isn't qualified at all. So you get the unqualified name of the class being designed (not the base one). Super, but what good is an unqualified class name?
3. Ok, so it's an undocumented/badly documented feature. This guy has it figured out:
http://blogs.vbcity.com/hotdog/archive/2006/03/31/5943.aspx
The RootComponentClassName is not initialized until the designer host has completed loading (which means, when IDesignerHost.LoadComplete is triggered). So, that's it: handle LoadComplete, and from LoadComplete get the RootComponentClassName.
Subscribe to:
Posts (Atom)
