Фунткоиды должны быть в GAC?

Я надеюсь, что кое-что упустил, но у меня проблема, для которой я не могу найти счастливую работу.Фунткоиды должны быть в GAC?

Я использую VSTS для своего решения CI. Каждая фиксация, приложения BizTalk извлекаются на выделенный сервер сборки, скомпилированы и выполняются модульные тесты.

Я не хочу, чтобы какая-либо из моих сборщиков решений BizTalk находила свой путь в GAC на сервере сборки, потому что Visual Studio будет компилироваться с ними, а не с проектами.

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

Functoid not found: guid (1d5de785-c639-4040-9704-c65a11127115) with functoid id (6003). Check if the assembly implementing this functoid is present in D:\Program Files (x86)\Microsoft BizTalk Server 2013 R2\Developer Tools\Mapper Extensions. If the functoid does not expose any inline code, make sure its assembly is made available in the GAC also

Таким образом, functoid сборка должна быть в GAC? Проблема в том, что ссылается на сборку common.components, что означает, что также нужно будет GAC'd, что возвращает меня обратно туда, где я не хочу! Это проблема, поскольку в следующий раз, когда агент сборки попытается создать проект со ссылкой на common.components, он будет использовать «старую» версию, которая, как правило, происходит в GAC, скорее, чем последняя версия, просто вытащенная из репо и сидел рядом с зависимым проектом в том же решении.

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

источник

2017-02-15 Rob Bowman

Я собираюсь сказать, что правильное решение обновить GAC, который является, где все связанные сборки BizTalk приложения должны всегда, вот как это работает. «кажется, что проекты BizTalk будут использовать эти, а не проектные ссылки», так как .Net решает сборки. Ничто не связано с BizTalk. –

Спасибо за ваш ответ @ Johns-305, я согласен, что разрешение сборки не связано с BizTalk (https://msdn.microsoft.com/en-us/library/yx7xezcf(v=vs.110).aspx).Тем не менее, функционалы, которые должны быть в GAC, являются причиной этой проблемы. Никаких пользовательских functoids, никаких проблем! Если common.components находятся в GAC, тогда «старая» версия будет ссылаться на сервере сборки каждый раз, когда commit запускает автоматическую сборку. Агент сборки получит последний код для common.components из удаленного репо, но зависимые проекты будут построены с использованием любой версии, находящейся в GAC. –

Извините, у меня все еще не проблема. Сборка должна обновить все необходимое. Значит, не должно быть «старых» версий чего-либо в GAC. Они также должны обновляться во время сборки, либо естественно, либо как конкретный шаг сборки. –

Благодаря @ Джонс-305 для ответа - я overthinking это!

Я добавил следующее в качестве события после сборки для проекта Common.Components:

"C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools\gacutil.exe" /i "$(TargetPath)"

источник

2017-02-23 14:20:36

я обычно поставить что-то вроде следующего в моих BizTalk проектов, связанных как шаг после сборки:

call "$(DevEnvDir)..\tools\vsvars32.bat" 
gacutil.exe /if "$(TargetPath)"

Я абсолютно уверен, что $(DevEnvDir) не разрешит на сервере сборки, хотя. Существует несколько работ - вы можете установить Windows SDK и установить правильный раздел реестра (например, здесь Running MSBuild fails to read SDKToolsPath), иначе вы могли бы установить среду, которая может быть изменена на сервере сборки, где есть путь к gacutil, или вы могли бы использовать что-то вроде сообщества задачи MSBuild (https://github.com/loresoft/msbuildtasks), который имеет задачу GacUtil, или, возможно, даже запустить Powershell скрипт вот так:

#Note that you should be running PowerShell as an Administrator 
[System.Reflection.Assembly]::Load("System.EnterpriseServices, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a")    
$publish = New-Object System.EnterpriseServices.Internal.Publish    
$publish.GacInstall("C:\Path\To\DLL.dll")

(от https://www.andrewcbancroft.com/2015/12/16/using-powershell-to-install-a-dll-into-the-gac/).

Обратите внимание, что процесс сборки должен запускаться с (локальными) правами администратора для успешной GAC-библиотеки.

Редактировать: Поскольку я столкнулся с этой проблемой локально, я использовал это, и он работает в любой среде, в которой я тестировал (независимо от того, какой Windows SDK установлен или администратор машины помещает его в C, D, или другой привод ...):

powershell -c "[System.Reflection.Assembly]::Load('System.EnterpriseServices, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'); $publish = New-Object System.EnterpriseServices.Internal.Publish; $publish.GacInstall('$(TargetPath)');"

источник

2017-02-18 22:17:31

Фунткоиды должны быть в GAC?

ответ

Смежные вопросы