Danke für den neuen Input.

Die App.xaml.cs Datei ist definitiv vorhanden.

Eine Main-Methode habe ich nicht explizit implementiert, da es bisher immer so war, dass diese entweder in der gewählten Projektvorlage vom VS schon enthalten war oder automatisch generiert wurde.

Wie dem auch sei.
Ich habe eben Visual Studio komplett deinstalliert und erneut installiert und seither funktioniert es wieder.

Vielen Dank für eure Tipps!

Hier die csproj-Datei:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>WinExe</OutputType>
    <TargetFramework>net5.0-windows</TargetFramework>
    <UseWPF>true</UseWPF>
  </PropertyGroup>

</Project>

Hallöchen,

erst Mal vielen Dank, dass du die Zeit und Mühe investiert hast.

Vielleicht kurz Vorweg. Ich habe .NET 5.0 nicht explizit installiert. Ich hatte es nach der Aktualisierung auf 16.9.3 einfach in der UI zur Auswahl als Zielframework.
Ich gehe daher davon aus, dass es mit der Version einfach mit installiert/aktiviert wurde.

Wie dem auch sei, ich habe hier das Ergebnis von dotnet --info kopiert. Sieht für mich allerdings korrekt aus.

.NET SDK (gemäß "global.json"):
 Version:   5.0.201
 Commit:    a09bd5c86c

Laufzeitumgebung:
 OS Name:     Windows
 OS Version:  10.0.19042
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\5.0.201\

Host (useful for support):
  Version: 5.0.4
  Commit:  f27d337295

.NET SDKs installed:
  5.0.201 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.All 2.1.26 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.26 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.13 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.26 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.13 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 3.1.13 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 5.0.4 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Hallo zusammen,

ich bin da auf ein Problem gestoßen, das ich bisher nicht selbständig lösen konnte und für das ich hier auch keinen bestehenden Eintrag gefunden habe.
Daher hoffe ich auf ein paar hilfreiche Tipps.

Ich habe vorgestern Visual Studio 2019 Community Edition auf die Version 16.9.3 aktualisiert.
Ich erstelle nun ein neues Projekt vom Typ "WPF-Anwendung" mit dem .NET 5.0 als Zielframework.

Wenn der Erstell-Assistent fertig ist und nachdem die IDE sich vollständig geöffnet hat und auch die Hintergrundaktionen zu Ende gelaufen sind, starte ich das Projekt mittels F5.
Man beachte bitte, dass ich noch keinerlei inhaltliche Änderungen vorgenommen habe.

Allerdings kracht es direkt mit folgender Fehlermeldung:

Erstellen gestartet...
1>------ Erstellen gestartet: Projekt: test8, Konfiguration: Debug Any CPU ------
1>CSC : error CS5001: Das Programm enthält keine als Einstiegspunkt geeignete statische Main-Methode.
1>Die Erstellung des Projekts "test8_04hfkclo_wpftmp.csproj" ist abgeschlossen -- FEHLER.
\========== Erstellen: 0 erfolgreich, 1 fehlerhaft, 0 aktuell, 0 übersprungen ==========

Folgendes habe ich daraufhin geprüft:

• Es tritt ausschließlich bei neu angelegten Projekten auf, die als Zielframework .NET 5.0 oder .NET-Core 3.1 haben.
  -> Bei Projekten mit Zielframework .NET-Framework 4.6 / 4.7.2 tritt es nicht auf.

• Es spielt auch keine Rolle, ob ich ein WPF-oder WinForms-Projekt verwende, sobald ich das oben genannte Zielframework verwende, knallt es.

• Ich konnte weiterhin herausfinden, dass die Methode offensichtlich nicht generiert wird.
  -> Im Verzeichnis : _...\test8\test8\obj\Debug\net5.0-windows_ wird keine App.g.cs bzw. App.g.i.cs generiert. Alle anderen Dateien, wie bspw für die MainForm, etc. sind aber vorhanden.

• Ich habe nun auch die Reparatur-Funktion des Visual Studio Installers benutzt, aber das hatte ebenfalls keinen Effekt.

• In der Windows-Ereignisanzeige konnte ich nirgends irgendeine Art von Fehlermeldung finden.

• Auch ein abschalten des Windows Defenders brachte keine Änderung am Verhalten.

• Ich habe auch keine Plugins/Add-Ins/Add-Ons für VS im Einsatz, es ist wirklich die reine Standard-IDE.

Vielleicht kann mich jemand in die richtige Richtung schubsen.

*argh*

