Jetzt verfügbar:  Berichte für DRACOONMehr Infos

C# SDK: Upload file

Kommentare

5 Kommentare

  • Avatar
    DAVISOL - Sebastian Hübner

    Hi Quirin,

    mit dem folgenden Code sollte es klappen, auch die Node-Information zur hochgeladenen Datei zu erhalten:

    // input variables, see ctor of FileUploadRequest for further information
    long targetNodeId = 123L;
    string targetFileName = "helloworld.txt";
    var classification = Dracoon.Sdk.Model.Classification.Confidential;
    var resolutionStrategy = Dracoon.Sdk.Model.ResolutionStrategy.AutoRename;
    string fileNotes = null;
    DateTime? fileExpireAt = null;

    string sourceFilePath = @"C:\TEMP\test.txt";


    var request = new Dracoon.Sdk.Model.FileUploadRequest(targetNodeId, targetFileName, classification, resolutionStrategy, fileNotes, fileExpireAt);
    using (var reader = File.OpenRead(sourceFilePath))
    {
    var newFile = _client.Nodes.UploadFile(file.SourceFilePath, request, reader);

    // newFile is of type Dracoon.Sdk.Model.Node
    return newFile;
    }

     

    Hoffe das hilft weiter :-)

    Viele Grüße,
    Sebastian

    0
    Aktionen für Kommentare Permalink
  • Avatar
    Quirin Wierer

    ich habe die Variante aus der Antwort probiert. Ich bekomme aber das gleiche Phänomen. Es bleibt an der Zeile hängen:

    var newFile = _client.Nodes.UploadFile(file.SourceFilePath, request, reader);

    Auch hier funktioniert es wieder wenn der asynchrone Upload geladen wird. Meine Variante der Funktion:

    private static Node newfile(DracoonClient client,FileInfo file, long targetNodeId, string targetFileName) 

    var classification = Dracoon.Sdk.Model.Classification.Public; 
    var resolutionStrategy = Dracoon.Sdk.Model.ResolutionStrategy.AutoRename; 
    string fileNotes = "Test"; 
    DateTime? fileExpireAt = DateTime.Today.AddDays(14); 
    string sourceFilePath = file.FullName;

    var request = new Dracoon.Sdk.Model.FileUploadRequest(targetNodeId, targetFileName, classification, resolutionStrategy, fileNotes, fileExpireAt); 
    using (var reader = File.OpenRead(sourceFilePath)) 

    var newFile = client.Nodes.UploadFile(file.Name, request, reader,file.Length, callback: new ULCallback()); 
    // newFile is of type Dracoon.Sdk.Model.Node 
    return newFile; 

    }

    Viele Grüße

    Quirin

    0
    Aktionen für Kommentare Permalink
  • Avatar
    DAVISOL - Sebastian Hübner

    Hi Quirin,

    was passiert wenn du zusätzlich den callback-Parameter angibst? Wird dieser aufgerufen, wenn ja für welche Events?

    Beim Initialisieren des DRACOON Clients kannst du eine eigene Implementierung von Dracoon.Sdk.ILog mitgeben. Erhältst du über diese Schnittstelle während des problematischen Befehls irgendwelche Rückmeldungen?

    Außerdem kannst du probieren, als actionId (erster Parameter) nicht den Quellpfad sondern z.B. eine GUID anzugeben (so wie in deinem initialen Beispiel). Dadurch werden ggf. Probleme durch zu lange Texte oder ungültige Zeichen umgangen. Da war mein runtergetipptes Beispiel keine gute Vorlage ;-)

    Ein weiterer Versuch wäre, die tatsächliche Dateigröße (Parameter fileSize) mitzugeben. Bisher hatte ich jedoch noch kein Problem damit, diesen Parameter wegzulassen.

    Wenn das alles nix hilft, mag ein wenig experimentieren mit weiteren Schnittstellenparametern helfen:

    • ebenfalls bei der Initialisierung des Clients kann ein DracoonHttpConfig-Objekt mitgegeben werden. Insbesondere ChunkSize und ReadWriteTimeout können hier nützlich sein
    • da es bei asynchronen Operationen funktioniert (die technisch im SDK exakt den gleichen Code wie die synchrone Variante ausführt, den Aufruf jedoch in einem eigenen Thread startet), kann die Ursache evtl. auch im Aufbau deiner Anwendung liegen. Hier kann man z.b. über die Threads-Ansicht im Visual Studio kontrollieren welche parallelen Threads ggf. Einfluss nehmen

    Zuletzt kann auch Hilfe von außerhalb nützlich sein. Ich arbeite z.B. mit folgenden zusätzlichen Tools:

    • der Swagger-Dokumentation des SDKs (https://mein.dracoon.team/api), hier können Requests auch direkt getestet werden. Up- und Downloadoperationen sind da aber schwer umzusetzen
    • WhireShark und Fiddler zum Mitschneiden von Requests
    • Postman zum manuellen Ausführen von Requests

    Zur Fehlersuche bzw. Abgleich kannst du auch das SDK über GitHub lokal clonen. Dort findest du auch ein Beispielprojekt mit dem du im Debugger deinen Fall exemplarisch durchtesten kannst.

    Um in deinem Projekt das SDK zu debuggen, entferne einfach (temporär) das NuGet-Package und binde das lokal kompilierte SDK-Projekt als Projektreferenz ein. Dann kannst du im Visual Studio auch direkt in die SDK-Implementierung debuggen.

    HTH,

    Sebastian

    0
    Aktionen für Kommentare Permalink
  • Avatar
    Marvin Schuchardt

    Hallo, 

    die Anfrage war von mir. Ich habe es mit dem synchronen Upload nicht hinbekommen. Probiert habe ich noch das Mitgeben einer GUID und die Angabe der Filesize. Ein Threadingproblem kann ich auch ausschließen, da es einfach das Beispiel von Github war. Es gab keine weiteren Threads. 

    Ich habe das Problem nun so gelöst, dass ich nach dem asynchronen Upload in einer Schleife die Nodes nach dem Namen meines Uploads durchsuche. Das funktioniert gut. 

    Mfg Marvin 

    0
    Aktionen für Kommentare Permalink
  • Avatar
    Michael Netter

    Hallo Marvin,

    bei uns tritt das Problem mit dem GitHub-Code nicht auf.

    Kannst du ein vollständiges Mini-Beispiel posten, damit wir nachvollziehen können, wo das Problem liegt?

    Viele Grüße

    Michael

    0
    Aktionen für Kommentare Permalink

Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.