Hello Kevin,
Thanks for the response. Yes, so far we used a strong-named import of the
MSXML type library, but now the problem is that we have a very compelling
reason to make a PIA for our own COM component, which references MSXML. As I
explained before, TlbImp requires all dependencies of a PIA to be PIAs too.
How do people deal with this problem in general? There are tens of popular
Microsoft COM APIs now used from .NET. The default importing of these type
libraries works just fine. So it would take Microsoft little effort just to
strong-name them and call them the "official PIAs"... Otherwise, we really
seem to be forced to break the PIA rules, or not be able to avail from them.
//
"Kevin Yu [MSFT]" <v-kevy@online.microsoft.com> wrote in message
news:Brl$1VPiEHA.2228@cpmsftngxa10.phx.gbl...[color=blue]
> Hi Chang
>
> First of all, I would like to confirm my understanding of your issue. From
> your description, I understand that you need to create a PIA for MSXML4
> COM. If there is any misunderstanding, please feel free to let me know.
>
> Based on the following KB article, we can see that a COM type library that
> is imported as an assembly and that is signed by someone other than the
> original type library publisher cannot be a PIA. Only the type library
> publisher can create a PIA that becomes the unit of official type
> definitions for interoperating with the underlying COM types.
>
>
http://support.microsoft.com/?id=304295
>
> So if you need to interop with the MSXML library, I think you can just
> create a strong-named wrapper for it instead of making a PIA. Could you
> please omit the /primary option and try the following statement?
>
> TLBIMP C:\WINDOWS\system32\msxml4.dll /out:MyWrappers.dll[/color]
/keyfile:mykey.snk[color=blue]
>
> HTH.
>
> Kevin Yu
> =======
> "This posting is provided "AS IS" with no warranties, and confers no
> rights."
>[/color]