設定ファイルでPowershellスクリプトでカスタムWCFプロキシを使用するには？

Question

私はそれ自身のアセンブリ内の手書きWCFプロキシを持っているが、それは非常に簡単です：

public class MyServiceClient : ClientBase<IMyService>, IMyService 
{ 
    public MyServiceClient() 
    { 
    } 

    public MyServiceClient(string endpointConfigurationName) : 
     base(endpointConfigurationName) 
    { 
    } 
} 

私はPowerShellスクリプトにこれをロードしています：私は、アプリケーションを設定しようとしています

Add-Type -Path "$LocalPath\MyService.Client.dll" 
Add-Type -Path "$LocalPath\MyService.Contracts.dll" 

.configをクライアントではなくスクリプト自体よりも、設定に定義されたエンドポイントでインスタンス化することができるように、（SOにother postsの通り）：

[System.AppDomain]::CurrentDomain.SetData("APP_CONFIG_FILE", "$LocalPath\MyService.Client.dll.config") 

I AppDomainをチェックし、設定ファイルがConfigurationFileプロパティとして設定されている。

私はクライアントのインスタンスを作成します。

Exception calling ".ctor" with "1" argument(s): "Could not find endpoint element with name 'MyServiceHttpEndpoint' and contract 'MyService.Contracts.IMyService' in the ServiceModel client configuration section. This might be because no configuration file was found for your application, or because no endpoint element matching this name could be found in the client element."

任意のアイデア：

$endpointName = "MyServiceHttpEndpoint" # defined in the app.config file 
$myclient = New-Object MyService.Client.MyServiceClient($endpointName) 

それは言って転倒しますか？スクリプトファイルに手動でエンドポイントを作成する必要はありません。configから読み込む必要があります。

Answer 1

アセンブリは32ビットまたは64ビットのターゲットとして構築されていますか？

私は32/64の問題を複数のケースで満たしました。

64ビットOSで実行している場合は、64ビット（通常）と32ビット（32個の外部アセンブリが必要なときにinterresting）の2つのPowerShellがあることに注意してください。

Answer 2

完全な設定を投稿した方が簡単ですが、次のセクションが欠落しているように見えます。

<system.serviceModel> 
    <bindings> 
     <basicHttpBinding> 
     <binding name="BasicHttpBinding"> 
      <security mode="TransportCredentialOnly"> 
      <transport clientCredentialType="Windows" /> 
      </security> 
     </binding> 
     </basicHttpBinding> 
    </bindings> 
    <client> 
     <endpoint address="ServiceAddress" 
     binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding" 
     contract="MyService.Contracts.IMyService" name="MyServiceHttpEndpoint" /> 
    </client> 
</system.serviceModel> 

あなたはそうではないと確信していますが、

だからあなたPowerShellのファイルに次のようなものを追加し、予想通りのPowerShellアプリは設定を拾っている場合

は確かに...試してみて、あなたのPowerShellのアプリが正しく設定を拾っていることを確認してくださいすることができます：

Get-Content $LocalPath\MyService.Client.dll.config | foreach {Write-Output $_} 

これは設定に問題がなければ、私はそれに同意すると思います。

dllはconfigの設定を見ることができますか？これまでPowerShellはconfigを見ることができ、dllを呼び出すことができることを知っています。

configはdllと同じ場所にありますか？

add-typeは期待していないことをしますか？ msdnドキュメントを見ると、追加タイプのように見えます。

Windows PowerShell セッションにMicrosoft .NET Frameworkタイプ（クラス）を追加します。

クラスが現在powershellセッションに入っている場合、通常どおりに設定にアクセスできますか？知りません。

[Reflection.Assembly]::LoadFromではなく、add-typeを試してみてください。

私は正確な答えがありません私は恐れていますが、私の話題はやや役立ちます。

Answer 3

あなたはバインディングのタイプが欠落しているようにあなたは、PowerShellの

にあるとき、それはあなたのコードを作るbasicHttpBindingしなければならないようだように見える：ところでそのPowerShellの違いがあるようです

$endpointName = "MyServiceHttpEndpoint" 
$httpBinding = new-object System.ServiceModel.WSHttpBinding 
$myclient = New-Object MyService.Client.MyServiceClient($httpBinding, $endpointName) 

Answer 4

Powershell ISEがこれを処理します。

ISE（少なくとも私が使用しているバージョン）では、強制的にリロードするように設定をクリアする必要があります。ただし、.dll.configファイルの内容をpowershell ISE configに入れることもできます。しかし、それは厄介なようです。以下のコードは動作します。私はこの問題を抱えている部分を見つけました。

# $dllPath is the path to the dll we want to load 
# first point to the correct config file 
[System.AppDomain]::CurrentDomain.SetData("APP_CONFIG_FILE", "$dllPath.config") 

# PowerShell ISE is a PITA we have to override the config 
if ($psISE -ne $null) { 
    Add-Type -AssemblyName System.Configuration 
    [Configuration.ConfigurationManager].GetField("s_initState", "NonPublic, Static").SetValue($null,0) 
    [Configuration.ConfigurationManager].GetField("s_configSystem", "NonPublic, Static").SetValue($null,$null) 
    ([Configuration.ConfigurationManager].Assembly.GetTypes() | where {$_.FullName -eq "System.Configuration.ClientConfigPaths"})[0].GetField("s_current", "NonPublic, Static").SetValue($null, $null) 
} 

#Now load the DLL 
$null = [Reflection.Assembly]::LoadFrom($dllPath) 

# DLL and Config should be loaded - test 

Answer 5

可能であれば、設定ファイルをすべてスキップすることをお勧めします。あなたのAPIがMEXまたはWSDLエンドポイントを提供している場合は、それらを照会してプロキシーを作成し、WsdlImporterを使用してメモリー内のバインディング構成を構築してください。その時点から、必要に応じてメモリ内で修正することができます。

これは、私が作業しているプロジェクトでは、WS-Trustを使用するセキュリティトークンサービスと統合されているため、構成WCFサービスに関して非常に重いものです。

question私は、WcfPSモジュールをギャラリーで使用してみることをお勧めしました。他の質問と重複があるので、私はその一部を引用します。

モジュールのcodeは、オープンソースであり、そのスクリプトではSystem.ServiceModelとSystem.IdentityModelアセンブリから.NETフレームワーククラスおよびアセンブリに大きく依存しません。私は、これらのアセンブリ内のapiのほとんどが.NET標準2から利用できないため、このモジュールを言います。そのため、モジュールは残念なことにWindows以外のオペレーティングシステムでは動作しません。あなたは私のポストWCFPS - PowerShell module to work with SOAP endpointsでそれについてさらに読むことができます。

これは、あなたがVisual Studioと設定なしで使用プロキシでもない、インライン.NET型のいずれかの輸入を必要としないこの方法でREADME

#region Initialize the channel/client 
$svcEndpoint="http://myserviceprovider/Service1.svc" 

$wsImporter=New-WcfWsdlImporter -Endpoint $svcEndpoint -HttpGet 
$proxyType=$wsImporter | New-WcfProxyType 

# select the endpoint and implicitly the binding from the imported configuration 
$endpoint=$wsImporter | New-WcfServiceEndpoint -Endpoint $svcEndpoint 
$channel=New-WcfChannel -Endpoint $endpoint -ProxyType $proxyType 
#endregion 

#region Use the channel/client 
$channel.Method1() 
$channel.Method2() 
#endregion 

の例です。ほとんどの場合、ユースケースに合わせて調整する必要があります。モジュールの機能を改善できる場合は、プルリクエストを提出してください。