Problem mit C# Debugging in Visual Studio 2019?
Ich habe mit dem Programmieren angefangen und starte erste Programme zu schreiben. Allerdings kommt mir immer, wenn ich das Debugging starten will, diese Meldung
"Visual Studio kann das Debuggen nicht starten, weil das Debugziel "C:\Users\49151\source\repos\AI THIS TIME AI THIS TIME\bin\Debug\AI THIS TIME.exe" nicht vorhanden ist. Erstellen Sie das Projekt, und wiederholen Sie den Vorgang, oder legen Sie die OutputPath- und die AssemblyName-Eigenschaft auf den richtigen Speicherort für die Zielassembly fest."
zu Gesicht. Das obere mit der .exe-Datei habe ich versucht, allerdings erfolglos.
PS.: Ich will nach diesen ((56) HOW TO MAKE VOICE ASSISTANT IN C# (PART 1) - YouTube)-Tutorial einen kleinen Personal Assistent schreiben. Hier ist mein Code:
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Windows.Forms;
using System.Speech;
using System.Speech.Recognition;
using System.Speech.Synthesis;
using System.IO;
namespace AI_THIS_TIME
{
public partial class Form1 : Form
{
SpeechRecognitionEngine recEngine = new SpeechRecognitionEngine();
SpeechSynthesizer speech = new SpeechSynthesizer();
public Form1()
{
InitializeComponent();
Choices choices = Choices();
string[] text = File.ReadAllLines(Environment.CurrentDirectory + "//gramer.txt");
choices.Add(text);
Grammar grammar = new Grammar(new GrammarBuilder(choices));
recEngine.LoadGrammar(grammar);
recEngine.SetInputToDefaultAudioDevice();
recEngine.RecognizeAsync(RecognizeMode.Multiple);
recEngine.SpeechRecognized += new EventHandler<SpeechRecognizedEventArgs>(recEngne_SpeechRecognized);
speech.SelectVoiceByHints(VoiceGender.Female);
}
private Choices Choices()
{
throw new NotImplementedException();
}
private void recEngne_SpeechRecognized(object sender, SpeechRecognizedEventArgs e)
{
string result = e.Result.Text;
if (result == "Hello")
{
result = "Hello, I am me how can i help you";
}
speech.SpeakAsync(result);
label2.Text = result;
private void Form1_Load(object sender, EventArgs e)
{
}
}
}
}
2 Antworten
Deine Klammersetzung ist falsch. Beende erst den Methodenkörper von recEngne_SpeechRecognized, bevor du die Form1_Load-Methode anführst. Die überflüssige Klammer am Ende der Datei kommt folglich weg.
Baue das Projekt danach erst einmal, denn so lange VS dein Projekt nicht erfolgreich kompilieren kann, wird auch keine EXE-Datei im Debug-Verzeichnis erstellt und du kannst das Projekt auch nicht ausführen. Bei Zugriffsproblemen solltest du VS im Administratormodus starten. Wenn du in der Output-Konsole siehst, dass kein Build gestartet wird, schau unter Build > Configuration Manager, ob für dein Projekt der Haken für Build gesetzt ist.
Halte bei diesem Kompiliervorgang deine Augen neben Fehlern auch nach Warnungen offen. Möglicherweise werden bestimmte Referenzen nicht gefunden oder es gibt Inkompatibilitäten (z.B. mit .NET-Versionen).
Sollte die erwartete Datei nach einem erfolgreichen Build nicht im erwarteten Debug-Verzeichnis liegen, öffne deine Projekteigenschaften und schau im Build-Tab, ob das Ausgabeverzeichnis korrekt ist.
Ich programmiere zwar in C++ und nicht in C#, aber beim Visual Studio 2019 ist mir (im Vergleich zu älteren Versionen) aufgefallen: Wenn der Linker-Output (also die EXE) nicht in dem Verzeichnis liegt, das unter "Allgemeine Eigenschaften" als Ausgabeverzeichnis angegeben wurde, gibt es beim Debuggen sehr unübersichtliche Probleme. Wenn es z.B. im Ausgabeverzeichnis auch eine EXE mit passendem Namen gibt, erzeugt der Linker die eine und der Debugger debuggt die andere. Und der Programmierer bekommt graue Haare.
Früher (Visual Studio 2008) war alles besser ;-)
Meine Firma legt sämtliche (!) Binaries in andere Ordner ab, nicht ein Ordner, sondern mehrere, manche Projekte der gleiche Ordner, manche unterschiedlich oder ein Unterordner. In den Einstellungen steht davon nichts.
Wir arbeiten mit C# und C++.
In keinem Fall gab es bisher einen Fehler, wie Du ihn beschreibst.
Ich behaupte, das was Du meinst, ist eher ein Anwenderfehler.
Ich bin froh, dass ich immer noch mit VS2008 arbeite.