Wie kann ich die Zeit in ms von Programmstart bis zum Folgetag 14:00 Uhr messen?

Ich möchte die Zeit in Millisekunden für ein Timer vom Programmstart bis zum darauffolgenden Tag 14:00Uhr messen.

Den nächsten Tag festzulegen war nicht schwer, aber irgendwie habe ich gerade ein Blackout. Wie kann ich die 14:00Uhr festlegen?
Womöglich recht simple, aber ich komm nicht drauf...

        public void TimeDiff_Update()
        {
            DateTime StartZeit, EndZeit; //EndZeit = nächster Tag 14.00Uhr
            StartZeit = DateTime.Now;
            EndZeit = StartZeit.AddDays(1);

           Hilfe 

            MessageBox.Show("Teststart: " StartZeit.ToString() + " Testende: " + EndZeit.ToString());
        }

Eigentlich hätte ein Blick in die Doku genügt, da wird das alles gezeigt.
DateTime und DateTimeOffset gehören zu den am besten dokumentierten Teilen überhaupt.

In .NET sollte man DateTimeOffset statt DateTime verwenden.
Ja, die Dokumentation ist hier etwas schwammig, dennoch gibt es deutlich den Hinweis:

These uses for DateTimeOffset values are much more common than those for DateTime values. As a result, DateTimeOffset should be considered the default date and time type for application development.

Wenn die Zeit abhängig vom User ist, dann kannst Du das entsprechend in der Berechnung anhand der Zeitzonen-Information beachten.

Da Du doch recht viele Basic Themen hast empfehle ich Dir, auch zu Deinem eigenen Interesse, dass Du Dir einfach regelmäßig mal die Microsoft Docs durchliest.
Du wirst nicht alles beibehalten, aber Du wirst vieles im Unterbewusstsein haben und dann im Fall der Fälle ein "Oh, da war doch was"-Gedanken haben.
Besonders bei den konzeptionellen Dingen wie DateTimeOffset.

DateTimeOffset now = DateTimeOffset.UtcNow;
DateTimeOffset tomorrow = now.AddDays(1);

DateTimeOffset tomorrow14 = new DateTimeOffset(tomorrow.Year, tomorrow.Month, tomorrow.Day, 
                                14, 00, 00, tomorrow.Offset);

Ansonsten hast Du leider nicht geschrieben, was Dein eigentliches Ziel ist.
Denn eine 100% exakte Millisekunden-Berechnnung (und Ausführung) ist aufgrund der Auflösung in Windows nicht möglich.

Okay ... ich werde das beherzigen - Danke.

Das Offset beträgt jetzt aber 00:00 - ist das richtig? Müsste da nicht die Länge der Zeitspanne stehen?

Zum Ziel:
Wir haben viele Nutzer, die das Tool nutzen würden und auf die Programmdatei per Verknüpfung im Gruppenlaufwerk zugreifen. Die Settings werden im eigenen Account gespeichert.
Wenn ich nun ein Update machen möchte, kann ich die Datei nicht überschreiben, weil irgendeiner diese offen in der Session hat.
Meine Idee ist folgende:

1. Ich setzte in einer Txt.Datei das Update-Signal 1 (1=steht bevor / 0=nichts)
2. wenn der Nutzer das Programm startet wird der Inhalt der Txt geprüft
   Wenn 1 dann startet ein Timer bis zum nächsten Tag 14:00 und schließt dann das Programm.
   So kann ich am nächsten Tag nach 14:00 ein neues Update einspielen.

Zumindest ist so der Plan....

Müsste da nicht die Länge der Zeitspanne stehen?

Wie Du der Doku in wenigen Sekunden entnehmen kannst bezieht sich das Offset auf UTC.
Da die Uhrzeit über UtcNow erstellt wurde ist respektive der Offset auch 0.

Daher mein Hinweis mit der Zeitzone des Benutzers; das hab ich schon bewusst dazu geschrieben.

Wir haben viele Nutzer, die das Tool nutzen würden und auf die Programmdatei per Verknüpfung im Gruppenlaufwerk zugreifen.

Das war noch nie eine gute Idee und wird auch niemals eine gute Idee sein. So funktioniert keine ordentliche Applikationsverteilung.
Zudem spielt Dir die Windows Sicherheitseinstellungen hier rein, weil Laufwerke per default als unsicher gelten und dann CAS greift.

Ein weiterer Nebeneffekt ist das Update, das geht so ohne weiteres nicht. Korrekt.

Die einzige Lösung, sodass Du dieses Gebastle nich machen musst: verteil Deine Anwendung ordentlich. So ist das Murks.
Zur Not über ClickOnce.

Nächster Tag 14 Uhr geht auch eventuell mit der .Date() Methode :

EndZeit = StartZeit.Date().AddDays(1).AddHours(14);

Abt : Ich mache das schon immer so dass die Applikation auf dem freigegebenen Netzwerklaufwerk liegt und das klappt immer noch super. Auch ein Update im laufenden Betrieb klappt.
Ich habe bisher keine Nachteile damit gehabt.

Ist eher Geschmacksache wie man das macht.

Ich mache das mit den Updates anders :
Ich kompiliere 5 Versionen mit den Namen App1.exe bis App5.exe. Ich installiere alle 5, aber nur die die nicht gesperrt sind. Per Programmlauncher starte ich immer die neueste Version dieser 5 Apps.

Ich muss die 5 Versionen einzelnen kompilieren da ich TxtControl verwende und das erlaubt die Umbenennung einer Exe nicht. Warum auch immer.

Grüße Bernd