Quartznet: Unterstützung für .NET Core oder vNext

Ich hatte einige Versuche, entschied mich aber, auf RC2 zu warten, da die Dinge im Moment ziemlich instabil zu sein scheinen. Hoffentlich wird v3 zumindest eine begrenzte Unterstützung dafür haben.

Danke für die schnelle Antwort.

Open-Source-Projekte wie wir (und viele andere) sind auf Quartz.NET angewiesen. Da Quartz.NET ein Framework ist (im Gegensatz zu Webanwendungen), wäre es spannend zu sehen, dass Quartz .NET Core unterstützt.

Ohne Quartz ist es für viele Webanwendungen (wie unsere) fast unmöglich, .NET Core zu unterstützen. Wir warten sehnsüchtig auf die Veröffentlichung von v3 und freuen uns darauf, auf jede erdenkliche Weise dazu beizutragen.

Hallo @lahma , ich bin Mitglied des .NET Customer Success Teams von Microsoft. Mein Team arbeitet unter anderem daran, sicherzustellen, dass nützliche Bibliotheken von Drittanbietern mit .NET Core und dem .NET Standard Profile funktionieren. Als Teil davon möchte ich Ihnen helfen, Quartz.Net auf .NET Core auszuführen.

Ich habe einige grobe Prototypen in einem verzweigten Zweig erstellt und habe grundlegende Szenarien am Laufen. Als Beispiel ist hier ein Screenshot eines einfachen Schedulers, der einen SQL Server-Jobspeicher verwendet, der unter Ubuntu ausgeführt wird:

Wie Sie in einem anderen Thread festgestellt haben, fehlen in .NET Core eine Reihe von Dingen oder sie wurden geändert. Es bleibt also noch einiges an Arbeit, um alles zum Laufen zu bringen. Ich denke, die meiste Arbeit wird sein:

• Entfernen von Remote-Abhängigkeiten. Die Remoting-Nutzung in Quartz.Net ist ziemlich einfach, so dass sie wahrscheinlich durch HTTP-Anfragen ersetzt werden kann. Das erfordert jedoch eine faire Neufassung des Remote-Schedulers.
• Ersetzen Sie die System.Net.Mail-Nutzung durch eine Drittanbieter-Alternative wie MailKit
• Aktivieren der Datenbankintegration. Ich habe bereits eine neue .NET-Standard-kompatible dbproviders.properties-Datei erstellt, mit der SQL Server funktioniert. Wir sollten auch Unterstützung für SQLite und PostgreSQL hinzufügen. Andere arbeiten noch nicht mit .NET Core, obwohl einige hoffentlich bald folgen werden.
• Überprüfen und bereinigen Sie einige meiner bisherigen Änderungen. Ich habe einige schnelle Änderungen vorgenommen, damit der SimpleThreadPool auf .NET Core funktioniert (da der CLRThreadPool dort nicht funktioniert), aber wir sollten zurückgehen und eine ordnungsgemäße .NET Core-kompatible IThreadPool-Implementierung erstellen.
• Migrieren Sie Tests zu .NET Core und beseitigen Sie die unvermeidlichen Fehler.

Hier ist ein Unterschied zwischen Quartznet/Quartznet-3 und meinem Entwicklungszweig. Es gibt viele Änderungen, aber die meisten haben mit den Serialisierungsänderungen, verschiedenen API-Ersetzungen oder dem Deaktivieren von Funktionen (wie Remoting) zu tun, die wir in Zukunft auf andere Weise wieder aktivieren müssen. Ich habe all diese 'Zukunftsarbeit'-Spots mit Kommentaren markiert, die "TODO (NetCore Port)" enthalten.

Wären Sie bereit, wenn ich hier mitmache? Letztendlich gehört Quartz.Net Ihnen und Ihnen, aber ich helfe Ihnen gerne dabei, einen Teil der Arbeit zu erledigen, um es auf .NET Core zum Laufen zu bringen.

@mjrousos , es fühlt sich großartig an, wenn jemand von Microsoft auftaucht und Open-Source-Frameworks beisteuert und unterstützt. Ich bin dankbar und froh, Sie zu sehen. Hut ab für die geleistete Arbeit!

Danke, @frapid. Ich freue mich sehr über alle Änderungen im Framework in letzter Zeit und freue mich, die Gelegenheit zu haben, beim Aufbau des .NET Core-Ökosystems mitzuwirken.

