Скомпилируйте независимую от версии DLL в .NET

Когда распознаватель сборок .NET не может найти сборку, на которую указывает ссылка, во время выполнения (в этом случае он не может найти конкретную версию DLL оболочки, с которой было связано приложение), его поведение по умолчанию - сбой и, по существу, сбой приложения. Однако это поведение можно изменить, подключив событие AppDomain.AssemblyResolve. Это событие запускается всякий раз, когда указанная сборка не может быть найдена, и дает вам возможность заменить отсутствующую сборку другой (при условии, что они совместимы). Так, например, вы можете заменить более старую версию DLL-оболочки, которую загружаете сами.

Лучший способ, который я нашел для этого, - добавить статический конструктор в основной класс приложения, которое перехватывает событие, например:

using System.Reflection;

static Program()
{
    AppDomain.CurrentDomain.AssemblyResolve += delegate(object sender, ResolveEventArgs e)
    {
        AssemblyName requestedName = new AssemblyName(e.Name);

        if (requestedName.Name == "Office11Wrapper")
        {
            // Put code here to load whatever version of the assembly you actually have

            return Assembly.LoadFile("Office11Wrapper.DLL");
        }
        else
        {
            return null;
        }
    }
}

Помещая это в статический конструктор основного класса приложения, он гарантированно запускается до того, как какой-либо код попытается получить доступ к чему-либо в DLL-оболочке, гарантируя, что ловушка будет на месте раньше времени.

Вы также можете использовать файлы политики для перенаправления версий, но это, как правило, более сложно.

Просто подумайте - можете ли вы использовать TlbExp для создания двух сборок взаимодействия (с разными именами и сборками) и использовать интерфейс / фабрику для кодирования двух через свой собственный интерфейс? Когда у вас есть interop dll, вам не нужна COM-зависимость (за исключением, конечно, тестирования и т. Д.).

TlbImp имеет / asmversion для версии, поэтому это можно сделать как часть сценария сборки; но я уверен, что вам это даже нужно: просто убедитесь, что "конкретная версия" неверна в ссылке (обозреватель решений)?

Также - я знаю, что это не помогает, но C # 4.0 с dynamic и / или «Без PIA» может здесь помочь (в будущем; возможно).

Я не уверен, что полностью следую всему, что вы сказали, но позвольте мне попробовать:

Похоже, у вас есть одно решение с 2 (?) Проектами. Одно - это собственное приложение, а другое - оболочка для Office API. Тогда ваше приложение будет иметь ссылку на проект вашей оболочки Office API. Я никогда раньше не занимался программированием для офиса, но похоже, что программные API-интерфейсы являются обычным компонентом, у вас может быть только одна версия на машине (например, 2003 или 2007, но не обе). И, возможно, здесь проблема, но поскольку у вас есть ссылка на проект, оболочка будет сначала скомпилирована, скопирована в каталог bin вашего приложения, где ваше приложение будет связано с этой сборкой оболочки. Это приведет к тому, что манифест приложения будет специально запрашивать эту версию оболочки во время выполнения.

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

Другой возможный выбор - перенаправление привязки сборки. Это более сложный вариант и имеет собственный набор проблем, но вы можете прочитать об этом здесь.

Или аналогично идее Марка, вы могли бы извлечь интерфейс и вытащить некоторые общие объекты в библиотеку Framework, а также закодировать свое приложение в соответствии с интерфейсом и общими объектами. Затем во время выполнения используйте отражение, чтобы загрузить сборку и создать экземпляр нужной оболочки.

Я думаю, что главное в том, чтобы по возможности удалить зависимость проекта. Похоже, оболочка довольно стабильна и не меняется, иначе вы бы не просили ссылку на ее предыдущую версию.

Параллельная установка Office 2003 и 2007 на одном компьютере определенно возможна - мы делаем это в нашей организации даже на рабочих станциях конечных пользователей.

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

Мое предположение может быть неверным, и вы пытаетесь сделать это для каждой машины разработчика. В таком случае игнорируйте этот ответ :-)

Хорошая розыск! Я просто собрал реализацию, основанную на концепции, представленной выше, и она прекрасно работает:

static Assembly domain_AssemblyResolve(object sender, ResolveEventArgs args)
{
     string partialName = args.Name.Substring(0, args.Name.IndexOf(','));
     return Assembly.Load(new AssemblyName(partialName));
}

Конечно, есть возможности для улучшения, но это помогает мне!