È una cattiva idea utilizzare ProgramData per consentire agli utenti non amministratori di aggiornare il nostro programma?

Presumibilmente queste aziende hanno "bloccato" i loro desktop degli utenti per [ciò che considerano essere] buone ragioni. Implementando un meccanismo che aggira la loro politica, si sta aprendo un'intera scatola di worm legali.

Parla di questi reparti IT su come loro gestiscono la distribuzione delle applicazioni e lavorano con loro. Non cercare di "aggirarli".

Sei uno sviluppatore che scrive un'applicazione. Ti interessa offrire nuove e brillanti funzionalità.

Sono aziende che usano la tua applicazione (tra le altre). Si preoccupano di avere un software che funzioni in modo che possano eseguire il loro business.

Inoltre, lavorando con questi reparti IT, guadagni intrinsecamente un sacco di tester [non retribuiti], perché probabilmente [vogliono] provare nuove versioni del tuo software e potrebbe trovare i difetti per tu.

In base alla descrizione del tuo obiettivo (piuttosto che alla tentata soluzione di cercare di scrivere nella cartella C:\ProgramData ), ti suggerirei di cercare Microsoft ClickOnce Deployment .

ClickOnce è più comunemente associato alle applicazioni .NET sviluppate con Visual Studio, tuttavia ClickOnce come strumento di distribuzione funzionerà per qualsiasi applicazione, indipendentemente dagli strumenti e dalle tecnologie utilizzate per crearlo.

Se hai un'applicazione .NET, ClickOnce è un gioco da ragazzi. Per qualsiasi altra app o app Visual C ++ è possibile raggiungere lo stesso obiettivo con uno strumento chiamato Mago .

(Nota: con ClickOnce, non ci sarà bisogno di sviluppare la propria applicazione bootstrap o aggiornamento, questa è tutta la parte del pacchetto)

Aggiornamento: credito a @RubberDuck :

There is a caveat to Click Once, you have to design your application so that it doesn't have to do things that require admin privileges on installation. For example, forget Click Once if you need to do any COM registration. There's a benefit you didn't mention as well. Updates can be controlled from a central location if you use the auto-update feature.

La tua domanda è specifica del sistema operativo e non ha senso su Linux o MacOSX.

Tecnicamente, un modo possibile per codificare la tua applicazione è di avere la maggior parte di esso un plug-in (cioè alcuni DLL ; ma attenzione ai DLL inferno ); l'eseguibile vero e proprio sarebbe solo un piccolo stub (si spera che sia uno fisso) che effettua chiamate a LoadLibrary o simili caricamento dinamico (o collegamento) delle funzioni.

Potresti anche prendere in considerazione l'inclusione di qualche interprete (es. Lua o Guile ) nella tua applicazione (e lascia che l'utente aggiorni il bytecode o lo script per esso). O anche usare qualche raccolta JIT libreria (à la asmjit o libgccjit o LLVM o libjit ).

In qualche modo astratto, il codice è dato e il dato è codice. Leggi informazioni su Turing-completezza e accidentalmente completo di Turing sistemi e ricorda che il blocco dei problemi è irrisolvibile.

In tutti i casi, non sono sicuro che sarebbe una saggia idea, come commentato, che i reparti IT dei tuoi clienti potrebbero non essere soddisfatti di ciò.

(Sento che stai cercando una soluzione tecnica a quello che è in realtà un problema sociale : il trust che i reparti IT mettono su software esterno)

Dovresti convincere il tuo cliente che (qualunque sia il meccanismo che utilizzerai) la tua "soluzione" non è una porta aggiuntiva per virus o malware (specificatamente scritta per la tua applicazione).

Leggi informazioni su base di calcolo attendibile e proof-carrying code e aggiornamento dinamico del software . Attenti a (indesiderato) iniezione di codice .

Leggi di nuovo Thompson's Turing Award Lecture Riflessioni su Trust Trust (1984) è ancora attuale e molto pertinente alle tue preoccupazioni.

^{PS. Non lo so e non uso Windows, ma solo Linux.}