AllenD's WebLog : Interop

Managed Package Framework Webcast

AllenD — Thu, 13 Jan 2005 21:25:00 GMT

I forgot about this 'til now.

http://msevents.microsoft.com/cui/eventdetail.aspx?EventID=1032258553&Culture=en-US is a link to a MSDN webcast I did describing the Managed Package Framework for the masses. Enjoy.

IVsRunningDocumentTable.RenameDocument - how to call in managed code

AllenD — Fri, 20 Aug 2004 20:52:00 GMT

Here's a little code to help managed packages call the Running Document Table to rename a document:

Calling IVsRunningDocumenTable.RenameDocument is not entirely straighforward in managed code. Here's some code the shows how to get the SVsRunningDocumentTable service, find a document therein and then rename it. I've had one partner confused by the calling pattern so I figured I'd share the solution with you in case you ever need to employ it.

IVsRunningDocumentTable pRDT = GetService(typeof(SVsRunningDocumentTable)) as IVsRunningDocumentTable;
IVsUIShellOpenDocument doc = GetService(typeof(SVsUIShellOpenDocument)) as IVsUIShellOpenDocument;
IVsUIShell uiShell = GetService(typeof(SVsUIShell)) as IVsUIShell;

if (pRDT == null || doc == null) return;

IVsHierarchy pIVsHierarchy;
uint itemId;
IntPtr docData;
uint uiVsDocCookie;
NativeMethods.ThrowOnFailure(pRDT.FindAndLockDocument((uint)_VSRDTFLAGS.RDT_NoLock, oldName, out pIVsHierarchy, out itemId, out docData, out uiVsDocCookie));

if (docData != IntPtr.Zero) {
    IntPtr pUnk = Marshal.GetIUnknownForObject(pIVsHierarchy);
    Guid iid = typeof(IVsHierarchy).GUID;
    IntPtr pHier;
    Marshal.QueryInterface(pUnk, ref iid, out pHier);
    try {
        NativeMethods.ThrowOnFailure(pRDT.RenameDocument(oldName, newName, pHier, itemId));
    } finally {
        Marshal.Release(pHier);
        Marshal.Release(pUnk);
    }

    Marshal.Release(docData);
    }

I hope this help!

Allen

Back in the late night saddle; ISelectionContainer

AllenD — Fri, 09 Apr 2004 08:09:00 GMT

Here I am again at 1:00am, working. Now, I know you may think that 1:00am is early, but consider the fact that I get up at 6:30am to get the whole thing going and it's just crazy how many hours of sleep I am NOT getting.

But that is life when we're all trying to get Whidbey Beta 1 ready for customers to try.

ISelectionContainer and Managed implementations thereof...

The VSIP Docs cover this, but they don't go into details about how this works in VSIP Extras. First there is the ISelectionContainer interface that an object must implement in order to be placed into the 'selection'. For native code, it is simple to implement this interface as defined in the native designer.idl file.

The problem comes when managed objects want to play in the Property Browser. If they just implement the ISelectionContainer as defined in the Microsoft.VisualStudio.Shell.Interop namespace, they'll work fine with some VS components, but the PropertyBrowser won't work. The reason for this is that the Property Browser is itself managed code. Normally you'd think that a managed object implementing ISelectionContainer would work well with a managed object like the Property Browser, but there's something subtle here.

The Property Browser was written before the interop assemblies as they shipped in VSIP Extras. The managed definition the Property Browser expects is actually inside a managed assembly that isn't documented and isn't supported for 3rd parties to interact with.

We solved this problem for you in VSIP Extras by providing a SelectionContainer class in the Microsoft.VisualStudio.VSIP.Helper namespace. This object implements both definitions of ISelectionContainer so that native VS code can interact with the object and the managed Property Browser can too. When each asks for their respective interfaces (the same in one sense, but technically different in the managed world) they get the right one and use it. The underlying implementation adapts the object to either interfaces.

This is a pattern you'll see often in VSIP in the future as we expose more and more functionality for things that have multiple definitions. Unfortunately there are sometimes things that ship before we get to them to unify all the interfaces under one definition.. When that happens we can employ this pattern to satisfy all the callers of the interfaces and have them interact with the same underlying object.

The VSIP Extras download includes the source code for this in SelectionContainer.cs. Take a look for the details.

Renaming Interop Functions

AllenD — Fri, 20 Feb 2004 07:33:00 GMT

