this == null

This is an actual screenshot... I don't know how (seemingly it does have to do with some lightweight generated code) but I managed to get an NullReferenceException because this was equal to null... Go figure.

CompositeUI Application Block: TypeLoadException GetExportedTypes in ModuleLoaderService

(Don't mind the title, I put all the necessary keywords to help others having the same problem to find this post :)).

Have you ever tried loading un-loadable assemblies with CAB? Like, the ones that have unresolvable references or something similar. You won't get a normal assembly binder (or whatever it's called) error... No, the exception you will get will be a TypeLoadException that is thrown by a call to GetExportedTypes() in the ModuleLoaderService. With a cryptic message saying that some type (probably the first one in the assembly) couldn't be loaded. if this happens, go back and check if your assemblies have valid references.

How to terminate a work item when its smart part closes?

I've been google-ing around for a solution to this, but had no luck. It seems that either the designers of the Composite UI Application Block (CAB) have entirely overlooked a pretty common situation or I am missing something obvious... The problem is quite simple: you have a WorkItem with a single view. When the WorkItem is run, it displays its view control (a smart part) in an MDI workspace - which means the control is automatically put inside an mdi child window. So, when the window is closed, you'd naturally want the WorkItem terminated.

Well, CAB doesn't do this for you, and rightly so because the WorkItem is not a part of the window even though its SmartPart is. You have to do this yourself. The most logical solution could be to handle the SmartPartClosed event on the MDI workspace and close your WorkItem at the moment the smart part is closed... Yeah, but there is no SmartPartClosed event, only SmartPartClosing! You could add it yourself, as John Luif did, or you could look for a workaround...

Since I don't like changing code published by others, I tried the latter option. If I try to terminate my work item from the SmartPartClosing event, the WindowWorkspace throws an exception because terminating the WorkItem kills everything inside it, probably including the smart part and maybe even the workspace itself. So when the SmartPartClosing event handler returns to the workspace, the workspace is not in its previous state anymore... (Note that I'm assuming that this behavior is not a bug - which it could be). But wait, there's a workaround for this one also: the SmartPartClosing event is cancelable. So, if I cancel the smart part close and terminate the WorkItem instead... Like this:

void containerWorkspace_SmartPartClosing(object sender, WorkspaceCancelEventArgs e)
{
 if(e.SmartPart == mySmartPart)
 {
  // cancel the closing operation and terminate the workitem instead
  e.Cancel = true;
  this.Terminate();
 }
}

Nice one: that is, ugly but working. Or is it? When the user tries to close the main MDI form, this triggers closing of all child forms, but this gets canceled at the first window. What now?

Well... I did this -

 protected override void OnClosing(CancelEventArgs e)
 {
  //base.OnClosing(e);
  WorkItem.Terminate();
 }

- in the MDI form. Even uglier, but it seems to work. Now, if I could figure out the reason why CAB works this way (there may well be one) I'd know if this solution is right.

CAB error: A circular control reference has been made. A control cannot be owned by or parented to itself.

I've stumbled upon an interesting issue that nicely illustrates how the Composite UI Application Block requires you to change the way you think. It would seem a logical procedure to create your SmartPart control first (call WorkItem.Items.AddNew to do it) then add it to a workspace. But what if your control contains an embedded workspace by the same name? You'll get a circular reference exception ("A circular control reference has been made. A control cannot be owned by or parented to itself.") This is because CAB completely ignores the control hierarchy and has its own system of tracking components. When you add a SmartPart control to the WorkItem, all of its child SmartParts also get registered with the WorkItem, regardless of the fact that your SmartPart hasn't been added to the container control. So when you look for a workspace in the WorkItem, CAB will also detect workspaces inside the SmartPart.

Yeah, but what happens if you use the dependency injection instead of the AddNew method to create your SmartPart? You'd probably be stuck...

Metadata and misunderstandings