Zum Thema Remoting-Schnittstelle habe ich einige Rückmeldungen. Es war großartig, es zu haben, und ich habe es immer noch in der Produktion im Einsatz, aber ich hätte viel lieber eine HTTP-basierte API. Eine binäre Abhängigkeit von Quartz in einem Überwachungsclient annehmen zu müssen, war unbequem. Es fühlt sich vernünftig an, dass dies ein separates Paket ist, finden Sie nicht?

@mjrousos das sind tolle Neuigkeiten! Ich freue mich sehr, dass Sie sich dafür interessieren und helfen. Ich werde Ihre Änderungen durchgehen und daraus lernen und eventuell noch weitere Fragen stellen. Ich hatte einen flüchtigen Blick und sieht wirklich gut aus.

Einige Gedanken, die ich teilen möchte, die möglicherweise Bedeutung haben oder nicht:

• Ich würde dies gerne früher oder später in den v3-Zweig aufnehmen, @danielmarbach hat bei der
• Web-API-basierte Schnittstelle ist im Rahmen des Quartz.Web-Projekts in Arbeit, jetzt als Plugin - Remoting kann wahrscheinlich aus v3 vollständig entfernt werden
• SendMailJob hat die System.Net.Mail-Abhängigkeit und den Job, der aus dem Kern herausgenommen und als Codebeispiel angeboten werden kann, das auf der Verbraucherseite der Bibliothek neu implementiert werden kann
• Die binäre Serialisierung wird hier ein großer Schmerzpunkt sein, v2-Daten befinden sich in der Datenbank im Binärformat und die Migration von einem Format in ein anderes (binär zu JSON) könnte sich als schwierig erweisen
  
  
  
  • nur etwas, das von meiner Seite etwas Nachdenken erfordert
  
  

Haben Sie eine Art Zeitrahmen, um an diesem oder einem anderen Ziel zu arbeiten, in dem Sie bereit sind, Änderungen als „bereit für die Zusammenführung“ zu melden? Da wir jede Hilfe in Anspruch nehmen, die wir bekommen können, bin ich auch damit einverstanden, die Änderungen einzubringen und zu reparieren, wenn Sie begrenzt sind.

Und wieder einmal bin ich super dankbar für die Hilfe und weiß es zu schätzen. Ich hätte wahrscheinlich unzählige Stunden gebraucht, um herauszufinden, wie man mit RC2 umgeht (mit RC1 gab ich nach einigen Kämpfen auf).

Es ist sinnvoll, Dinge in den v3-Zweig (oder möglicherweise einen Quarznet-Zweig davon) einzubinden, damit wir sicherstellen können, dass die Dinge mit asynchronen Änderungen funktionieren. Ich habe versucht sicherzustellen, dass die ursprüngliche Quarz.sln-Lösung weiterhin wie zuvor erstellt und funktioniert, aber wir sollten dies vor dem Zusammenführen noch einmal überprüfen. Irgendwann wird alles direkt aus der Datei project.json erstellt, aber es ist wahrscheinlich Es ist sinnvoll, den alten Build-Prozess kurzfristig am Laufen zu halten, während wir alles verschieben.

Wenn Remoting (und in geringerem Maße Post) aus dem primären Quarzprojekt entfernt werden kann, wird die Portierung viel einfacher. Ich sehe keinen Grund dafür, dass ein Web-API-Plug-In oder MailKit-Plug-in später nicht mit .NET Core funktioniert.

Ich denke, Sie haben Recht, dass Serialisierung und Threading als die beiden Hauptbereiche für die Arbeit im neuen Modell belassen werden. Leider ist es wahrscheinlich nicht realistisch, dass die .NET Core-Implementierung von Quartz mit Daten arbeitet, die mit dem Binärformatierer serialisiert wurden. Ich denke, es gibt ein paar Möglichkeiten -