In a previous post (http://blogs.msdn.com/allend/archive/2003/10/16/56791.aspx) I ranted about a weird behavior in generating Interop Assemblies where case changes occured in function names. Well, it turns out that the TLB is the culprit. All methods therein are case insensitive (the VB standard). The first method into the TLB wins when it comes to the case for all similarly named functions. So if you have Foobar and FooBar functions in your IDL, they'll both end up with the case of the first one in the TLB and in the Interop Assembly for the TLB. (I found the info in Adam Nathan's .NET/COM Interop book, THE definitive source for practically all Interop information.)

Getting to IServiceProvider services with VSIP Extras

AllenD — Tue, 17 Feb 2004 01:02:00 GMT

If you have access to the underlying Package base class, it exposes a method to get services called GetService. You use it like so:

IVsShell vsshell = (IVsShell) GetService(typeof(SVsShell));

vsshell can then be used to call methods it exposes (the IVsShell interface). The GetService method is simply implemented by using the ServiceProvider object which wrapes the use of the IServiceProvider interface passed to the package's IVsPackage.SetSite method.

For other objects that don't have access to the Package base class and receive another IServiceProvider (like the IVsWindowPane interface associated with VS windows which has its own SetSite method) then the GetService method exposed by the Package base class isn't available. Instead the IVsWindowPane.SetSite method can be written as follows to create its own ServiceProvider object:

ServiceProvider myServiceProvider;

int IVsWindowPane.SetSite(IServiceProvider sp)
{
myServiceProvider = new ServiceProvider(sp);
return NativeMethods.S_OK;
}

Now code that has access to myServiceProvider can use it to get services just like in the Package base class.

IVsShell vsshell = (IVsShell) myServiceProvider.GetService(typeof(SVsShell));

The ServiceProvider class handles all of the marshaling of the interface pointer and handles the error cases for you so you don't have to worry about them.

Unfortunately the VSIP Extras samples are frozen at this point and I'm not allowed to crack them to make this little change. You can make it yourself in your code, though and it should save you some headaches when trying to get services in other objects besides your package based on the Helper's Package base class.

I hope this helps,

Allen

Gotcha re-implementing interfaces

AllenD — Thu, 06 Nov 2003 21:14:00 GMT

I've recently stumbled upon a problem that a couple of VSIP Developers have encountered. I say 'a couple' because it required two packages interacting in order to discover the real problem.

Basically a managed package derived from the base Package class in the VSIPHelper base class and also re-implemented the IOleCommandTarget interface. This confuses the CLR interop code. The most common effect of this is that the base class always gets called on the interface when called from unmanaged code. (The derived class implementation is never called). The worst case could be that it is indeterminate if the base class will be called or the derived class.

The really bad thing is that there appeare to be cases where the vtable offset of the interface appears to be cached. So, depending on the behavior above, you could get random functions called since the vtable for derived objects could be different (depending on the class hierarchy). The offset for one package not overriding the implementation is different than the offset for another package which does override the implementation. If the first one to be called causes the offset to be stored. The second one to be called loses because a random place in the vtable will be called.

The bottom line for VSIP developers is: Don't re-implement interfaces already implemented by a base class.

In Everett Extras we provide a virtual method for each IOleCommandTarget method so that you can override the behavior of the base class and continue to rely on its implementation of the interface.

In VSI Everett Extras, if you find the need to override the base implementation of some other interface, but we don't provide a way like with IOleCommandTarget, please let me know.

Thanks, Allen

Thursday PDC Report

AllenD — Thu, 30 Oct 2003 20:17:00 GMT

General comments at the end of the PDC

Boy am I tired.

First, coming to these things requires like 14 hours of activity each day. Add to that the fact that booth duty requires standing like 6 hours each day and I can't wait to get back to my desk!

Second, I can't sleep without my wife. Tonight I'm going to sleep like a baby.

Tue PM

So I haven't had a chance to blog for a while. My apologies.

At the end of the last entry I indicated I was about to attend the Managed/Native Interop Birds of a Feather session 10-11 on Tue. There was approximately 30-40 of us there and Adam and Sonja hosted, taking suggestions for future features in the interop features of the CLR. Lots of good suggestions. One thing that was requested was a tool that would compare an IDL or TypeLib against an Interop Assembly. Maybe I'll write one.

Wed

I met some VSIP partners whom I'd never had a chance to meet. LogicLibrary was very prominent at this show and they came by and chatted about Everett Extras. Turns out it was John from LogicLibrary whom I'd actually helped over the phone to get their package to load. Much thanks to John since that exercise worked the kinks out of the VSIPDev.com package load key generation process. The email that you get from VSIPDev.com containing the key string and the instructions are much clearer now. Our documentation folks are even working on a Walkthrough in this area that will really help VSIP partners to get their package load keys working correctly.

Wed was less booth duty than previous days plus one meeting with Intel. All the rest of the day was less 'work' and more education/conference attendee stuff. I had the opportunity to attend Chris Anderson's session on Longhorn Application Fundamentals. Longhorn apps are very cool and easy to write. Some day, we'll have to figure out how the next version of Visual Studio should take advantage of the Longhorn features. Another session I attended was the Peer-To-Peer Networking offerings being created for Longhorn (and some of this is available in XP service packs).

It's an interesting contrast in these two sessions. In general the more exciting, well-received sessions seem to be the one that showed lots of code, code being written and few power point slides. BillG and the other keynotes didn't have a lot of code being written since they're presenting general direction and announcements, etc. But in the individual sessions I feel that code, code, code is the thing. I'll keep this in mind for my own customer presentations.

Wed PM

Wed night was the Attendee Party at Universal Studios. It was really cool and everything was free. I met up with my friend Bill and one of his co-workers (David) and we went to the Mummy Returns, Backdraft and the Back to the Future Ride. That's about all the time we had.

One humorous point was an escalator ride where Don Box was getting the group around to chant something. Here's my script from the event:

Don: Okay everyone on 3, "Linux Sucks", 1...., 2...., 3....
Crowd: "Linux Sucks" (Laughter)
Guy behind me: "Who was that weirdo?"

Shortly after this Chris Anderson was getting the crowd to 'whoop' it up.

Chris: "Come on everyone. Hoo, hoo, hoo!"
Guy beind me: "Man, what is going on around here?"

I guess those two were really happy their sessions were done and they could relax. Seriously though, they were both great presenters. Any time you get a chance to listen to either or both of them, you should take advantage of the opportunity.

Thurs AM

I got back to the convention center this morning and finally got my Attendee bag. Microsoft employees, even if paying full conference fee, weren't given the conference bag or materials (CDs with Longhorn, etc) when we checked in. We deferred to real customers, given the fact that this conference was sold out (we didn't want to run out of materials for everyone else).