A great number of software development problems arises from the fact that the whole philosophy of current development languages and environments is about programs doing something, but without any effort to explain what they're doing. I will give you an example: if you disable a button in a windows form, do you ever give the user a way to find out why the button is disabled? If you perform some database operation in one or another way, will anybody (except a developer armed with a debugger) know what - and more importantly, why - was done?

The answer to my questions would probably be: yeah, so how would you expect me to do it? Log everything? Show message boxes (not exactly useful for disabled buttons) or tooltips? There isn't a standard way to do this and the user would never expect nor find the information. We lack a user- as well as developer- friendly mehanism. If I could write a piece of code like -

btnDelete.Enabled = false -> explain "You don't have enough permission to delete this record";

... the user could possibly be able to see somewhere the list of available explanations (marked with, say, glyphs visible under certain conditions) and review what interests him at that moment. Of course, there's another problem with what I've written here - the framework should somehow be intelligent enough to understand that the explanation should be attached to btnDelete. Or we would have to tell it - in which case we get the following code:

btnDelete.Enabled = false;
btnDelete.StateExplanation = "You don't have permission for this.";

This explanation mechanism is now nothing more than a more intelligent and somewhat differently standardized tooltip. Of course, if the button was completely hidden, we'd display its state somewhere else (for example after a click on some kind of a "what's going on" button).

How about explaining to user the performed operation? We'd need to have a standardized way of buffering explanations and then possibly displaying them as a glyph on a message box that says "The operation was successfully performed. Click here to see what it did and why".

So, in this case it's a relatively simple matter and all that is lacking is a standardized infrastructure. But it would make the application's logic and inner workings much clearer to the user and rapidly drive the learning curve down.

Yeah, but this is not enough, is it? The explanation data cannot be examined by another program, for example. There's no metadata in string explanations. We cannot determine programmatically what the application has done or what it's currently doing, or why has it done something. Why would we need this, you ask? Well, if an application opens a confirmation message box while you are shutting down Microsoft Windows, Windows will say that the application is not responding and ask you if you want to kill it. If the windows could find out what the application is currently doing, it would (or at least could) behave much more intelligently. The "I'm busy, come back later" or "I'm waiting for the user" metadata explanations could be a standard way for the applications to communicate and could probably be built at a higher level into various interprocess communication mechanisms or remote procedure calls. So you wouldn't have to have an "out errorMessage" parameter in each one of your web service methods.

Ok, so does this mean we'd have to write metadata to explain every single method the application can perform? The answer is of course - god forbid, because our development speed would suffer greatly. Not to mention the security issues. But we could start somewhere, try attaching metadata to a minimal set of standard procedures and go from there. Today we are witnessing the convergence of metadata and procedural programming: there are more and more tools that can generate an application from a rich model or execute code based on metadata (.Net attributes), and the programming languages have increasingly richer metadata content. Soon enough the applications will start talking to each other, and at that point C# could be replaced (or more probably extended) with some kind of a metadata language. Look at dependency injection frameworks: the components are already learning how to talk to each other :).

How to not waste your time on stupid mistakes?

Ayende made an interesting light-hearted post concerning developers that spend hours chasing a bug in an application only to find out they forgot to do some utterly trivial thing. Well, stuff like that is maddening. The solutions to these kind of mistakes are utterly nonsensically simple yet we don't know the proper way to prevent them but instead lose time debugging.

The contradiction we have today is that we get these all-encompassing frameworks that do a lot of things by themselves, but are so big we almost always miss something when using them. And instead of losing time writing intelligent stuff we get the stuff ready-made but lose time on trivial mistakes :). But how to solve this time-wasting issue? Microsoft's answer is - guidance. It sounds promising as I believe it would generally be helpful to generate more code (at least skeleton code), but that's not so easy. Also, we should be careful when designing APIs, make them as obvious as possible (even if we have to make dozens of method overloads). And validate and assert everything we can... But that's still not enough. And the stuff we are talking about is ridiculously simple to describe: if you use a TransactionScope you should commit it. How to protect ourselves from this simple mistake? Use FxCop to validate code? Use a higher-level language? Stop coding alltogether and use an AI to generate applications?

