I use VS 2008, .net 3.5, C# projects. I need do the same functionally like Microsoft.VisualBasic.FileIO.FileSystem.DeleteDirectory.
Anyone says referencing the Microsoft.VisualBasic is often undesirable from within C#. Any association with VB from within C# code strikes me as undesirable.
Using FileSystem class, this is a perfectly fine solution, but I prefer not references Microsoft.VisualBasic library. That one I would avoid.
private static void DeleteDirectory(string destino)
{
//UIOption Enumeration. Specifies whether to visually track the operation's progress. Default is UIOption.OnlyErrorDialogs. Required.
//RecycleOption Enumeration. Specifies whether or not the deleted file should be sent to the Recycle Bin. Default is RecycleOption.DeletePermanently.
//UICancelOption Enumeration. Specifies whether to throw an exception if the user clicks Cancel. Required.
Microsoft.VisualBasic.FileIO.FileSystem.DeleteDirectory(destino,
Microsoft.VisualBasic.FileIO.UIOption.OnlyErrorDialogs,
Microsoft.VisualBasic.FileIO.RecycleOption.DeletePermanently,
Microsoft.VisualBasic.FileIO.UICancelOption.ThrowException);
//Directory.Delete(destino, true);
}
Other samples:
How do you place a file in recycle bin instead of delete?
Microsoft.VisualBasic.FileIO.FileSystem.DeleteFile(file.FullName,
Microsoft.VisualBasic.FileIO.UIOption.OnlyErrorDialogs,
Microsoft.VisualBasic.FileIO.RecycleOption.SendToRecycleBin);
Possible duplicate of
System.IO Versus VisualBasic.FileIO
You can use FileIO from Microsoft.VisualBasic and AFAIK it will not behave unreasonably..
The same/similar functionality is available within the System.IO namespace:
System.IO.FileInfo fi = new System.IO.FileInfo("C:\\Test.txt");
fi.Delete();
System.IO.DirectoryInfo di = new System.IO.DirectoryInfo("C:\\Test");
di.Delete(true); //Recursive, pass false for no recursion.
I'm not aware of existing SendToRecycleBin equivalent, but you could try:
di.MoveTo("C:\\$Recycle.Bin\\S-..."); //You'd need to know the SID of the user logged in
To replicate the example
The following code will give you something similar to what you have provided as your example:
try
{
bool deletePermanently = true; //Set to false to move
System.IO.DirectoryInfo di = new System.IO.DirectoryInfo("C:\\Test");
if (deletePermanently)
{
if (di.Exists)
di.Delete(true);
}
else
{
if (di.Exists)
di.MoveTo("C:\\$Recycle.Bin\\S-0-0-00-00000000-000000000-0000000000-000"); //Replace with your SID
}
}
catch
{
Console.WriteLine("Error deleting directory"); //Add exception detail messages...
}
Again, the above example would need you to identify the SID of the user before being able to send to the recycle bin.
You could try the following.
System.IO.DirectoryInfo di = new System.IO.DirectoryInfo("C:\\MyDirectoryToDelete");
di.Delete(true);
Or even
System.IO.Directory.Delete("Path goes here");
Hope this helps.
Related
On Windows, I have a C# assembly that is COM visible. It references other assemblies to control an application in the machine. It works fine.
However, under Apache Web Server and using CGI, it doesn't work. After doing some debuging, I found out that the problem is that, while running under Apache's CGI, the environment variables SYSTEMROOT and SYSTEMDRIVE, which aparently are needed by the referenced assemblies, are not loaded.
I can configure Apache to pass those environemtn variables too, but before doing so, I'd really like to know if there's some command I can put on my C# COM visible assembly to make it load environment variables as if it was, let's say, the SYSTEM user or something like that, so it doesn't have to relay on the environment passed by the starting application.
How do you force loading an existent system environment variable in C#, when IT IS NOT SET in the current process (or it was process-deleted by the launching process)?
Thanks in advance for any suggestions!
EDIT 1 - ADDED INFO: Just to make it more clear (as I see in the current answers it's not so clear): Apache intendedly deletes a lot of environment variables for CGI processes. It's not that Apache cannot see them, it can, but it won't pass them to CGI processes.
This should do the trick:
Environment.GetEnvironmentVariable("variable", EnvironmentVariableTarget.Machine);
I did a small test and it is working:
//has the value
string a = Environment.GetEnvironmentVariable("TMP");
Environment.SetEnvironmentVariable("TMP", null);
//does not have has the value
a = Environment.GetEnvironmentVariable("TMP");
//has the value
a = Environment.GetEnvironmentVariable("TMP", EnvironmentVariableTarget.Machine);
SOLUTION: Marco's answer was great and technically answered my question - except that I found out that the environment variables SYSTEMROOT and SYSTEMDRIVE are not really set in the registry where all environment variables are set, so, the chosen answer works for all variables except those two, which I specified in the OP.
SYSTEMROOT is defined on the registry in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot, and apparently (after more research), SYSTEMDRIVE is generated as a substring of SYSTEMDRIVE.
So, to get SYSTEMDRIVE and SYSTEMROOT from registry and load them into the environment:
using Microsoft.Win32;
namespace MySpace
{
public class Setup
{
public Setup()
{
SetUpEnvironment();
}
private void SetUpEnvironment()
{
string test_a = Environment.GetEnvironmentVariable("SYSTEMDRIVE", EnvironmentVariableTarget.Process);
string test_b = Environment.GetEnvironmentVariable("SYSTEMROOT", EnvironmentVariableTarget.Process);
if (test_a == null || test_a.Length == 0 || test_b == null || test_b.Length == 0)
{
string RegistryPath = "HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion";
string SYSTEMROOT = (string) Registry.GetValue(RegistryPath, "SystemRoot", null);
if (SYSTEMROOT == null)
{
throw new System.ApplicationException("Cannot access registry key " + RegistryPath);
}
string SYSTEMDRIVE = SYSTEMROOT.Substring(0, SYSTEMROOT.IndexOf(':') + 1);
Environment.SetEnvironmentVariable("SYSTEMROOT", SYSTEMROOT, EnvironmentVariableTarget.Process);
Environment.SetEnvironmentVariable("SYSTEMDRIVE", SYSTEMDRIVE, EnvironmentVariableTarget.Process);
}
}
}
}
Then you can just call Setup setup = new Setup(); from other classes. And that's it. :-)
Environment.GetEnvironmentVariable
see reference here.
e.g.
Environment.CurrentDirectory = Environment.GetEnvironmentVariable("windir");
DirectoryInfo info = new DirectoryInfo(".");
lock(info)
{
Console.WriteLine("Directory Info: "+info.FullName);
}
Are the variables set as system wide?
If they are not, that is what you need to do, otherwise create user variables for the user the COM is running under.
Thank you. I cannot state with any certainty that this has once and for all driven a stake through the heart of the vampire, but amazingly enough, the error has disappeared (for now). The odd thing is that access to the statement
Environment.GetEnvironmentVariable("variable", EnvironmentVariableTarget.Machine);
is a real oddity in the debugger. It does not show up in Intellisense and does not even appear to fire, which leads me to suspect, which you all knew already, that this is some sort of magic runtime object Environment that has no instantiation in the debugger but also can be benignly jumped over. Oh well.
Oh and I should mention that after you see that error, you will note oddities in your Windows OS, which is worrisome. In particular, you will see, if you try to use the Control Panel /System/Advanced Properties (whatever) that it cannot load the dialog for the environment variables any more, indicating that %windir% has been seriously hosed (compromised) across all applications. Bad bad bad....
I have many user scoped settings being stored in user.config by objects which inherit from ApplicationSettingsBase.
The SettingsKey for each instance is derived dynamically at runtime using primarily the form name. Therefore there could be hundreds.
I've read many questions and answers (Like this one - How do you keep user.config settings across different assembly versions in .net?) which all recommend wrapping a ApplicationSettingsBase.Upgrade() call in some version number checking.
The problem is (as far as I can tell) you need to know every single *SettingsKey( value used in order to instantiate all the ApplicationSettingsBase objects to in turn call the upgrade method.
Is there a way to upgrade all user.config settings at once or alternatively, iterate through all settings in the file to upgrade them?
The approach I have come up with is something of a hack I feel, but too many approaches have failed and I need to get on with things :-(
I have resorted to copying the previous version of the user.config in the event of a new version running.
Firstly, determine whether or not an upgrade is required, like so many variants of this question recommend.
System.Reflection.Assembly assembly = System.Reflection.Assembly.GetExecutingAssembly();
Version version = assembly.GetName().Version;
if (version.ToString() != Properties.Settings.Default.ApplicationVersion)
{
copyLastUserConfig(version);
}
then, to copy the last user.config....
private static void copyLastUserConfig(Version currentVersion)
{
try
{
string userConfigFileName = "user.config";
// Expected location of the current user config
DirectoryInfo currentVersionConfigFileDir = new FileInfo(ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.PerUserRoamingAndLocal).FilePath).Directory;
if (currentVersionConfigFileDir == null)
{
return;
}
// Location of the previous user config
// grab the most recent folder from the list of user's settings folders, prior to the current version
var previousSettingsDir = (from dir in currentVersionConfigFileDir.Parent.GetDirectories()
let dirVer = new { Dir = dir, Ver = new Version(dir.Name) }
where dirVer.Ver < currentVersion
orderby dirVer.Ver descending
select dir).FirstOrDefault();
if (previousSettingsDir == null)
{
// none found, nothing to do - first time app has run, let it build a new one
return;
}
string previousVersionConfigFile = string.Concat(previousSettingsDir.FullName, #"\", userConfigFileName);
string currentVersionConfigFile = string.Concat(currentVersionConfigFileDir.FullName, #"\", userConfigFileName);
if (!currentVersionConfigFileDir.Exists)
{
Directory.CreateDirectory(currentVersionConfigFileDir.FullName);
}
File.Copy(previousVersionConfigFile, currentVersionConfigFile, true);
}
catch (Exception ex)
{
HandleError("An error occurred while trying to upgrade your user specific settings for the new version. The program will continue to run, however user preferences such as screen sizes, locations etc will need to be reset.", ex);
}
}
Thanks to Allon Guralnek on his answer to this question (How do you upgrade Settings.settings when the stored data type changes?) for the Linq in the middle which gets the PreviousSettingsDir.
I have spent quite a while trying to solve this problem, but to no avail. I have searched stackoverflow as well as Google and have not been able to resolve my (seemingly) simple problem.
I am getting a FileNotFoundException in the following line:
Image.FromFile("\\Resources\\Icons\\key-icon.png");
The folders and image are really there, and I can't see what the problem is.
You should consider that it is started from "yourproject/bin/Release" so you need to go up 2 directories. Do this:
Image.FromFile("..\\..\\Resources\\Icons\\key-icon.png");
Try using an absolute path not a relative one... i.e.
Image.FromFile(Server.MapPath(#"~\Resources\Icons\key-icon.png"));
Image.FromFile(Path.Combine(AppDomain.CurrentDomain.BaseDirectory,
#"Resources\\Icons\\key-icon.png"))
Base-directory Combine your file-name
You may be missing a leading ".":
Image.FromFile(".\\Resources\\Icons\\key-icon.png");
Internally, Image.FromFile uses File.Exists to check whether the file exists. This method returns false when:
the file does not exist (makes sense)
the current process identity does not have permission to read the file
It may be that the second option is your problem.
And another possibility: is Resources a network share? In that case you should use the following:
Image.FromFile("\\\\Resources\\Icons\\key-icon.png");
For this case I discovered that sikuli does not automatically detect the root folder of the project. What you should do for this case is specify the folder using the command System.getProperty("user.dir");
import org.sikuli.script.*;
public class Test {
public static void main(String[] args) {
Screen s = new Screen();
try{
String pathYourSystem = System.getProperty("user.dir") + "\\";
s.click(pathYourSystem + "imgs/spotlight.png");
//s.wait(pathYourSystem + "imgs/spotlight-input.png");
//s.click();
s.write("hello world#ENTER.");
}
catch(FindFailed e){
e.printStackTrace();
}
}
}
When I recursive through some folders and files, I encounter this error:
The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directoryname must be less than 248 characters.
Here's my function
private void ProcessDirectory(DirectoryInfo di)
{
try
{
DirectoryInfo[] diArr = di.GetDirectories();
foreach (DirectoryInfo directoryInfo in diArr)
{
if (StopCheck)
return;
ProcessDirectory(directoryInfo);
}
ProcessFile(di);
}
catch (Exception e)
{
listBoxError.Items.Add(e.Message);
}
TextBoxCurrentFolder.Text = di.ToString();
}
I cannot make the directory names shorter, because I'm not allowed too so... How can I solve this problem?
Added:
Here's the other function:
private void ProcessFile(DirectoryInfo di)
{
try
{
FileInfo[] fileInfo = di.GetFiles();
if (fileInfo.LongLength != 0)
{
foreach (FileInfo info in fileInfo)
{
Size += info.Length;
CountFile++;
}
}
}
catch (Exception e)
{
listBoxError.Items.Add(e.Message);
}
}
EDIT
Found this where he used Zeta Long Paths:
How can I use FileInfo class, avoiding PathTooLongException?
Have implemented it and now i'm going to let the program run over the night to see if it works.
EDIT
Used the ZetaLongPath yesterday and it worked great! It even went through folders that needed permission access.
EDIT
Instead of zetalongPath, I've used Delimon.Win32.IO.dll which i think is much better. It has the same interfaces as Win32.
Here's more info about the Delimon library referred to earlier. Its a .NET Framework 4 based library on Microsoft TechNet for overcoming the long filenames problem:
Delimon.Win32.IO Library (V4.0).
It has its own versions of key methods from System.IO. For example, you would replace:
System.IO.Directory.GetFiles
with
Delimon.Win32.IO.Directory.GetFiles
which will let you handle long files and folders.
From the website:
Delimon.Win32.IO replaces basic file functions of System.IO and
supports File & Folder names up to up to 32,767 Characters.
This Library is written on .NET Framework 4.0 and can be used either
on x86 & x64 systems. The File & Folder limitations of the standard
System.IO namespace can work with files that have 260 characters in a
filename and 240 characters in a folder name (MAX_PATH is usually
configured as 260 characters). Typically you run into the
System.IO.PathTooLongException Error with the Standard .NET Library.
This is a known limitation in Windows: http://msdn.microsoft.com/en-us/library/aa365247.aspx
I don't believe you'll be able to get around it, so whoever is telling you that you aren't allowed to make them shorter, you'll have a pretty solid argument as to why you have to.
The only real alternative is to move the deep folder somewhere else, maybe right at the root of your drive.
EDIT: Actually there may be a workaround: http://www.codinghorror.com/blog/2006/11/filesystem-paths-how-long-is-too-long.html
You'll have to use P/Invoke and the Unicode version of the Win32 API functions. You'll need FindFirstFile, FindNextFile and FindClose functions.
Also see:
C# deleting a folder that has long paths
DirectoryInfo, FileInfo and very long path
You can use the subst command. It creates a virtual drive starting at whatever folder you pass as parameter.
For example, you can turn the path c:\aaaaaaaaaaaaaaaaaaaaaa\aaaaaaaaaaaaaaaaaaaa\aaaaaaaaaaaaaa into the drive R: and continue exploring the subfolders of c:\aaaaaaaaaaaaaaaaaaaaaa\aaaaaaaaaaaaaaaaaaaa\aaaaaaaaaaaaaa thru R:...
Do you know what I mean?
I also recommend reading this three-part blog post from the BCL Team, published in 2007, but relating specifically to the limitations of DirectoryInfo when it comes to deeply nested folders. It covers the history of the MAX_PATH limitation, the newer \?\ path format, and various .NET-based solutions and workarounds.
Comprehensive, though perhaps a bit dated.
How can I just make a function call, without URL, and without HTTP, to a simple ASP.NET file, and capture the byte stream it generated?
More background information,
I need a some kind of template can put a little logic inside, to render some INI like text files. I give up those libraries ported from Java and come up a solution of using ASP.NET for template engine. (I am NOT using it to build a website, not even a HTML.)
I have written a ASP.NET page (no WebForm, no MVC), which accept a XML POST, and it generate a long text file based on a set of simple but not too simple rules.
I generate the XML from DB objects, submit to the ASP page, grep the result and it works very well. However, the problem is that we want to use as a library, using by a WCF. Because of this, I failed to use a relative path and I have to store the URL of the ASP somewhere in the configuration, which I do not want to.
It will be hosted on a IIS server, but not called (at least not directly) from any frontend ASP, and will never called from end user.
PS. I was originally looking for a simple template engine for C#, but they are too old and not maintenance anymore, poor documentation, missing integrated editor/debugger, too simple, and the they might speak different languages.
PPS. I've also thought about T4, but it does not have a editor nor debugger in VS 2008.
You can run an ASPX page without IIS, without an HTTP message, if you build a host for the ASPNET runtime.
Example:
public class MyAspNetHost : System.MarshalByRefObject
{
public void ProcessRequest(string page)
{
var request = new System.Web.Hosting.SimpleWorkerRequest
(page, // the page being requested
null, // query - none in this case
System.Console.Out // output - any TextWriter will do
);
// this will emit the page output to Console.Out
System.Web.HttpRuntime.ProcessRequest(request);
}
public AppDomain GetAppDomain()
{
return System.Threading.Thread.GetDomain();
}
}
public class Example
{
public void Run(IEnumerable<String> pages)
{
// ASPNET looks for assemblies - including the assembbly
// that contains any custom ASPNET host - in the bin\
// subdirectory of the physical directory that backs the
// ASPNET Host. Because we are going to use the current
// working directory as the physical backing directory for
// the ASPNET host, we need to ensure there's a bin
// subdirectory present.
bool cleanBin = false;
if (!Directory.Exists("bin"))
{
cleanBin = true;
Directory.CreateDirectory("bin");
}
// Now, ensure that the assembly containing the custom host is
// present in that bin directory. The assembly containing the
// custom host is actually *this* assembly.
var a = System.Reflection.Assembly.GetExecutingAssembly();
string destfile= Path.Combine("bin", Path.GetFileName(a.Location));
File.Copy(a.Location, destfile, true);
host =
(MyAspNetHost) System.Web.Hosting.ApplicationHost.CreateApplicationHost
( typeof(MyAspNetHost),
"/foo", // virtual dir - can be anything
System.IO.Directory.GetCurrentDirectory() // physical dir
);
// process each page
foreach (string page in pages)
host.ProcessRequest(page);
}
}
If you want to clean up that bin directory, you have to get the AppDomain to unload first. You can do that, like this:
private ManualResetEvent aspNetHostIsUnloaded;
private void HostedDomainHasBeenUnloaded(object source, System.EventArgs e)
{
// cannot clean bin dir here. The AppDomain is not yet gone.
aspNetHostIsUnloaded.Set();
}
private Run(IEnumerable<String> pages)
{
try
{
....code from above ....
}
finally
{
if (host!= null)
{
aspNetHostIsUnloaded = new ManualResetEvent(false);
host.GetAppDomain().DomainUnload += this.HostedDomainHasBeenUnloaded;
AppDomain.Unload(host.GetAppDomain());
// wait for it to unload
aspNetHostIsUnloaded.WaitOne();
// optionally remove the bin directory
if (cleanBin)
{
Directory.Delete("bin", true);
}
aspNetHostIsUnloaded.Close();
}
}
}
This makes sense for testing ASPX pages, and that sort of thing. But I'm not so sure this is the right thing, for your scenario. There are more direct ways to generate text files. But, it may be right for you. If you really like the template engine idea, hosting ASPNET may be just the thing for you.
In your case, you would want to modify the custom Host so that the output for each page goes to a StringWriter instead of Console.Out, and then you could do Grep (or more likely a search with Regex) on that output. You might also want to modify it to accept all the input data as a querystring. You'd need to format the page request to do that.
EDIT: There's a good article on MSDN Magazine on this technique of hosting the ASPNET runtime. From December 2004.
EDIT2: There's a simpler way to manage the bin directory. Just create a symbolic link named bin, pointing to ".". Then, you can remove the symlink after the call to AppDomain.Unload(), without waiting. Looks like this:
public void Run(string[] pages)
{
bool cleanBin = false;
MyAspNetHost host = null;
try
{
// This creates a symlink.
// ASPNET always looks for a bin\ directory for the privateBinPath of the AppDomain.
// This will create the bin dir, pointing to the current dir.
if (!Directory.Exists("bin"))
{
cleanBin = true;
CreateSymbolicLink("bin", ".", 1);
}
host =
(MyAspNetHost) System.Web.Hosting.ApplicationHost.CreateApplicationHost
( typeof(MyAspNetHost),
"/foo", // virtual dir - can be anything
System.IO.Directory.GetCurrentDirectory() // physical dir
);
foreach (string page in pages)
host.ProcessRequest(page);
}
finally
{
// tell the host to unload
if (host!= null)
{
AppDomain.Unload(host.GetAppDomain());
if (cleanBin)
{
// remove symlink - can do without waiting for AppDomain unload
Directory.Delete("bin");
}
}
}
}
This eliminates the need for the ManualResetEvent, copying files, synchronization, etc. It assumes the assembly for the custom ASPNet Host as well as all the assemblies required by the ASPX pages you run are contained in the current working directory.
This sounds like a very similar issue which is generating HTML emails on a server. There are some answers here that do that (for MVC):
ASP.NET MVC: How to send an html email using a controller?
You can proceed in a similar fashion for non-MVC by loading and rendering a control (ASCX) to a file.