Исправление ошибки HRESULT 80004005 в сборках .vdproj CI/CD

Ошибка HRESULT ‘80004005’, с которой вы сталкиваетесь при сборке .vdproj MSI в CI/CD? Да, это довольно распространенная головная боль с проектами развертывания Visual Studio. Обычно она сводится к проблемам с разрешением зависимостей, проблемам с конфигурацией реестра или просто особенностям вашей конкретной среды сборки. Эта конкретная ошибка возникает на этапе проверки процесса сборки vdproj, и почти всегда она связана с отсутствующими зависимостями или несоответствиями между вашим сервером сборки и средой разработки.

Содержание

• Понимание ошибки HRESULT 80004005
• Распространенные причины этой ошибки в CI/CD
• Пошаговые решения
• Альтернативные подходы к сборке vdproj
• Предотвращение и лучшие практики
• Чек-лист для устранения неполадок

Понимание ошибки HRESULT 80004005

Итак, когда вы видите “Произошла ошибка при проверке” с HRESULT ‘80004005’, что на самом деле происходит, это то, что система проектов развертывания Visual Studio (.vdproj) не проходит проверку. Движок devenv.exe не может правильно проверить зависимости вашего проекта или конфигурацию, и выдает эту конкретную ошибку.

Судя по тому, что я видел на Stack Overflow (и поверьте мне, эта ошибка возникает часто), она особенно проблематична в средах CI/CD и на серверах сборки, где у вас нет полного опыта работы с Visual Studio IDE. Ошибка обычно возникает, когда:

• Зависимости, на которые ссылается ваш vdproj, просто недоступны в среде сборки
• Настройки реестра не правильно сконфигурированы для headless-сборок
• Процесс сборки сталкивается с проблемами с внешними зависимостями, такими как CEFSHARP
• Есть несоответствия между вашей рабочей станцией разработки и сервером сборки

Распространенные причины этой ошибки в CI/CD

Проблемы с разрешением зависимостей

Эти предупреждения о зависимостях CEFSHARP в вашем журнале ошибок? На самом деле, это довольно значимые подсказки. Когда devenv.exe пытается проверить ваш vdproj, он ищет все упомянутые сборки и зависимости. Если они недоступны в среде сборки, бум - проверка завершается ошибкой с HRESULT ‘80004005’.

Проблемы с конфигурацией реестра

Теперь, вы уже пытались использовать настройки реестра EnableOutOfProcBuild и DisableOutOfProcBuild, что хорошо. Но на самом деле есть еще несколько значений реестра, которые могут влиять на сборки vdproj в средах CI/CD. Эти настройки контролируют, как Visual Studio взаимодействует с компонентами COM и проверяет зависимости во время headless-сборок.

Несоответствия среды сборки

Самохостинговые раннеры могут не иметь точно такой же настройки, как ваша рабочая станция разработки. Отсутствующие компоненты Visual Studio, неверные версии SDK или недостаточные права доступа - любое из этого может способствовать возникновению этой ошибки.

Пошаговые решения

Решение 1: Убедитесь, что все зависимости доступны в среде сборки

Предупреждения о зависимостях CEFSHARP указывают на то, что ваша среда сборки не может найти требуемые сборки. Вот как это исправить:

1. Добавьте сборки CEFSHARP в ваш проект:

   powershell

   # В вашем рабочем процессе GitHub Actions убедитесь, что бинарные файлы CEFSHARP включены
   - name: Копирование зависимостей CEFSHARP
     run: |
       mkdir -p $(Build.ArtifactStagingDirectory)\lib\net472
       cp "C:\path\to\CEFSHARP\*.dll" $(Build.ArtifactStagingDirectory)\lib\net472\
   

