2017-02-15 12 views
2

私はここで何か見落としたいと思っていますが、私は幸せな解決策を見つけることができない問題を打ちました。FunctoidはGACに存在する必要がありますか?

私はCIソリューションにVSTSを使用しています。それぞれのコミット、BizTalkアプリケーションは専用ビルドサーバーにフェッチされ、コンパイルされ、単体テストが実行されます。

ビジュアルスタジオはプロジェクト参照ではなくこれらを使用してコンパイルするため、私のBizTalkソリューションアセンブリはビルドサーバー上のGACにアクセスしたくありません。ビルドエージェントは、カスタムのFunctoidのプロジェクトが含まれているソリューションを構築しようとしたときに

問題が来る、私は次のエラーを取得する:

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である必要があることを意味します。これは、私が欲しくない場所に私を戻します!これは問題です。次回ビルドエージェントがcommon.componentsへの参照を含むプロジェクトを構築しようとすると、GACで起きている "古い"バージョンが使用されます。レポを作成し、同じソリューション内の依存プロジェクトと一緒に座っていました。

誰かが同じ問題にぶつかった場合は、私はあなたからのお話をお待ちしています。

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

私は$(DevEnvDir)はしかし、ビルドサーバー上で解決されないことをかなり確信している:

+0

私は正解がどこすべてのBizTalkアプリケーションに関連するアセンブリがすべきであるGACを、更新することであると言うつもりです:

私はCommon.Componentsプロジェクトのポストビルドイベントとして、以下を追加しました常にそうである、それはそれがいかに機能するかである。 「BizTalkプロジェクトは、プロジェクト参照ではなく、これらを使用しているようです.Netがアセンブリを解決する方法です。 BizTalkとはまったく関係がありません。 –

+0

@ Johns-305のお返事ありがとうございます。私は、アセンブリの解像度はBizTalk(https://msdn.microsoft.com/en-us/library/yx7xezcf(v=vs.110).aspx)とは何の関係もないことに同意します。しかし、GACに必要なFunctoidsがこの問題の原因です。いいえ、カスタムFunctoids、問題ありません! common.componentsがGACにある場合、コミットによって自動ビルドがトリガーされるたびに、ビルドサーバーで「古い」バージョンが参照されます。ビルドエージェントは、リモートのリポジトリからcommon.componentsの最新のコードを取得しますが、依存するプロジェクトはGACに存在するすべてのバージョンを使用してビルドされます。 –

+2

申し訳ありませんが、まだ問題は発生しません。ビルドで必要なものがすべて更新されるはずです。つまり、GACには古いバージョンのものはないはずです。ビルド時には、自然に、または特定のビルドステップとして更新する必要があります。 –

答えて

0

答えのための@ Johns-305のおかげで - 私はこの1つを思っていました!

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

は、私は通常、ビルド後のステップとして、私のBizTalk関連のプロジェクトでは、以下のようなものを置きます。いくつかの回避策があります.Windows SDKをインストールして適切なレジストリキー(ここではRunning MSBuild fails to read SDKToolsPathなど)を設定するか、gacutilへのパスを持つビルドサーバー上で環境を設定するだけです

#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/から)します。gacutilタスクを持っているか、おそらくそうであっても同様にPowerShellスクリプトを実行するMSBuildのコミュニティタスク(https://github.com/loresoft/msbuildtasks)のようなものを使用することができます。

正常に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)');" 
関連する問題