Aufruf einer WCF-Service-Methode mit einem Parameter aus einem dynamischen Objekt - 64bit Bug?
private ICalcService Service
{
get
{
if (_channel == null)
{
var serviceFactory = new ChannelFactory<ICalcService>(
new NetTcpBinding(), "net.tcp://localhost:54000");
_channel = serviceFactory.CreateChannel();
}
return _channel;
}
}
private void Good_Click(object sender, RoutedEventArgs e)
{
try
{
ICalcService service = this.Service;
int result = service.CalcHalf(16);
txtResult.Text += "Result: " + result;
}
catch (Exception ex)
{
txtResult.Text += ex.ToString();
}
}
private void Bad_Click(object sender, RoutedEventArgs e)
{
try
{
ICalcService service = this.Service;
dynamic dynArgs = new DynamicDictionary();
dynArgs.ID = 16;
txtResult.Text += "Parameter: " + dynArgs.ID;
int result = service.CalcHalf(dynArgs.ID);
txtResult.Text += "Result: " + result;
}
catch (Exception ex)
{
txtResult.Text += ex.ToString();
}
}
Programmablauf: Eine WPF-Applikation hostet ein Service in einem eigenen Thread. Das Service (ICalcService) hat 2 Methoden: CalcHalf(int) und Negative(bool). Das MainWindow hat 2 Buttons "Good" und "Bad". In den _Click-Methoden der Buttons wird ein Channel zum Service instanziert und dann die Methode CalcHalf aufgerufen. Die ganze Solution gibts hier zum downloaden: ProxyProblem.zip
Wenn man das auf einer 64bit Maschine (Win7) im VS2010 startet, funktionieren beiden Buttons ohne Probleme. Im TaskManager aber erkennt man, dass die App eigentlich als 32bit App gestartet wird. Startet man diese nun direkt (aus bin\Debug) sodass sie als 64bit-App läuft, funktioniert der Good-Button noch, beim Bad-Button aber friert die Applikation ein. CPU läuft hoch und Speicher wird ohne Ende verbraucht.
Ich habe dann festgestellt, dass der Aufruf CalcHalf mit dem Wert aus dem dynamischen Objekt nicht funktioniert (siehe Unterschied Good und Bad). Da hab ich mir also gedacht, das dynamic-Object kann für TryGetMember die Member-Infos nicht auflösen, da diese von einem TransparentProxy (WCFService) kommen. Ich hab also den Aufruf auf: service.CalcHalf(**(int)**dynArgs.ID); geändert. App als 64 bit starten: Funktioniert!
Ich hab da aber auch noch eine zweite Methode Negative(bool) die im 64bit Modus natürlich prima funktioniert wenn man Negative(true) oder Negative(false) oder Negative((bool)dynArgs.SomeBoolValue) aufruft.
Ich habe aber auch probiert Negative(dynArgs.ID == 16) aufzurufen, weil ich mir dachte, eigentlich sollte klar sein, dass da ein Bool kommen muss, hab aber übersehen, dass das Bool ja erst das Result ist, das dynamicObject also wieder nicht wirklich herausbekommen kann was es für einen Typ liefern soll (oder sollte es beim Vergleich mit 16 wissen, dass ein int gefordert ist?).
Dann habe ich folgenen CodeBlock eingebaut:
public bool MethodUsingBool(bool value)
{
return value;
}
...
var boolValue = MethodUsingBool(dynArgs.ID == 16);
bool result = service.Negative(boolValue);
Der Wert aus dem dynamicObject wird also schon ermittelt, bevor die Methode des Services aufgerufen wird, allerdings funktioniert der Aufruf immer noch nicht. Das Programm friert beim Aufruf der ServiceMethode wie vorher ein.
Ich hab dann mal
var boolValue = true;
bool result = service.Negative(boolValue);
probiert und das hat funktioniert.
Ich bin jetzt an einem Punkt angelangt, wo ich nicht mehr weiß, warum manches funktioniert und manches nicht. Zumal alles einwandfrei funktioniert, wenn man es als 32bit App ausführt.
Das ist ein Crosspost aus der MSDN, da aber keine Antworten gekommen sind, poste ich es hier auch nochmal in der Hoffnung hier hilfe zu bekommen: MSDN Eintrag
Hi,
klingt nach ner relativ seltenen Konstellation. Ich würde da eventuel mal per ILSpy oder Reflector nachschauen, welcher Code im Hintergrund daraus erzeugt wird. Vielleicht wirds dadurch klarer.
Sieht aber jetzt für mich auch eher nach einem Bug aus.
Gruß
Roland