1. Die einfachste Lösung besteht darin, den Kunden mitzuteilen, dass die neue .NET Core-Implementierung von Quartz.Net keine Datenbankinformationen aus früheren Versionen der Bibliothek verwenden kann und sie mit der Verwendung der .NET Core-Version warten sollten, bis sie mit einer neuen Version beginnen können Datenbank.
2. Die Json-Serialisierung könnte in der vollständigen Desktop-Version der Bibliothek sehr einfach aktiviert werden, sodass möglicherweise eine Konfigurationseinstellung für Desktop-Quartz.Net hinzugefügt werden könnte. Wenn der Benutzer die binäre Serialisierung wählt, erhält er einige Größenvorteile (und Abwärtskompatibilität), aber wenn er sich für die Json-Serialisierung entscheidet, kann er die Datenbank zwischen Desktop- und .NET Core-Implementierungen von Quartz.Net freigeben.
3. Wenn alte Datenbankinformationen migriert werden müssen, um mit dem neuen .NET Core Quartz.Net zu arbeiten, ist es möglicherweise möglich, ein eigenständiges .NET-Desktoptool zu erstellen, das die Konvertierung durchführt. Wir müssten jedoch mehr über dieses Szenario nachdenken.

Aus Zeitgründen werde ich wohl in den nächsten Wochen mindestens die Hälfte meiner Zeit oder mehr in dieses Projekt investieren können. Danach werde ich wahrscheinlich andere Projekte haben, die meinen Fokus benötigen, aber ich kann mich weiterhin einige Stunden pro Woche mit Quartz.Net beschäftigen, bis die Portierung abgeschlossen ist. Was den Zeitpunkt angeht, an dem wir Dinge zusammenführen sollten, ich denke, Sie haben Recht, dass früher besser ist, aber lassen Sie uns zuerst überprüfen, ob sich in der Desktop-Quartz.Net-Implementierung nichts versehentlich zurückgebildet hat.

Bitte lassen Sie mich auch wissen, wenn Sie Fragen haben, während Sie meinen Code durchsehen. Wenn es helfen würde, richte ich gerne einen Anruf ein, um die Änderungen zu besprechen. Sie finden meine E-Mail-Adresse in meinem GitHub-Profil, wenn Sie so etwas arrangieren möchten.

Warum überhaupt eine Standardserialisierung? Sie können die Abstraktion einfach im Kern haben und der Serializer ist ein Plugin, das beim Einrichten als Parameter obligatorisch ist.

Am 27.04.2016 um 17:48 schrieb Mike Rousos [email protected] :

Es ist sinnvoll, Dinge in den v3-Zweig (oder möglicherweise einen Quarznet-Zweig davon) einzubinden, damit wir sicherstellen können, dass die Dinge mit asynchronen Änderungen funktionieren. Ich habe versucht sicherzustellen, dass die ursprüngliche Quarz.sln-Lösung weiterhin wie zuvor erstellt und funktioniert, aber wir sollten dies vor dem Zusammenführen noch einmal überprüfen. Irgendwann wird alles direkt aus der Datei project.json erstellt, aber es ist wahrscheinlich Es ist sinnvoll, den alten Build-Prozess kurzfristig am Laufen zu halten, während wir alles verschieben.

Wenn Remoting (und in geringerem Maße Post) aus dem primären Quarzprojekt entfernt werden kann, wird die Portierung viel einfacher. Ich sehe keinen Grund dafür, dass ein Web-API-Plug-In oder MailKit-Plug-in später nicht mit .NET Core funktioniert.

Ich denke, Sie haben Recht, dass Serialisierung und Threading als die beiden Hauptbereiche für die Arbeit im neuen Modell belassen werden. Leider ist es wahrscheinlich nicht realistisch, dass die .NET Core-Implementierung von Quartz mit Daten arbeitet, die mit dem Binärformatierer serialisiert wurden. Ich denke, es gibt ein paar Möglichkeiten -

