• Du befindest Dich hier:
• Community
• »
• Mitglieder
• »
• weismat
• »
• Beiträge von weismat

Ich möchte gerne mehrere unabhängige Grpc Services auf einem Host laufen lassen.
Kann ich das mit dem Grpc.AspNetCore Template machen oder eher nicht? Mir sind die Vorteile durch Grpc.AspNetCore gegenüber einem Console-Programm bisher nicht so ganz klar. Gibt es da eine Übersicht?

Würde mir an Deiner Stelle eher mar pp anschauen, um aus dem Perl Skript eine exe zu machen, die Du dann aufrufen kannst. Ist aber schon lange her, seit ich so etwas mal gemacht habe.

Ich würde mir auch R.NET anschauen - Skripte aufrufen würde bedeuten, daß Du keine Daten austauschen kannst.

Ich würde mir an Deiner Stelle mal Fidler ansehen - es gibt da auch Extensions, die automatisch den C# Code zum Recording aufzeichnen, um schnell ein Codegerüst zu bekommen.

Mit der VS Version hat das nix zu tun.
Du musst Dir per Nuget Google Protobuf installieren.
Alternativ kannst Du Protobuf-Net ein Tool zum Generieren der Klassen finden.

Gibt doch ein paar freie Alternativen.
Die würde ich an Deiner Stelle benutzen. Ich würde aber die Bibliothek gut nach außen abkapseln, so daß man im Zweifel leicht die Bibliothek wechseln kann, wenn sich da etwas ändert.

An Deiner Stelle würde ich etwas wie SignalR oder gRPC anstatt Sockets nehmen.
Wenn Du den Socket nimmst, dann musst vor allem entweder im Protokoll am Anfang die Länge mitteilen oder mit einem Trennzeichen arbeiten.
Du musst dann auf jeden Fall mehrfaches Lesen vom Socket implementieren, wenn Deine Nachrichten länger als die BufferSize sind.

Grpc.Tools

Im VS brauchst Du zwei Projekte.
Ein Class Library Projekt, in dem Du die Proto Datei hast. Mit der neuen Version der Tools musst Du die Proto Datei nur als Element in VS hinzufügen ("Add existiting item) - dann gRPC, gRPC Tools und Protobuf Nuget Paket hinzufügen und kompilieren.
Das zweite Projekt ist dann eine Consolen-Anwendung, die das Class Library Projekt referenziert und die gRPC und Protobuf Nuget Pakete referenziert. Du startest dann dort wie im Beispiel den Server.
In der Server Implementierung erbst Du von der Class Library die Server Implementierung und überschreibst die Methoden für die Funktionsaufrufe.

Die Beispiele sind sehr gut. Die Proto Dateien kann mit VSCode mit einem Plugin für Syntax-Highlighting erstellen.
Ich implementiere nur das Aufrufen des Proto Compilers als Pre-Build Event in Visual Studio, so daß der Build ohne Command Line auskommt:

cd $(ProjectDir)
$(SolutionDir)packages\Grpc.Tools.1.18.0\tools\windows_x86\protoc.exe   xxx.proto --csharp_out=$(ProjectDir) --grpc_out=$(ProjectDir) --plugin=protoc-gen-grpc=$(SolutionDir)packages\Grpc.Tools.1.18.0\tools\windows_x64\grpc_csharp_plugin.exe

Wenn es sich bei den beiden dlls um Assemblies handelt, dann könntest Du die mit ILMerge zusammenfassen.
Wenn die DLLs nativer Code sind, dann wüßte ich nicht, wie Du die Dlls statisch zusammenfügen kannst.

Selbst das Verdoppeln hat nicht geholfen - bin etwas ratlos.
Habe gesehen, daß Gamer Azure zum Spielen nutzen und das würde ich mit meinen Anforderungen vergleichen.

Ich versuche gerade eine 3rd Party App von einem lokalen PC auf Azure zu heben.
Zurzeit läuft die App auf einem Xeon 2630.
Obwohl ich schon F4 als Größe gewählt habe, gehen mir die CPU - Ressourcen aus. Ich vermute mal, daß es am fehlenden Turbo Boost liegt. Was würdet ihr mir für eine Maschinengröße empfehlen?

Direkt ist das nicht so einfach nicht möglich.
Es gibt aber das Nuget Paket System.Linq.Dynamic.Core, mit dem Du das machen kannst.

Probiere mal, ob Dir ein serialPort1.Flush() nach dem WriteLine() hilft.

Für solche Aufgaben solltest Du benchmarkdotnet nehmen.
StopWatch ist auch nicht sauber für das Messen von Microbenchmarks.

Würde an Deiner Stelle eher C# 7.0 in a Nutshell kaufen und mir dann das Kapitel über Networking anschauen, wenn Du neu anfängst.
Aktuell ändert sich gerade viel, da mit Dotnet Core und Pipelines neue Möglichkeiten kommen, die wirklich kniffligen Probleme wie BackPressure für Sockets im Framework abzuarbeiten.
Andere Möglichkeit wäre SimplSockets zu benutzen oder als Beispiel zu nehmen.

Habe das problematische Assembly nach dotnetstandard 2.0 migriert und da ist das Problem verschwunden.
Bei Kopieren des Codes in ein neues Projekt und beim Aufräumen von alten Versionsdateien habe ich gemerkt, dass die Bibliothek schon 8 Jahre alt ist ;-)

