what is the advantage of .net4's new no pia feature [deploying PIA's]

Question

Its possibly im just missing something here but, when I write some code for Excel interop, here is how it goes.

• I add a reference to the Excel Com libraries.
• VS creates a PIA - Microsoft.Office.Interop.Excel....(via tlbimp right?).
• I copy the exe and the interop(PIA) dll to any machine (with .net) and it works?

Is there a scenario where I would have to deploy/register the PIA? Or have I got something wrong here, because it seems to me embedding the PIA into the main assembly doesn't seem like a great big feature?

Please excuse my ignorance, if any.

---

Update:
So I did some tests, I wrote an app that opens excel adds "hello" in a cell and saves the file.

I built it on my Win7 Dev machine with Office 2003 installed(So I referenced 2003 libs). Interestingly, without embedded PIA's the app is 9KB (The 3 PIA's total upto 1.32MB). With embedded PIA's the exe is 13KB.

Secondly, with embedded PIA, the app worked on a machine with Office 2007 and 2010. And without embedded PIA, on WinXP+Office2007 it failed only when the PIA's were not in the exe's directory.

So I guess whatever method, there is some kind of dynamic resolution? And then why did it work on a Win7 without the PIA's in the exe directory, but on WinXP it failed (only when the PIA's were not in the exe's dir), did the Win7 box have the PIA's prolly deployed globally or something?

Thanks
Gideon

Answer 1

It's not that common to actually need a PIA. You have to have one if you expose any interop types from the Excel type library in one of your public classes. This goes wrong when other code uses your class and doesn't use the same interop library. A type in .NET is only identical when they came from the same assembly. You'd get a difficult to interpret error message like "Cannot cast Application to Application". The PIA ensures that everybody is using the same type. As long as everybody is using the same PIA version, which in itself is a difficult problem. Deploying your own interop DLL along with your app is fine if you can avoid this. Which is not difficult in most scenarios.

This problem was solved in .NET 4.0 through a feature called 'type equivalence'. It is specific to COM interface types, the CLR considers them compatible when they have the same [Guid] and the same declaration, regardless what assembly contains them. This was then taken advantage of with the 'embed interop types' feature (same as 'no pia'), the compiler embeds the interop types in the metadata of your assembly. Only the ones you actually use.

So you don't have to ship the interop library anymore and don't need the PIA. And it is a lot smaller since you only pay for the types you actually use. That's a lot of bang for the buck, strongly recommended.

Answer 2

I haven't done much interop myself, but I believe that:

• Sometimes the PIA can be quite large; if the app itself is quite small, the PIA can dwarf it
• The no-PIA approach is more flexible with respect to versioning: so long as you only use the members provided by the version of the COM object which is actually provided, you're fine... whereas I think with the PIA approach, you need to use the PIA for the same version of the COM object as the one on the target machine

Answer 3

One of the key things to understand about NoPIA is that it does not embedd the PIA into your assembly but instead only embeds the portion of the PIA that your application uses. It does this in a very fine grained manner (all the way down to the method level). The result is usually a very significant reduction in the deployment size of your application.