Silverlight picks on Flash

... as Microsoft attacks Adobe's piece of the cake.

Microsoft has announced the official release of WPF/E under the official name of Silverlight.  The list of announced features is quite interesting (here's Tim Sneath's post), and it seems consistent with the philosophy we already saw with other .Net technologies: borrow everything that's good from the competitors, improve their weaknesses, integrate with .Net and make it develop-able in Visual Studio. If you know how C# stands compared to Java or ASP.Net compared to JSP, you know the answer... It's similar but not the same as SWF. Silverlight looks like a more technologically advanced version of Shockwave/Flash, it has some new ideas (like embedding XAML directly into the html page - which Flash player cannot do because it's SWF format is binary). But this is all on paper. For years Microsoft developers have been victims of unfulfilled promises: features were delivered as broken or incomplete or just silently dropped.

The real question is, will Microsoft Expression Whateveritsname be a better tool than Adobe Flash? If you compare feature lists, this is almost certain. But how will this features be implemented? There are already reports that the even the present Expression version, the Web Designer is far from complete. The other tool that could be WPF/Silverlight compatible, Visual Studio Orcas, is also in the making but if the previous Visual Studio .Net versions are anything to go by, it won't be a high quality or stable tool. For example, a major killer-feature of VS 2005, data binding, is still very much broken, even after service pack 1... And visual inheritance - present but unstable in previous versions - was just dropped in 2005's first release.

There was also some stir because the official announcement failed to mention a Linux Firefox plug-in for Silverlight. Well, I'm quite sure it had been announced at MIX 06: I remember one of the presenters declared that developing a Linux Firefox plug-in was (quite understandably) a great technological challenge for Microsoft people. I may be mistaken, it may have been just Firefox, without Linux :)... One thing should be clear, though: Microsoft's is going cross-platform not because they like Mac or Firefox but because of the antitrust case and because Adobe's already there. So, a Linux plug-in shouldn't be a big surprise at all.

There's also another interesting twist: with Silverlight, Microsoft is essentially entering an arena in which Adobe/Macromedia was the only fighter - seemingly, a benign monopolist. It's somehow strange to see Microsoft actually boosting competition instead of trying to destroy it.

Visual Studio project references

Replacing one project in a Visual Studio 2005 solution with another one is not as simple as it sounds. Partially because of Visual Studio playing smart and/or dumb but partially because of project file structures.

Let's say you have made a new branch for one of projects in your solution. It's in a separate folder than the version you're currently using and you want to change all projects in the solution to reference the new one. If you remove the old project from your solution the smartypants Visual Studio will remove references to it from every single project in the solution. Even if you could save only this changed solution and discard changes to project files (don't know if you can), it wouldn't work. Even if you open the solution file in notepad instead, and change it to include the new project, it's a no-go. The solution would probably build fine and the project references in visual studio would seem ok (no exclamation marks, paths shown in the properties window pointing to the new version) but still the wrong dll will be used.

Why is this? The project file (*.csproj) stores its own path to the referenced project and uses it instead of the solution's (this actually makes sense). It doesn't matter if the referenced project is included in the solution or not: Visual Studio will find the referenced project's dlls and use them without building the project. Only if you go to the old project's bin folder and delete everything will you get build errors for projects referencing this old version. And the curios thing is that again if you inspect the culprit project's references, Visual Studio will still insist that it references the new dll's.

So, in the end, you will use compiler errors to detect which projects reference the wrong version, and then remove-add references to change them. You probably would have saved time if you let Visual Studio remove all references in the first place.

Mind over Microsoft: curing DataSet autism

The deeper I dig into Visual Studio 2005 the more I get the impression that it contains more obstacles than features. It isn't enough to just think something over and figure out how to do it: each step of the implementation may hide a showstopper - either a bug or a crippled feature. You have to check very carefuly if all you thought of can really be implemented.

