I have a System.Win32.RegistryKey object that points to, for example, "HKCU\Software\Test". The .Name property is populated with the absolute path. Is there a way to get only the current (relative) key name?
In the example above, I am looking for just the "Test" part of the path. I am looking for the Registry equivelent to System.IO.Path.GetDirectoryName without having to parse the path manually.
You can just call System.IO.Path.GetDirectoryName.
The Path.* functions (except for GetFullPath()) are purely string manipulation functions and work fine even with non-filesystem paths.
The question asks for the relative value (just Test) not the absolute full path. The GetDirectoryName method returns the absolute path.
The method you want to use is:
System.IO.Path.GetFileNameWithoutExtension(subkey.Name);
See this link
You can simply use System.IO.Path.GetDirectoryName(string) which works just fine with registry paths.
Related
This is the simple C# code I wrote :
string file = #"D:\test(2021/02/10).docx";
var fileName = Path.GetFileNameWithoutExtension(file);
Console.WriteLine(fileName);
I thought I would get the string "test(2021/02/10)" , but I got this result "10)".
How can I solve such a problem?
I just wonder why would you want such behavior. On windows slashes are treated as separator between directory and subdirectory (or file).
So, basically you are not able to create such file name.
And since slashes are treated as described, it is very natural that method implementation just checks what's after last slash and extracts just filename.
If you are interested on how the method is implemented take a look at source code
I want to get the path of the temp folder (C:\Users\user\AppData\Local\Temp).
GetEnvironmentVariable("TEMP") works fine, but I get the path with tilde:
C:\Users\STANHE~1\AppData\Local\Temp\
.. and I need the path without the tilde:
C:\Users\StanHerrmann\AppData\Local\Temp\
You can use Path.GetFullPath to expand it:
If you pass in a short file name, it is expanded to a long file name.
But... it would be better to just use Path.GetTempPath for this, so you don't have to rely on environment variables to be correct.
There is a little confusion in my mind about server.mappath
which is correct and what's the difference betwwen these two
FileUpload1.saveAs(Server.MapPath("~/User/images/")+"ankush.jpg"));
FileUpload1.saveAs(Server.MapPath("~/User/images")+"ankush.jpg"));
The correct way of using MapPath() would be:
FileUpload1.saveAs(Server.MapPath("~/User/images/ankush.jpg"));
or if you insist:
FileUpload1.saveAs(Path.Combine(Server.MapPath("~/User/images"),"ankush.jpg")));
MapPath() doesn't append a trailing backslash to the mapped path because it has no way of knowing if the path is a directory or a file (it doesn't check if the given path actually exists)
I would advise you to use this way
FileUpload1.saveAs(Server.MapPath("~/User/images/ankush.jpg"));
Reason : because if you already know the path then why break down the filename separately
If the filename was getting passed by parameter then you could do
FileUpload1.saveAs(Server.MapPath(String.Format("~/User/images/{0}", fileName)));
I have the code
string xsltPath = System.Web.HttpContext.Current.Server.MapPath(#"App_Data") + "\\" + TransformFileName
It returns
C:\inetpub\wwwroot\websiteName\SERVICENAME\App_Data\FileName.xsl
Why am I getting the path to the ServiceController, SERVICENAME? I want the path to App_Data which is in
C:\inetpub\wwwroot\websiteName\App_Data\FileName.xsl
You need to specify that you want to start from the virtual root:
string xsltPath = Path.Combine(System.Web.HttpContext.Current.Server.MapPath(#"~/App_Data"), TransformFileName);
Additionally, it's better practice to use Path.Combine to combine paths rather than concatenate strings. Path.Combine will make sure you won't end up in a situation with double-path separators.
EDIT:
Can you define "absolute" and "relative" paths and how they compare to "physical" and "virtual" paths?
MSDN has a good explanation on relative, physical, and virtual paths. Take a look there.
The answers given so far are what you are looking for, but I think, in your particular case, what you actual need is this:
AppDomain.CurrentDomain.GetData("DataDirectory").ToString()
This will still return the file path to the App_Data directory if that directory name changes in future versions of MVC or ASP.NET.
Try doing like this (#"~/App_Data"). ~/ represents the root directory.
I have a variable in code that can have file path or url as value. Examples:
http://someDomain/someFile.dat
file://c:\files\someFile.dat
c:\files\someFile.dat
So there are two ways to represent a file and I can't ignore any of them.
What is the correct name for such a variable: path, url, location?
I'm using a 3rd party api so I can't change semantics or separate to more variables.
The first two are URLs, the third is a file path. Of course, the file:/// protocol is only referring to a file also.
When using the Uri class, you can use the IsFile and the LocalPath properties to handle file:/// Uris, and in that case you should also name it like that.
Personally, I'd call the variable in question "fileName"
in fact a formal URL will be file:///c|/files/someFile.dat
urls always starts with protocol:// and then path + names, with '/' as seperator.
evil windows IE sometimes use '\' to replace '/', but the formal usage is '/'.
Pick one that you'll be using internally to start with. If you need to support URLs, use URLs internally everywhere, and have any method that can set the variable check if it got a file path, and coerce it to an URL immediately.
If the values are not opaque to your application you may find it better to model them as a class. Otherwise, whenever you are going to act upon the values you may find yourself writing code like this:
if (variable.StartsWith("http://") || variable.StartsWith("file://")) {
// Handle url
}
else {
// Handle file path
}
You may fold some of the functionality regarding treatment of the values into your class, but it is properly better to treat it as an immutable value type.
Use a descriptive name for your class like FileLocation or whatever fits your nomenclature. It will then be very natural to declare FileLocation variables named fileLocation or inputFileLocation or even fl if you are sloppy.
if the path you are using includes the protocol "file://" then it is in fact a url.