Ich habs gerade heraus gekriegt... schäm
Ich hatte wegen ner anderen Sache irgendwo im Code mal das Paint-Ereignis von der ProgressBar angepackt -.-
Ich hab die 2 Zeilen gelöscht und schon läufts prima.

Danke für eure Hilfe!

Ok, vom Ablauf her passiert folgendes:
Im Load-ereignis für die Form wird der Timer bereits gestartet.
Zum Beeinflussen der Value-Eigenschaft der Progressbar gibt es 2 Methoden:

1. Methode erhöht den Wert relativ

        private void RaiseProgress (int LengthSteps) {
            if(this.tspbProgress.Maximum/LengthSteps>=1)
                this.tspbProgress.Value+=this.tspbProgress.Maximum/LengthSteps;
        }

2. Methode setzt den Wert fest

        private void SetProgress (int Step) {
            this.tspbProgress.Value=Step;
        }

Das Tick-Ereignis selbst beinhaltet folgendes:

        private void tmrTimeStamp_Tick (object sender, EventArgs e) {
            this.tsslTimeStamp.Text=DateTime.Now.ToShortDateString()+" // "+DateTime.Now.ToLongTimeString();
            if (Ticker%3==0)
                this.tsslDistMessages.Text="";

            if ((Ticker%3==0)&&(this.tspbProgress.Value>=this.tspbProgress.Maximum)) {
                SetProgress(0);
                this.tspbProgress.Invalidate();
            }

            Ticker+=1;
            this.stsStatus.Refresh();
        }

So, während der Ausführung von anderen selbst erstellten Methoden oder auch beispielsweise Button_Click-Ereignissen, wird oben die Methode 1 zum steuern von value verwendet.
Man sieht dann auch an der Oberfläche wie sich der Ladebalken bewegt.

Da ich, wie schon beschrieben, in anderen Artikeln den Hinweis gefunden hatte, das eine solche Value-Änderung innerhalb der selben Funktion nicht unbedingt an der Oberfläche angezeigt wird, habe ich einfach zu testzwecken noch einen Button auf die Form gelegt:

        private void tsbDetails_Click (object sender, EventArgs e) {
            this.stsStatus.Refresh();
            MessageBox.Show(this.tspbProgress.Value.ToString());
            this.stsStatus.Refresh();
        }

Das Ergebnis ist jedoch nach dem Tick-Ereignis immer "0", so wie es meiner Meinung nach auch sein sollte.

Hi,

Ich weiß das es zum Thema ProgressBar aktualisieren hier schon einige Beiträge und Artikel gibt. Ich öffne das Thema jedoch weil ich der Ansicht bin, dass dieses Verhalten irgendwie nicht so wirklich zu den vorhandenen Beiträgen passt. Wenn ich was übersehen haben sollte, tut es mir leid.

Das Problem um das es geht, ist recht simpel.
Ich entwickle auf Basis von .NET 3.5 mit VS2008 eine WindowsForms Anwendung.
Diese enthält unter vielem anderen auch einen Timer, sowie ein StatusBar-Steuerelement, welche wiederum 2 Labels und eine ProgressBar enthält.
Auch wenn es nicht gerade die eleganteste Lösung ist, werden im Tick-Ereignis des Timers die Steuerelemente in der StatusBar aktualisiert.

Interessanterweise funktioniert das für die beiden Labels problemlos. Die Applikation reagiert während des Vorgangs normal und der Text in den Labels wird gelöscht.
Dummerweise bleibt die ProgressBar bei 100% stehen.
Wenn ich später dann per Code die Value-Eigenschaft auslese, bekomme ich eine "0" zurück, was code-technisch auch stimmt, aber selbst mit einem dutzend refresh-Befehle an den verschiedensten Stellen des Programms, bekomme ich die ProgressBar nicht dazu den Ladebalken wieder auf "0" zurückzustellen.

Hi,

Ich entwickle gerade eien Windows-Forms Anwendung und bin auf folgende Problematik gestoßen.
Da ich standardmäßig auf Vista mit Aero-Style entwickle sieht meine Oberfläche natürlich entsprechend gut aus.
Einige Kollegen die in den Genuß der Applikation kommen werden, nutzen jedoch das "classic"-Theme wie unter Win2000. Und da sieht meine Oberfläche dann entsprechend, naja, sagen wir mal "dürftig" aus 😉

Ich habe bisher schon google bemüht und auch die Forensuche. Hab mich auch schon selbst in den Namespaces "Environment" etc umgesehen, konnte aber nichts finden.

Meine Frage ist nun, gibts eine Möglichkeit zu ermitteln, welches Theme ein User auf seinem lokalen System aktiviert hat und wenn ja, wie?