Here's a good example on how you can get sucked into "Visual Studio does everything by itself" Microsoft agitprop. I wanted to work out a simple solution for a non-creative task which is making search forms for my windows application. You know, search: enter what you want to search for and you get a list of records from the database. A form with a data grid in the center, some text and combo boxes above it for the user to enter search criteria into, and a SEARCH button.

What would be the best way to implement this kind of component, to make mass production as fast as possible? Let's see... I'd have to utilise the design-time functionality to the maximum. There could be a base class containing most of the logic and all common components: say, an empty DataGridView which the user could configure from inside a derived component to add columns etc. The dataGrid would be bound to a BindingSource which is in the base class, but its DataSource type (the DataSet used for search operation) should be set from the derived component so the designer could know what properties exist in it.

Then, in the derived component, a developer would add a new data source for the BindingSource - i.e. create a DataSet, modify its sql query and voila, the grid's columns are automatically initialized and prepared for customization. The base class would pick up the DataSet type being used and wire up the logic (i.e. SearchButton_Click handler) for filling the DataSet - after all, the DataSet has a generated TableAdapter configured and ready to go.

Now, how to enter search criteria? This one could be interesting: write the DataSet SQL with prepared parameters in the WHERE part, like "SELECT something FROM something WHERE (column1 = @param1 OR @param1 IS NULL) AND (column2 etc.)". Next, create a separate BindingSource in the base class for search criteria. In the derived class, bind it to the table adapter's parameters, then add text and combo boxes to your liking and bind them to individual parameters. Ok, this could be problematic, but an ICustomTypeDescriptor wrapper class or something could help turn the adapter parameters into something bindable. So, using high-tech Visual Studio designer components, the user gets to make a complete search form in half an hour. Wow!

Um, I hope you didn't read this post from the middle? Because you could have gotten the wrong impression that this could be done. The cruel reality is that most of the abovementioned doesn't work. Let's start from the beginning.

Have you ever looked at the generated DataSet source in VS 2005? I don't know if it's the same as in VS 2003, but it's not just ugly, it's absolutely hideous. I thought that if I notify my component of the type of DataSet being used, it could somehow detect the proper DataAdapter from it. Not likely: not only there is no property on the DataSet that could point to the DataAdapter type (let's say this is ok, there could be more than one DataAdapter for a given DataSet), but the DataAdapter is not even in the same namespace! Why isn't it a class embedded in the DataSet? Nobody thought of that. It doesn't seem there was a lot of thinking invested here anyway.

But this is not the end of it: the generated TableAdapter is not a table adapter at all, it's a class derived directly from Component - in other words, a nobody! The real DataAdapter is in its private property. (Aarrggh, ok, we'll use reflection to access it then). Yeah, but the real adapter is not initialized when the quasi-TableAdapter is instantiated. It's initialized only when you call the Fill method... And since there is no base Fill method (remember, the base class is a Component), the only option is to call the generated Fill method and feed it parameter values. So, if I'm going to use reflection anyway to get the private property, why not call the Fill method directly.

Ok, never mind: use reflection to get the adapter, call all the proper initialization methods using reflection and hope their names don't change in future versions. (Fat chance, I'd bet this code survived from the VB days. I tried finding the DataSet designers using Reflector and stopped when at some point the .Net code jumped through the interop mirror over into the COM world... Well, that's true at least for the sql designer - which is the most useful part of it anyway).

Now, to make an ICustomTypeDescriptor to bind to the sql query parameters. Well, it can't be done: BindingSource doesn't support ICustomTypeDescriptor. Just think of it: what do you get when you add two cool technologies together? Nothing, because they've been made by Microsoft. Do the guys over there talk to each other at all?

So, I resorted to a brute-force solution: created a new wrapper class complete with a VS.Net designer that detects parameters from a given TableAdapter and creates an accessor property for each of them. So I can bind to the wrapper and the wrapper will then call the TableAdapter.

