В чем преимущество новой функции .net4 no pia [развертывание PIA]

Question

Возможно, я просто что-то здесь упускаю, но когда я пишу код для взаимодействия с Excel, вот как это происходит.

• Я добавляю ссылку на библиотеки Excel Com.
• VS создает PIA - Microsoft.Office.Interop.Excel .... (через tlbimp, верно?).
• Я копирую exe и dll взаимодействия (PIA) на любой компьютер (с .net)и это работает?

Есть ли сценарий, когда мне придется развернуть / зарегистрировать PIA?Или я что-то здесь не так понял, потому что мне кажется, что встраивание PIA в основную сборку не кажется большой большой особенностью?

Прошу прощения за мое невежество, если таковое имеется.

---

Обновление:
Итак, я провел несколько тестов, написал приложение, которое открывает Excel, добавляет «привет» в ячейку и сохраняет файл.

Я построил его на своемМашина Win7 Dev с установленным Office 2003 (поэтому я ссылался на библиотеки 2003 года).Интересно, что без встроенного PIA приложение имеет размер 9KB (общий объем 3 PIA до 1,32 МБ).Со встроенной PIA exe составляет 13KB .

Во-вторых, со встроенной PIA, приложение работало на компьютере с Office 2007 и 2010. И без встроенной PIA, на WinXP + Office2007 она выходила из строя только тогда, когда PIA отсутствовали в каталоге exe.

Так что я думаю, какой бы метод не был, какое-то динамическое разрешение?И затем, почему он работал на Win7 без PIA в каталоге exe, но на WinXP это не удавалось (только когда PIA не было в каталоге exe), на коробке Win7 глобально развернуто PIA, или что-то в этом роде?

Спасибо
Гидеон

Answer 1

На самом деле не так уж часто нужно ПИА. У вас должен быть один, если вы предоставляете какие-либо типы взаимодействия из библиотеки типов Excel в одном из ваших открытых классов. Это идет не так, когда другой код использует ваш класс и не использует ту же библиотеку взаимодействия. Тип в .NET идентичен, только если он пришел из одной сборки. Вам будет трудно интерпретировать сообщение об ошибке типа «Невозможно привести приложение к приложению». PIA гарантирует, что все используют один и тот же тип. Пока все используют одну и ту же версию PIA, что само по себе является сложной проблемой. Развертывание собственной библиотеки взаимодействия с вашим приложением - это хорошо, если вы можете избежать этого. Что не сложно в большинстве сценариев.

Эта проблема была решена в .NET 4.0 с помощью функции, называемой «эквивалентность типов». Он специфичен для типов интерфейсов COM, CLR считает их совместимыми, когда они имеют одинаковый [Guid] и одно и то же объявление, независимо от того, какая сборка содержит их. Затем это было использовано с помощью функции «вставлять типы взаимодействия» (такой же, как «no pia»), компилятор встраивает типы взаимодействия в метаданные вашей сборки. Только те, которые вы на самом деле используете.

Так что вам больше не нужно отправлять библиотеку взаимодействия и вам не нужна PIA. И это намного меньше, так как вы платите только за те типы, которые действительно используете. Настоятельно рекомендуется это много бакса.

Answer 2

Я не особо много взаимодействовал, но я считаю, что:

• Иногда PIA может быть довольно большой;если само приложение довольно маленькое, PIA может затмить его
• Подход без PIA более гибок в отношении управления версиями: при условии, что вы используете только элементы, предоставленные версией COM-объекта, которая является на самом деле при условии, что вы в порядке ... тогда как я думаю, что с подходом PIA вам нужно использовать PIA для той же версии COM-объекта, что и на целевой машине

Answer 3

Одной из ключевых вещей, которые нужно понять в NoPIA, является то, что она не встраивает PIA в вашу сборку, а встраивает только часть PIA, которую использует ваше приложение.Он делает это очень мелкозернистым образом (вплоть до уровня метода).Результатом обычно является очень значительное уменьшение размера развертывания вашего приложения.