Hi all,
I am developing a suite of .NET non-visual components with design-time capabilities. They will be used mainly in Visual Studio 2005, but I would like them to work in any IDE supporting .NET Framework 2.0 development.
So I would like to understand what is the behavior of a "generic" design-time environment, which can be expected by a Component and its Designer, Type Converter and so on. It seems obvious that it must provide the IDesignerHost interface, and can provide many other Services. But it is not clear which Services are mandatory, recommended or optional.
I see that Visual Studio implements all Design-Time Services, which are "exported" into the .NET Framework SDK, as well as many other features. I would like to use these features when available to improve the design-time behavior of my components. On the other hand, my code should not "break" when used by another conforming IDE. So I would like to understand how could a Component "discover" if Visual Studio is present and use its features, but still work in other IDEs.
I am also curious if there is a mechanism for an IDE to "advertise" the services it implements, especially when they are not defined in the .NET Framework SDK.
Thanks in advance,
Jordan Jossifov

Generic Design-Time Environment Features
Shadow83
CheckOutSQL2K5
OK, I think I get the idea. In reality, my component designers are too dependent on the Visual Studio features, so I will set up the VS-integrated build first. Maybe I will think about an IDE-neutral version in a future release.
Thanks again.
Jordan Jossifov
Juan Suarez
I believe the service model was overengineering -- it was a nice idea that failed in practice. In practice, components cannot function properly without certain services, so pretty much any IDE must implement most of them.
Ashish Kaila
Thank you for your comment, and sorry I took so much time to say it.
Having the component(s) work well within Visual Studio is a good first step. Most developers, including me, will continue to use it as their primary development tool. So it seems that a good statement would be "the component suite works with Visual Studio, as well as with any other IDE which implements the xxx Services". So far so good.
A thing I don't like, and other developers certainly won't like either, is the phrase "requires Visual Studio". To avoid it I might write a code fragment like this:
EnvDTE.DTE dte =( EnvDTE.DTE) myComponent.GetService( typeof( EnvDTE.DTE));
if( dte != null) {
// use cool Visual Studio features ...
} else {
// provide a workaround ...
}
The problem with this code is that it needs a reference to the EnvDTE assembly. So if the appropriate version of Visual Studio is not installed on the developer's machine, the designer for myComponent will not be able to load, even if it really provides a workaround for the cool IDE features found in Visual Studio (such as code refactoring).
To make this code compile and run in all cases, I must load the EnvDTE assembly dynamically. Then I must use reflection to obtain a reference to the DTE or use any of its methods, just as I needed to call LoadLibrary and GetProcAddress in Win32 programming. It would surely work, but the overhead seems quite expensive to me.
Another solution would be to write two different versions of the component designers, one for Visual Studio and another for alternative IDEs, and install the appropriate one on the developer's machine. I don't like it either.
This is not really a question, but if somebody could suggest a simpler solution, I would be glad to hear about it.
Good luck!
Jordan Jossifov