Forenbeiträge von svenson Ingesamt 8.746 Beiträge
Was sagt mir die Meldung: "Transaktionen mit IsolationLevel-Snapshot können nicht erweitert werden"?
Transaktionen gehören eben auch in den DAL.
Vielleicht wird dir diese Diskussion helfen:
Oder sowas um die Connection durchzuschleppen:
http://blogs.msdn.com/dataaccess/archive/2006/02/14/532026.aspx
Um bei deinem Debug-Beispiel zu bleiben. Ein C-Coder würde dir antworten: "Geht gar nicht" und mit #ifdef um sich werfen.
Aber das sind eben Entscheidungen zur Compile-Time. Da gibt es in C# auch #if-Anweisungen, oder optional das ConditionalAttribute.
Was heisst bei dir "Port geschlossen"? Und wer schließt?
Grundsätzlich bietet TCP ein Protokoll zum (regulären) Abbau der Verbindung. Wenn aber das Protokoll nicht ausgeführt werden kann, z.B. weil jemand den Stecker gezogen hat, dann erkennt der Sender das erst während des Sendens (weil die ACK-Pakete ausbleiben). Beim Empfänger ist es noch kritischer. Hier hilft dann nur das KeepAlive-Protokoll. Aber die Keep-Alive-Timeouts sind i.d.R. so hoch, dass sie nicht sinnvoll verwendet werden können. Der sichere Weg für eine Abbruch-Erkennung ist daher der anwendungsgesteuerte Timeout. Dazu muss man natürlich die Annahme treffen können, dass Verkehr in einem Zeitraum verbindlich ist. Ggf. muss man dafür halt einen eigenes "Hallo, bin noch dran" implementieren.
In besagtem Artikel steht doch noch ganz unten das:
After 3 hours of searching everywhere i realized that I had to add the following to the web config the following besides the fact i am not using the scriptmanager or what ever its name is!!!!!! But it is so obvious...not!!!!
<httpHandlers>
<remove verb="" path=".asmx"/>
<add verb="" path=".asmx" type="System.Web.Script.Services.ScriptHandlerFactory" validate="false"/>
</httpHandlers>
Ausprobiert?
Du kannst auch einfach einen Windows-Mobile-Emulator nehmen. Sofern du keine Features von WM einsetzt und auf deinem Device keine speziellen Funktionen hattest, dann benutzt du ja die gleichen CE-Module. Solltest natürlich darauf achten, dass es die gleiche CE-Basis hat, also ein 5.x bzw. 6.x.
WCF ist NICHT objektorientiert. Von DataContracts werden immer nur die Daten, niemals Methoden zur Verfügung gestellt. WCF!= Remoting.
Oder, dass er das intern mittels memcpy() ausführt....
Das wäre auch eine gute Idee, danke. Aber ich würde auch gerne es mal per Hand versuchen.
Dir ist schon klar, dass du das gesamte FTP-Protokol per Hand implementieren musst. Manche Leute backen sich auch die Steine selbst, aus denen sie ihr Haus bauen wollen...
Ich versuche mich gerade daran eine **Telnet **Verbindung zu implementieren :
Du meinst FTP...
Wie wärs, wenn du einfach eine vorhandene FTP-Implementierung um deine Spezialkommandos erweiterst:
NetTCPBinding macht Duplex über einen Socket. Der Callback ist damit problemlos.
Das ein SysAdmin einen Port auf der Firewall öffnen um eine Applikation kommunizieren zu lassne ist meienr Meinung nach ein vertretbarer aufwand.
Die Widerstände seitens der Sysadmins sind i.d.R. nicht durch Aufwand, sondern durch Sicherheit motiviert. Und da heisst es eben schnell: HTTP only.
Das gilt für Client wie für die Server-Seite. Beim Client kriegt man am ehesten noch eine Portfreigabe. Auf der Serverseite wirds bei großen Unternehmen fast unmöglich, weil die i.d.R. eine ziemlich heftige Security-Policy haben. Ich kann dir nur raten, dir vorab beim Kunden die entsprechende Zusage für TCP-Verkehr über einen dezidierten Port **schriftlich **geben zu lassen. Oftmals werden nämlich die IT-Abteilungen erst konsultiert, wenn die Anwendung fertig ist. Und wenn da die ganze Architektur auf Callbacks angewiesen ist, dann ist das Geschrei groß. bei einem Produkt sollte dir klar sein, dass du ggf. auf Kunden verzichten mußt, dessen Sicherheitsanforderungen du dann eben nicht erfüllst. Aber: Bei den Kunden mit den heftigen Sicherheitsanforderungen kommt man mit .NET-Servern sowieso nicht an den Start. Ohne J2EE-Stempel kommt da nix ins Netzwerk.
http://codeidol.com/csharp/wcf/Operations/Callback-Operations/
TCP ist nicht paketorientiert.
Wenn du einen Socket aufmachst, dann musst du dich überhaupt nicht um die Adapter kümmern, denn das Routing macht das Betriebssystem. Es wählt anhand der Subnet-Masken der Adapter den Weg automatisch. Wenn es keinen passenden Adapter findet, dann schickt es das IP-Paket an den erstbesten Adapter mit einem Gateway. Anders forumuliert: Aus Anwendungssicht gibt es für dich nur EIN großes Netzwerk.
Falls es darum geht, die Bits in Symbole (Wörter) zu übersetzen, dann bieten sich Enums statt Konstanten an. Dank Enum.GetValues() kann man dann auch schöne Bit-Schleifen produzieren, die ein wenig "sprechender" sind als Schleifen mit Shifts.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace EnumTest
{
class Program
{
[Flags]
public enum Bit : byte
{
Eins = 0x1,
Zwei = 0x2,
Vier = 0x4,
Acht = 0x8
// usw.
}
static void Main(string[] args)
{
Output1();
Output2();
Console.ReadLine();
}
private static void Output1()
{
Console.WriteLine("Folgende Bits sind gesetzt: " + ((Bit)5).ToString());
}
private static void Output2()
{
CheckAllBits(5);
}
public static bool CheckBit(byte val, Bit b)
{
return ((Bit)val & b) != 0;
}
public static void CheckAllBits(byte val)
{
foreach (Bit b in Enum.GetValues(typeof(Bit)))
{
if (CheckBit(val, b))
{
Console.WriteLine(string.Format("Bit {0} gesetzt", b));
}
}
}
}
}
Ich dürfte auch mal einen Hardware-Prüfstand enwickeln. Dazu habe ich mir einfach NUnit geschnappt und ein wenig aufgebohrt um auch manuelle Prüfaktionen (Nutzer drückt irgendwas und Prüfhardware testet das Ergebnis, bzw. Nutzer prüft bestimmte durch die Prüfhardware ausgelöst Aktionen (Lampe geht an) ).
Ob das für deinen Fall auch eine gute Lösung ist, sei mal dahingestellt, aber in jedem Fall ist es sehr lehrreich sich in die Architektur von NUnit einzuarbeiten, weil dort viele der genannten Muster (und einige mehr) beispielhaft umgesetzt sind. Auch wenn du Nunit dann nicht als Basis wählst wirst du viele Ideen in deine eigene Implementierung mitnehmen.
Allerdings war die wirkliche Herausforderung eher das Datenmodell für die Datenbank, die ja nicht nur die Prüfvorschriften, sondern auch die Ergebnisse und Geräte- bzw. Teileinformationen enthalten mußte. In diesem Fall war die der Prüfstand zugleich auch Teil eines Baustandserfassungssystems.
http://dev.mainsoft.com/Default.aspx?tabid=130
Oder halt eine Mono Anwendungen gehostet im Apache.
Gute Antwort, falsche Frage. Die Kosten einer IF-Anweisung sind sicher gering, die Kosten des zu prüfenden **Ausdrucks **könnens immens sein.
Klar, IF-Anweisungen sind notwendig, aber manchmal denkt man über zusätzliche, u.U. nicht notwendige IF-Anweisungen nach, mit denen man **irgendetwas **bezwecken will.
Wenn man anfängt sich über Optimierungen auf Befehlsebene Gedanken zu machen, sollte man sich zuerst fragen:
- Weiss ich genau was ich tun will?
- Haben die gewählten Verfahren/Algorithmen die zum Nutzungsprofile (CRUD) passenden Aufwände?
"U.U. nicht notwendig" und "irgendetwas" lassen doch stark vermuten, dass schon 1. nicht erfüllt ist.
Kann ich mit IF-Anweisungen nur so um mich werfen ( Augenzwinkern wahrscheinlich nicht) oder sollte ich die mit Bedacht einsetzen (in Bezug auf die langen Durchläufe)?
Man sollte grundsätzlich keine Zeile mehr Code schreiben, als für die Erfüllung der Aufgabe notwendig ist. Die Frage ist nur: Was ist die Aufgabe?
Google mal nach "obex ftp".
Na halt immer schön per "ref" übergeben. Erzwingen kannst du da aber nix. In C++ auch nicht, den du kannst ja den Pointer ja auch dereferenzieren und dann weiter übergeben.
Google doch einfach mal nach "WCF callback". Da gibts ohne Ende Beispiele. Es sei aber gesagt, dass all das i.d.R. ohne weiteres nur im Intranet funktioniert.
Die WSDL wird bei Compilation des Servers erzeugt. Die (+ die zugehörigen XSDs) kannst du verwenden um svcutil zu füttern.
Warum generierst du den Proxy nicht einfach aus dem WSDL? Bei .NET ist es leider recht schwierig Server aus dem WSDL zu generieren, aber Client ist doch kein Problem. scvutil.exe hat extra eine Option um eine WSDL-Datei anzugeben.
Ja Intranet schön und und gut, aber wenn ich eh Peer-To-Peer-Bedingung wie im Intranet habe, liegt meine Verständnisschwierigkeit darin, warum man auf das aufgeblähte HTTP statt auf das performate net.tcp setzten sollte.
Im professionellen Umfeld sieht es doch so aus:
- Du hast nur HTTP. Alle anderen Ports sind dicht.
- Firewall/NAT
- Gegenseite hat dann Mehrfach-Firewalls/NAT/Proxies
Mit P2P-Techniken wie Hole-Punching brauchst du gar nicht erst losgehen. Die hängen dich schon am Eingang der IT-Abteilung auf. Darauf kannst du keine Geschäftsanwendung aufsetzen, selbst wenn es funktionieren würde. Azure versucht ja ähnliches mit der Cloud, aber hier ist der Relay angeblich "vertrauenswürdig". Mal sehen wie das die Admins sehen. 😃
Aber auch die neuen Azure-Relay-Bindings sind im Prinzip nur die alten, aber diesmal vermittelt. Für private Geschichten sind Azure-Dienste hingegen ok, also wenn einfach nur zwei NATs den Fullduplex-Verkehr verhindern, aber die Ports prinzipiell frei sind.
Hast du damit schon gearbeitet ?, oder ist die ganze Sache noch zu Beta-lastig ?
Ist es keine Frage. Aber es gibt ja praktisch nichts anderes für echtes Fullduplex im Internet. Entweder alles per Hand oder wenigstens nur das Binding und dann ein halbwegs stabilen Service Bus drüber. Ich versuche gerade einen NServices-Klon auf das CF zu portieren um darauf eine mobile Fullduplex-Anwendung draufzusetzen. Frag mich nochmal in ein paar Monaten, ob das eine gute Idee war. 😉
Hätte ich ein großes Framework mit WCF würde ich wohl den .NET Service Bus mit PollingDuplex verwenden.
Wie schon gesagt: Intranet.
Ansonsten schau mal hier:
http://tomasz.janczuk.org/2009/07/pubsub-sample-using-http-polling-duplex.html
http://tomasz.janczuk.org/2009/09/scale-out-of-silverlight-http-polling.html
Damit hat man dann wenigstens Pub/Sub. Leider wird es ein wenig unschön, wenn man über diese Kanäle dann auch noch Request-Response machen will - in beide Richtungen.
Hier sollte man dann einen Service-Bus einsetzen...
Aber: Interoperabilität sollte man nicht erwarten
Kurz gesagt: Das bringt nur was im Intranet. Im Internet sind diese Bindings nicht einsetzbar, bzw. im professionellen Umfeld wird man das nicht an den Start bekommen.
Es gibt bisher auch keine offiziellen Bindungen für SOAP, die z.B. mittels LongPolling arbeiten. Mit Silverlight ist PollingDuplexBinding gekommen, aber das wird zu 100% nicht mit Java-COMET zusammenspielen.
Meine Vermutung: Alles wartet auf HTML5 und Websockets und dann werden die DMZ-Admins ihr schöne Port80-Welt aufgeben müssen.
Alternativ: Baue dir ein VPN.
Mtom scheint hier schon richtig zu sein. Was "funktioniert" denn in diesem Fall nicht?
Wie prüfen die eigentlich den Upgrade? Läuft das über die Registrierung bei MS? Muss ich den alten XP-Registrierungscode bei der Upgrade-Registrierung von Windows 7 angeben?
Wenn die 3 Sticks alle auf dem gleichen Chipsatz basieren, dann wäre der Treiber immer noch die Hauptvermutung...
Weil das Cross-Process ist, brauchst du einen Named-Mutex. Und den gibts nicht im CF.
Gibts die Exception nur beim Lauf mit dem Debugger?
Ich würde mal versuchen einen weiteren Thread zu starten und zuvor den richtigen Apartement-State via SetApartementState() zu setzen. Dort dann die Clipboard-Funktionen ausführen. Unsafe Code brauchst du nicht.
Ngen iinstalliert direkt in den GAC. Zudem: Die Original-Assemblies müssen verfügbar bleiben, um der CLR Zugriff auf die Meta-Daten zu gestatten. Insofern scheidet mein Vorschlag sowieso aus:
Mit einem Satz gesagt: xsd.exe ist ein rottes Mist-Tool. Irgendjemand bei M$ gehört dafür aufgehängt, dass sie es wagen die Community mit dieser Grottenimplementierung zu belästigen - und das nun über Jahre.
Nimm das, damit klappt es:
http://www.codeplex.com/Xsd2Code/Wiki/View.aspx?title=Home
Konkret klappt in deinem Fall der Schema-Import von Xlink nur bedingt. Da werden referenzierte Typen mal erkannt, mal nicht. Xsd.exe ist schlicht total buggy. In die Tonne damit.
Aber auch der XmlSerializer ist leider nicht in der Lage, alles zu serialisieren, was mit Schema beschreibbar ist.
Wenn xsd2code nicht weiterhilft, dann empfiehlt es sich, die Trial-Version von XmlSpy zu besorgen und den kompletten Serialisierungscode generieren zu lassen.
Hier ein Artikel zum Einschalten der Referenzerzeugung:
Mach mal eine Console auf und gib dort ein: "mode con". Der Wert der bei "Codepage" steht nimmst du für GetEncoding, z.B.
GetEncoding(850)
Der Fehler ist bekannt Sonderzeichen im Pfadnamen führen zu einer Exception. Du kannst nur den Namen des X86-Verzeichnisses ändern (geht irgendwie über die Registry).
5.1? Wer benutzt den denn noch? Der gehört schon aus Sicherheitsgründen ausgemustert...
Webservices gibt es in 2 "Styles". RPC-Style und Message-Style. Unter der Haube werkeln immer Messages (Documents). Es ist die Sicht, die die Anwendung einnimmt.
http://soa.sys-con.com/node/39728
Leider ist WCF nur bedingt für Message-Style geeignet, bzw. ist die Infrastruktur hier eher ärmlich. So darf man das sehr gebräuchliche Publish-Subscribe doch tatsächlich per Hand implementieren.
Hier nimmt man dann besser Service-Bus-Frameworks (.NET Services, NService, Simple Service Bus, etc.). Die lassen dann unter der Haube (u.a.) WCF werkeln, bieten aber mehr Komfort hinsichtlich der Message-Verarbeitung. Der Trend geht aktuell stark in Richtung Service-Bus, weil Aspekte hinsichtlich QoS und Entkopplung sich deutlich besser lösen lassen. So entfällt für deine Anwendung z.B. die gemeinsame Basisklasse.
Mit .NET Services ist man dann auch schon mit einem Bein in der Cloud.
Duplex-Bindings bieten Callbacks. Aber: In einer ernsthaft gesicherten Business-Umgebung bzw. im mobile Umfeld sind sie leider keine Option, weil dort der Verbindungsaufbau zum Client leider unmöglich ist (Incoming-Requests werden generell von der Firewall abgebügelt). Abhilfe würde TCP schaffen, aber HTTP-only ist bei Unternehmensnetzwerken quasi gesetzt.
Bei Silverlight-Anwendungen bietet sich die Polling-Bindings an. Damit kommst du durch jede Firewall sofern die mehr als einen Request pro Server erlaubt.
Man sollte aber auch sagen: Polling-Bindings beanspruchen relativ viel Last auf dem Server und einen Cluster/Load-Balancer sollte man auch nicht haben. Für Riesen-Dienste also nur bedingt tauglich, bzw. kritisch.
Alternativ kann du natürlich versuchen, dir für deine Anwendung einen TCP-Port schalten zu lassen (auf beiden Seiten). Das ist technisch im Prinzip die beste und einfachste Lösung. Aber das entscheiden dann leider die Sicherheitfuzzies und die ziehen einfach ihre Policy auf dem Schubfach und sagen: Ist nicht. Da gibts dann auch keine Diskussion.
Der Test war natürlich gegen compiliertes Regex. Die Compilation war außerhalb der Benchmark-Schleife, insofern brachte auch CompileToAssembly praktisch nix (1% gegenüber normalem Compile). Den "klassischen" AtoI-Code kann man locker nochmal so optimieren, dass er um weitere 15% schneller läuft. Damit ist er dann 43mal schneller als compiliertes Regex...
Interessanterweise ist tatsächlich das Regex für 70% der Ausführungszeit verantwortlich. Der Rest geht auf das Konto des Parse().
Aber um mal die Dimension zu verdeutlichen: AToI() macht 30 Millionen Konvertierungen pro Sekunde (auf meinem älteren Dual-Core). Da kann man auch Faktor 40 verschmerzen. 😃
In diesem konkreten Fall ist Regex etwa 30mal langsamer...
AtoI function - String to Integer in C# .NET
Wahlweise als Extension Method implementieren.
Asche auf mein Haot:
WS-Standard: WS-MakeConnection
Unterstützung .NET: PollingDuplexHttpBinding aus Silverlight 2.0 (kann man auch unter Full 3.5 nutzen)
In jedem Fall traurig, dass sich für dieses Problem keine out-of-the-box-Lösungen finden lassen. In ASP.NET gibt es wenigstens rudimentären COMET-Support, aber auf der WS-Ecke schläft wieder mal alles. Vermutlich bekommen wir bald irgendein REST-Geraffel. Wenn ich mir die ganzen SOAP-basierten Standards anschaue, dann hat man das Gefühl, W3C sitzt im Elfenbeinturm. 1000 und 1 WS-*-Standard, aber Reverse SOAP ist nicht dabei.
Gerade im Mobile-Umfeld ist normales Polling einfach keine Option. Blackberry ist groß geworden, weil sie als erste Push hatten. Wird langsam Zeit dass auch für den Otto-Normal-Programmierer Push-Services zu Verfügung stehen.
Aber vielleicht geht demnächst wieder alles durch den Browser mit HTML5 und Websockets... 😉
Der Vollständigkeit halber: Es gibt eine Draft Spezifikation von Nokia namens "PAOS". Dahinter steht "Reverve HTTP Binding for SOAP". Nur hat das leider niemand umgesetzt - außer Nokia.
Alternativ kannst du aber sogenanntes "Long Polling" auch direkt auf der WS-Schicht implementieren. Im AJAX-Bereich gibt es sowas schon länger und nennt sicht Bayeux-Protokoll (MS macht das mit seinem WebSync-Server). Leider gibt es bisher noch keine passablen und genormten Bindungen im WS-Umfeld.
Ob sich der Mehraufwand für Long Polling lohnt, hängt wohl davon ab, inwiefern man die bekannten Nachteile von Polling bereit ist in Kauf zu nehmen.
http://www.codeproject.com/KB/aspnet/AspNetComet.aspx?display=Print
Das größte Problem in diesem Zusammenhang ist die Tatsache, dass sich die vorgeschlagene Implementierung des Oberserver-"Callbacks" in der Praxis als sehr schwierig rausstellt. Den Client einfach zum Server zu machen ist meistens nicht möglich. Das gilt z.B. wenn der Client sich in einem Handy-Netz befindet oder wenn beide hinter einer NAT sitzen (klassisches B2B-Szenario).
In diesem Fall muss man auch "schlaue" Poll-Techniken wie Reverse HTTP, BOSH, etc. zurückgreifen.
Exceptions werden in deiner IAsyncResult-Instanz zwischengespeichert und erst beim Aufruf von EndXYZ geworfen.
Kleine Korrektur: Das ist fast immer der Fall. Man sollte sich jedoch darauf einstellen, dass auch BeginXXX() eine Exception werfen kann. Praktisch kommt das auch vor.