Have you started wondering why I haven't chosen to abandon DataSets and create my independent components? I did think about it - but at this point it is pure bloody-mindedness that drives a man to beat the damn technology. It's a challenge.

Yeah, right. Next step: the DataGrid. In the derived class, we configure the BindingSource to use the generated DataSet and then get the DataGrid to automatically configure its columns from it. Then we just reposition and format the columns and -

Well, surprise surprise: visual inheritance is turned off in VS 2005. (I know it's old news, this is a story that was a long time in the making: just look at the sheer volume of text above). So - man, do you still want to beat the technology?

I had to make my own templating mechanism (an extender provider, actually: these are very useful) so one can put the controls into the derived class and then set their "extender-ed" property that says into which area of the template it should be placed. So the base class picks up thusly marked controls and knows which is which.

Next? Binding issues: the pre-SP1 data binding designers in VS 2005 are extremely fiddly (the post-SP1 ones are just fiddly). You can bind controls to datasources but you aren't sure you'll be able to open the designer again in the future. The class properties don't always appear in the data sources toolbox. And the ones that do, don't appear when you try to bind from the properties window. If you want to bind to a property's property, you'll have to write the path manually. Jesus Christ! Today they'd give you Visual Studio .Net instead of a cross.

Wait, there's more: the DataSet designer resets most of the manually set properties (like parameter or column types or their AllowDbNull property) every time you reconfigure it. Before you start modifying a DataSet, you have to memorize its properties' values first. If you forget a single detail, you either won't be able to compile or you'll introduce a bug you'll waste some more time fixing (possibly at a later time when you forget what you did).

And more: I'm not quite sure how connection strings are supposed to be handled in VS 2005 SP2. If I try adding a new connection string to the project, it doesn't show up in the dataset designer. I suppose the designer caches existing connection strings in the XSD files but never seems to refresh them. If I try to rename one of the connection strings, I either get a refactoring error (the refactoring engine somehow destroys a property in the dataset's Designer.cs file) or I end up with crippled XSD files (half of its XML simply goes missing). Sometimes, for reasons unknown to me, a one of connection string names gets a full path with a namespace, and XSD starts reporting errors until you fix it (turns out it cannot stand dots in connection string names).

I'd already lost enough time battling with Visual Studio 2005 that any productivity improvements from using it - and after all this I seriously doubt there will be any surprises any time in the future - cannot compensate for it. It did sound like a good solution before I started implementing it, but that is because it was based on wishful thinking fueled by Microsoft marketing. One has to be very careful about these things: for any such adventure, multiply your time estimate by three.

How to get the containing folder for a ProjectItem in a Visual Studio 2005 designer

It was a long search, and I must say that the item in question was very well hidden (congratulations to whoever put it there :)). The problem was this: how do you, from inside a Visual Studio designer or add-in, get a reference to the current ProjectItem's containing folder? And I don't mean the folder on the disk, but the Visual Studio project folder that may not be the same.

You'd never find it... It's in ProjectItem.Collection.Parent! Here's some sample code (the idea is to put the code into a component designer: I haven't tried this actual code, but the basic idea is the same as what worked for me):

public ProjectItem FindActiveDocumentsSibling(string fileName)
{
// we need the DTE to get the active document
DTE dte = (DTE)Component.Site.GetService(typeof(DTE));

Project ret = null;

// try-catch is necessary because Item() throws an exception if no item is found
try
{
   ((ProjectItem)dte.ActiveDocument.ProjectItem
.Collection.Parent).ProjectItems.Item(fileName);
}
catch { }

return ret;
}

So, what's this for? Well, I'm trying to put an NHibernate *.hbm.xml file next to a code class. (Look at a previous post as to why it isn't a child item but a sibling). Now if I could only figure out how to (or whether I should) open it using Visual Studio mechanisms - but without showing it to the user...