Проблема с работой сборки политики.NET Publisher

Question

Я создал новые проекты для этого в качестве доказательства концепции, но я не могу заставить его работать.

Я создал ClassLibrary1.dll с простым методом, в версии 1.0.0.0. Я создал WindowsFormsApplication1, который вызывает этот метод, также в версии 1.0.0.0. Я создал соответствующие проекты установки для каждого решения и установил MSI. Пока все хорошо.

Затем я увеличил все номера версий ClassLibrary1 до 1.0.1.0. Я создал файл конфигурации для перенаправления на новую версию:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">

    <dependentAssembly>
        <assemblyIdentity name="ClassLibrary1" publicKeyToken="99e3abf647b4f724" culture="neutral" />
        <bindingRedirect oldVersion="1.0.0.0" newVersion="1.0.1.0"/>
      </dependentAssembly>

      </assemblyBinding>
  </runtime>
</configuration>

Я использовал это для создания политики издателя policy.1.0.ClassLibrary1.dll с помощью этой команды:

al /embed:ClassLibrary1.dll.config /out:Policy.1.0.ClassLibrary1.dll /keyfile:TestKey.snk /platform:anycpu /v:1.0.1.0

Я вставил это в GAC, как с помощью программы установки, так и вручную после установки DLL программой установки. Оба способа имеют одинаковый результат: gacutil /l policy.1.0.ClassLibrary1 возвращает один экземпляр политики в GAC, но при запуске программы не удается использовать новую версию.

C:\Program Files (x86)\Liberty Testing\ClassLibrary1>gacutil /l Policy.1.0.ClassLibrary1
Microsoft (R) .NET Global Assembly Cache Utility.  Version 4.0.30319.0
Copyright (c) Microsoft Corporation.  All rights reserved.

The Global Assembly Cache contains the following assemblies:
  Policy.1.0.ClassLibrary1, Version=1.0.1.0, Culture=neutral, PublicKeyToken=99e3abf647b4f724, processorArchitecture=MSIL

Number of items = 1

Однако я хотел бы отметить, что поиск в C:\Windows\Assembly вручную не показывает, что сборка политики существует где-либо в этом поддереве. Я удалил все библиотеки и переустановил только новую версию, и теперь программа вылетает вместо использования новой библиотеки DLL. Вывод fuslogvw выглядит следующим образом:

*** Assembly Binder Log Entry  (6/26/2017 @ 2:31:59 PM) ***

The operation failed.
Bind result: hr = 0x80070002. The system cannot find the file specified.

Assembly manager loaded from:  C:\Windows\Microsoft.NET\Framework64\v2.0.50727\mscorwks.dll
Running under executable  C:\Program Files (x86)\Liberty Testing\Test Form\WindowsFormsApplication1.exe
--- A detailed error log follows. 

=== Pre-bind state information ===
LOG: User = DOMAIN\user
LOG: DisplayName = ClassLibrary1, Version=1.0.0.0, Culture=neutral, PublicKeyToken=99e3abf647b4f724
 (Fully-specified)
LOG: Appbase = file:///C:/Program Files (x86)/Liberty Testing/Test Form/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = NULL
Calling assembly : WindowsFormsApplication1, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null.
===
LOG: This bind starts in default load context.
LOG: No application configuration file found.
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework64\v2.0.50727\config\machine.config.
LOG: Post-policy reference: ClassLibrary1, Version=1.0.0.0, Culture=neutral, PublicKeyToken=99e3abf647b4f724
LOG: The same bind was seen before, and was failed with hr = 0x80070002.
ERR: Unrecoverable error occurred during pre-download check (hr = 0x80070002).

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

Answer 1

Оказывается, проблема была в том, что мы запускали команду al.exe, когда рабочий каталог находился на подключенном диске.

У нас есть папки проекта Visual Studio на общем сетевом ресурсе, и мы настроили командную строку Visual Studio для использования pushd для автоматического сопоставления диска. В течение всего процесса не было ошибок, но конфигурация политики не была установлена ​​из-за диска карты.

Мы скопировали одну из папок локально и прошли через процесс с положительными результатами.

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

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

Создание сборки политики издателя для пользовательских библиотек