Die einfachste Lösung besteht darin, den Kunden mitzuteilen, dass die neue .NET Core-Implementierung von Quartz.Net keine Datenbankinformationen aus früheren Versionen der Bibliothek verwenden kann und sie mit der Verwendung der .NET Core-Version warten sollten, bis sie mit einer neuen Version beginnen können Datenbank.
Die Json-Serialisierung könnte in der vollständigen Desktop-Version der Bibliothek sehr einfach aktiviert werden, sodass möglicherweise eine Konfigurationseinstellung für Desktop-Quartz.Net hinzugefügt werden könnte. Wenn der Benutzer die binäre Serialisierung wählt, erhält er einige Größenvorteile (und Abwärtskompatibilität), aber wenn er sich für die Json-Serialisierung entscheidet, kann er die Datenbank zwischen Desktop- und .NET Core-Implementierungen von Quartz.Net freigeben.
Wenn alte Datenbankinformationen migriert werden müssen, um mit dem neuen .NET Core Quartz.Net zu arbeiten, ist es möglicherweise möglich, ein eigenständiges .NET-Desktoptool zu erstellen, das die Konvertierung durchführt. Wir müssten jedoch mehr über dieses Szenario nachdenken.
Aus Zeitgründen werde ich wohl in den nächsten Wochen mindestens die Hälfte meiner Zeit oder mehr in dieses Projekt investieren können. Danach werde ich wahrscheinlich andere Projekte haben, die meinen Fokus benötigen, aber ich kann mich weiterhin einige Stunden pro Woche mit Quartz.Net beschäftigen, bis die Portierung abgeschlossen ist. Was den Zeitpunkt angeht, an dem wir Dinge zusammenführen sollten, ich denke, Sie haben Recht, dass früher besser ist, aber lassen Sie uns zuerst überprüfen, ob sich in der Desktop-Quartz.Net-Implementierung nichts versehentlich zurückgebildet hat.

Bitte lassen Sie mich auch wissen, wenn Sie Fragen haben, während Sie meinen Code durchsehen. Wenn es helfen würde, richte ich gerne einen Anruf ein, um die Änderungen zu besprechen. Sie finden meine E-Mail-Adresse in meinem GitHub-Profil, wenn Sie so etwas arrangieren möchten.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an

Ich habe eine Pull-Anfrage erstellt, um die Änderungen zu besprechen: #359 . Ich kommentierte einige Sachen, als sie vorbeikamen, wiederholte sie nicht, als ich das gleiche zum zweiten / dritten Mal sah. Jeder ist herzlich eingeladen, mitzumachen und mein Geschwafel zu lesen. Allgemeine Beobachtungen:

• Wir können wahrscheinlich die Serialisierung für Ausnahmen fallen lassen
• Entfernte Teile können entfernt werden, REST'ish Web API kann verfügbar gemacht werden
• Viele DataMember-Attribute.. was ich für private Mitglieder verstehe, aber hoffentlich können wir auf der Seite von Json.NET konfigurieren
• Wie in meinem Rezensionskommentar erwähnt und wie @danielmarbach auch hier, ich denke, wir könnten die Auswahl der Serialisierungsstrategie einfach obligatorisch machen, der Benutzer muss dort eine fundierte Entscheidung treffen
• Die neue SimpleThreadPool-Implementierung ist ein großes fehlendes Glied (kontrollierbare Thread-Anzahl, Prioritäten usw.)

Wir können besorgniserregende Datenbankmigrationen einem späteren Stadium überlassen. Ich würde dieses Land gerne bald im v3-Zweig sehen.

Insgesamt tolle Arbeit! :+1:

Groß; danke, @lahma. Ich werde mir die PR anschauen und auf Kommentare antworten. Und ich stimme zu, dass es sinnvoll sein kann, die Serialisierung einfach steckbar zu machen und die Benutzer auswählen zu lassen, was sie verwenden möchten.

Eine andere Sache, die ich vergessen habe zu erwähnen, ist, dass ich .NET Core RC2-Ziele verwende. Um das Projekt zu erstellen, benötigen Sie also das RC2-SDK . Wir haben noch keine RC2-Visual Studio-Tools veröffentlicht (sollten in Kürze erscheinen), daher kann die .NET Core-Version der Bibliothek derzeit nur über die Befehlszeile erstellt werden (dotnet restore, dotnet build, dotnet pack).

Wir warten sehnsüchtig auf Quartz.net, damit unsere Lösung auf vNext portiert wird.

Könnten wir einen Alpha-Build im Nuget haben, damit die Leute zumindest auf ihre Projekte verweisen und sie kompilieren können?

Hoffentlich können wir in den nächsten Wochen etwas in Alpha-Qualität herausbringen, damit Sie die Reifen loswerden können. Die API wird jedoch nicht stabil sein und es wird keine Unterstützung für die Fernverwaltung geben.

Persönlich denke ich, dass die Remoteverwaltung aus der coreclr-Version herausbleiben könnte. Ich würde denken, dass die Leute das sowieso mit einer MVC-App umgehen möchten. Das sollte kein Quarzproblem sein.

Für IThreadPool habe ich eine Version geschrieben, die auf Aufgaben basiert, die ich bei Interesse zurücktragen könnte.

