I have a string in C# 2002 that is coded like this:
private string m_strProdOutputBeginPath = @"\\DOR-PROD-FTP\NAUPA\";
and when it is used it displays exactly like it is coded. When I copied the code to C# 2005, and ran itthru this code:
m_strOutFilePath = m_strProdOutputBeginPath + "EROUTFILE.txt"
if (!File.Exists ( m_strOutFilePath))
{
using ( FileStream fs = File.Create(m_strOutFilePath))
{
. . .
}
}
When the run gets to the "if/using" code, the path looks like this:
\\\\DOR-PROD-FTP\\NAUPA\\EROUTFILE.txt
Why isn't the string displaying correctly I thought the at (@) symbol told C# to display the string exactly as coded and ignore escape characters. I removed the at symbol and changed the file path to look like this:
\\\\DOR-PROD-FTP\\NAUPA\\EROUTFILE.txt
which should have removed the replicated escape characters and displayed the path correctly but it still displayed the string exactly as I coded it.
I used the "Text Visualizer" in debug and the string is displayed correctly. What am I doing wrong here Is there something new in version 2005 I missed
Handling strings with escape characters in C# 2005
MLynch
Then could this be a security problem This will try to create the file if it does not already exist.
If this is a security situation, how do I get the program to accept the destination as an accepted location
The drive I'm trying to write to is on the LAN.
joesucks
Well, you may or may not be able to write a file to that location; it depends on how the permissions are setup, and that's a question for the LAN admin.
-Tom Meschter
Software Dev, Visual C# IDE
Ivo Manolov MSFT
I assume you're examining the string in the debugger, rather than printing it out through Console.Write() or similar. If my assumption is correct, \\\\DOR-PROD-FTP\\NAUPA\\EROUTFILE.txt is exactly what you should be seeing.
The @ symbol only affects how a string literal is defined, not how it is displayed in the debugger or a Console.Write(). When the debugger displays a string literal, it shows you many of the escape sequences, so what was a single \ in @"\\DOR-PROD-FTP\NAUPA\" shows up in the debugger in it's escape sequence version, \\.
@"\\DOR-PROD-FTP\NAUPA\" and "\\\\DOR-PROD-FTP\\NAUPA\\" are, in fact, exactly the same string.
-Tom Meschter
Software Dev, Visual C# IDE