Schweregrad Code Beschreibung Projekt Datei Zeile Unterdrückungszustand
Warnung Das Element 'behavior' hat ein ungültiges untergeordnetes Element 'newtonsoftJsonBehavior'. Erwartet wurde die Liste der möglichen Elemente: 'clientVia, callbackDebug, callbackTimeouts, clear, clientCredentials, transactedBatching, dataContractSerializer, dispatcherSynchronization, remove, synchronousReceive, webHttp, enableWebScript, endpointDiscovery, soapProcessing'.
Wenn ich meinen Code probiere ohne den Service auf den neuen endpointBehavior umzuleiten bekomme ich schon einen Fehler.
Im TestCode füge ich aber die Eingangsparameter dazu, die Variable ist aber leer.
SimpleDictionary<String, String> result = new SimpleDictionary<String, String>();
result.Add("key3", "value3");
result.Add("key4", "value4");
foreach (KeyValuePair<String,String> keyvalue in webServiceRequestParams.ProcessData) {
result.Add(keyvalue.Key, keyvalue.Value);
}
r.ResultList = result;
Muss ich für die hin serializierung noch was machen?
Und noch eine Frage:
Ich habe das mit der GetObjectData Methode auch schon mal probiert, aber mit overwrite. Das funktioniert nicht, wieso eigentlich nicht?
public class KeyValuePairList<TKey, TValue> : Dictionary<TKey,TValue>
{
public override void GetObjectData(SerializationInfo info, StreamingContext context)
{
this.ToList().ForEach(p => info.AddValue(p.Key.ToString(), p.Value));
}
}
Wie gesagt; dann wirste wohl nen Custom Formatter brauchen (vermutlich).
Die Default-Darstellung des Serializers ist übrigens nicht falsch, sondern inhaltlich und in Sachen Json absolut korrekt.
Die simple Darstellung formatiert es nur als Json-Objekt.
Schade, ich denke die Einstellungsänderung müsste doch eigentlich leicht sein.
Ich weiss, das die Json Darstellung korrekt ist, aber die Kunden würden gerne die andere Darstellung übermitteln und zurück bekommen.
Naja vielleicht finde ich ja noch die Möglichkeit die Einstellung
Ich soll also Rest und SOAP Webservice mit ASP.Net Core WebApi erstellen.
Da habe ich nicht das Seralisierungsproblem?
Ich brauche in meinem Fall einen Service der mittels REST oder SOAP angesprochen werden kann.
Diesem Service werden Listen von KeyValuePairs übergeben und als Ergebnis werden wieder Listen von KeyValuePairs zurückgegeben (nach einer Verarbeitung natürlich :-)).
Mit WCF funktioniert alles prima nur eben leider nicht die richtige Darstellung von Dictionary (KeyValuePairs) sowohl bei der Übergabe und auch bei der Rückgabe.
Da die Verarbeitung gekapselt ist, könnte ich, hoffe ich zumindest, auch einen neue ASP.Net Core Api verwenden. Ich bräuchte nur eine KeyValuePair Übergabe und Rückgabe.
Könnt Ihr sagen, ob das funktioniert mit der Serialisierung?
Danke, aber Google habe ich auch. Sorry!
Aber ich habe jetzt schon zwei Tage im Internet zu gebracht.
Es kann sein, dass das zu einer Lösung führt, aber ich habe es so nicht hinbekommen.
Ich möchte auch nicht den ganzen Standard umhauen, es sollen immer noch alle anderen serialisierungen funktionieren.
Die Funktion (ab .net 4.5) ist relativ neu und der Beitrag schon älter. Ich kann mir nicht vorstellen, dass es so aufwendig ist, diesen Parameter zu setzen.
Die Klasse ist mir bekannt. Ich hatte ja geschrieben:
Zitat
Im Internet habe ich gefunden, das man ein Parameter UseSimpleDictionaryFormat in DataContractJsonSerializerSettings setzen kann.
Leider finde ich keinen Weg den Parameter zu setzen.
Ich habe ja kein Code wo ich ansetzen kann, denn die Serialisierung macht ja der WCF Service intern für mich.
Genau das ist die Frage, wo kann ich das für den internen DataContractJsonSerializer setzen?
Ich brauche aber {Key-Wert:Value-Wert} .
Im Internet habe ich gefunden, das man ein Parameter UseSimpleDictionaryFormat in DataContractJsonSerializerSettings setzen kann.
Leider finde ich keinen Weg den Parameter zu setzen.
Ich habe ja kein Code wo ich ansetzen kann, denn die Serialisierung macht ja der WCF Service intern für mich.
ich habe ein grosses Problem. Ich verwende in meinem .net csharp Projekt (A) eine .net csharp dll aus einem anderen Projekt (B) von mir.
Ich habe sie über den Verweis eingebunden.
Und die Applikation erstellt. Alles gut, bis dahin.
Jetzt ändere ich was in meinem DLL Projekt (B) ohne irgendwelche Aufrufparameter von Methoden zu ändern. Wenn ich jetzt nur die dll tausche in meiner Applikation aus Projekt (A), ohne die Applikation neu zu erstellen, kommt ein Fehler beim Aufruf, da die Version nicht mit der kompelierten Version übereinstimmt.
Gibt es eine Lösung, das ich die DLL Versionsunabhängig einbinden kann?
Es gibt sehr viele Version der DLL und daher müsste ich z.b bei Änderungen an Projekt A mit jeder DLL Version (B) kompelieren und damit eine Version von A erzeugen. Das ist sehr unschön.
Wie gesagt, es ändert sich nichts an den öffentlichen Aufrufen und den Parametern in der DLL
Danke, hast du zum letzten Punkt einige Informationsseiten oder Bücher die du empfehlen kannst.
Zitat
Wer bzw. woher soll die Implementierung von Summe und Produkt kommen?
Es gibt eine Interface Programmierung die immer genauso vom Webservice aufgerufen wird. Was passiert steht in der Datenbank und wird dynamisch von der internen Webserviceprogrammierung aufgerufen. Das ist nicht das Problem.
Ich muss nur irgenwie hinbekommen, dass der Aufrufer weiss welche Methoden und Parameter intern aufgerufen werden können.
Ich habe ein Entwicklungsframework mit dem man Formulare und Funktionen erstellt werden. Der Webservice soll Formulare bedienen und Feldinhalte eintragen und Ergebnisse zurückgeben.
Im Framework wird also ein neuer Webservice definiert, welches Formular mit welchen Feldern und welchen Funktionen aufgerufen werden.
Zur Zeit gibt schon einen .Net Webservice der nur aus zwei Felder besteht.
1. Name des Webservice (String)
2. Prozessdaten (XML Type) - die Speziellen Daten des Webservice (Feld1, Feld2)
So funktioniert es, aber Nachteil ist, dass der User nicht weiss welche Webservice überhaupt angeboten werden und auch nicht welche Werte erwartet werden.
Und es kann aus dem WSDL kein Client automatisch erstellt werden, was die Kunden sehr stört.
Also soll es jetzt anders umgesetzt werden.
Man müsste also das WSDL irgendwie automatisch zusammenbauen oder er müsste es aus der Datenbank ziehen.
ich möchte gerne den Druckerdialog aus Office 2010 nachbauen. Dafür bräuchte ich die Installierten Drucker (habe ich schon mit PrinterSettings.InstalledPrinters), deren Eigenschaften und das Drucker-Icon.
Ich bräuchte also eine Möglichkeiten die Eigenschaften und das Icon, was unter Windows angezeigt wird, abzurufen.
Wie DickesB schon richtig geschrieben hat, liegt es an der schwäche der Standard Version der riched20.dll die in Windows system32 Ordner liegt (Version 3.1).
Wenn Office installiert wurde, gibt es noch eine Passende riched20.dll im "Common Files\microsoft shared\officexx" (z.B. bei Office2010 Version 6.0).
Ok ich kann auch die Datei laden, aber wie bekomme ich raus in welchem Ordner "officexx" die Datei liegt, denn bei jeder Office Version gibt es einen anderen Ordner.
Ich kann natürlich von Office14 bis Office10 alle Ordner durch gehen und schauen,
aber ist das schön?
Des Weiteren gibt es das Problem, wenn kein Office installiert ist, dann gibt es keinen Ordner mit einer neueren dll.
So habe ich mir gedacht, die Datei einfach mitzulieferen. Leider hat sich gerade ergeben, dass bei Office 2007 Installationen die mitgelieferte Datei von Office 2010 nicht funktioniert.
Leider gibt mir das nicht das was ich möchte.
Ich bekomme
asm = {System.Windows.Forms, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089}
Mich intressiert aber die Version von riched20.dll.
Assembly asm = typeof(RichTextBox).Assembly;
Version version = asm.GetName().Version;
Ja, das funktioniert auf jedenfall, aber schöner wäre es, wenn ich die richtige Version nachladen könnte.
Nur leider bekomme ich es nicht hin.
Assembly[] appAssemblies = AppDomain.CurrentDomain.GetAssemblies();
for (int i = 0; i < appAssemblies.Length; i++)
Console.WriteLine(
"{0}: {1}\n", i + 1, appAssemblies[i].FullName);
Komisch ist auch das nach dem Laden keine Assembly riched20 geladen ist.
Wie kann ich die Version einer geladenen DLL ermitteln.
Es geht darum nicht ein File-Namen anzugeben, sondern es soll die
geladen DLL ermittelt werden. (Im aktuellen Fall riched20.dll)
Ich liefer die riched20.dll mit, denn im Windows Verzeichnis ist ein alte dll mit der einige Dinge nicht gehen (Tabellen werden nicht richtig dargestellt).