After that I wanted to attend the Longhorn panel discussion, but there was no room in the hall and little room outside. I continued on to the CLR Internals discussion. Luminaries sitting on stage holding court musing on memory models, architecture & platforms, language syntax, programming paradigms and where the CLR is headed. Very informative, but I must confess I started typing this blog entry and, like very bad laptop users I didn't pay much attention.

Goodbye LA, smog, fires, (really bad) traffic (compared to Seattle), ...

Now I'm heading to the airport, home, my family and bed. Catch you later...

Tue Report

AllenD — Wed, 29 Oct 2003 07:50:00 GMT

Mon Night

Monday night we had a reception in the Expo Hall and there were a lot of people around. We gave out a bunch of VSIP t-shirts and VSIP 2003 SDK bits, including the Everett Extras bits.

We continue to have some really interested customers who are learning of the new VSIP (it’s free now) for the first time. There are also a number of customers who are learning, for the first time, that the beta of Everett Extras is available publicly. We had one customer come by and I showed him how easy it was to incorporate a .NET User Control into a VS Tool Window. He was totally enthusiastic at how easy it was to accomplish. This gave me the opportunity to demonstrate the beta wizard for generating a VSIP package. I’m really excited about Everett Extras and the whole VSIP team (especially the developers whom I work closely with) should be very proud of what’s being done to enable customers to solve problems and integrate their really neat features into VS.

Tue AM

I sat in on Eric Rudder’s keynote. The audience was very enthusiastic about new features in VB, ASP.NET, Smart Devices and other newly announced products that integrate into VS.

I did more booth duty this morning after the keynote and things have definitely slowed down. We got rid of the t-shirts and now only the most serious of customers are dropping by. With nothing free to give away, except a CD with SDK bits, people aren’t as interested in hearing about VSIP and VS Extensibility. It is good, however, to get the serious questions and have time to actually demo some of the bits for potential and existing partners.

Tue Noon

I sat in on Adam Nathan and Sonja Keserovic for their session on Managed/Native Interoperability. Adam literally wrote the book on this topic. He was giving his book away with signature for lucky attendees who answers certain quiz questions correctly. (For the record, I could answer these, but I held back for the benefit of real customers.) This was a great talk and it got me thinking that we’ve got more work to do in VSIP to make sure that we don’t fall into the traps that were demonstrated in the session and to make it easy for our VSIP partners to avoid them as well.