Bringen Sie es herein. Ich habe vor, es zu überarbeiten, aber derzeit im Militärdienst. Werde es in 2 Wochen ca. wieder aufnehmen

Am 30.04.2016 um 13:12 schrieb Shaun Becker [email protected] :

Für IThreadPool habe ich eine Version geschrieben, die auf Aufgaben basiert, die ich bei Interesse zurücktragen könnte.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an

Ich habe auch eine IThreadPool-Implementierung mit Aufgaben. Ich habe es der laufenden .NET Core PR hinzugefügt, aber Sie können auch hier nachsehen, um nur die IThreadPool-bezogenen Änderungen zu sehen. @smbecker , @danielmarbach , schau doch mal

Ich habe gerade die ersten Änderungen von @mjrousos übernommen . Sie sind ab sofort in der Quartznet-3-Filiale erhältlich. Dies wird die Zusammenarbeit wahrscheinlich erleichtern, da jetzt der "große Wandel" bereits erfolgt ist. Wir können die Lösung weiter verfeinern und optimieren.

Ich werde versuchen, als nächstes einen funktionierenden POC zum Ersetzen der Remoting-Bits zu erstellen.

:+1:

Am 03.05.2016 um 06:53 schrieb Marko Lahma [email protected] :

Ich habe gerade die ersten Änderungen von @mjrousos übernommen . Sie sind ab sofort in der Quartznet-3-Filiale erhältlich. Dies wird die Zusammenarbeit wahrscheinlich erleichtern, da jetzt der "große Wandel" bereits erfolgt ist. Wir können die Lösung weiter verfeinern und optimieren.

Ich werde versuchen, als nächstes einen funktionierenden POC zum Ersetzen der Remoting-Bits zu erstellen.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an

Danke, @lahma! Lassen Sie mich wissen, wenn Sie Fragen zu .NET Core haben, während Sie am Ersetzen von Remoting-Bits arbeiten.

Meine Idee dafür war, die API so umzugestalten, dass, sobald ein Scheduler für den Empfang von Remoteverbindungen eingerichtet wurde, ein ASP.NET Core IWebHost , das eingehende HTTP-Anforderungen (mithilfe des Kestrel-Servers) verarbeitet. Ich hatte ursprünglich beabsichtigt, Web-Sockets zu verwenden, aber es sieht so aus, als ob Web-Sockets noch nicht plattformübergreifend funktionieren . Ich habe also eine einfachere Lösung prototypisiert, die nur ein JSON-Objekt im Anforderungstext akzeptiert, das die aufzurufende Methode und die an die Methode zu übergebenden Argumente angibt.

Um dies zu testen, habe ich eine einfache .NET Core RC2-„gemeinsam genutzte Liste“ erstellt, die nur eine Liste istdie es Remote-Maschinen ermöglicht, eine Verbindung herzustellen, um die Liste anzuzeigen/zu bearbeiten. Sie können sich den (etwas unordentlichen) Code hier ansehen.

Hier sind die relevanten Auszüge aus diesem Beispiel:
In meinem einfachen Prototyp sieht das Einrichten von IWebHost aus:

``` C#
host = neuer WebHostBuilder()
.UseServer("Microsoft.AspNetCore.Server.Kestrel")
.Konfigurieren(App =>
{
// Middleware-Funktion zur Verarbeitung eingehender Anfragen
app.Use(async (HttpContext-Kontext, Funcweiter) =>
{
if (context.Request.Path.Value == Pfad && context.Request.ContentLength > 0)
{
// Den Rumpf der Anfrage in ein InvokeRequest-Objekt (eine von uns definierte Klasse) deserialisieren
InvokeRequest invokeRequest = default(InvokeRequest);
invokeRequest = (InvokeRequest)invokeRequestSerializer.ReadObject(context.Request.Body);

            object reply = null;
            // Try to dispatch the call
            if (Invoke(invokeRequest, ref reply))
            {
                // I used DCS in my prototype, but probably we should use JSON.NET since Quartz.Net already uses it elsewhere
                var replySerializer = new DataContractJsonSerializer(reply.GetType());
                using (var ms = new MemoryStream())
                {
                    replySerializer.WriteObject(ms, reply);
                    await context.Response.WriteAsync(new string(Encoding.UTF8.GetChars(ms.ToArray())));

                    // Halt the HTTP request processing pipeline
                    return;
                }
            }
        }
        await next();
    });
})
.Start(new[] { $"http://0.0.0.0:{port}" });

``` C#
private bool Invoke(InvokeRequest invokeRequest, ref object reply)
{
    // In my simple test, the methods that could be invoked were just simple APIs to manipulate a list.
    // In the real Quartz.Net product, we will need to support more methods. Because of that, it may make sense to just use reflection to build the list of APIs that can be called dynamically when the host starts.
    switch (invokeRequest.MethodName)
    {
        case "Add":
            Console.WriteLine("Invoking 'Add'");
            list.Add(invokeRequest.Arguments[0] as string);
            return false;
        case "GetEnumerator":
            Console.WriteLine("Invoking 'GetEnumerator'");
            reply = list.ToArray();
            return true;
        default:
            Console.WriteLine($"Unknown method: {invokeRequest.MethodName}");
            return false;
    }
}    

