Forenbeiträge von GarlandGreene Ingesamt 497 Beiträge
schonmal nen Breakpoint bei port_DataReceived gesetzt und geprüft, ob überhaupt was da ankommt?
Ansonsten kann ich fürs Debuggen mit seriellen Ports das SysInternals-Utility PortMon empfehlen. Da kann man genau nachvollziehen, welche Daten wohin gehen.
dieser Exploit funktioniert nur mit MD5, für andere Hash-Funktionen gibt es teilweise auch Exploits. AES und DES sind meines Wissens nach aber aber noch nicht so leicht angreifbar wie das mittlerweile ziemlich angegraute MD5.
im Prinzip ist das so korrekt. Du erstellst für jeden Wörterbucheintrag einen Hash und vergleichst ihn mit dem Hash des gesuchten Passworts.
Gerade bei MD5 gibt es mittlerweile aber eine effizientere Methode, einen passenden Hash zu finden. Es gibt für den MD5-Algorithmus einen Exploit, der auf mathematischem Wege Kollisionen zu einem Hash finden kann.
Des weiteren helfen Wörterbuchattacken nicht gegen Passwörter, die mit einem sogenannten "Salt" erweitert worden sind. Dabei wird ein nur der Anwendung selbst bekannter zusätzlicher Text zum Passwort hinzugefügt (oder das Passwort anderweitig verändert), so daß es auch keine Möglichkeit gibt, einen gefundenen passenden Hash zu nutzen.
FileNameTemp wird aber innerhalb eines if-Blocks zugewiesen. Trifft die if-Bedingung nicht zu, ist FileNameTemp nicht initialisiert.
diese Einstellung kannst du am besten für jeden Nutzer des Rechners getrennt speichern. Damit bist du auch auf der sicheren Seite, wenn der Nutzer keine Berechtigung hat, schreibend auf das Programmverzeichnis zuzugreifen.
[Tutorial] Das neue Konfigurationsmodell im .NET Framework 2.0
ich würds viel einfacher machen. Schreib dir einen Wrapper für die Log-Funktionen. Anstatt direkt ein ILog-Objekt zu holen und das Log zu schreiben, rufst du nur eine Funktion des Wrappers auf, der wiederum das Log-Objekt holt und die Nachricht übergibt. Jetzt kannst du über öffentliche Methoden des Wrappers das Logging abschalten, indem du ein bool-Feld entsprechend setzt und es vor dem Schreiben einer Lognachricht prüfst.
Beispiel:
using System;
using System.Text;
using log4net;
namespace Blubb
{
public static class Log
{
private static bool m_LogIsEnabled;
public static void EnableLog()
{ m_LogIsEnabled = true; }
public static void DisableLog()
{ m_LogIsEnabled = true; }
public static void WriteLog(string msg, Exception ex)
{
if (m_LogIsEnabled)
{
ILog logger = LogManager.GetLogger("AppLog");
if (logger != null)
{
if (ex != null)
logger.Error(msg, ex);
else
logger.Info(msg);
}
}
}
}
}
ich vermute, daß du das Archiv nicht mit Close() schliessen solltest, wenn du anschliessend darauf noch einen Test durchführen willst. Schau mal, ob du mit noch geöffnetem ZipFile ein anderes Ergebnis bekommst.
vielleicht solltest du das "success"-Flag auch irgendwo auf "true" setzen. Du initialisierst das Flag mit "false", weist danach nichts mehr zu und prüfst später auf true. Wie soll da ein True reinkommen?
Genau. Ich baue mir für WebService-Parameter immer Parameterklassen, die ich dann mit privaten Feldern und öffentlichen Eigenschaften ausstatte. So kann ich auch mehrere Rückgabewerte zurückgeben. Für binäre Daten wie Zip-Archive nehme ich dann einen String. Auf Client-Seite wird die Datei als Stream eingelesen und in Base64 konvertiert. Auf WebService-Seite dann der umgekehrte Weg, von Base64-String zurück in einen Stream.
Bei der Konvertierung in Base64 vergrößert sich übrigens die Datenmenge um 1/3, da jeweils 6 Bit Binärdaten mit einem 7 Bit-ASCII-Zeichen dargestellt werden.
am besten Base64-encoded als String hochladen und im Webservice zurückkonvertieren lassen. Ich übertrage so (allerdings auf umgekehrtem Wege, also vom Webservice aus nach draussen) eine größere Datenmenge, die vorher serialisiert und gezippt wird. Das Konvertieren funktioniert mit der Convert-Klasse und deren Methoden ToBase64String bzw. FromBase64String.
8000 Datensätze will kein Anwender sehen. Das ganze ist mit Client-Server-Anwendungen auch nicht wirklich performant hinzubekommen (wobei 8000 Datensätze jetzt noch nicht das Problem wären, müsste mit einem brauchbaren Server nur einige Sekunden dauern). Die einfachste Lösung wäre ein vorgeschalteter Suchdialog, der die Auswahl vor dem Abruf eingrenzt. Alternativ ginge ein Paging, das jeweils nur ein paar Datensätze holt und dem Anwender die Möglichkeit gibt, im Datenbestand zu blättern.
du brauchst keinen Objektnamen, sondern eine Objektreferenz. Da du das MainWindow aber erst innerhalb des Application.Run()-Aufrufs mit new... erzeugst, hast du keine für dich greifbare Referenz.
Du könntest das MainWindow vor dem Run() erzeugen, in einer statischen Eigenschaft ablegen und dann dieses Objekt mit Run() in der Standardmeldungsschleife starten. Danach hättest du die statische Eigenschaft, um auf das MainWindow zuzugreifen.
da der Compiler aber keine Kristallkugel eingebaut hat, kann er das nicht ahnen. Und der Sourcecode gibt es nicht her, im Falle einer falsch aufgebauten Xml-Datei wäre da tatsächlich eine nicht zugewiesene Variable.
du erhöhst den Zähler a sowohl in der for-Schleife als auch in der Wertzuweisung. Du willst wahrscheinlich folgendes:
for (Int32 a = 0; a < Convert.ToInt32(dataGridView1.RowCount.ToString()); a++)
{
dataGridView1.Rows[a+1].Cells[1].Value = "OK";
}
wobei das ganze sehr seltsam aussieht. Du konvertierst den RowCount (der ja schon Int ist), in einen String, dann zurück in Int, um den dann gegen a zu prüfen. Hat das einen Grund?
€: das kommt davon, wenn zwischen Lesen, Schreiben und Absenden Telefonate dazwischen kommen...
wenn du dem ASPNET auf dem lokalen System Rechte zuweist, hat das Konto diese Rechte nur auf dem lokalen System. Ein Zugriff auf ein Netzlaufwerk innerhalb einer Domäne würde daher nicht funktionieren.
Es gibt wie gesagt zwei Varianten. Variante 1 wäre die Festlegung eines anderen, in der Domäne bekannten, Kontos anstelle des ASPNET-Kontos. Das geschieht z. B. in der web.config in der <identity>-Sektion:
<identity impersonate="true" userName="domain\username" password="password"/>
Damit läuft der gesamte Webservice unter dem Konto "domain\username".
Variante 2 läuft darauf hinaus, sich diese Konto-Berechtigung nur für den Moment, in dem man sie wirklich braucht, zu holen. Beispielcode dazu findet sich hier. In diesem Fall hat der Prozess nur kurz Berechtigungen in der Domäne, das könnte als Sicherheitsvorkehrung gegen Missbrauch interessant sein.
eventuell "nur" lokaler Administrator, der auf das Netzlaufwerk keinen Zugriff hat? In einer Domäne hat der lokale Admin ja keine Berechtigungen...
nebenbei: besser wäre ein Domänenkonto mit eingeschränkten Rechten, das den Webdienst ausführt. Oder man holt sich im Webservice selbst über Impersonation kurzzeitig die entsprechenden Rechte.
ich hab hier grad ein Problem, zu dem ich keine Lösung finde. Ich entwickle eine Anwendung für Windows Mobile 5, Compact Framework 2.0. Ich möchte global alle Fehler, die in der Anwendung auftreten können, vor dem Beenden der Anwendung anzeigen und evtl. noch loggen. Nach kurzem Suchen stellte ich fest, daß das CF da etwas eingeschränkt ist und u.a. Application.ThreadException nicht bietet.
Lösung 1: try...catch um Application.Run(form)
Aufbau: 2 Forms, jeweils ohne Controls. Form1 wirft bei einem beliebigen Tastendruck eine Exception mit der Message "Test". Daraufhin soll Form2 mit der Exception als Parameter im Konstruktor erzeugt und per ShowDialog() modal angezeigt werden.
Code:
[MTAThread]
static void Main()
{
try
{
Application.Run(new Form1());
}
catch (Exception ex)
{
Form2 eForm = new Form2(ex);
eForm.ShowDialog();
}
}
dumm daran: ShowDialog() wird zwar ausgeführt, blockiert aber nicht. Sprich: die Anwendung schliesst sich sofort.
Lösung 2: AppDomain.CurrentDomain.UnhandledException, abfangen aller unbehandelten Ausnahmen in der gesamten Anwendungsdomäne und Anzeigen in einem Form.
Aufbau: wieder zwei Forms ohne Controls, Exception bei KeyDown in Form1.
Code:
static class Program
{
private static Form1 m_Mainform;
[MTAThread]
static void Main()
{
AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);
m_Mainform = new Form1();
Application.Run(m_Mainform);
}
static void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)
{
if (m_Mainform == null)
{
Form2 eForm = new Form2(e.ExceptionObject as Exception);
eForm.ShowDialog();
}
else
{
m_Mainform.Invoke(new Form1.ErrorDelegate(m_Mainform.ProcessError), new object[] { e.ExceptionObject as Exception });
}
}
}
public partial class Form1 : Form
{
public delegate void ErrorDelegate(Exception ex);
public Form1()
{
InitializeComponent();
}
private void Form1_KeyDown(object sender, KeyEventArgs e)
{
throw new Exception("Test");
}
public void ProcessError(Exception ex)
{
Form2 eForm = new Form2(ex);
eForm.ShowDialog();
}
}
Ergebnis: derselbe Effekt. ShowDialog() wird aufgerufen, blockiert aber nicht, der Thread wird beendet, damit die Anwendung.
Was zum Henker ist da los? Daß die zweite Variante nicht funktioniert, könnte ich mir noch damit erklären, daß das .Net-Framework den MainThread abwürgen will. Aber in Variante 1 wird der Fehler abgefangen, behandelt und ShowDialog() müsste funktionieren.
Witziger Zusatz: schmeisse ich den Fehler im Konstruktor von Form1, funktionieren beide Varianten. Eventuell, weil da die Standardnachrichtenschleife noch nicht läuft und Program.m_Mainform NULL ist.
es gibt verschiedene Typen der Replikation: http://technet.microsoft.com/de-de/library/ms152531.aspx
Für dich wäre, wenn ich die Beschreibung deiner geplanten Synchronisation als Grundlage nehme, die Merge-Replikation passend. Dabei wird einmalig ein Snapshot der Datenbank als Grundlage genommen, danach werden nur noch Änderungen übertragen.
Original von Lexodus
@GarlandGreene...mobiler Internetanwender, die maximal mit UMTS (und damit 384 kbit/s)...
würde ich vielleicht zustimmen, nur würde ich nicht eh dann eine Extraseite machen für mobile Internetseiten ? Weil auf ein Handy und eine 19" dürfte die Darstellung ja schon etwas abweichen 😉
GarlandGreene meint wohl weniger die Leute die mit dem Handy ins Inet gehen (für mich sowieso unverständlich sowas 😉 sondern die Leute die ne UMTS/GPRS PC-Card in ihrem Notebook haben um damit mobil ins Internet "einzuwählen 😉"
Das hingegen empfinde ich aber als sehr gutes Argument.
Gruss
nö, wobei die natürlich auch dazukommen. Aber mit Handys wie dem IPhone und den aktuellen Nokia-Smartphones mit großem Display kann man durchaus gut im Internet surfen. Das ganze wird gerade erst brauchbar, nichtsdestotrotz wird es immer stärker benutzt werden. Man sollte sich bei der Webseitenerstellung nur fragen, ob man diese Nutzer mit in seine Zielgruppe einbeziehen möchte oder halt nicht.
UMTS ist gar nicht so teuer und in vielen Fällen, wenn DSL nicht verfügbar ist, die beste Lösung. Eine Base-Flatrate kostet 25 € monatlich, dazu kommt die Karte. Immer noch besser als eine ISDN-Einwahl, für die man kaum bezahlbare Flatrates bekommt.
hast du schon über Replikation nachgedacht?
was Bilder und Ladezeiten angeht, wär ich vorsichtig. Zwar ist DSL heutzutage der Standard, eine auf DSL ausgelegte Webseite ist mit allem unterhalb DSL aber absolut unbrauchbar. Einkanal-ISDN hat nur 1/16 der Download-Bandbreite einer kleinen DSL 1000-Leitung. Wer damit eine Seite aufruft, die mit DSL 1000 knapp 2 Sekunden zum Laden braucht, darf knapp 30 Sekunden auf den Seitenaufbau warten. Die meisten Surfer dürften nicht so lange warten.
Auch im Hinblick auf die stark wachsende Zahl mobiler Internetanwender, die maximal mit UMTS (und damit 384 kbit/s) unterwegs sind, würde ich meine Seiten so schmalband-freundlich wie möglich gestalten. Ist der Surfer gar ohne UMTS unterwegs, ist man wieder im Bandbreitenbereich eines ISDN-Anschlusses.
Alle Fenster sollten in demselben Thread laufen. Von daher würde ich das Fenster einfach per ShowDialog() anzeigen und über Events und Invoke mit dem Thread kommunizieren lassen.
Was das Ändern von Eigenschaften aus einem anderen Thread heraus angeht: schau dir mal (unter anderem) lock() an. Ansonsten gibts irgendwann die seltsamsten Fehler und Abstürze, wenn du aus mehreren Threads ungeschützt auf dieselben Eigenschaften und Objekte zugreifst.
wen's interessiert:
System.Diagnostics.Process.GetCurrentProcess().Kill();
würgt den Prozess hart ab. Ist zwar nicht die feine englische Art, aber es verfehlt seine Wirkung nicht.
Nein, leider nicht. Ich habe im Prinzip überhaupt keine Möglichkeit, die Klasse irgendwie zu deaktivieren. Ich habe schon (da das CF etwas zickig ist) vor dem Schliessen sämtliche Events manuell wieder deregistriert und das Objekthandle mit NULL initialisiert. Leider jeweils ohne sichtbaren Erfolg...
Hallo,
ich entwickle gerade eine Kommissionieranwendung für CE 5.0-Geräte. Als Framework kommt das Compact Framework 2.0 SP2 zum Einsatz.
Der Scanner des Geräts wird über eine Activex-DLL angesprochen, die ich in meinem Projekt verweise, VS hat dafür eine Interop-DLL erstellt. Der Zugriff auf die Funktionen der Activex-Bibliothek funktioniert soweit ganz gut, allerdings will sich die Bibliothek anscheinend nicht aus dem Speicher entfernen lassen. Nach Beenden und Neustart der Anwendung ist der Scanner blockiert, da die vorherige Instanz der Bibliothek anscheinend noch im Hintergrund läuft. Auch das mitgelieferte Testprogramm für den Scanner meldet nach Beenden meiner Anwendung, daß der Zugriff auf den Scanner gesperrt ist.
Weiterhin ist mir aufgefallen, daß bei normalem Beenden der Anwendung im Debug-Modus mein Visual Studio im Debug-Modus bleibt, die Anwendung also anscheinend noch läuft. Ich kann die Anwendung dann über Visual Studio beenden und neu starten. Das ist aber keine Lösung, die sich für den produktiven Einsatz eignet. Das ganze passiert nur, wenn die Interop-DLL geladen und die darin enthaltene Scanner-Klasse auch instanziert wurde - benutze ich die Anwendung ohne Scannereinsatz, beendet VS brav den Debug-Modus. Im Process Explorer sieht das ganze so aus, dass nach einem Scannereinsatz die Threads, die das Framework neben meinem normalen Dialogthread aufmacht, bestehen bleiben.
Bevor ich mich jetzt in die Untiefen von C/C++ bemühe und eine eigene Bibliothek für den Scanner schreibe, meine Frage: gibt es eine Möglichkeit, eine bestimmte DLL hart, also zuverlässig, zu entladen? Oder kann ich die gesamte Anwendung zuverlässig beenden? Application.Exit() hat leider auch nicht die erhoffte Wirkung gezeigt.
Infos zur Entwicklungsumgebung:
VS 2005 Professional SP1
Compact Framework 2.0 SP2
Das Gerät ist ein Datalogic Skorpio Gun, Windows CE 5.0
du musst die DLLs natürlich noch in dein Projekt einbinden. Im Projektexplorer Rechtsklick auf "Verweise", neuen Verweis erstellen und im erscheinenden Dialog die DLL auswählen.
einfach anstelle
private Font printFont;
das ganze so deklarieren:
private System.Drawing.Font printFont;
Du musst, wenn du eine Klasse verwendest, die in zwei über die using-Angabe angegebenen Namespaces Verwendung findet, immer genau angeben, welche Klasse du meinst.
installiert man den .Net Connector, so kann man im VS 2003 im Server-Explorer eine Verbindung zu einem R3-Applicationserver herstellen und dort die für Rfc-Calls nötigen Proxyklassen von einem Wizard erzeugen lassen (das Sapproxy-Element öffnen, im Serverexplorer zur Rfc-Verbindung navigieren und diese per Drag & Drop auf das Sapproxy-Element ziehen - fertig), man spart sich also einen Haufen Tipparbeit und eventuelle Deklarationsfehler. Zudem generiert dieser Wizard auch die Datenklassen für Idocs. Nichts, was man nicht auch selber machen kann, aber das Ding spart halt unglaublich viel Zeit - und läuft anscheinend nur im Visual Studio 2003, ins 2005er Studio integriert sich das Plugin nicht. Der .Net Connector läuft auch nur als .Net 1.1-DLL, auch wenn man die Assembly auch in .Net 2.0-Projekten nutzen kann.
ich nutze den SAP .Net-Connector, um damit Rfc-Funktionen aus R3 (4.6c) aufzurufen und Idocs ans System zu senden. Um sich einen Überblick über die Funktionsweise des Connectors verschaffen zu können, sind die dem Connector beigefügten Beispielprojekte ganz nützlich (stehen im Unterverzeichnis "Samples" des Connector-Installationsverzeichnisses).
Man kann den Connector auch mit Visual Studio 2005 und .Net 2.0 nutzen, muss dann aber entweder ein VS 2003 für die Erstellung der Proxyklassen benutzen oder diese Proxyklassen selbst erstellen. Wenn die Anzahl der Rfc-Funktionen, die man nutzen will, nicht zu groß ist, geht das ganz gut. Da der .Net Connector aber keine sonderlich gute Fehlerbehandlung besitzt, ist die Fehlersuche bei vergessenen oder falschen Funktions- oder Parameterdeklarationen ziemlich nervig. Von daher ist die VS 2003-Variante die nervenschonendere.
da der Skype-Client sich zwischendurch immer mal wieder mit dem Server verbinden muss, teilt er ihm wahrscheinlich gleich den konfigurierten UDP-Port mit.
ICQ und diverse andere Anwendungen (allen voran Skype) können sich durch einen simplen Trick ein Loch in die Firewall bzw. eine Portweiterleitung in den Router bohren:
kann ich bei mir nicht nachvollziehen, der Quellcodeauszug wird sauber kompiliert (nach Deklaration von i und length).
so sollte das in einem Einzeiler gehen:
// Variable "langtext" vom typ System.String enthält den ursprünglichen Text unbekannter Länge
string substr = langtext.Length > 0 ? langtext.Substring(0, langtext.Length > 7 ? 7 : langtext.Length) : langtext;
ORM gehen immer zu Lasten der Performance. Ich selbst nutze trotzdem NHibernate, da es die Arbeit, wenn einmal konfiguriert und in einer Bibliothek gekapselt, extrem vereinfacht. Ich kann mit typsicheren Objekten arbeiten, bin mehr oder weniger unabhängig von der verwendeten Datenbank und kann mit Hibernate-Queries komplexe Abfragen durchführen, die sich nicht mehr auf die Datenbankstruktur, sondern die Hibernate bekannte Objektstruktur beziehen. Da ist natürlich einiges an Mappingaufwand zu leisten (wobei da Codegeneratoren wie MyGeneration gute Arbeit leisten), aber einmal erledigt, hat man lange hohen Nutzen davon.
ADO nutze ich seit meinen ersten Erfahrungen mit NHibernate fast gar nicht mehr. Da man den Zugriff per NHibernate relativ schnell eingerichtet hat, nutze ich das mittlerweile auch für kleinere Projekte.
warum nicht an eine Tabelle binden? Muss ja keine Tabelle sein, die in der Datenbank existiert. Du kannst auch ein Dataset nebst Tabelle definieren, das Ding zur Laufzeit einfach instanzieren und ein paar Leerzeilen einsetzen. GridView dran binden, fertig.
Hi Skunky!
über WMI kommt man da - in gewisser Weise - dran, schau mal hier: http://www.codeproject.com/csharp/usbeject.asp
da wird über WMI nach Disks am USB-Interface gesucht (ziemlich weit unten)
der Dienst läuft ja unter einem anderen Konto, startet Powerpoint also für dieses Konto. Dienste sollen mit lokalen Anmeldungen eigentlich nichts zu tun haben.
genauso wie sonst auch, z. B. über die File- bzw. FileInfo-Klasse. Da ASP.Net-Anwendungen meist aber unter einem niedrig privilegierter Benutzerkonto ausgeführt werden, kann es sein, dass dieses Konto einfach keine Berechtigung zum Lesen der Datei hat. Dann kann man entweder die Berechtigung anpassen, die ASP.Net-Anwendung insgesamt unter einem anderen Konto laufen lassen oder sich über Programmcode kurzfristig eine andere Berechtigung beschaffen (Identitätswechsel bzw. Impersonation).
Zum Identitätswechsel: http://www.devtrain.de/artikel_935.aspx
wenn man einen Webservice implementiert, sollte man keinesfalls blind die Standard-Serialisierung des Frameworks annehmen. Problematisch ist vor allem, daß das Framework die Deklaration des WSDL dynamisch anhand der im Quellcode benutzten Variablennamen generiert. Ändert man den Variablennamen, ändert sich damit das Interface und Anwendungen, die den Webservice nutzen, müssen entsprechend angepasst werden. Das kann man verhindern, indem man zum einen die Ein- und Ausgabeparameter der Webservice-Methoden mit XmlElement-Attributen versieht und damit die Elementbezeichnungen vorgibt. Dazu sollte man noch die eigentlichen Parametertypen mit XmlType, XmlElement und XmlArray-Attributen versehen, falls es sich dabei um eigene Datentypen handelt. Andererseits könnte auch hier jede kleine Änderung im Webservice-Quellcode auf der Consumer-Seite Probleme bereiten.
ich kann dazu den folgenden MSDN-Webcast nur empfehlen: https://www.microsoft.com/germany/msdn/webcasts/library.aspx?id=100100141
vermutlich wird XNA die vertikale Synchronisation beachten. Die müsstest du im Grafikkartentreiber abschalten.
Was genau meinst du mit .NET-spezifisch? Meinst du die Klassennamen, die für die Bezeichnung der Strukturen verwendet werden? VS generiert das WSDL erstmal aus dem Sourcecode und benutzt für die Benennung der Strukturen Klassen- und Variablennamen aus dem Code. Wenn man das nicht will, kann man über Attribute Vorgabewerte für Strukturen und Parameter machen.
Beispiel:
[WebMethod]
[return: XmlElement(ElementName = "CreateNewPalletResponse")]
public palletServiceCreateNewPalletResponseTransport CreateNewPallet([XmlElement(ElementName="CreateNewPalletRequest")] palletServiceCreateNewPalletRequestTransport req)
{
...
...
}
Im WSDL sind jetzt die Strukturen nicht mehr mit dem .NET-Klassennamen, sondern den von mir vorgegebenen Bezeichnungen benannt. Auch die Parameternamen sind jetzt unabhängig vom Sourcecode. Wenn man komplexe Strukturen als Parameter verwendet, sollte man auch diese entsprechend mit Attributen "ausstatten".
Beispiel:
[Serializable]
[XmlType(Namespace = "urn:xxx:yyy", TypeName = "CreateNewPalletRequestTransport")]
public class palletServiceCreateNewPalletRequestTransport
{
private int m_LineNumber;
[XmlElement(ElementName = "LineNumber")]
public int LineNumber
{
get { return m_LineNumber; }
set { m_LineNumber = value; }
}
[XmlArray(ElementName = "Pallets")]
public List<dtoPallet> Pallets
{
get { return m_PalletList; }
set { m_PalletList = value; }
}
}
zu beachten ist hier die Verwendung von XmlArray für Listen und XmlElement für einzelne Elemente. So bekommt man dann das gesamte WSDL statisch und unabhängig von Variablen- und Klassennamen im Sourcecode. Sollte man im jeden Fall machen, ansonsten ist beim späteren Überarbeiten des Codes unter Umständen das WSDL nicht mehr dasselbe.
Der LOGON_USER ist derjenige, der den Prozess ausführt. Probier mal AUTH_USER: http://www.codeproject.com/useritems/How_to_NT_User_Name.asp
solang du die neu erstellte Datei noch geöffnet hast, ist sie doch schreibgeschützt. So wie ich das verstehe, willst du eine Art Lockfile als Lesesperre für eine Konfigurationsdatei benutzen. Wenn die Datei gelöscht werden kann oder nicht da ist, kann die Konfigurationsdatei gefahrlos gelesen werden. Wenn nicht, zurück in die Warteschlange. Das sollte funktionieren, indem du einfach diese Sperrdatei vor der Änderung der Konfigurationsdatei erzeugst, sie bis nach dem Speichern der Konfigurationsdatei offen hälst und erst danach den Stream schliesst.
den Connectionstring in die app.config oder eine andere Konfigurationsdatei auslagern, sonst musst du für jede Änderung daran neu kompilieren...
ohne die Fehlermeldung vermute ich einfach mal die fehlenden Anführungszeichen im zusammengebastelten SQL-Kommando.
string test = "stefan";
cmd.CommandText = "INSERT INTO table(name) VALUES('"+test+"')";
Edit: dieser Befehl würde in die Tabelle "table" eine Zeile einfügen und den Wert "stefan" in das Feld "name" einsetzen.
das ist normal, NHibernate fügt über OleDB-Parameter die Werte ein. Im Query selbst erscheinen bei OleDB anstelle der Parameter nur die "?". Normalerweise gibt NHibernate in seinen Fehlermeldungen auch noch den Grund an, aus dem eine Aktion nicht möglich war (in dem Fall dürfte es ein vom SQL-Server gemeldeter Fehler sein).
ganz interessanter Webcast zu dem Thema:
Connected Systems (Teil 3-6) - Implementierungsstrategien: ASMX + WSE 2.0
Besonders der Teil, der auf die Hintergründe der in VS generierten Proxyklassen und (noch wichtiger) das aus dem Code erzeugte WSDL-Schema eingeht. Wenn man da zu Beginn ein bisschen konzeptionelle Arbeit reinsteckt, gewinnt man später enorm bei Pflege und Erweiterung.
Original von Mystique
Skype verwendet eine elegante und sehr effektive Methode, um Router und Firewalls zu umgehen:
>> . Man müsste sich einen Ersatz für den Vermittlungsserver überlegen, da reicht aber schon die IP-Eingabe oder als (für Endanwender) einfachere Variante dynamisches DNS.Link ist leider schon tot 🙁 (404-Error)
nö, der Punkt am Satzende ist leider mit in die URL gerutscht:
Skype verwendet eine elegante und sehr effektive Methode, um Router und Firewalls zu umgehen: http://www.heise.de/security/artikel/82054. Man müsste sich einen Ersatz für den Vermittlungsserver überlegen, da reicht aber schon die IP-Eingabe oder als (für Endanwender) einfachere Variante dynamisches DNS.