Come dare lettura/scrittura autorizzazioni a una cartella durante l'installazione utilizzando .NET

Question

Ho un progetto di installazione che ho costruire utilizzando Visual Studio 2010.

Il programma di installazione funziona bene in termini di installare l'applicazione e tutte le sue dipendenze nelle rispettive sottodirectory e nelle directory dei dati del programma.

Tuttavia, ho notato che ogni directory (cartella principale e tutte le sue sottodirectory) che il programma di installazione creato non dà "scrivere" i permessi. Le uniche autorizzazioni che vengono aggiunti alle directory per il gruppo "utenti" sono:

• Leggi & Esegui
• contenuti delle cartelle Lista
• Leggi

Questa, apparente impostazione autorizzazioni predefinite, sarà succede indipendentemente se l'utente installa l'applicazione come "Amministratore" o meno.

Mi sembra strano che il programma di installazione non conceda le autorizzazioni di "Scrittura" a una cartella utilizzata dall'applicazione che viene installata. È ancora più confusa la cartella creata dal programma di installazione nella cartella ProgramData per il database dell'applicazione non ottiene i permessi di "Scrittura".

La mia domanda è: esiste un modo per configurare il progetto di installazione in modo che, se e quando si crea una cartella, possiamo dire che il tipo di autorizzazioni per dare ea chi. Nel mio caso, ho bisogno di dare la directory root (dell'applicazione) e tutte le sue sottodirectory e la cartella che è posizionata nella cartella ProgramData "Lettura/Scrittura" per il "Gruppo utenti". Tecnicamente, mi sento figo nel dare il comando "Controllo completo" al "Gruppo utenti".

Answer 1

Per gruppo di utenti predefinito non dispone di accesso in scrittura in percorsi distinti per ogni macchina come Program Files. Questo è uno standard di Windows che non è correlato alle installazioni. Tuttavia, durante l'installazione è possibile impostare le autorizzazioni desiderate.

Windows Installer supporta autorizzazioni personalizzate, ma Visual Studio non offre un modo per loro impostazione. Quindi l'unica soluzione in Visual Studio è un'azione personalizzata.

Sfortunatamente Visual Studio non supporta azioni personalizzate collegate. Quindi usare XCACLS.EXE per impostare le autorizzazioni funzionerebbe solo se lo includi nel tuo pacchetto (verrà installato sul computer di destinazione insieme ai tuoi file).

Un pulitore, ma più complessa soluzione è quella di scrivere un azione personalizzata da soli (utilizzando il codice personalizzato) per impostare le autorizzazioni che si desidera.

La soluzione più veloce e più pulita sarebbe quella di utilizzare un diverso strumento di authoring di installazione che offre un maggiore controllo sulle autorizzazioni.

Answer 2

Il comportamento è di progettazione. I programmi non dovrebbero modificare se stessi (di conseguenza la loro directory di installazione) per qualsiasi cosa eccetto gli aggiornamenti (che di nuovo possono essere eseguiti con il programma di installazione di Windows senza problemi). Se si utilizza .NET, isolated storage è una posizione eccellente per archiviare i dati utente.

Answer 3

Credo che il mio altro post è stato cancellato per essere un po 'troppo generico, così ho raffinato qui sotto:

La cosa da fare è fare un'azione personalizzata.È piuttosto semplice, controlla la procedura dettagliata MSDN per scrivere un'azione personalizzata C# here. Potrai inserire il codice di autorizzazione che cambia all'interno del metodo Installare:

Seguire i primi due passi dal link per ottenere un nuovo progetto di installazione di riferimento dalla vostra soluzione installatore. Devi farlo in questo modo, quindi puoi creare una DLL che viene chiamata alla fine dell'installazione.

realtà impostazione privilegi di lettura/scrittura per gli utenti è stato un po 'più complicato, e il più vicino ho potuto ottenere era quello di impostare per gli utenti autenticati. Ho messo insieme un paio di altre soluzioni che ho trovato su Internet per venire con questo:

public override void Install(IDictionary stateSaver) 
{ 
    // This gets the named parameters passed in from your custom action 
    string folder = Context.Parameters["folder"]; 

    // This gets the "Authenticated Users" group, no matter what it's called 
    SecurityIdentifier sid = new SecurityIdentifier(WellKnownSidType.AuthenticatedUserSid, null); 

    // Create the rules 
    FileSystemAccessRule writerule = new FileSystemAccessRule(sid, FileSystemRights.Write, AccessControlType.Allow); 

    if (!string.IsNullOrEmpty(folder) && Directory.Exists(folder)) 
    { 
     // Get your file's ACL 
     DirectorySecurity fsecurity = Directory.GetAccessControl(folder); 

     // Add the new rule to the ACL 
     fsecurity.AddAccessRule(writerule); 

     // Set the ACL back to the file 
     Directory.SetAccessControl(folder, fsecurity); 
    } 

    // Explicitly call the overriden method to properly return control to the installer 
    base.Install(stateSaver); 
} 

Poi, quando si crea l'azione personalizzata, modificare le sue proprietà, e aggiungere qualcosa di simile sotto la proprietà CustomActionData:

/folder="[CommonAppDataFolder][ProductName]" 

Answer 4

DirectoryInfo info = new DirectoryInfo(path[x]); 

DirectorySecurity security = info.GetAccessControl(); 

security.AddAccessRule(new FileSystemAccessRule(logonName, FileSystemRights.Modify, InheritanceFlags.ContainerInherit, PropagationFlags.None, AccessControlType.Allow)); 

security.AddAccessRule(new FileSystemAccessRule(logonName, FileSystemRights.Modify, InheritanceFlags.ObjectInherit, PropagationFlags.None, AccessControlType.Allow)); 

info.SetAccessControl(security); 

Impostazione della parte ereditare è anche importante se si desidera salvare e accedere più di un file nella cartella ProgramData.

Answer 5

Come è stato già detto gruppo Users non ha i permessi di scrittura in Program Files. Se non vuoi gestire la classe di installazione o Wix (se si tratta di un programma semplice), preferisci semplicemente installare il tuo software in un volume di Windows.

sto parlando Visual Studio Setup Wizard: Change Application Folder 'DefaultLocation' immobile da [CartellaProgrammi] a [WindowsVolume] [produttore] [ProductName] nel file system sul computer di destinazione.

Answer 6

private static void GrantAccess(string file) 
     { 
      bool exists = System.IO.Directory.Exists(file); 
      if (!exists) 
      { 
       DirectoryInfo di = System.IO.Directory.CreateDirectory(file); 
       Console.WriteLine("The Folder is created Sucessfully"); 
      } 
      else 
      { 
       Console.WriteLine("The Folder already exists"); 
      } 
      DirectoryInfo dInfo = new DirectoryInfo(file); 
      DirectorySecurity dSecurity = dInfo.GetAccessControl(); 
      dSecurity.AddAccessRule(new FileSystemAccessRule(new SecurityIdentifier(WellKnownSidType.WorldSid, null), FileSystemRights.FullControl, InheritanceFlags.ObjectInherit | InheritanceFlags.ContainerInherit, PropagationFlags.NoPropagateInherit, AccessControlType.Allow)); 
      dInfo.SetAccessControl(dSecurity); 

     } 

Il codice sopra riportato imposta i diritti di accesso della cartella a controllo completo/lettura-scrittura per ogni utente (tutti).

Answer 7

Immagino che dipende dal sistema operativo del server, e se si sta costruendo il codice sullo stesso server come si sta distribuendo a, o uno a distanza?

La cosa più semplice da fare è mettere il vostro comando xcopy in un file batch, e includere qualcosa di simile a quanto segue dopo il xcopy:

cacls c:\[PathToWebsite]\[ChartImagesFolder] /E /G [AccountSiteRunsUnder]:C 

O un altro fino a un'opzione per la data (non ho usato questo, così i miei parametri può essere spento):

icacls c:\[PathToWebsite]\[ChartImagesFolder] /grant [AccountSiteRunsUnder]:M 

in sostanza, uno di questi dovrebbe dare l'account utente che il sito è in esecuzione in Modify (modifica) i diritti nella cartella specificata. Questo dovrebbe essere in aggiunta a tutti i diritti esistenti sulla cartella, ci sono modificatori o opzioni per sostituire i diritti esistenti.

Se si sta eseguendo la distribuzione su un server remoto, è necessario un meccanismo per eseguire i comandi da lì, abbiamo riscontrato che lo PSExec funziona come un trattamento (parte degli strumenti PS di SysInternals).