After this I went back to the booth and answered questions, demo’d EvEx some more and generally couldn’t wait to get off my feet.

We had the opportunity to sample some of the fine steak of downtown LA. Craig, Ken, Doug, Tom, Chris and my good friend Bill took a ride to one of the local establishments and enjoyed a nice dinner.

Tue PM

After dinner, Ken, Doug and I went to meet with an existing partner to demo their upcoming product and to talk about possible future directions. It was a good demo and they’ve got a great product. I wish I could say more, but you’ll just have to wait ‘til they go to market with this and then I’ll include more here.

The hotel we went to was the Standard Hotel in LA. The sign outside the hotel was upside down. I had a feeling this was anything but ‘standard’. Inside (on the 5’th floor at least) we found room labels that said “My name is: 503” instead of the traditional “Room 503”. There were also is labels on the stairs that said, you guessed it, “My name is: stairs”. One of the rooms had been hastily converted to a “conference room”. The bed was still there as well as the funky modern furniture. The shower had no door and it was a completely white room (tile, furniture, fixtures, bedding, walls, everything). It felt more sterile than a hospital. I was happy to get out of there and will never stay there when I travel, that's for sure. Maybe some people like that kind of thing, but it was fairly bad in my opinion.

I finally made it back to the Convention Center with only 30 minutes left in the Ask The Experts session, but managed to learn of some cool Whidbey bugs customers have found and talk to some customers about Extensibility and VSIP.

I took the opportunity to introduce myself to Adam and Sonja whom I have exchanged some emails with, but have never actually said ‘hello’ to. I’m sitting in the Tools & Languages Lounge now, waiting for the Birds of a Feature session on Managed/Native Interop to see what’s going on with others who do the same things that my team does.

Fires

This morning I looked at the TV News and it looked pretty grim. The fires are still spreading and threatening even more populated areas. The smoke & haze outside the Convention Center was even worse today than yesterday. I estimate visibility to be less than 1 miles. No one on the streets seemed to be alarmed at this. SoCal attitude I suppose.

VS Dialog font and dying my hair, maybe

AllenD — Sat, 25 Oct 2003 03:01:00 GMT

Preparations

I'm in the mode where everything needs to get done before I can leave. Don't you hate that mode?! It's like going on a long vacation. You get extra productive making sure everything is OK before you leave. If only I could work this way everyday!

Giving Campaign

Well, my Product Unit (Visual Studio Core) may just win for the Giving Campaign Challenge. Remember, if 80% participate in this year's campaign, I said I'd dye my hair. The deadline was extended and it's looking grim for my dark brown hair. As of today they've reached 59%. At this pace, they'll win for sure. I'll keep you posted here.

VS dialog font from managed code

An internal MS integrator posted this question:

I have a managed package, where I'd like to reflect the font selected in the shell for Toolwindows and Dialogs into my package's toolwindows. Using the interop assemblies for the Shell, there is a QueryService to get an IUIHostLocale, which then has a GetDialogFont method. My question is how do I transform the resulting UIDLGLOGFONT into a managed System::Drawing::Font object. The static System::Drawing::Font::FromLogFont throws an invalid arg exception if I try to use it. Anyone got any advice?

Here's how to do this using the VSIP SDK from Everett Extras:

Use the LOGFONT struct out of the NativeMethods namespace in the VSIP Helper classes, filling in that struct with the info you get from the IUIHostLocale::GetDialogFont method. Then use the .NET Framework's Font.FromLogFont method to create a Font object for your use.

