Domanda

Ho un'applicazione a tre livelli installata in ambienti aziendali.Con ogni aggiornamento della versione del server, anche tutti i client devono essere aggiornati.Attualmente fornisco un pacchetto MSI che viene distribuito automaticamente tramite Active Directory, tuttavia i miei clienti (per lo più con 20-300 utenti ciascuno) sembrano odiare la soluzione MSI perché è

  • Complicato farlo funzionare (poca conoscenza di Active Directory);
  • Il processo di aggiornamento non può essere attivato dal server, quando viene rilevata una nuova versione;
  • I clienti non possono installare più versioni del client (ad es.2.3 e 2.4) contemporaneamente per parlare con server diversi;
  • Il processo di aggiornamento in sé non funziona sempre come previsto (a volte un comportamento molto strano si risolve da solo dopo poche ore)

Ora ho fatto alcuni esperimenti con ClickOnce, ma per me è poco flessibile e troppo difficile da integrare nel mio processo di creazione automatizzato.Inoltre, produce messaggi di errore criptici che sicuramente confonderebbero i miei clienti.

Non avrei problemi a scrivere personalmente la logica di aggiornamento, ma il problema è che gli utenti che utilizzano applicazioni ad aggiornamento automatico hanno diritti troppo limitati per eseguire un aggiornamento.Ho scoperto che sono in grado di scrivere nella directory dei dati dell'applicazione locale, ma non penso che questo sarebbe il luogo tipico in cui installare i file dell'applicazione.

Conosci un modo per ottenere un aggiornamento che "funzioni e basta"?

È stato utile?

Soluzione

Puoi replicare in qualche modo ciò che fa ClickOnce, basta adattarlo alle tue esigenze.

  1. Crea un eseguibile leggero che controlla la presenza di aggiornamenti in una posizione di rete/web.
  2. Se sono presenti aggiornamenti, li copia localmente e sostituisce i file "reali" dell'applicazione.
  3. Esegue l'applicazione "reale".

La posizione dei file dell'applicazione deve essere determinata dalle autorizzazioni e dal sistema operativo.Se gli utenti dispongono dell'autorizzazione di scrittura solo per un set limitato di cartelle, non hai altra scelta che utilizzare una di queste cartelle.Un'altra opzione è fornire un pacchetto di installazione iniziale che installi l'eseguibile leggero e conceda l'autorizzazione di lettura/scrittura su una cartella specifica come "C:\Programmi\MyApp".Questo approccio di solito richiede il consenso dell'IT.

Spero che aiuti.

Altri suggerimenti

È davvero difficile fornire risposte esatte perché le informazioni critiche sul programma di installazione lato client non sono esplicite.I file lato client vengono installati in Programmi?Quindi potresti riscontrare problemi quando gli utenti sono limitati.

Non pensi che i dati dell'applicazione locale siano una cartella per distribuire l'applicazione, ma Google lo fa.Il suo browser Chrome si installa in questo modo su Windows e il suo processo di aggiornamento automatico è persino impercettibile (il che può sembrare orribile).Allora perché non distribuire la tua applicazione in questa cartella per gli utenti con restrizioni?Puoi trovare ulteriori informazioni sul programma di installazione di Chrome qui,

http://robmensching.com/blog/archive/2008/09/04/Dissecting-the-Google-Chrome-setup.aspx

Ecco una soluzione open source che ho scritto per soddisfare le esigenze specifiche che avevamo per le app WinForms e WPF.L'idea generale è quella di avere la massima flessibilità, con il minor sovraccarico possibile.Dovrebbe darti tutta la flessibilità di cui hai bisogno per tutto ciò che hai descritto.

COSÌ, integrazione è semplicissimo e la libreria fa praticamente tutto per te, comprese le operazioni di sincronizzazione.È altresì altamente flessibile, e ti consente di determinare quali attività eseguire e a quali condizioni: sei tu a stabilire le regole (o usarne alcune già presenti).Ultimo ma non meno importante è il supporto per qualsiasi fonte di aggiornamenti (web, BitTorrent, ecc.) e qualsiasi formato del feed - qualunque cosa non sia implementata puoi semplicemente scriverla per conto tuo.

Sono supportati anche gli aggiornamenti a freddo (che richiedono il riavvio dell'applicazione), che vengono eseguiti automaticamente a meno che non venga specificato "hot-swap" per l'attività.

Ciò si riduce a una DLL, di dimensioni inferiori a 70 KB.

Maggiori dettagli su http://www.code972.com/blog/2010/08/nappupdate-application-auto-update-framework-for-dotnet/

Il codice è a http://github.com/synhershko/NAppUpdate (Concesso in licenza con la licenza Apache 2.0)

Ho intenzione di estenderlo di più quando avrò più tempo, ma onestamente dovresti essere in grado di migliorarlo rapidamente da solo per tutto ciò che attualmente non supporta.

Se non vuoi dare troppi diritti ai tuoi utenti, è possibile scrivere un servizio Windows, che verrà eseguito su ciascun computer con un account con i privilegi appropriati e che può aggiornare la tua applicazione, quando diventa disponibile una nuova versione .

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top