Quantcast
Channel: Visual Studio Integrate forum
Viewing all articles
Browse latest Browse all 4410

What are the best practice with new service when dealing with VS Isolated Shell

$
0
0

We are working on an application build around VS 2010 SP1 Isolated Shell. This application include a lot of package for our shell. Some of the package provide service consume by other package, and/or for external people which build extension for our product. All those package are build using C#.

We are looking to best practices when dealing with services.

In Visual Studio SDK, we observe the following:

- SVsSolution is passed to GetService to return a reference to IVsSolution.
- Declaration of  IVsSolution2 is public interface IVsSolution2 : IVsSolution
- Declaration of IVsSolution4 is public interface IVsSolution4

Also of interest is a note from the VS SDK:
"Although you could use the same type or GUID for both the service and the interface, we recommend that you separate the two because a service can expose different interfaces."

What is the reason for having IVsSolution2 implement IVsSolution, while IVsSolution3 and subsequent interfaces do not implement anything?
While it is understandable that not IVsSolution4 may not need to implement IVsSolution3, is it assumed that is could not even implement IVsSolution ?
As a general rule to augment an interface, should we create a new exclusive interface, whose instances may or may not implement the base interface?

When dealing with non-COM objects, what is the gain of having a distinct service interface for the GetService (i.e., SInterface distinct of IInterface) ?
Or, to put it differently, what do we lose by directly using the interface in a GetService call (i.e., GetService (typeof(IInterface)), instead of GetService( typeof(SInterface)) ) ?




Viewing all articles
Browse latest Browse all 4410

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>