C# public struct InvokeRequest { public string MethodName { get; set; } public object[] Arguments { get; set; } }

Um die Remote-Aufrufe zu tätigen, kann der Remote-Client einfach ein HttpClient , um die vom Server eingerichteten Endpunkte aufzurufen.

Das scheint eine Menge Arbeit und eine Menge schwerer Abhängigkeiten zu erfordern. Wie bereits erwähnt, würde ich die Remoteverwaltungsteile von Quartz für .NET Core auf eine niedrigere Priorität setzen. Oder zumindest in eine separate Bibliothek auslagern. Ich stelle Quartz sowieso immer mit meiner eigenen ReST-API vor.

Zugegeben, @smbecker. Ich weiß nicht, dass es zur Laufzeit ressourcenintensiver ist als Remoting im alten Stil, aber es ist definitiv ein bisschen Code und würde viele Änderungen erfordern. Wenn Quartz.Net on Core sich auf diese Weise von älteren Quartz.Net-Produkten unterscheidet, ist es wahrscheinlich ein guter Kandidat für die Ausgliederung in eine eigene Bibliothek.

@smbecker das ist wahr, ich würde gerne mal ein paar Checks darüber machen, was machbar wäre. Remote-Scheduler werden verwendet, und einige, die keine Zeit haben, um alles zu verpacken, sind darauf angewiesen, etwas sofort einsatzbereit zu haben. Wie auch immer, ich sehe fehlendes Remoting für eine Weile nicht als Showstopper für den Versand früher Builds. VS-Tooling und Stabilität wären von Core zuerst nett :smile:

@mjrousos Ich

Das klingt so, als ob es funktionieren könnte (und ASP.NET-Abhängigkeiten aus der Kernbibliothek entfernen würde, was gut wäre). Wenn Sie auch die HttpClient-Abhängigkeit in Quartz.Net nicht haben möchten, könnten Sie wahrscheinlich auch eine separate Bibliothek für den Client haben und einen vom Standard abgeleiteten untergeordneten Scheduler erstellen lassen. Vertrags-DTOs sind sinnvoll, aber sie könnten mit protected markiert werden, wenn wir sie in untergeordneten Implementierungen verwenden möchten.

Ich denke, das Entfernen der HttpClient-Abhängigkeit hat eine niedrigere Priorität als das Herausziehen des HTTP-Servers, aber es würde helfen, eine bessere Schichtung zu haben. Unabhängig davon, wie Sie es gestalten, hängt das Client-Teil implizit vom Server-Teil ab (wenn sich die Web-API ändert, müssen Sie den Client entsprechend aktualisieren). Wenn die Quartz.Net-Kernbibliothek den Clientcode enthält, muss sie möglicherweise aktualisiert werden, wenn die Serverbibliothek aktualisiert wird, und das scheint ein wenig rückwärts zu sein.

Habe gerade gesehen, dass RC2 ausgefallen ist und wollte sehen, ob Quartz.net .net Core bereit ist, und bin froh zu sehen, dass es so vorankommt.

Gibt es dazu jetzt irgendwelche Neuigkeiten (ich weiß erst seit einer Woche) .Net Core ist bei 1.0.0?

Wenn ich versuche, "dotnet restore" auszuführen, erhalte ich eine Fehlermeldung, dass Quartz 2.3.3 das Framework .NetStandard, Version=v1.6 nicht unterstützt.

Bitte bitte bitte, ich brauche das wirklich, um für .Net Core zu arbeiten. :)

