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

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

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

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

Пожалуйста, извините мое невежество, если таковые имеются.


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

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

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

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

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

3 ответа

Решение

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

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

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

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

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

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

Другие вопросы по тегам