.NET 2008, Path werkt anders?

[Verwijderd]

Beste tweakers,

Voorheen gebruikte ik vaak Path.Combine om een folder te achterhalen..., bijvoorbeeld:

code:

Path.Combine(Path.GetDirectoryName(Assembly.GetAssembly(typeof(Logging)).CodeBase), "Bestandje.txt");

Dit gaf dan altijd iets terug als c:\projecten\applicatie\bin\debug\bestandje.txt. En dat is mooi, want dat snapt een streamreader, streamwriter, etc.

Nu, in VS2008, krijg ik als resultaat ineens: file:\\c:\projecten\applicatie\bin\debug\bestandje.txt terug. Dus plakt iets of iemand er ineens file:\\ erbij. Dan krijg ik overal een "URI's are not supported" terug. Kan ik mij voorstellen. Er zit geen override op Path.Combine om er geen URI van te maken.

Iemand enig idee waar dit gedrag vandaag komt en hoe je het hopelijk weer uit kan zetten?

[Woy]

maar wat geeft

C#:

Path.GetDirectoryName(Assembly.GetAssembly(typeof(Logging)).CodeBase)

of

C#:

Assembly.GetAssembly(typeof(Logging)).CodeBase

Want ik heb in vs 2008 geen last van dat er file:\\ voor staat.

[riezebosch]

Verwijderd schreef op donderdag 06 november 2008 @ 15:14:
Beste tweakers,

Voorheen gebruikte ik vaak Path.Combine om een folder te achterhalen..., bijvoorbeeld:

code:

Path.Combine(Path.GetDirectoryName(Assembly.GetAssembly(typeof(Logging)).CodeBase), "Bestandje.txt");

Dit gaf dan altijd iets terug als c:\projecten\applicatie\bin\debug\bestandje.txt. En dat is mooi, want dat snapt een streamreader, streamwriter, etc.

Nu, in VS2008, krijg ik als resultaat ineens: file:\\c:\projecten\applicatie\bin\debug\bestandje.txt terug. Dus plakt iets of iemand er ineens file:\\ erbij. Dan krijg ik overal een "URI's are not supported" terug. Kan ik mij voorstellen. Er zit geen override op Path.Combine om er geen URI van te maken.

Iemand enig idee waar dit gedrag vandaag komt en hoe je het hopelijk weer uit kan zetten?

Het punt is dat Assembly.CodeBase blijkbaar tegenwoordig een path met file:// teruggeeft. Dat zie ik bij mij inderdaad ook. Klein puntje: heb je speciale reden om GetAssembly(typeof(Logging)) te gebruiken, of zou je ook Assembly.GetExecutingAssembly() kunnen gebruiken?

[Niemand_Anders]

GetDirectoryName speelt een beetje vals, want het een String.LastIndexOf op de meegegeven string en geeft de string tot die positie terug.

Path.Combine is een wrapper van String.ConCat(str1, Path.DirectorySeperatorChar, str2).

Een simpele workaround zou zijn om te controleren of het path start met 'file://' en dan de eerste 7 tekens te negeren. Een andere workaround is je project compileren als .NET 1.x of 2.0 assembly.

Vanwege de toevoegingen aan het framework 3.x zoals XPS (System.IO.Packaging) en WPF(/E), pack uri c.q. OPC, worden sindsdien ook assemblies als resources beschreven. Een en ander heb ik een flink aantal maanden terug gelezen op een MSDN blog. Heb net even gezocht, maar kon de blog page niet zo snel terug vinden.

[Data-base]

Niemand_Anders schreef op donderdag 06 november 2008 @ 16:03:
Path.Combine is een wrapper van String.ConCat(str1, Path.DirectorySeperatorChar, str2).

Nope, staat los van string.concat.

Dit is de code voor Path.Combine:

C#:

    char ch = path1[path1.Length - 1];
    if (((ch != DirectorySeparatorChar) && (ch != AltDirectorySeparatorChar)) && (ch != VolumeSeparatorChar))
    {
        return (path1 + DirectorySeparatorChar + path2);
    }
    return (path1 + path2);

Maar dat is even offtopic

[CMG]

Stomme vraag misschien, maar waarom gebruik je niet gewoon Application.StartupPath?

[kunnen]

CMG schreef op donderdag 06 november 2008 @ 20:37:
Stomme vraag misschien, maar waarom gebruik je niet gewoon Application.StartupPath?

Je kan een applicatie in een andere map starten dan waar de executable staat.

[Niemand_Anders]

Data-base schreef op donderdag 06 november 2008 @ 20:25:
[...]


Nope, staat los van string.concat.

Dit is de code voor Path.Combine:

C#:

    char ch = path1[path1.Length - 1];
    if (((ch != DirectorySeparatorChar) && (ch != AltDirectorySeparatorChar)) && (ch != VolumeSeparatorChar))
    {
        return (path1 + DirectorySeparatorChar + path2);
    }
    return (path1 + path2);

Maar dat is even offtopic

Wat ik probeerde aan te geven is dat Path.Combine geen (bestand) controle op path1 en path2 doet. Alleen in de daadwerkelijk code zit er een check die controleert of path1 eindigt op een slash.

En dat is dan ook de reden dat de TS een 'ongeldig' path terug kreeg.

[Verwijderd]

ThomasB schreef op donderdag 06 november 2008 @ 23:58:
[...]

Je kan een applicatie in een andere map starten dan waar de executable staat.

Application.ExecutablePath

die dan?
Is precies hetzelfde maar dan met exe naam erbij.
Echter hij geeft toch altijd het goeie pad aan, ook als ik Starten In verander.

Wat bedoel je precies met starten in andere map?

[ Voor 22% gewijzigd door Verwijderd op 07-11-2008 13:40 ]

[Verwijderd]

Bedankt voor alle reacties...

@CMG: Ik heb de applicatie gescheiden in modules, dit is de business layer en dat is een classe project. Daarin zit geen application die je kan gebruiken. Het ging mij er ook meer om waarom dit nu ineens anders is.

@Niemand_Anders: Ik had het inderdaad gefixt met een .Replace("file:\\", string.empty), maar blijf dat toch een beetje een lelijke oplossing vinden. Had gehoopt met een soort van instructie op de thread, culture of wat dan ook het gedrag aan te kunnen passen.

@Riezebosch / @rwb: Jullie hebben gelijk, het is de assembly.codebase en niet de path.combine die dit gedrag geeft. Erg irritant.