Unverwalteter Speicher ist Speicher, der nicht mit dem Garbage Collector überwacht wird.
Den bekommst Du entweder mit GCHandle.Alloc oder wenn Du mittels P/Invoke externen Code ausführst und Du dann einen Zeiger auf einen Speicherbereich bekommst.

Mit COREHOST_TRACE 1 sieht man etwas mehr - aber so richtig schlau hat mich das auch nicht gemacht.
Fusion Log gibt es nicht für Dotnet Core.

Ich hatte halt gehofft, dass ich ohne große Code-Änderungen auskomme.
Bei einer einzelnen Projekt-Abhängigkeit hatte ich kein Problem auch mit log4net gehabt.
Ich werde erstmal alles zu netstandard2 umändern und dann gegebenfalls auf Serilog wechseln.
Muss mir ohnehin noch anschauen, wie ETW mit DotNet Core funktioniert oder nicht.

Ich habe bei der Migration nach DotNet Core Probleme mit Type Initalization Exception/Method not Found mit log4Net - obwohl alle Äbhängigkeiten die letzte Version von log4Net benutzen.
Ich habe auch im Projekt in csproj

<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
<GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>

Danke für den Hinweis "Publish". Damit komme ich in der Tat weiter.
Mich hatte vor allem irritiert, daß ich einen Teil der dlls gesehen hatte.

In meiner produktiv Umgebung arbeite ich hinter einer Firewall, die keine Verbindungen zu nuget möglich macht.
Wenn ich nun in VS 2017 ein Dotnet Core Projekt baue, dann fehlen mir unter \bin\Release\netcoreapp2.1 viele MS dlls. Wie bekomme ich die nun alle in ein Verzeichnis, so dass ich via eines einzigen Archivs meine Applikation installieren kann?

Wie bekommt man denn am besten seine Nuget packages hinter die Firewall.
Das ganze .nuget/packages von der Entwicklermaschine kopieren wäre nicht sehr elegant.

Man muss tatsächlich

Ich bin gerade dabei mein erstes Dotnet Core Projekt fertigzustellen.
Da ich einen 32 bit DLL referenziere, muss ich die 32 Bit Runtime benutzen.
Wenn ich nun in den Projekt-Properties 32 Bit als Target angebe, dann bekomme ich bei dotnet run den Fehler

Quartz sehe ich relativ unkritisch, da das meiste alles beim Warmup passiert.

Wenn Du halbwegs deterministisch sein willst, dann solltest Du Dich vor allem beim Code zum Extrahieren der Daten und beim anschließenden Serialisieren anstrengen, effizient zu sein.
Da Du Dotnet Core 2.1 benutzt, solltest Du vor allem mit Span<T> arbeiten, damit Du nicht zu viele Arrays allozierst.

In jedem Fall würde ich Dir vor allem raten, daß Du mit BenchmarkDotnet für Performance Tests arbeitest und mit Perfview das Verhalten Deiner Applikation misst - insbesondere um das Verhalten das Garbage Collectors einschliesslich der Pausen nachvollziehen zu können.

In einer async Methode macht Task.Run keinen Sinn - Du bist ja schon der Stelle asynchron in einem eigenen Task, den hier die Textbox erstellt hat.

Ich persönlich benutze EPPlus für so etwas.
Man kann auch direkt das Office XML benutzen.
Bei 200.000 Spalten wirst Du vielleicht recht viel Speicher brauchen - aber das sollte sehr schnell sein.