Come gestire il passaggio da ASP MVC versione 4.0.0.0 alla 4.0.0.1

Question

Si tratta di un follow-up a Windows update caused MVC3 and MVC4 stop working

Ho avuto anche il problema in cui Windows Update sulla mia macchina di sviluppo ha causato il mio progetto MVC 4 di smettere di lavorare. Ho cambiato il riferimento all'assembly alla versione di destinazione 4.0.0.1 e ha iniziato a funzionare. Per me.

Il mio problema è che l'applicazione viene quindi distribuita su un numero di server web. In realtà, abbiamo un server di build in cui sono state create le versioni dei clienti e quindi un numero di server web.

Prima domanda: Quando eseguiamo l'aggiornamento di Windows sui server di produzione, le vecchie versioni dell'applicazione smetteranno di funzionare? Immagino che la risposta sia "sì". Non abbiamo ancora eseguito l'aggiornamento di Windows sui computer di produzione o di produzione.

Cambiare il riferimento significava che non poteva più essere costruito sulla macchina di costruzione. Posso aggirare questo impostando il flag Versione specifica su falso e Copia locale su vero. Quindi si basa sia sul mio ambiente di sviluppo che sul server di build.

Domanda: Come è il controllo se ho una versione specifica falsa? Consente 4.0.0.x? 4.0.x.x? 4.x.x.x? o x.x.x.x?

Tuttavia, nonostante sia stato creato in tale configurazione, non riesce a eseguire (impossibile trovare l'assembly) sul server Web di prova. Il problema qui è che ho seguito nel mio web.config (come da istruzioni Microsofts quando ho aggiornato da MVC 2 a MVC 4):

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> 
    <dependentAssembly> 
    <assemblyIdentity culture="neutral" name="System.Web.Mvc" publicKeyToken="31BF3856AD364E35"/> 
    <bindingRedirect newVersion="4.0.0.1" oldVersion="0.0.0.0-4.0.0.1"/> 
    </dependentAssembly> 
    <dependentAssembly> 
    <assemblyIdentity name="System.Web.Helpers" publicKeyToken="31bf3856ad364e35"/> 
    <bindingRedirect newVersion="2.0.0.0" oldVersion="1.0.0.0"/> 
    </dependentAssembly> 
    <dependentAssembly> 
    <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35"/> 
    <bindingRedirect newVersion="4.0.0.0" oldVersion="1.0.0.0-3.0.0.0"/> 
    </dependentAssembly> 
    <dependentAssembly> 
    <assemblyIdentity name="System.Web.WebPages" publicKeyToken="31bf3856ad364e35"/> 
    <bindingRedirect newVersion="2.0.0.0" oldVersion="1.0.0.0"/> 
    </dependentAssembly> 
</assemblyBinding> 

Il problema è la linea

<bindingRedirect newVersion="4.0.0.1" oldVersion="0.0.0.0-4.0.0.1"/> 

per l'assemblea System.Web.Mvc. (Era solito dire 4.0.0.0 non 4.0.0.1 in quella riga, ovviamente.) Se torno a 4.0.0.0 sul server di test, allora funziona.

Il mio problema è duplice. In parte è solo che voglio essere in grado di creare ed eseguire sia localmente che sui nostri server di produzione/produzione. Tuttavia, abbiamo una situazione in cui ospitiamo un numero di clienti che eseguono versioni diverse della nostra applicazione sullo stesso server. Non possiamo costringere tutti i nostri clienti a eseguire l'aggiornamento all'ultima versione contemporaneamente solo a causa di questa correzione per gli aggiornamenti di Windows - a parte ogni altra cosa l'applicazione Web fa parte di una più ampia suite di applicazioni, quindi dovremmo costringerli ad aggiornare il lotto!

Suppongo che un'opzione è quella di eseguire il checkout di ciascuna delle vecchie versioni ancora in uso, aggiornare il numero di versione MVC e creare una nuova versione. Quindi, quando aggiorniamo il server web, dobbiamo aggiornare tutti i i clienti su quel server a una nuova versione (4.0.0.1 compatibile) della loro versione corrente. Mi piacerebbe davvero evitare di dover aggiornare, commettere e ricostruire molte versioni se possibile.

Un'altra opzione potrebbe essere quella di non eseguire l'aggiornamento di Windows sul server Web e provare a installare entrambe le DLL 4.0.0.0 e 4.0.0.1 sul computer di creazione. Quindi potremmo costruire sia la vecchia che la nuova versione. Dal momento che qualsiasi nuova versione (utilizzando 4.0.0.1) ha CopyLocal impostato su true sull'assembly MVC (i vecchi non lo fanno) dovrebbero essere in grado di essere distribuiti sui server Web senza che i server Web vengano aggiornati.

Domande:

• Qualcuno sa se è possibile avere entrambe le versioni installate contemporaneamente? Spero di poter semplicemente salvare la dll 4.0.0.0, eseguire l'aggiornamento di Windows, quindi copiare la vecchia dll in GAC insieme alla nuova.
• Quanto è grave il rischio per la sicurezza risolto da questa patch? È un problema consentire alle persone di eseguire le vecchie versioni un po 'più a lungo? Sta avendo la vecchia .dll sul server web un rischio per la sicurezza o solo per le applicazioni che la usano?
• C'è un modo per fare un bindingRedirect a 4.0.0.x? oppure è possibile semplicemente rimuovere completamente il reindirizzamento del binding?

Non riesco a credere di essere l'unico in questa situazione e vorrei anche ricevere suggerimenti per soluzioni a cui non ho pensato affatto.

Answer 1

Ero un membro di una squadra che ha riscontrato questo stesso problema da un'angolazione leggermente diversa. Il messaggio di errore che invia quando l'aggiornamento della sicurezza è errato può essere fuorviante e difficile da interpretare. Ci siamo imbattuti nella distribuzione e abbiamo creato errori quando abbiamo provato a pubblicare le nostre app in diversi ambienti. La causa principale era che questa patch veniva applicata tramite l'aggiornamento di Windows su alcuni ambienti di test ma non su altri server. Qualsiasi server che non ha avuto la patch si arresterebbe in modo anomalo quando abbiamo distribuito la nostra applicazione. Vorrei raccomandare al vostro team di sistemi di applicare la patch e aggiornare tutte le vostre applicazioni per fare riferimento a questa DLL. Security updates Poiché la libreria a cui si fa riferimento viene ignorata nel controllo del codice sorgente, ma è ancora descritta dettagliatamente nelle configurazioni Web, deve essere affrontata rapidamente. Alcuni ambienti ti consentiranno di fare clic con il pulsante destro del mouse e scegliere quale versione MVC dll utilizzare localmente e continuare a distribuire l'applicazione senza problemi. Se si utilizza la distribuzione Web e DEVE essere in grado di passare, è possibile scrivere trasformazioni di configurazione Web per ogni Transforms web config. Una cosa che ho notato durante la correzione di questo problema (l'aggiornamento alla 4.0.0.1) è che l'aggiornamento alla versione più recente di MVC.dll nel mio progetto mi ha permesso di ottenere le ultime versioni dei pacchetti di nuget. Se non si aggiorna e si rimane con le vecchie versioni, si sarà bloccati con le vecchie versioni di MVC javascript, jquery e altre librerie.