2. Измените ваш vdproj, чтобы ссылаться на локальные зависимости вместо тех, что в GAC:

   xml

   <!-- В вашем файле vdproj измените это: -->
   <Dependency>
     <DependentAssembly 
       DependencyName="CEFSHARP" 
       DependentAssemblyQualifiedName="CefSharp.BrowserSubprocess.exe, Version=121.3.70.0, Culture=neutral, PublicKeyToken=40c4b6fc221f4138" 
       Codebase="file:///C:/Windows/assembly/GAC_MSIL/CEFSHARP/121.3.70.0__40c4b6fc221f4138/CefSharp.BrowserSubprocess.exe" />
   </Dependency>
   
   <!-- На это (с указанием на локальные файлы): -->
   <Dependency>
     <DependentAssembly 
       DependencyName="CEFSHARP" 
       DependentAssemblyQualifiedName="CefSharp.BrowserSubprocess.exe, Version=121.3.70.0, Culture=neutral, PublicKeyToken=40c4b6fc221f4138" 
       Codebase="file:///$(Build.ArtifactStagingDirectory)\lib\net472\CefSharp.BrowserSubprocess.exe" />
   </Dependency>
   

Решение 2: Дополнительные настройки реестра для VS 2022

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

# Модификации реестра для поддержки vdproj в Visual Studio 2022
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\SxS\VS7" /v "17.0" /t REG_SZ /d "C:\Program Files\Microsoft Visual Studio\2022\Community\" /f
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\SxS\VS7" /v "17.0" /t REG_SZ /d "C:\Program Files (x86)\Microsoft Visual Studio\2022\Community\" /f
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\Setup\VS" /v "17.0" /t REG_SZ /d "C:\Program Files\Microsoft Visual Studio\2022\Community\" /f

# Дополнительные настройки оптимизации сборки
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\14.0\Setup" /v "EnableOutOfProcBuild" /t REG_DWORD /d 0 /f
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\14.0\Setup" /v "DisableOutOfProcBuild" /t REG_DWORD /d 1 /f
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\14.0\Setup" /v "EnableOutOfProcMSBuild" /t REG_DWORD /d 0 /f

Решение 3: Оптимизация команды сборки devenv.com

Вы также можете изменить команду devenv.com, чтобы включить дополнительные параметры проверки и ведения журнала:

# Улучшенная команда devenv.com с лучшей обработкой ошибок
$devenv = "C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\IDE\devenv.com"
$config = "$Configuration|$Platform"
$logFile = "$(Build.ArtifactStagingDirectory)\BuildLog.txt"

& $devenv "$SolutionPath" /project "$SetupProjectPath" /build "$config" /out "$logFile" /ForceClean

# Проверьте файл журнала для получения подробной информации об ошибках
Get-Content "$logFile" | Write-Host

Альтернативные подходы к сборке vdproj

Переключение на WiX Toolset

Честно говоря, поскольку проекты vdproj устарели и продолжают вызывать проблемы в современных средах CI/CD, вам стоит рассмотреть возможность миграции на WiX Toolset:

<!-- Рабочий процесс GitHub Actions с использованием WiX -->
- name: Установка WiX
  run: choco install wixtoolset

- name: Сборка MSI с WiX
  run: |
    candle MySetup.wxs
    light MySetup.wixobj -out MySetup.msi

Использование Advanced Installer

Коммерческие инструменты, такие как Advanced Installer, предлагают гораздо лучшую интеграцию с CI/CD:

# Использование Advanced Installer в CI/CD
$advinst = "C:\Program Files (x86)\Caphyon\Advanced Installer 18.6\bin\x86\AdvancedInstaller.com"
& $advinst /build "MySetup.aip"

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

Или вы можете разработать скрипт PowerShell, который обрабатывает сборку vdproj с лучшей обработкой ошибок:

