Trenn mal die version von Data Source in deinen Connection string mit einem Semikolon ab, sonst denkt er doch dass version Teil des Pfades ist. Wahrscheinlich Schreibfehler in deiner Doku.
Numax schrieb:
Ich habe das grade mal probiert die EndpointAdress auszutauschen, jedoch funktioniert das auch nicht.
Also so wie ich das sehe werden die Daten von der MainPage.xaml.cs nich an den WebService übermittelt bzw. nicht das Signal zum Senden gegeben.
Das siehst du vermutlich richtig. Probleme im Binding sorgen dafür, dass dein WebService für deine Silverlight-Anwendung unerreichbar bleibt. Deshalb gehen alle weiterführenden Anweisungen ins Leere. Aber ohne das vollständige Projekt sind Fehlersuche / -behebung zum Scheitern verurteilt ...
Zur 1. Frage: Direkt von .Net, soweit ich weiss, nicht. Man könnte diese rekursive Funktion allerdings in eine Extension-Method reinsetzen und somit indirekt DirectoryInfo damit erweitern.
Zur 2. Frage: Meinst du den Output umleiten? Sowas geht definitiv. In Process muss man StartInfo setzen, dass ist ja ein ProcessStartInfo Typ. In ProcessStartInfo gibt es die Property RedirectStandardOutput . Dies auf true setzen und man kann in Process StandardOutput verwenden.
Ähnlich funktioniert dies auch für StandardError und StandardInput .
Grüssli
Grundregel:
Wenn man mit Technologie X arbeitet und diese noch nicht kennt, dann RTFM.
Konkret: wenn man mit Assemblies arbeitet schaut man mal auf die Übersucht zum Thema Assemblies und liest die Teile, die man noch nicht kennt:
http://msdn.microsoft.com/en-us/library/hk5f40ct.aspx
Und siehe da, gleich auf der Hauptseite zu Assemblies ist die Rede vom GAC:
http://msdn.microsoft.com/en-us/library/yf1d93sz.aspx
Hallo,
ich holpere und stolpere in den WCF Services. Mit einer Sache komme ich nicht klar, und zwar habe ich ein Testprogram als Konsolenanwendung und ich muß programmatisch WCF Services erstellen. Soweit habe ich das irgendwie hinbekommen und mein Testprogramm als Client kann einen WCF Testservie ansprechen. So weit so gut.
Nun muss ich diesem Testservice andere Credentials übergeben. Zur Zeit kriegt er naemlich immer meine, weil ich auch das Testprogramm (Client) starte. Aber wie?
Es muss programmatisch sein, also Editieren von config-Dateien etc. fällt grundsätzlich aus (auch wenn das besser ist, es geht eben nicht).
Probiert habe ich das:
WCF_WeatherClient = new SvcWeather.WeatherClient(binding, address);
WCF_WeatherClient.ChannelFactory.Credentials.Windows.AllowedImpersonationLevel = TokenImpersonationLevel.Impersonation;
WCF_WeatherClient.ChannelFactory.Credentials.Windows.AllowNtlm = true;
WCF_WeatherClient.ChannelFactory.Credentials.UserName.UserName = "DEV\testadmin";
WCF_WeatherClient.ChannelFactory.Credentials.UserName.Password = "pw1234!";
Ergebnis: klappt nicht, die zugewiesenen Credentials haben überhaupt keine Wirkung. Der Fehler liegt auf jeden Fall bei mir, aber wo? Um ehrlich zu sein verstehe ich nur Bahnhof , es handelt sich um Code aus dem MSDN. Und ich dachte mir, wenn ich mit "try and error" an die Sache rangehe, wird das schon.
Danke für jeden helfenden Tip!
Hehe da haben sie es sich relativ einfach gemacht.
Wie folgt sieht die neue Funktion aus:
public StringBuilder Clear()
{
this.Length = 0;
return this;
}
Also wie erwartet.
hustbaer schrieb:
Du kannst dir ein eigenes Attribut implementieren, und das hängst du dann an alle abgeleiteten Klassen dran.
Darin kannst du die Daten hinterlegen die die Manager/Factory Klasse braucht um zu wissen was sie machen soll.
ähnlich wie hier - http://x8bit.de/index.php?option=com_content&view=article&id=70&Itemid=79&lang=de
Und was das EventArgs Beispiel angeht...
Einen Anfänger hätte es hier vermutlich auch nicht gerettet, wenn er auf Optimierungen verzichtet hätte, denn der IMO naivste Weg sowas zu machen ist:
class Foo
{
void MyThread()
{
while (...)
{
// do some stuff, modify m_list and/or the objects referenced in it
do_some_stuff();
something.BeginInvoke(new SomeDelegate(Target), new SomeEventArgs(m_list));
}
}
List<Stuff> m_list;
}
class SomeEventArgs
{
public SomeEventArgs(List<Stuff> list)
{
List = list; // just referencing the list, no copy!
}
public List<Stuff> List;
}
Das fliegt dir dann genauso um die Ohren.
Damit es nicht knallt, muss man die Liste kopieren, und u.U. sogar die darin referenzierten Objekte.
Das Erstellen des Delegate kann man dagegen problemlos in den ctor verlagen, denn den Delegate ändert man ja nicht mehr (kann man auch gar nicht, da .NET Delegates genauso wie .NET Strings immutable sind).
BTW: du meinst vermutlich Control.BeginInvoke. Control.Invoke ist synchron
Vor dem selben Problem stand ich auch mal. Was in meinen Augen ein Problem darstellen könnte ist folgendes: Die SystemsEvents Klasse hat ein Event das heißt
EventsThreadShutdown. Diese Event beendet den Thread der auf alle Events lauscht. Es kann sein das dieses Event VOR den anderen beiden Events fliegt, somit kann man auf die gar nicht mehr reagieren, aber das ist nur eine Theorie, ausprobiert habe ich das nicht, jedoch kann ich mir das aufgrund des Verhaltens gut vorstellen.
Achso daran habe ich jetzt gar nicht gedacht:D
Grundsätzlich gilt, wenn du in einem Thread ein Control erzeugst kann auch nur in diesem Thread damit gearbeitet werden. An deiner Stelle würde ich die Listview über den UI Thread erzeugen lassen und das anzeigen deiner Progressbar über einen anderen Thread machen, über BeginInvoke kannst du dann der GUI kurz zwischendurch immer nochmal eine Anzeige rüberschieben sozusagen.
