Ich arbeite an der Aktualisierung einer unserer Anwendungen. Es muss .NET 2.0 verwenden. Ein Teil erstellt eine Datei auf dem Desktop, mitDatei auf dem Desktop in Vista/Windows 7 in .NET 2.0 speichern
FileStream fs = new FileStream(Environment.GetFolderPath
(Environment.SpecialFolder.DesktopDirectory), FileMode.Create);
Aber ich erhalte eine UnauthorizedAccessException in Windows 7 (und auch Vista, ich gehe davon aus, obwohl ich das noch nicht getestet). Ich untersuchte die Höhe (nicht für das gesamte Programm, sondern für eine separate Assembly, die die Datei erstellen und Aktionen ausführen würde). Dies scheint jedoch .NET 3.0 oder 3.5 zu erfordern. Gibt es eine Möglichkeit, mit .NET 2.0 auf den Desktopordner zuzugreifen? (Requiring das Programm als Administrator ausgeführt werden, ist auch keine Option)
(Ich habe eine Suche, und die einzige Frage, die nahe an dem, was ich frage, ist dies: File creation fails in standard account (Vista) aber es geht um die gesamte App erhöhen und ist nicht .NET 2.0 spezifisch, so dass ich glaube, das ist kein Duplikat)
EDIT:
Wow, ich wäre wirklich dumm. Das funktioniert tatsächlich gut. Ich habe versucht, eine Datei namens C: \ Users \ MyUser \ Desktop zu erstellen. Hoppla. Entschuldigung für die Verwirrung.
EDIT: Hier ist der Text der Ausnahme:
System.UnauthorizedAccessException was unhandled
Message="Access to the path 'C:\\Users\\MyUser\\Desktop' is denied."
Source="mscorlib"
StackTrace:
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy)
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options, String msgPath, Boolean bFromProxy)
at System.IO.FileStream..ctor(String path, FileMode mode)
at MyProgram.Prog.SaveDiagnostic(String filename, String text) in C:\Source\MyProgram\Prog.cs:line 95
at MyProgram.Form1.buttonGenDiagnostic_Click(Object sender, EventArgs e) in C:\Source\MyProgram\Form1.cs:line 4729
at System.Windows.Forms.Control.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ButtonBase.WndProc(Message& m)
at System.Windows.Forms.Button.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)
at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(Int32 dwComponentID, Int32 reason, Int32 pvLoopData)
at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)
at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)
at System.Windows.Forms.Application.Run(Form mainForm)
at Northwoods.CRM.Import.Form1.Main(String[] args) in I:\WebProspect\Source\Northwoods.CRM.Import\Form1.cs:line 2616
at System.AppDomain._nExecuteAssembly(Assembly assembly, String[] args)
at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()
InnerException:
Ich denke, Sie sollten vollständigen Fehler exception.ToString() mit vollständiger Ablaufverfolgung, da dies klingt nicht Problem mit Administrator-Konto oder nicht. Environment.GetFolderPath liefert immer den korrekten Desktop für den aktuellen Benutzer, der das Programm ausführt, und der aktuelle Benutzer hat immer vollen Zugriff auf den Desktop, um die Datei auf dem Desktoppfad zu erstellen/zu löschen. Allerdings haben wir dies auf Vista für Nicht-Admin-Account getan und es funktioniert, für Windows 7 werde ich bald testen, aber ich bestehe immer noch darauf, dass Sie die detaillierte Stack-Trace veröffentlichen. –
Es erhält den richtigen Desktop-Ordner für den aktuellen Benutzer, aber ich denke, Win7 lässt Programme dort nichts ändern. Ich werde jedoch immer noch die vollständige Ausnahme posten. – NickAldwin
@Nick: Die Ironie ist, dass ich genau die gleiche Ausnahme erzeugt habe, als ich versucht habe, dein Problem zu reproduzieren. Ich habe Ihren Code nicht kopiert und eingefügt, aber ich habe etwas Ähnliches geschrieben und die Ausnahme erhalten. Anschließend habe ich die Ausnahme geändert, indem ich dem Pfad einen tatsächlichen Dateinamen hinzugefügt habe, damit er funktioniert. Ich habe nie bemerkt, dass dein Code das gleiche gemacht hat. Normalerweise versuche ich in meinen Codebeispielen einen Zeilenumbruch zu machen, damit ich die horizontale Bildlaufleiste nicht bekomme - sonst ist es einfacher, solche Dinge zu übersehen. – MusiGenesis