Vielen Dank im voraus!

hi, vielen dank für den Hinweis, ich bin mir nur nicht ganz sicher, ob das so funktioniert.

Dss ganze was ich ursprünglich beschrieben hab, läuft alles per Code.
Das bedeutet, der Benutzer gibt über einen OpenFileDialog lediglich das 1. große Zip-Paket an und noch einen Ordner, in den alles entpackt wird. Das wars.
Alles weitere, also auch schon das 1. entpacken des großen Pakets läuft Programmintern.
Um die Sache mit der Freigabe, respektive dann als UNC angeben zu können, müßte ich das doch vom Benutzer machen lassen, oder kann ich das auch per Code machen, ohne Benutzerinteraktion?

Hi,

also das Thema mit den EVT-Dateien habe ich zunächst mal zurück gestellt.
Werde mich damit die nächsten Wochen mal beschäftigen.

Zum Thema der *.dat-Files, habe ich das nun folgendermaßen gelöst.
Auch wenn es von MS explizit nicht empfohlen wird, habe ich einen Verweis auf die ADO 2.8 gesetzt und per folgendem Code wird der Tabellenexport in XML umgewandelt:

public void ConvertDATtoXML(string FilePath,string FileName)
        {
            try
            {
                Connection ADOConnect = new Connection();
                Recordset ADORecord = new Recordset();

                ADOConnect.Open("Provider=MSPersist", null, null, 0);
                ADORecord.Open(FilePath + "\\" + FileName + ".dat", ADOConnect, CursorTypeEnum.adOpenKeyset, LockTypeEnum.adLockOptimistic, -1);
                ADORecord.Save(FilePath + "\\" + FileName + ".xml", PersistFormatEnum.adPersistXML);

                ADORecord.Close();
                ADOConnect.Close();
            }
            catch(Exception ex)
            {
                ErrorMessenger.WEL("Beim Konvertieren der Tabellendateien ist ein Fehler aufgetreten.\n" + ex.Message, "Error");
                ErrorMessenger.WTL("Beim Konvertieren der Tabellendateien ist ein Fehler aufgetreten.\n" + ex.Message, "Error");
                ErrorMessenger.WSL("Beim Konvertieren der Tabellendateien ist ein Fehler aufgetreten.\n" + ex.Message, "Error");
            }
        }

Hallo Leute,

In der Hoffnung, dass das hier am richtigen Platz landet, würde ich einfach nur um den ein oder anderen Denkansatz bitten, falls jemandem also dazu ne Möglichkeit einfällt, wäre ich sehr dankbar.

Beschreibung:
Ich entwickle derzeit ein Programm, dass dafür da ist um mehrere Log-Dateien und DB-Tabellenexporte auf lokalen Systemen übersichtlich darzustellen.
Geliefert bekomme ich diese Dateien innerhalb einer großen ZIP-Datei.
Mithilfe der CSharp-ZipLib, war ich in der Lage das entpacken vorzunehmen.

Problemstellung:
Nach dem entpacken des 1. großen Pakets, befinden sich nun 2 weitere Zip-Dateien in dem entpackten Ordner. Eines der Zip-Pakete enthält jedoch anstatt Dateien eine stark ineinder geschachtelte Ordnerstruktur (Tiefe: bis zu 8 Ordner). Die Dateien an die ich heran will befinden sich ganz "unten" in dieser Struktur.
Dummerweise scheint das entpacken von Zeit zu Zeit die 256-Zeichen Grenze zu überschreiten, was dann zu einem Fehler führt.

Die Frage ist nun, kann ich die 256-Zeichen Grenze irgendwie umgehen? Wenn ja, wie? und/oder würde jemand eine Möglichkeit einfallen, wie ich während des entpackens, den Dateipfad kürzen könnte?

Hi,

Vielen Dank dass du dich durch meine endlos lange Beschreibung durchgewühlt hast.

Also das Problem an den EVT-Dateien ist, dass der LogParser diese nur dann in XML umwandeln kann, wenn die LogParser.exe auf einem XP-Rechner ausgeführt wird.
Sobald du das auf einem Vista-Rechner versuchst, meldet LogParser dass die EVT-Datei angeblich beschädigt sei. Was jedoch nicht der Wahrheit entspricht.

Was die EVTX-Dateien angeht, das ist schonmal ein guter Schritt! Vielen Dank für den Hinweis!!

Gruß DarkSide

Hi,

ich bin noch neu hier und habe mich mal durch die Themen gekämpft, in der Hoffnung dass dieser Thread hier richtig platziert ist. Falls nicht, bitte ich um Entschuldigung.

