Ich habe einen handgeschriebenen WCF-Proxy in seiner eigenen Assembly, es ist sehr einfach:
%Vor%Ich lade dies in ein Powershell-Skript:
%Vor%Ich versuche dann, die App.config (nach ) zu setzen andere Posts zu SO), damit der Client mit einem Endpoint instanziiert werden kann, der in config und nicht im Skript selbst definiert ist:
%Vor% Ich habe die AppDomain überprüft und die Konfigurationsdatei wird als ConfigurationFile -Eigenschaft festgelegt.
Wenn ich eine Instanz des Clients erstelle:
%Vor%Es fällt um zu sagen:
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."
Irgendwelche Ideen? Ich möchte den Endpunkt nicht manuell in der Skriptdatei erstellen - er muss aus der Konfiguration gelesen werden.
Sind Ihre Baugruppen als 32-Bit- oder 64-Bit-Ziel erstellt?
Ich habe das 32/64 Problem in mehreren Fällen gefunden.
Seien Sie vorsichtig, wenn Sie ein 64-Bit-Betriebssystem verwenden, haben Sie zwei PowerShells mit 64 Bit (gewöhnlich) und 32 Bit (interessant, wenn Sie 32 externe Assemblys benötigen).
Es wäre einfacher, wenn Sie Ihre komplette Konfiguration gepostet hätten, aber es klingt, als ob Ihnen der folgende Abschnitt fehlt.
%Vor%Obwohl Sie ziemlich sicher klingen, ist das nicht der Fall.
Versuchen wir also, sicherzustellen, dass Ihre Powershell-App die Konfiguration korrekt aufnimmt ...
Um sicher zu sein, dass die Powershell-App die Konfiguration wie erwartet übernimmt, fügen Sie Ihrer Powershell-Datei so etwas hinzu:
%Vor%Wenn es dann kein Config-Problem ist, dann können wir uns meiner Meinung nach darauf einigen.
Also kann die dll die Einstellungen in der Config sehen? Inzwischen wissen wir, dass Powershell die Konfiguration sehen und Ihre DLL aufrufen kann.
Ist die Konfiguration am selben Ort wie die DLL?
Macht Add-Type etwas, was wir nicht erwarten? Mit Blick auf die msdn docs sieht es aus wie add-type
Fügt einer Windows PowerShell einen Microsoft .NET Framework-Typ (eine Klasse) hinzu Sitzung.
Wenn die Klasse jetzt in einer Powershell-Sitzung ist, hat sie Zugriff auf die Konfiguration, so wie sie es normalerweise tun würde? Ich weiß es nicht.
Vielleicht probiere [Reflection.Assembly]::LoadFrom eher und add-type , um zu sehen, ob das einen Unterschied macht?
Ich habe keine genaue Antwort, aber ich hoffe, dass mein Geschwafel etwas hilfreich ist.
Es scheint einen Unterschied in der Art und Weise zu geben, wie Powershell und Powershell ISE damit umgehen.
Mit ISE (mindestens die Version, die ich benutze) müssen Sie die Konfiguration löschen, um das Neuladen zu erzwingen. Allerdings könnten Sie den Inhalt Ihrer .dll.config-Datei auch in die Powershell-ISE-Konfiguration einfügen. Das scheint jedoch eklig zu sein. Der unten angegebene Code funktioniert. Ich habe Teile davon gefunden, die dieses Thema googlen.
%Vor% Ich würde vorschlagen, die Konfigurationsdatei alle zusammen zu überspringen, wenn möglich. Wenn Ihre API einen MEX- oder WSDL-Endpunkt bereitstellt, versuchen Sie, Ihre Proxies zu erstellen, indem Sie sie abfragen, und verwenden Sie WsdlImporter , um die Bindungskonfiguration im Speicher aufzubauen. Von diesem Zeitpunkt an können Sie es bei Bedarf im Speicher ändern.
Dies ist, was ich für das Projekt mache, an dem ich arbeite, das einen sehr großen Konfigurations-WCF-Dienst hat, weil es in einen Sicherheitstokendienst mit WS-Trust integriert ist.
Für eine ähnliche Frage habe ich vorgeschlagen, das WcfPS Modul in der Galerie verfügbar. Da es eine Überschneidung mit der anderen Frage gibt, werde ich einen Teil davon zitieren.
Der Code für das Modul ist Open Source und obwohl es im Skript ist, hängt es stark von .net Framework Klassen und Assemblies ab
System.ServiceModelundSystem.IdentityModelBaugruppen. Ich erwähne dies, weil die meisten Apis in diesen Assemblys nicht von .NET Standard 2 verfügbar sind, so dass das Modul leider nicht mit Windows-Betriebssystemen funktioniert. Sie können auch mehr darüber in meinem Beitrag WCFPS - PowerShell-Modul lesen, um mit SOAP zu arbeiten Endpunkte .
Dies ist das Beispiel aus der README
%Vor%Mit dieser Methode benötigen Sie keinen Import von Inline-.NET-Typen, weder die Proxies, die Sie in Visual Studio verwenden, noch eine Konfiguration. Wahrscheinlich müssen Sie es an Ihren Anwendungsfall anpassen. Wenn Sie die Funktionalität des Moduls verbessern können, senden Sie bitte eine Pull-Anfrage.
Tags und Links wcf .net c# powershell configuration-files