# Пользовательский скрипт сборки vdproj
function Build-VDProj {
    param(
        [string]$SolutionPath,
        [string]$ProjectName,
        [string]$Configuration,
        [string]$Platform
    )
    
    $devenv = "C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\IDE\devenv.com"
    $logPath = "$(Build.ArtifactStagingDirectory)\VDProjBuild.log"
    
    try {
        Write-Host "Сборка $ProjectName в конфигурации $Configuration|$Platform"
        & $devenv "$SolutionPath" /project "$ProjectName" /build "$Configuration|$Platform" /out "$logPath" /ForceClean
        
        if ($LASTEXITCODE -ne 0) {
            Write-Host "Сборка не удалась. Содержимое журнала:"
            Get-Content "$logPath" | Write-Host
            throw "Сборка vdproj не удалась с кодом выхода $LASTEXITCODE"
        }
        
        Write-Host "Сборка vdproj успешно завершена"
    }
    catch {
        Write-Host "Ошибка сборки vdproj: $_"
        throw
    }
}

Предотвращение и лучшие практики

Согласованность среды

Убедитесь, что ваш самохостинговый раннер имеет точно такую же среду, как ваша рабочая станция разработки:

# Рабочий процесс GitHub Actions с согласованностью среды
name: Сборка MSI
on: [push, pull_request]

jobs:
  build:
    runs-on: windows-latest
    env:
      VisualStudioVersion: 17.0
      MSBuildSDKsPath: C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Current\Bin\Sdk\
    
    steps:
    - uses: actions/checkout@v3
    
    - name: Настройка Visual Studio
      uses: microsoft/setup-msbuild@v1.1
      
    - name: Кэширование пакетов NuGet
      uses: actions/cache@v3
      with:
        path: ~/.nuget/packages
        key: ${{ runner.os }}-nuget-${{ hashFiles('**/*.csproj') }}
        
    - name: Восстановление зависимостей
      run: nuget restore MySolution.sln
      
    - name: Сборка решения
      run: msbuild MySolution.sln /p:Configuration=Release /p:Platform="Any CPU"
      
    - name: Сборка MSI
      run: |
        powershell -File build-msi.ps1

Управление зависимостями

Реализуйте правильное управление зависимостями в вашем конвейере CI/CD:

# Скрипт управления зависимостями
function Ensure-Dependencies {
    param(
        [string]$DependencyPath,
        [string]$TargetPath
    )
    
    # Создайте целевую директорию, если она не существует
    if (!(Test-Path $TargetPath)) {
        New-Item -ItemType Directory -Path $TargetPath | Out-Null
    }
    
    # Скопируйте все зависимости
    Copy-Item -Path "$DependencyPath\*" -Destination $TargetPath -Recurse -Force
    
    # Проверьте, что все требуемые файлы присутствуют
    $requiredFiles = @(
        "CefSharp.BrowserSubprocess.exe",
        "CefSharp.BrowserSubprocess.Core.dll",
        "CefSharp.Core.dll",
        "CefSharp.dll"
    )
    
    foreach ($file in $requiredFiles) {
        if (!(Test-Path "$TargetPath\$file")) {
            throw "Требуемый файл зависимости '$file' не найден в среде сборки"
        }
    }
}

Ведение журнала сборки и диагностика

Реализуйте комплексное ведение журнала для помощи в диагностике будущих проблем:

