Как установить предпочтительный CLR неуправляемого приложения (<supportedRuntime>) во время выполнения? - PullRequest
Новая
       30

Как установить предпочтительный CLR неуправляемого приложения (<supportedRuntime>) во время выполнения?

1 голос
/ 13 июня 2019

У меня есть неуправляемое приложение (MSACCESS.EXE), которое динамически загружает различные сборки .NET (через COM-взаимодействие).

В настоящее время неуправляемое приложение автоматически инициализирует CLR .NET 2.0 при загрузке первой сборки. Поскольку я хочу перенести (некоторые из) сборок .NET на .NET Framework 4.x, я хочу, чтобы неуправляемое приложение вместо этого загружало .NET 4.0 CLR.

Хорошо известно, что это можно сделать, предоставив неуправляемому приложению следующий файл * .exe.config : 

<configuration>
  <startup useLegacyV2RuntimeActivationPolicy="true">
    <supportedRuntime version="v4.0.30319"/>
  </startup>
</configuration>

Это работает. Тем не менее, это требует создания изменяющей установки MS Office пользователя (путем создания файла в той же папке, что и msaccess.exe), чего я хотел бы избежать, потому что (а) это требует административных разрешений и (б) это потенциально влияет на другие и несвязанные приложения на основе доступа.

Таким образом, я хотел бы установить эту supportedRuntime конфигурацию на время выполнения , используя VBA и / или (более вероятно) вызовы API Windows.

Как изменить «настройку CLR» неуправляемого приложения во время выполнения?

Альтернативные решения, которые я попробовал и исключил:

1 Ответ

1 голос
/ 14 июня 2019

Материал <supportedRuntime> и useLegacyV2RuntimeActivationPolicy действительно необходим, только если у вас есть сборки смешанного режима (где по причинам обратной совместимости они не будут загружаться ни в чем, кроме CLR 2.0) или сборки 2.x, пытающиеся загрузить 4.x единиц.

Если у вас чисто управляемые сборки, то внутрипроцессное параллельное выполнение .NET 4 обеспечит возможность загрузки как CLR 2.x, так и CLR 4.x в одном и том же процессе, по мере необходимости сборки. Единственная реальная проблема, с которой вы можете столкнуться - это то, что сборка, загруженная во время выполнения 2.x, не сможет загрузить сборку 4.x; в этом случае вам все равно придется форсировать структуру 4.x через конфигурацию. Аналогично, совместное использование данных с помощью удаленного взаимодействия и доменов приложений не будет работать для компонентов, работающих в разных средах, хотя это довольно редкий сценарий.

...