Here's some code (I've not compiled, but it is close to what is expected to work):

                              IUIHostLocale locale = (IUIHostLocale) GetService(typeof(IUIHostLocale));
                              if (locale != null) {
                                   UIDLGLOGFONT[] fArray = new UIDLGLOGFONT[1];
                                    locale.GetDialogFont(fArray);
                                    UIDLGLOGFONT font = fArray[0];

                                    // Convert the face name from ushort[32] to string
                                    StringBuilder sb = new StringBuilder();
                                    int ch = 0;
                                    while (ch < 32) {
                                        ushort charVal = font.lfFaceName[ch];
                                        if (charVal == 0) {
                                            break;
                                        }
                                        sb.Append((char)charVal);
                                        ch++;
                                    }
                                    if (sb.Length == 0) {
                                        Debug.Fail("Unable to get face name of VS dialog font.");
                                    }

                                    // Copy one LOGFONT to the other...
                                    NativeMethods.LOGFONT lfAuto = new NativeMethods.LOGFONT();
                                    lfAuto.lfHeight = font.lfHeight;
                                    lfAuto.lfWidth = font.lfWidth;
                                    lfAuto.lfEscapement = font.lfEscapement;
                                    lfAuto.lfOrientation = font.lfOrientation;
                                    lfAuto.lfWeight = font.lfWeight;
                                    lfAuto.lfItalic = font.lfItalic;
                                    lfAuto.lfUnderline = font.lfUnderline;
                                    lfAuto.lfStrikeOut = font.lfStrikeOut;
                                    lfAuto.lfCharSet = font.lfCharSet;
                                    lfAuto.lfOutPrecision = font.lfOutPrecision;
                                    lfAuto.lfClipPrecision = font.lfClipPrecision;
                                    lfAuto.lfQuality = font.lfQuality;
                                    lfAuto.lfPitchAndFamily = font.lfPitchAndFamily;
                                    lfAuto.lfFaceName = sb.ToString();

                                    try {
                                        object dialogFont = Font.FromLogFont(lfAuto);
                                    }
                                    catch (ArgumentException) {
                                    }

VS7.1 VSIP Extras Beta is available

AllenD — Sat, 18 Oct 2003 02:14:00 GMT

VSIP Extras SDK Beta

The VSIP Extras SDK Beta (additional bits that work with the VS7.1 VSIP SDK) is now available. Visit www.vsipdev.com to get it.

This release of the SDK includes 4 major things:

Visual Studio Interop Assemblies - enables managed code to call native interfaces and implement interfaces called by managed code.
A set of simple helper classes that implement the basic functionality of a VS Package. You extend these base classes for your package. This includes some helpers classes for Tool Windows, Selection Container adapter, Registration Attribute Classes, a Registration utility & more.
Wizard to generate VS Packages including Language Services (limited since we may not know your grammar).
Updated documentation including functions reference for the managed interfaces as well as information on how to use the helper classes and registration utility.

VS Automation allowing macros and add-ins as well as driving VS via the DTE automation model are really cool features. I think this is one of the strengths of the IDE in that any user can easily do something custom they want to do. With VSIP you can now extend the IDE even more deeply by creating your own Project Systems, Editors, Designers and Language Services, as well as Tool Windows (VS Automation already does this fairly well though).

And this is all free with the new VSIP program. There are ways to pay more if you want marketing involvement, but the free program is great to get started.

PDC

Several of us from Visual Studio will be at the PDC talking about VSIP. Come by our trade show booth for more information and cool swag! See you there.

Managed code rocks!

AllenD — Fri, 17 Oct 2003 08:04:00 GMT

So, my team is working on the VSIP Everett Extras release of the VSIP SDK. We have a beta about to be released. Someone using an early release of this beta commented:

I had a working C# WinForms project already and I was able to generate a VSIP Project using the wizard, copy and paste the various controls and supporting code, and get a working VS Tool window in under 2 hours! Within 6 hours, I had some advanced stuff working, including use of the new SelectionContainer helper class. And I have never done a line of VSIP code before today (though I have done a little reading of SDK docs over the past few weeks).

Pretty sweet if you ask me!

Case sensitivities

AllenD — Fri, 17 Oct 2003 01:14:00 GMT

So my team produces Interop Assemblies for Visual Studio. Chris on my team does a great job maintaining a set of monster perl scripts and a batch file that processes IDL's into TLB's into Interop Assemblies. Most people just recommend using TLBIMP on the TLB, but for nasty interfaces which violate OLE Automation rules, you have to muck with the IL directly. (More on this in a future entry.)

So we use MIDL, TLBIMP, ILDASM & ILASM + those perl scripts to create assemblies for interop for the VS interfaces. Great in theory, but the devil is in the details.

There's a strange behavior in MIDL (& TLBIMP also possibly) where the case of some names change during compilation. For instance in the IDL you might have:

interace IFoo : IUnknown

{

HRESULT GetFoobar([out, retval] BSTR * pbstrFoobar);

}

In the TLB after TLBIMP you might have:

IFoo.GetFooBar

Yes, that's right IFoo.GetFoo B ar (as in CAPITAL "B")!

and in the Interop Assembly, of course we end up with:

IFoo.GetFooBar

So I was implementing IFoo.GetFoobar in my managed code and it all worked great. I changed some things that are unrelated to the interface and method names and bang! Now the C# compiler is complaining that I haven't implemented IFoo.GetFooBar. Things like this really are difficult to find since it appears that something else was wrong (like missing references). Hey, why can't the C# compiler complain that there's a problem, notice a similar method only differing by case and mention this as a possible cause?

Maybe I'll switch to VB.