What is the advantage of the .net4 function new no pia [PIA deployment]

Question

Maybe he just missed something, but when I write code to interact with Excel, here's how.

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

Is there a scenario when I have to deploy / register a PIA? Or is there something wrong with me because it seems to me that embedding the PIA in the main assembly does not seem like a big feature?

Please excuse my ignorance, if any.

---

Update:
So I did some tests, I wrote an application that opens excel adds “hello” to the cell and saves the file.

I built it on my Win7 Dev machine with Office 2003 installed (so I referenced 2003 libs). Interestingly, without the built-in PIA, the 9KB application (only 3 PIAs up to 1.32 MB). With integrated PIA exe 13KB .

Secondly, with the built-in PIA, the application worked on a computer with Office 2007 and 2010. And without the built-in PIA, on WinXP + Office2007 this happened only when the PIA were not in the exe directory.

So, I guess some method, is there some kind of dynamic resolution? And then why did it work on Win7 without PIA in the exe directory, but on WinXP it failed (only when the PIA was not in exe dir), did the Win7 PIA box deployed all over the world or something like that?

thanks
Gideon

Answer 1

This is not what the PIA usually needs. You should have one if you expose any types of interaction from the Excel type library in one of your public classes. This happens incorrectly when another code uses your class and does not use the same interop library. A type in .NET is identical only when they come from the same assembly. It will be difficult for you to interpret the error message, for example, "Unable to transfer application to application." PIA ensures that everyone uses the same type. So far, everyone is using the same version of the PIA, which in itself is a complex problem. Deploying your own DLL with your application is great if you can avoid it. This is not difficult in most scenarios.

This problem was resolved in .NET 4.0 with 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 of which one contains them. Then it was used with the function "embed interop types" (just like "no pia"), the compiler embeds the interop types in the metadata of your assembly. Only the ones you use.

So, you no longer need to send the interop library and you do not need the PIA. And this is much less, because you only pay for the types that you actually use. This is very important for the buck, highly recommended.

Answer 2

I didn’t do too much, but I think that

• Sometimes a PIA can be quite large; if the application is very small, the PIA can Karl it
• The no-PIA method is more flexible with respect to version control: as long as you use only the members provided by the version of the COM object that is really provided, you are fine ... whereas I think that with PIA you should use PIA for the same version of COM object as on the target machine.

Answer 3

One of the key things to understand about NoPIA is that it does not embed the PIA in your assembly, but instead includes only the portion of the PIA used by your application. He does this very subtly (down to the method level). The result, as a rule, is a very significant reduction in the deployment size of your application.