VS.NET constrains the application development process

Have you ever pondered the current practice of referencing assemblies from within a VS.NET project? I haven´t much until recently. I just took this way of linking to code for granted. It´s how we do dynamic linking today. Great!

Or isn´t it?

No, I don´t think it´s that great. I think it limits our thinking on how we develop software. It is just one way to link components together at runtime.

What´s limiting in referencing assemblies is that it binds the component under development to a certain implementation of other components. Isn´t that, what we want, you might ask? Yes, sure, that´s what we need and want for components that already exist (lets call them libraries) while we develop our own component.

When I work on my component, I need the services of libraries like the .NET Fx DLLs or the assembly of my favorite DataGrid. Those libraries exist prior to my project, their interfaces are set, their implementation is complete. So, sure, I should be able to include their services into my component by setting a reference to them, thereby importing not only their meta data, but also later on during runtim loading concrete assemblies.

But when I want to do real component based development (CBD), then I consequentially want to divide my own application up into several modules/components. These components will be developed by several programmers in parallel. This will often lead to situations where a developer working on component A needs component B - which is still under development. But this scenario is not well supported by VS.NET or the .NET Fx.

I cannot reference an assembly that does not exist yet. So what should I do in my project? There are several ways out of this dilemma. The one chosen most often is not to develop components at all. Next comes building huge solutions with many, many projects in them. Both ways sooner or later lead to tight coupling between components and thus thwart the vision of CBD.

But there is a third way: I could define interfaces for components first and put them in a separate assembly. This assembly I could readly reference in my component A project. I´d then know how to use component B thru its interface IB. Great!

Or isn´t it?

Yes, a very good idea - but no well supported by VS.NET and the .NET Fx. Because this way entails you need to discover the implementation of the interfaces you bind to during runtime. Currently there is no way to accomplish that. You can´t pass an interface type to Activator.CreateInstance() and ask it to instanciate an unknown class implementing that interface.

But that´s what´s necessary if you truely want to decouple a client component A from the implementation of some interface IB. Because during development of A you might use mock-up component BMockup which implements IB. But later on a client´s system BMockup has to be replaced by BFinal. Or maybe you want to try different implementations of IB, e.g. BStrategy1 and BStrategy2. How do you bind to those different implementations during development? Not at all, because they don´t exist.

That´s what I mean, when I state, VS.NET contrains the development process. VS.NET and the .NET Fx are targeted towards developing applications where all implementations are well known during development time. It supports well bottom-up development. But it does not support well parallel, independet development. We still need to come up with additional infrastructure to overcome these limitations. We need to build our own Contract First tools for intra application interfaces between components.

3 Comments

  • This sounds like a problem COM solved.



    Basically you're saying that VS.NET does not allow you to create an object that you're not bound to at design time? (Thats a lot of words to say that)



    Can't you do something like:



    Type codeDomProviderType =3D

    Type.GetType("Microsoft.CSharp=AD.CSharpCodeProvider", true);





    ObjectHandle objHandle =3D Activator.CreateInstance(null,

    "Microsoft.CSharp.CSharpCodePr=ADovider");

  • @Alex: Yes, you can create objects from assemblies not referenced explicitly in your project at any time. Use Activator.CreateInstance() for example. But this does not slove the basic problem I described. Rather it points in the direction of a solution. But the solution is not here in full yet. The .NET Fx lacks an infrastructure for dynamic binding and runtime integration of applications.

  • @Udi: Sure, each tool should only try to be good at a limited tasks. And I don´t want to blame VS.NET for not supporting dynamic binding. VS.NET does already a lot (probably more than is good for it; it´s too general a tool - but that´s another story).



    Rather, dynamic binding is an infrastructure problem and thus should be handled deep down in by the CLR/BCL. It´s on par with the GAC and Fusion.

Comments have been disabled for this content.