Uri path Den angivna sökvägens format stöds inte : System.NotSupportedException

[code][/code]

Tjo! Jag har dessvärre väldigt svårt för C# pga. dess objektorientering men jag frågade Gemini (gratisversionen) som föreslog följande kod:

private void SeparatePath()
{
    string path = Directory.GetCurrentDirectory();
    string[] pathSegments = path.Split('\\'); // Split the path using the backslash character
    int segments = pathSegments.Length;
    segments -= 2; // Remove the 'debug' and 'bin' directories

    string newPath = "";
    for (int i = 0; i < segments; i++)
    {
        newPath += pathSegments[i] + "\\"; // Append each segment with a backslash
    }

    string[] fileArray = Directory.GetFiles(newPath); // Get all files in the newPath directory

    foreach (string file in fileArray)
    {
        Debug.WriteLine(file);
    }

    Debug.WriteLine(path);
    Debug.WriteLine(newPath);
}

När du använder Uri-klassen så genomför den URL-teckenkodning genom att ersätta exempelvis mellanslag med %20 vilket i sin tur leder till en icke-fungerande filsökväg. Notera exempelvis hur "2019 PC" blir "2019%20PC" pga. Uri-klassens metoder.

Så någon annan variant av separation av "\" är nog vad du behöver experimentera med.

Mvh,
WKF.

Du vill typiskt inte ta bort bin/debug. Du vill snarare hämta filer som ska installeras med programmet från undermappar jämfört med där programmet körs, vilket i debug-läge råkar vara bin/debug.

Filerna som ska installeras med programmet lägger du i undermappar i Visual Studio-projektet och markerar dem som ”Copy to Output”=”Copy if newer”, så kopieras de in till bin/debug vid kompilering. Det är i alla fall så man typiskt gör i vanliga Visual Studio, hur man gör i Code kommer jag inte ihåg.

Sedan använder man System.IO.Path för att slå ihop det man får från Directory.GetCurrentDirectory() med undermappen och filnamnet på filen man vill öppna. Path.Combine() är rätt metod.

(Det finns andra, mindre fragila, sätt att hitta mappen där .exe:n ligger.)

Ovanstående kommer funka även efter att man byggt ett installationsprogram och installerat filerna på logiskt ställe. Eller om man kör Release-bygge i stället, från bin/Release.

Filer som i stället skapas av användaren behandlas på samma sätt, men de sparar man lämpligen i Environment.GetFolderPath(Environment.SpecialFolder.UserProfile) i stället.

Tycker Lento har givit ett rätt rimligt förslag sett till hur man gör *det som efterfrågas*...

MEN hela idén att ha ett program som är hårdkodat att ta Current Working Directory (CWD) och gå två nivåer upp för att hitta filerna det ska jobba med är ju ett rätt bisarrt beteende. Dvs det som efterfrågas känns inte alls genomtänkt, åtminstone inte i något slags större perspektiv.

Jag förstår av frågan att det handlar om att TS råkar stå i någon katalog i utvecklingsmiljön när programmet körs... men så är det ju inte sedan i verkligheten. CWD kan ju vara precis vilken katalog som helst i verkligheten.
Det känns som att antingen så skulle programmet leta efter filerna i CWD (som ju är något som användaren iaf direkt styr över på ett tydligt sätt), eller så behöver det ett argument med vilken katalog det ska leta i / en dialog som frågar om katalogen.