Zu meinen konkreten Problemen.

Ausgangslage:
Ich Schreibe an einem Programm welches Log-Dateien aus einem Zip-Ordner aufbereitet und übersichtlich für unser Team darstellen kann. Aktuell ist die Basis .NET Framework 2.0, eine Portierung auf .NET Framework 3.5 erfolgt, sobald die hier beschriebenen Probleme gelöst sind.
In dem Zip-Ordner findet sich unter anderem sowohl das Anwendungsprotokoll als auch das Systemprotokoll der Windows-Ereignisanzeige von diversen Pc's. Je nach OS als *.evt oder eben *.evtx.
Außerdem gibt es noch diverse Exporte von SQL-Server Tabellen als *.dat-Dateien, welche im ADTG-Format von ADO vorliegen.

Das konkrete Problem
Ich bekomme beide Dateitypen nicht eingelesen.

Das bisherige Vorgehen bei *.dat:
Ich habe versucht über einen Verweis im Projekt auf die Microsoft ActiveX Data Objects Library 2.8 und den damit verbundenen RecordSets die Daten einzulesen.
In der MSDN ist unter der "Open"-Methode für RecordSets der einzige Eintrag wo Dateien im ADTG-Format überhaupt erwähnt werden (zumindest habe ich seither keine weiteren gefunden). Leider ist der Eintrag nicht sehr aufschlußreich, da nur drin steht, dass man solche Dateien als DataSource angeben kann...
Als Provider habe ich "MSPersist" und auch einige andere bereits durchprobiert, ich erhalte jedoch immer bei der Zuweisung der Datei zur Eigenschaft "DataSource" des Recordsets, die Exception "Diese Quelle ist nicht zulässig".

Vorgehen bei Eventlog:
Der 1. Versuch war mittels der Eventlog-Klasse ein Array, DataSet oder eine List<> zu generien, welche die Einträge aus der evt/evtx-Datei enthält, und diese dann in eine ListBox oder DataGridView anzuzeigen.
Hier scheiterte ich daran dem Objekt der Eventlog-Klasse eine Datei als Quelle anzugeben. Es gelang mir nur aus dem aktiven Eventlog des lokalen PC's zu lesen, nicht jedoch aus der Datei.

Der 2. Versuch war dann direkt die lokal auf den Pc's installierte eventvwr.exe anzusprechen und die gespeicherte Datei per Parameter an die eventvwr.exe zu übergeben und den Prozess der Exe aus dem Code heraus selbst zu starten.
Wenn ich das aus den Artikeln, aus dem Web und den Fehlermeldungen richtig heraus gelesen habe, kann ich per Parameter jedoch nur eine Direktverbindung zum Eventlog eines anderen Pc's herstellen und nicht einfach nur eine gespeicherte Datei angeben. Die Schwierigkeit besteht wohl darin, dass die mmc.exe bzw die eventvwr.exe dann automatisch das Argument "/computername=" erwartet, sobald man ein anderes Argument "/V", "/I", etc angibt. Da ich live keinen Zugriff auf die Pc's habe, scheitert diese Option leider.

Der 3. Versuch war der Microsoft LogParser 2.2.
Der hat es mir erlaubt, nachdem ich mir einen Query selbst zusammen gebastelt hatte, die EVT-Datei als XML sehr komfortabel zu speichern. Die Performanz beim Umwandeln ist überragend. (Größe EVT = 7MB, Größe XML = 18MB, Dauer 0,99sec)
Dummerweise wird der LogParser seit 2005/2006 nicht mehr weiter entwickelt, was dann folgende Probleme mit sich bringt:
Unterstützt kein evtx, unter XP funktioniert der Parser problemlos. Führt man den selben Query, mit den selben Dateien unter Vista aus, kommt die Fehlermeldung des Parsers zurück, dass die Quell-EVT beschädigt wäre. Ich habe das dann mit mehreren anderen Dateien probiert und es ist immer das selbe Ergebnis.

Meine Bitte:
Ich habe google schon hinreichend dazu strapaziert und diverse Seiten wie diese hier, um meine Probleme zu lösen. Ich hatte jedoch keinen Erfolg. Die einzige Möglichkeit die mir noch einfallen würde, wäre einen ByteReader zu implementieren, wobei ich nicht weiß wie performant das ganze dann sein kann?!

Hat jemand vielleicht noch eine Idee oder einen Ansatz den ich noch versuchen könnte? Oder einen Hinweis, einen Artikel oder irgendetwas, was mich noch auf eine Spur bringen könnte?