@BerndFfm: Mit welchem "Scripting-Host" werden die Skripte denn geladen bzw. ausgeführt und unterstützt du das Laden von 3rd Party Libraries (durch Referenzen auf die Assemblies) oder muss sich das Skript da selbst drum kümmern?
@T-Virus: Aktuell wäre der Plan, zur Laufzeit an einer bestimmten Stelle im Code nach [BestimmterOrdner]\[BestimmterDateiname].cs zu suchen. Falls diese Datei existiert, sollte ein ScriptingHost die Datei laden und eine gewünschte (hoffentlich vorhandene Methode) ausführen.
Der Kunde könnte im Endeffekt selbst Hand anlegen und z.B. hauseigene Bibliotheken zur Ver-/Entschlüsselung von Inhalten zwischen schalten.
Das mit dem Scripting ist nur aufgekommen, da das Produktmanagement meint, es wäre für die Kunden bzw. unsere Consultants einfacher mal eben in einer kundenspezifischen Programmierung ein Skript anzupassen, anstatt eine DLL zu kompilieren.
Ich selbst bin ein Freund der Plug-in Lösung. Allerdings kann ich auch die Einfachheit der Skript-Lösung nachvollziehen.
@Abt: Bisher wurden diese Probleme tatsächlich mit VB-Script gelöst. Da gab es keine Assemblies die in App-Domains geladen werden und OOP bis ans Limit.
Da das Kernprodukt in C# entwickelt wurde und die meisten Entwickler innerhalb der Firma auch C# beherrschen, wollte man am liebsten in dieser Sprache bleiben.
Vielleicht ist der Ansatz aber auch einfach verkehrt. Ich versuche das ursprüngliche Problem mal zu schildern...
Innerhalb des C# Codes gibt es Stellen die, falls eine Implementierung für diese Stelle/Hook existiert, diese Implementierung dann auch durchlaufen werden soll. Quasi nach dem Motto: Wurde ein Handler für diesen Hook gefunden, dann rufe ihn auf und lass ihn arbeiten. Die Signaturen dieser "Erweiterungspunkte" wären wohl definiert und die Entwickler würden sich an die Konventionen halten und somit könnte die Hauptanwendung die Methode innerhalb des "Erweiterungsskriptes" finden und aufrufen. Leider sind diese "Erweiterungsskripte", wie immer, abhängig von anderen Assemblies.
Von daher sehe ich inzwischen eigentlich nur noch die Plug-in Lösung. Also die Entwickler sollen bitte sehr DLLs in nen bestimmten Ordner werfen und die Hauptanwendung scannt diese Ordner nach verwendbaren Modulen.
Ich muss wohl etwas weiter ausholen merke ich gerade....
Innerhalb des Skripts, sollen andere Entwickler ihren C# Code ausführen können, der wiederum auf andere 3rd Party Bibliotheken zurückgreifen muss.
Jetzt habe ich Ansätze wie die Roslyn Scripting API gesehen, die Code Zeile für Zeile ausführt.
Dadurch würden zur Laufzeit ja nicht automatisch die benötigten 3rd Party Assemblies geladen werden oder etwa doch?
Muss ich vielleicht doch lieber eine Assembly per AssemblyResolver als Plug-in laden und aufrufen anstatt ein Skript zu laden?
Die Skript Variante erschien mir Anfangs attraktiv, da so die anderen Entwickler für Anpassungen nicht immer erst eine Plug-in DLL kompilieren müssten, sondern den Skript-Code "mal eben" anpassen und sofort laufen lassen könnten.
ich schaue mich gerade nach einer Möglichkeit um, mit der ich zur Laufzeit ein externes C#-Skript (liegt im Dateisystem in einem zugreifbaren Ordner) laden und Methoden innerhalb dieses Skripts ausführen kann.
Also z.B. würde das Skript folgende Methode enthalten, die ich gerne zur Laufzeit aufrufen würde:
public Task<object> Execute(object parameter) {}
Nun finde ich Beiträge im Netz von 2010, in denen z.B. der Typ Microsoft.CSharp.CSharpCodeProvider verwendet wird um den Code zu laden und on-thy-fly zu kompilieren.
Ist es aktuell immer noch der Weg den man gehen sollte oder hat sich in der Zwischenzeit da etwas getan und ich würde auf das falsche, schlecht gealterte, Pferd setzen? Vielleicht gibt es inzwischen bessere (Standard-) Bibliotheken?
ich möchte in meinem Setup Projekt in einer Custom Action den Inhalt einer (durch den Installer) installierten Datei lesen und verwenden. Wenn bei dieser Custom Action ein Fehler auftritt, möchte ich die komplette Installation des Produkts rückgängig machen, also das es später nicht unter den installierten Programmen erscheint.
Ich habe nun das Problem das ich den Inhalt der Datei erst nach dem "InstallFinalize" event von der Platte lesen kann und wenn ich nun die Custom-Action einen Fehler werfen lasse, hat das keine Auswirkung auf die Installation. Sprich, die Dateien bleiben an Ort und Stelle und es erscheint natürlich auch unter den installierten Programmen.
Laut Doku wird mein gewünschtes Verhalten anscheinend auch nicht unterstützt.
Nun hoffe ich auf viele pfiffige Entwickler, die es vielleicht doch irgendwie hinbekommen haben oder 'nen Workaround gefunden haben?
Eine http-Bindung wurde im IIS konfiguriert.
Der eigentliche Service-Endpoint verwendet binding="basicHttpBinding" und eine bindingConfiguration mit den http Security-Settings.
Ich habe gehofft, dass mir trotzdem noch der http Zugang zur WSDL Definition bleibt, nur leider ist dem nicht so. Unter "myService.svc?wsdl" finde ich dann plötzlich nichts mehr.
Hat jemand eine Ahnung warum dann plötzlich kein ?wsdl Aufruf mehr möglich ist, obwohl httpGetEnabled="true" gesetzt ist.
edit: Es wird dann plötzlich nur noch diese URL vorgeschlagen: "http://[servername]/myService.svc/mex"
Ich habe es hinbekommen und es lag tatsächlich an der Art und Weise wie das SOAP-XML in SoapUI definiert wird. Wenn man in SoapUI ein Attachment hinzufügt, dann wird eine ContentID vergeben.
Und genau diese ContentID musste einfach gleich sein zu dem dazugehörigen PART Eintrag:
[DataContract]
public class MultipartDocument
{
[DataMember(IsRequired = true)]
public string ID
{
get;
set;
}
[DataMember(IsRequired = true)]
public string CreationDate
{
get;
set;
}
[DataMember(IsRequired = true)]
public string Name
{
get;
set;
}
[DataMember(IsRequired = true)]
public Collection<DocumentPart> Parts
{
get;
set;
}
public MultipartDocument()
{
Parts = new Collection<DocumentPart>();
}
}
[DataContract]
public class DocumentPart
{
[DataMember(IsRequired = true)]
public string Name
{
get;
set;
}
[DataMember(IsRequired = true)]
public byte[] PartData
{
get;
set;
}
}
Es muss nicht unbedingt per Stream gemacht werden.
Ich habe jetzt eine Variante, in der mehrere Dateien gleichzeitig geschickt werden könnten.
Hier mal ein Beispiel Aufruf, wie ich ihn aus SoapUI heraus abschicken möchte:
Ich habe einen WCF Service der es ermöglicht Dateien hochzuladen. Nun habe ich die Anforderung bekommen, dass die Dateien am besten mittels MTOM Encoding hochgeladen werden sollen und am besten 3 Dateien in einem Request. Der Endpunkt der sich um den Upload kümmert, hat als Binding Parameter das MessageEncoding mit MTOM eingerichtet. Jetzt frage ich mich ob ich im dazugehörigem ServiceContract einfach eine Collection von Streams verwenden kann oder ob es eine Collection von Byte Arrays sein muss, um mehrere MTOM Attachments gleichzeitig entgegennehmen zu können.
also auf andere Projekte innerhalb meiner Solution verlinke ich über "Add Reference -> Projects". Ich referenziere aber auch .DLLs per "Add Reference -> Browse".
Sind diese "Browse" Verweise irgendwie anders hinterlegt im Projekt?
Ich habe da ein kleines Problem mit absoluten Pfaden aus der Entwicklungszeit, die aus einem mir unbekannten Grund in meinen Assemblies verbacken sind.
Wäre eigentlich nicht so wild, nur leider stecken in den Log Files beim Kunden jetzt in den Exception Beschreibungen meine "C:\Dev\..." Pfade. Das fühlt sich falsch an. ;-)
Ich hatte die ganze Zeit einen falschen Typen verwendet. Jetzt bekomme ich mit meinem Code das gewünschte Verhalten, sprich es werden die Exceptions geworfen, falls ein Typ unbekannt ist.
der wegen des fehlenden KnownType-Attributes in einer SerializationException resultiert. Wenn du das hast, kannst du deine TestCases anpassen und dann deine DataContracts vervollständigen
Genau das möchte ich erreichen und ich hatte gehofft das ein serialisieren mit dem DataContractSerializer die Exception werfen würde im Fehlerfall.
Ich stehe gerade auf dem Schlauch wie ich diese Exceptions herauskitzeln könnte.
ps: Der UnitTest dazu sieht so aus:
static Object[] DataContractTypes =
{
new Object[] {new ItemContainerDTO()},
new Object[] {new ItemContainerDTO()},
new Object[] {new DownloadDocumentDTO()},
new Object[] {new UploadDocumentDTO()},
new Object[] {new DocumentItemContainerDTO()},
new Object[] {new DocumentResponseContainerDTO()},
new Object[] {new ResponseContainerDTO()},
new Object[] {new UploadDocumentResponseContainerDTO()}
};
[TestCaseSource("DataContractTypes")]
public void ReflectionTest<T>(T source) where T : class
{
// Arrange
ReflectionEqualityComparer<T> comparer = new ReflectionEqualityComparer<T>();
// Act
T deserializedObject = DataContractTestHelper.DataContractSerializationRoundTrip<T>(source);
// Assert
Assert.IsTrue(comparer.Equals(source, deserializedObject));
}
ich würde gerne per Unit Test die Serialisierung/Deserialisierung meiner WCF Contract Klassen testen.
Um die De-/Serialisierung zu testen, kommt folgende Hilfefunktion zum Einsatz:
public static T DataContractSerializationRoundTrip<T>(T obj, IEnumerable<Type> knownTypes = null)
{
T result = default(T);
var serializer = new DataContractSerializer(obj.GetType());
using (MemoryStream memoryStream = new MemoryStream())
{
serializer.WriteObject(memoryStream, obj);
memoryStream.Position = 0;
result = (T)serializer.ReadObject(memoryStream);
}
return result;
}
Das funktioniert für alle meine Typen ohne Probleme.
Zur Laufzeit wirft mein WCF Service am Client allerdings die Fehlermeldung, dass ein nicht erwarteter Typ gefunden wurde und ich diesen doch bitte zur Liste der "KnownTypes" hinzufügen soll. Wenn ich das mache klappt es natürlich wieder, allerdings würde ich gerne etwas Prophylaxe betreiben und diese Fehler bereits per Unit Tests finden.
Wie kann ich also die tatsächliche Serialisierung "simulieren" für den Unit Test?
ich schreibe zur Zeit an einem WebSocket und würde diesen aus Gründen der Einfachheit gerne durch meinen bereits existierenden WebApi Service hosten lassen.
Webserver ist der IIS ab Version 8.
Der "Handshake" funktioniert soweit auch gut mittels:
[HttpGet]
public HttpResponseMessage Connect()
{
if (HttpContext.Current.IsWebSocketRequest)
{
HttpContext.Current.AcceptWebSocketRequest(ProcessRequestInternal);
}
return new HttpResponseMessage(HttpStatusCode.SwitchingProtocols);
}
Ich bin diesen Weg gegangen, da mein Service sich bereits um die Authentifizierung meiner User kümmert. Dies wurde bisher per Basic-Http Authentication gemacht. Nun habe ich das Problem, dass ich den "Authorization: Basic blabla" Header nicht mehr mitsenden kann und somit sich der WebSocketController nicht mehr in meine Umgebung "passt".
Weiß jemand wie man das normalerweise macht? Per JavaScript WebSocket Objekt kann man z.B. keine Http-Header setzen. ;-(
Es ist nur so das ich nicht steuern kann wann welcher Test ausgeführt wird und die einzelnen SUTs verwenden Zugriffe auf window["MyGlobal"]. Ich möchte gerne erreichen das jeder Test seine eigene globale Umgebung erhält. Leider kriege ich das unter TypeMoq nicht hin. Deswegen die Frage
let globalMock = TypeMoq.GlobalMock.ofType2<IMyGlobal>('MyGlobal', window);
Das funktioniert soweit auch ganz gut, allerdings bekomme ich mit mocha race conditions, da sich mehrere Tests wohl parallel das globale Objekt "kaputt" schreiben.
Nun habe ich auf der Doku-Seite von TypeMoq etwas von GlobalMock + GlobalScope gesehen und getestet, bekomme dieses "Sandbox" verhalten allerdings nicht hin. Wenn ich z.B. am Ende des Tests verifiziere, wie oft eine bestimmte Methode des Mocks aufgerufen wurde, dann sehe ich, dass alle Aufrufe addiert wurden und nicht in eigenen Scopes stattfanden.
Falls hier jemand Erfahrung hat, wie man am besten damit umgeht, wenn Tests sich mit globalen Objekten in die Haare kriegen, dann möge er dies bitte mitteilen. ;-)
Die Plugin Controller erben von einem Basis-Controller und dieser ist in einer "Basis-Dll" definiert.
Wenn nun diese Basis-Dll-Version aus z.B. firmenpolitischen Gründen erhöht wird, was geschieht dann mit abhängigen Assemblies?
Mir fallen zwei Lösungen spontan ein:
1. Die Plugin-Hersteller zwingen neu zu kompilieren.
2. Den Plugins sagen, dass sie nicht eine spezifische Basis-Dll referenzieren sollen.
ich habe eine ASP.NET Web Api Lösung die z.B. mit der Assembly Version 1.0 markiert wurde. Für diese Basis Dll wurden nun Plugin Controller entwickelt. Die Plugins verweisen auf die Basis Dll. Wenn ich nun eine neue Version 2.0 der Web Api veröffentliche, wie kann ich dann sicher stellen, dass die alten Plugins weiterhin funktionieren?
Eine Neukompilierung aller Plugins kommt nicht in Frage.
ich schraube zur Zeit an einem WiX Setup und installiere mit Hilfe des Setups Visual Studio Projektvorlagen.
Dazu verwende ich diese Custom Action aus der WixVSExtension Biblio:
<CustomActionRef Id="VS2015InstallVSTemplates" />
Leider ist dieser Aufruf seeeeehr laaaangsam. Ich spreche von ca. 5 Minuten. Egal auf welchem System installiert wird.
Das Setup macht zwar was es soll und die Templates werden anschließend auch im Studio angezeigt, doch das Setup ist so nicht ertragbar. Selbiges passiert dann auch beim deinstallieren.
Die Projektvorlagen sind geradezu winzig. Nur ein paar KB groß.