# Улучшенное ведение журнала сборки
function Invoke-VDProjBuildWithLogging {
    param(
        [string]$SolutionPath,
        [string]$ProjectName,
        [string]$Configuration,
        [string]$Platform
    )
    
    $timestamp = Get-Date -Format "yyyy-MM-dd HH:mm:ss"
    $logFile = "$(Build.ArtifactStagingDirectory)\VDProjBuild_$timestamp.log"
    
    Write-Host "Начало сборки VDProj в $timestamp"
    Write-Host "Решение: $SolutionPath"
    Write-Host "Проект: $ProjectName"
    Write-Host "Конфигурация: $Configuration"
    Write-Host "Платформа: $Platform"
    
    # Создайте подробный заголовок журнала
    @"
Журнал сборки VDProj
===================
Время: $timestamp
Решение: $SolutionPath
Проект: $ProjectName
Конфигурация: $Configuration
Платформа: $Platform
Среда: $env:COMPUTERNAME
Пользователь: $env:USERNAME
Версия Visual Studio: $((Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\VisualStudio\SxS\VS7" -Name "17.0")."17.0")
"@ | Out-File $logFile
    
    $devenv = "C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\IDE\devenv.com"
    
    try {
        # Выполните сборку с комплексным ведением журнала
        & $devenv "$SolutionPath" /project "$ProjectName" /build "$Configuration|$Platform" /out "$logFile" /ForceClean 2>&1 | Tee-Object -FilePath $logFile
        
        if ($LASTEXITCODE -ne 0) {
            Write-Host "Сборка не удалась. Код выхода: $LASTEXITCODE"
            Write-Host "Последние 50 строк журнала:"
            Get-Content $logFile | Select-Object -Last 50 | Write-Host
            throw "Сборка vdproj не удалась"
        }
        
        Write-Host "Сборка успешно завершена"
    }
    catch {
        Write-Host "Ошибка сборки: $_"
        throw
    }
}

Чек-лист для устранения неполадок

При работе с ошибками HRESULT ‘80004005’ следуйте этому систематическому подходу:

Немедленные проверки

• [ ] Убедитесь, что все зависимости CEFSHARP присутствуют в среде сборки
• [ ] Подтвердите, что настройки реестра правильные для Visual Studio 2022
• [ ] Убедитесь, что используется devenv.com, а не msbuild, для файлов vdproj
• [ ] Проверьте, что у пользователя сборки есть соответствующие права доступа

Проверка среды

• [ ] Сравните среду самохостингового раннера с рабочей станцией разработки
• [ ] Убедитесь, что компоненты Visual Studio полностью установлены
• [ ] Проверьте отсутствие пропущенных компонентов Windows SDK или .NET Framework
• [ ] Убедитесь, что все необходимые рабочие нагрузки Visual Studio установлены

Обзор процесса сборки

• [ ] Используйте подробное ведение журнала для точного определения точек ошибок
• [ ] Проверьте, что все ссылки на проекты правильные
• [ ] Проверьте наличие несоответствий версий в зависимостях
• [ ] Протестируйте процесс сборки вручную на самохостинговом раннере

Долгосрочные решения

• [ ] Рассмотрите возможность перехода с vdproj на WiX или Advanced Installer
• [ ] Реализуйте комплексное управление зависимостями
• [ ] Создайте стандартизированные скрипты сборки с обработкой ошибок
• [ ] Документируйте требования к среде сборки

Ошибка HRESULT ‘80004005’ при сборках vdproj в средах CI/CD обычно решается путем обеспечения доступности всех зависимостей, правильной настройки реестра и использования правильных инструментов сборки. Для долгосрочной стабильности рассмотрите возможность перехода на современные технологии развертывания, такие как WiX Toolset, которые предлагают лучшую интеграцию с CI/CD и постоянную поддержку Microsoft.

Заключение

Слушайте, ошибка HRESULT ‘80004005’ в вашем конвейере CI/CD в основном сводится к проблемам с проверкой зависимостей во время сборок vdproj. Чтобы исправить это, убедитесь, что все ваши зависимости CEFSHARP доступны в среде сборки, настройте правильные настройки реестра для Visual Studio 2022 и используйте devenv.com вместо msbuild для файлов vdproj. Честно говоря? Для более надежной интеграции с CI/CD вам стоит подумать о переходе на современные технологии развертывания, такие как WiX Toolset или Advanced Installer. Они предлагают гораздо лучшую поддержку для автоматизированных сборок и последующего обслуживания.

Источники

1. Stack Overflow - Почему я получаю “Произошла ошибка при проверке. HRESULT = ‘80004005’” при сборке проекта установки?
2. Stack Overflow - Сборка .vdproj с Visual Studio 2015 не создает выходные файлы (.msi)
3. Stack Overflow - Visual Studio 2013 и TFS Build 2015: Devenv.exe не может создать файл MSI
4. Zditect - Произошла ошибка при проверке HRESULT = ‘80004005’
5. Stack Overflow - HRESULT ‘8000000A’ в Visual Studio 2017 для проекта WPF
6. Stack Overflow - Сборка VSTS не создает файл .msi с использованием .vdproj