Es ist noch keine NuGet-Vorabversion verfügbar, daher muss aus dem Quellcode erstellt werden. Ich hoffe, dass ich bald die Zeit habe, Pre-Release-Alpha herauszubringen (TM).

Ich habe versucht, aus dem Quellcode zu erstellen, aber es sieht nicht so aus, als ob Sie auf externe DLLs in einem .NET Core-Projekt verweisen können (zumindest kann ich es nicht zum Laufen bringen) und ich kann den Code nicht aus .NET kompilieren Kernprojekt, für den Anfang, weil das Common.Logging Nuget-Paket auch noch nicht kompatibel ist. Vielleicht habe ich nicht die nötige Erfahrung, um es durchzuziehen...

@robborden Hast du den Ast Quartznet-3 gezogen? Das ist der Zweig, der in .Net Core baubar sein sollte. (Ich spiele gerade damit in einem Projekt, das ich baue und es funktioniert).

Danke @cjnanda , das werde ich mal ausprobieren.

Alpha 1 ist bei NuGet gelandet, bitte beachten Sie die Ankündigung . Es gibt noch viel zu tun, aber jetzt sollte es einfacher sein, die Reifen zu treten.

Einige Notizen:

• Quartz.Serialization.Json als separates Paket getrennt, Quartz selbst hat keine Abhängigkeiten mehr wie JSON.NET
• Remote-Alternative nicht bereit
• Es wird Drachen geben

Fantastisch! Es ist großartig, Bits zu sehen, die die Leute ausprobieren können.

Nachdem 2.4 veröffentlicht wurde, habe ich den v3-Zweig mit Master zusammengeführt. Alle v3-Arbeiten sind jetzt gegen den Master.

Ich werde es auch ausprobieren!

Irgendwelche Gedanken zu einer ETA für v3 oder wie stabil sie für den Produktionseinsatz ist? Ich interessiere mich sowohl für die Netstandard- als auch für die Async-Unterstützung.

Beeindruckend. Komisch seit Oktober letzten Jahres, der einzige Kommentar, der danach fragt, ist am selben Tag (und zu derselben Stunde) ich komme, um danach zu suchen!

Tolle Arbeit Leute. Haben Sie eine Idee, wann wir eine Produktionsversion von .NET Core (Quartz.NET 3.0) haben werden?

Haben Sie eine Idee, wie weit davon entfernt ist oder ob Hilfe benötigt wird, um es fertig zu stellen? Es wäre toll, einige unserer Nutzungen aktualisieren zu können. z.B. https://github.com/MassTransit/MassTransit/issues/909

Nur um hier ein Update zu geben, ich hatte etwas Zeit, um aktuelle Probleme mit 2.x und 3.0 auszubügeln, aber beim nächsten alpa geht es hauptsächlich um Bugfixes und .net Core 2 Support + API Cleanup. Hoffentlich schaffe ich bald die nächste Alpha (mein Sommerurlaub neigt sich dem Ende zu).

@lahma Ich wollte mich nur bei diesem Projekt bedanken und für den .net-Standardsupport arbeiten! Betreibe seit einigen Monaten 3.0.0 alpha 2 in Docker + Postgres + Clustered-Umgebung und funktioniert größtenteils einwandfrei. Ich freue mich auf die Unterstützung von .net Core 2. 👏

Und 3.0 Alpha 3 ist raus! Wie immer sind alle Rückmeldungen und Tests von unschätzbarem Wert, bitte treten Sie die Reifen ab und sehen Sie, wie es sich schlägt.

Ich schließe das Problem, da .NET Core-Unterstützung vorhanden ist, ich habe gerade Beta 1 verfügbar gemacht .

Hi,

von: https://github.com/quartznet/quartznet/issues/355#issuecomment -215127050

1. Wenn alte Datenbankinformationen migriert werden müssen, um mit dem neuen .NET Core Quartz.Net zu arbeiten, ist es möglicherweise möglich, ein eigenständiges .NET-Desktoptool zu erstellen, das die Konvertierung durchführt. Wir müssten jedoch mehr über dieses Szenario nachdenken.

Wurde dieses Tool jemals erstellt? Wir stehen vor diesem Szenario.
Wenn nicht, gibt es eine empfohlene Methode, dies zu erreichen?
Wäre für jede Info dankbar.

Danke im Voraus,
Eyal