|
|
There is a thing called "the documentation", it holds answers to such elementary questions. Look for the Process class.
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
I know there are many things to reffer. but cant u
answer a little more explicit? thanks anyway.
|
|
|
|
|
He did. It's your job as a programmer to understand the classes you're using. Read the documentation on the Process class and you'll probably end up learning a lot about the Process class instead of knowing just the single little use case that someone gives you in a code sample.
|
|
|
|
|
|
Hi,
I have to write an application that has the ability to perform a system-restart, shutdown or user-logoff. So far, I have found two solutions to do it, which both work very well. I'd like to know which is the best way to do it, i.e. if there are any disadvantages to the one or the other way to do it. Which is the most professional way to deal with it?
Currently, I use the System.Management Namespace, whic looks like the most elegant way to do this to me:
ManagementBaseObject mboShutdown = null;
using (ManagementClass mcWin32 = new ManagementClass("Win32_OperatingSystem"))
{
mcWin32.Get();
mcWin32.Scope.Options.EnablePrivileges = true;
ManagementBaseObject ShutdownParams = mcWin32.GetMethodParameters("Win32Shutdown");
ShutdownParams["Flags"] = "1";
ShutdownParams["Reserved"] = "0";
foreach (ManagementObject manObj in mcWin32.GetInstances())
{
mboShutdown = manObj.InvokeMethod("Win32Shutdown", ShutdownParams, null);
}
ret = true;
}
On the other hand, I have found many users who load the appropriate system-DLLs, and perform the whole tsak "unmanaged", an call ExitWindowsEx from these DLLs. This works too, but I am wondering why people decide to do it this way, if there is a namespace available in .NET that actually does it, like in my example above.
Which way would you chose, and why?
|
|
|
|
|
I have used neither one. I think I once used something akin to "Process.Start("shutdown").
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
The un-managed code is not recommended one in long term, although it is faster way to achieve same.
With managed, good way is:
using System.Diagnostics;
ProcessStartInfo startinfo = new ProcessStartInfo("shutdown.exe","-r");
Process.Start(startinfo);
Keep in mind the options you want to use:
-i Display GUI interface, must be the first option
-l Log off (cannot be used with -m option)
-s Shutdown the computer
-r Shutdown and restart the computer
-a Abort a system shutdown
-m \\computername Remote computer to shutdown/restart/abort
-t xx Set timeout for shutdown to xx seconds
-c "comment" Shutdown comment (maximum of 127 characters)
-f Forces running applications to close without warning
-d [u][p]:xx:yy The reason code for the shutdown, u is the user code, p is a planned shutdown code, xx is the major reason code (positive integer less than 256)
,yy is the minor reason code (positive integer less than 65536)
|
|
|
|
|
RaviSant wrote: The un-managed code is not recommended one in long term
Got a citation for this??
|
|
|
|
|
Dave Kreskowiak wrote: Got a citation for this??
Certainly is something I try to avoid since incorrect usage of interop or even the unmanaged itself code can cause an OS system exception thus exiting the app. That behavior is not acceptable in a server application. Probably not something that one wants to occur in any app as well.
The following certainly would suggest that there are reasons that one might want to look for other options.
http://msdn.microsoft.com/en-us/library/ms973872.aspx#manunman_topic4[^]
|
|
|
|
|
The most direct and rock solid way to do it, with the greatest amount of control, is ExitWindowsEx. I don't like using WMI because it has a habit of silently commiting suicide and you're left wondering why your call that used to work fine suddenly fails with cryptic errors, like "RPC Server unavailable".
|
|
|
|
|
Dear all,
Im using this code to get the names of shared network drives in my computer:
DriveInfo[] allDrives = DriveInfo.GetDrives();
foreach (DriveInfo d in allDrives)
{
if (d.DriveType == DriveType.Network)
{
Response.Write(d.Name);
}
}
In win xp this works fine, but in windows7 i can only see the local drives.
Any idea why ? and how to solve this?
Thanks in advance.
|
|
|
|
|
Priya Prk wrote: In win xp this works fine, but in windows7 i can only see the local drives.
how that is possible to see the local drives after using given code. It will display only when you will use DriveType.Fixed [as I know]
Check your code it only display Network Drives Name not LocalDrives Name because Response.Write(d.Name)
only works and print the Name of Drives when DriveType will equals to DriveType.Network
Take a look you've applied condition.
Priya Prk wrote: if (d.DriveType == DriveType.Network)
{
Response.Write(d.Name);
}
modified on Friday, January 14, 2011 5:19 AM
|
|
|
|
|
I think what he means is that d.DriveType == DriveType.Network is never true under Windows 7, while it is under Windows XP. If you look, the OP does say that the code works under XP...
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
|
|
|
|
|
Hi all,
My bad.
OriginaGriff is right.. DriveType.Network is never true.
|
|
|
|
|
I have checked your code but it works in Windows 7 also!
|
|
|
|
|
Hi Goutam Patra,
It does not work in my envoirment. i can see the drives in windowns explorer , but not with my code.
And if i try to read a file from a directory in network drive(i have read permissions) , im getting:
Could not find a part of the path \\network\dir
|
|
|
|
|
Goutam Patra wrote: I have checked your code but it works in Windows 7 also!
are you sure you are able to see Network Drive as well as Local Drive by using OP codes.
|
|
|
|
|
|
Try using WMI instead. The following code should get a list of network drives:
public static List<string> FindNetworkDrives()
{
List<string> networkDrives = new List<string>();
SelectQuery query = new SelectQuery("select name from win32_logicaldisk where drivetype=4");
ManagementObjectSearcher searcher = new ManagementObjectSearcher(query);
foreach (ManagementObject obj in searcher.Get())
{
networkDrives.Add(obj["Name"]);
}
return networkDrives;
}
|
|
|
|
|
Hi Pete O'Hanlon,
I did try your code, but unfortunately still no results.
|
|
|
|
|
My guess would be you have a problem with permissions on your Win7 machine; nothing wrong with all the code you tried.
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
I think also it had to do with permissions, but dont understand how,
i tried to get files via asp.net fileupload control from those network drives, no problems...but when i try to read the same file with StreamReader im getting again that error.
|
|
|
|
|
Uhhh, what? How does a web app fit into all this?? There's something you're not telling us that's affecting this problem or causing it.
|
|
|
|
|
Priya Prk wrote: but in windows7 i can only see the local drives.
1. Create a sample class/project console application that ONLY does this code and prints the results via System.Console.
2. Open a console window in Windows 7.
3. Run that app.
4. If it does NOT display the network drives then remove the condition check and run again.
Post that class, the complete class, and the output if it does not report the drives.
If it does report the drives then it means the context of your original app, not the code, is the source of your problem.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
