Introduzione

In questo articolo viene hotfix cumulativo 2996568 disponibile per Microsoft .NET Framework 4.5, il.NET Framework 4.5.1 e di.NET Framework 4.5.2. Per ulteriori informazioni sui problemi che risolve l'aggiornamento cumulativo, vedere la sezione "Informazioni".

Questo hotfix cumulativo è disponibile per i sistemi operativi seguenti:

  • Windows Server 2008 R2 SP1

  • Windows 7 SP1

  • Windows Server 2008 SP2

  • Windows Vista SP2


Risoluzione

Un hotfix supportato è ora disponibile da Microsoft. Tuttavia, destinato esclusivamente alla risoluzione del problema descritto in questo articolo. Applicarlo solo ai sistemi in cui si verificano questo problema specifico.

Per risolvere questo problema, contattare il supporto tecnico clienti Microsoft per ottenere l'hotfix. Per un elenco completo dei numeri di telefono supporto tecnico clienti Microsoft e informazioni sui costi dell'assistenza, visitare il seguente sito Web Microsoft:

http://support.microsoft.com/contactus/?ws=supportNota: In casi particolari, le spese normalmente addebitate per le chiamate di supporto potrebbero essere annullate qualora un addetto al supporto Microsoft determina che uno specifico aggiornamento risolverà il problema. I costi di supporto normale verranno applicati per eventuali ulteriori domande e problemi che non dovessero rientrare nello specifico aggiornamento in questione.

Ulteriori informazioni

Prerequisiti

Per applicare questo hotfix, è necessario disporre di.NET Framework 4.5.2 installato .NET Framework 4.5 o di.NET Framework 4.5.1.

Richiesta di riavvio

È necessario riavviare il computer dopo avere applicato questo hotfix se vengono utilizzati i file interessati. Si consiglia di chiudere tutte le applicazioni basate su.NET Framework prima di applicare questo hotfix.

Informazioni sulla sostituzione dell'aggiornamento rapido

Questo hotfix non sostituisce un pacchetto di hotfix precedentemente rilasciato.


















Problemi che risolve questo hotfix cumulativo

Problema 1

Questo hotfix risolve i seguenti problemi threading in System.IO.Packaging quando si utilizza .NET Framework 4.5, il.NET Framework 4.5.1 o.NET Framework 4.5.2.

  • Un deadlock può verificarsi quando si utilizzano pacchetti di grandi dimensioni su un thread separato. System.IO.Packaging utilizza IsolatedStorage per i pacchetti superiori a 10 megabyte (MB). Quando due o più thread utilizza pacchetti di grandi dimensioni, può verificarsi un deadlock, anche se i pacchetti sono indipendenti. Il deadlock prevede due thread. Uno è in attesa in IsolatedStorageFile.Lock mentre l'altro è in attesa in un altro metodo della classe IsoloatedStorageFile . Questo problema viene risolto aggiungendo la sincronizzazione a System.IO.Packaging per evitare il problema in IsolatedStorageFile.

  • Le eccezioni possono verificarsi quando si recuperano PackageProperties dai pacchetti che vengono aperti in thread separati, anche se i pacchetti sono indipendenti. Gli stack di chiamate più comuni che a questo riguardo sono i seguenti:System.Xml.XmlException: Unrecognized root element in Core Properties part. Line 2, position 2. atMS.Internal.IO.Packaging.PartBasedPackageProperties.ParseCorePropertyPart(PackagePart part) at
    System.IO.Packaging.Package.get_PackageProperties()
    System.ArgumentOutOfRangeException: Specified argument was out of the range of valid values. Parameter name: id atMS.Internal.IO.Packaging.PartBasedPackageProperties.ParseCorePropertyPart(PackagePart part) at
    System.IO.Packaging.Package.get_PackageProperties()
    Questo problema è causato dal conflitto per una risorsa condivisa interno e viene risolto assegnando a ciascun pacchetto una copia di tale risorsa.


Problema 2

Un'applicazione Windows Presentation Foundation (WPF) può utilizzare una grande quantità di memoria quando riceve molte richieste per il servizio UIAutomation . La memoria appartiene agli oggetti presenti nello spazio dei nomi System. Threading . Ciò include System.Threading.CancellationTokenSource, System.Threading.TimerQueueTimer, System.Threading.Timere varie altre classi correlate.

Questi sono gli oggetti allocati per conto di WPF quando WPF riceve una richiesta per l'attività UIAutomation . Sono infine disponibili fino a quando il timeout della richiesta scadenza (in genere tre minuti). Se le richieste arrivano rapidamente, l'applicazione sembra essere perdita di memoria o l'utilizzo di più memoria rispetto a ciò che è ragionevole (per quanto 500 MB).

Questo problema viene risolto da rilasciare gli oggetti quando la richiesta viene completata, anziché attendere la scadenza del timeout.

Problema 3

In un'applicazione WPF, quando si immette del testo utilizzando il coreano Input Method Editor (IME), la proprietà Text di un controllo ComboBox di modificabili non viene modificata correttamente in alcuni casi.

Questo problema può presentare diversi sintomi e che dipende da come l'applicazione (o l'autore del controllo) è configurato il controllo ComboBox. Per esempio:

  • Dopo aver digitato e scheda di stoccaggio (o spostare lo stato attivo a un altro controllo), al testo visualizzato del controllo ComboBox viene ripristinato su una stringa vuota o al valore che aveva prima della digitazione.

  • La funzionalità di TextSearch di ComboBox si comporta in modo non corretto. Il prefisso che è stata immessa non corrisponde oppure corrisponde a un elemento correlato.

Questo problema viene risolto modificando la logica necessaria per contenere i tempi di IME per il coreano che si differenzia leggermente da altri IME.

Problema 4

Dopo aver utilizzato un tocco per eseguire un'operazione di trascinamento e in un'applicazione WPF, il successivo movimento tocco viene ignorato.

Questo problema è risolto una volta completata l'operazione di trascinamento e di ripristinare lo stato interno del gestore di input tocco. In questo modo, calcola la posizione del successivo movimento tocco correttamente.

Problema 5

È possibile attivare facoltativamente una nuova implementazione AuthenticationManager per ottenere significativi delle prestazioni quando si lavora con personalizzato IAuthenticationModules.

Nota: Principali rischi di protezione vengono visualizzati se il codice non è progettato per essere thread-safe. La modifica del comportamento principale si trova sui metodi PreAuthenticate e autentica . In precedenza è stato garantito che il codice era in esecuzione in serie (un blocco globale intrapresa). Nella nuova implementazione, non viene richiesto alcun blocco e il codice del cliente deve garantire la sicurezza del thread.
Inoltre, con la nuova implementazione, la dimensione della cache di PrefixLookup può essere controllata tramite registro di sistema.

Le seguenti chiavi del Registro di sistema possono essere utilizzate per attivare e configurare la lunghezza massima di PrefixLookup:

  • Configurazione globale[HKEY_LOCAL_MACHINE\SOFTWARE[\Wow6432Node]\Microsoft\.NETFramework\v4.0.30319]"System.Net.AuthenticationManager.HighPerformance"=dword:00000001
    "System.Net.AuthenticationManager.PrefixLookupMaxCount"=dword:00010000

  • Configurazione dell'applicazione locale[HKEY_LOCAL_MACHINE\SOFTWARE[\Wow6432Node]\Microsoft\.NETFramework\v4.0.30319\System.Net.AuthenticationManager.HighPerformance]"c:\myapp\myapp.exe"=dword:00000001
    [HKEY_LOCAL_MACHINE\SOFTWARE[\Wow6432Node]\Microsoft\.NETFramework\v4.0.30319\System.Net.AuthenticationManager.PrefixLookupMaxCount]
    "c:\myapp\myapp.exe"=dword:00010000

Impostazioni globali hanno priorità sulle impostazioni locali dell'applicazione. È possibile combinare le impostazioni locali e globali dell'applicazione. PrefixLookupMaxCount non essere interessati se l'impostazione di HighPerformance di applicazione globale o locale è DWORD 1.

Problema 6

Si supponga che si esegue un'applicazione basata su .NET Framework 4.5, il.NET Framework 4.5.1 o di.NET Framework 4.5.2. L'applicazione genera un'eccezione in un metodo gestito che è stato chiamato da codice nativo e un'interfaccia COM è stato passato per riferimento. In questo caso, l'applicazione potrebbe bloccarsi.

Ad esempio: un'applicazione scritta in VB6 chiama una DLL in C#. Se l'applicazione e la DLL vengono compilati in modalità di rilascio, quando viene generata un'eccezione nel codice C#, si verifica una violazione di accesso e l'applicazione si blocca.

Problema 7

Quando i progetti basati su XAML del flusso di lavoro richiedono più tempo rispetto al tempo di lease predefinita (cinque minuti) degli oggetti remoti definiti per le attività per la creazione di XAML, viene visualizzato un messaggio di errore analogo al seguente:

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Xaml.targets(193,5): errore XC1000: XC1020: errore di compilazione per l'attività di MSBuild XAML: ' oggetto ' / cc8d6dcf_823f_4ce0_aaad_fb1d3f85e42b/mzr1is8dfgy6yqtpnhegu6pt_4.rem' è stato disconnesso o non esiste nel server. "

Dopo avere applicato questo hotfix, è possibile definire il proprio tempo di lease (in minuti) per la definizione della variabile di ambiente denominata XamlBuildTaskRemotingLeaseLifetimeInMinutes.

Per impostare la variabile di ambiente in un file di progetto MSBuild, è necessario includere le seguenti informazioni nel file di progetto:<Project ...> <UsingTask TaskName="MySetEnv" TaskFactory="CodeTaskFactory" AssemblyFile="$(MSBuildToolsPath)\Microsoft.Build.Tasks.v4.0.dll" >
<ParameterGroup>
<Name Required="true" />
<Value Required="false" />
</ParameterGroup>
<Task>
<Code Type="Fragment" Language="cs">System.Environment.SetEnvironmentVariable(Name, Value);</Code>
</Task>
</UsingTask>
...
...
<Target Name="BeforeBuild">
<MySetEnv Name="XamlBuildTaskRemotingLeaseLifetimeInMinutes" Value="1440" />
</Target>
<Target Name="AfterBuild">
<MySetEnv Name="XamlBuildTaskRemotingLeaseLifetimeInMinutes" Value="" />
</Target>
</Project>
Il nome operazione in questo esempio è MySetEnv. È possibile impostare qualsiasi stringa valida per i nomi delle attività. Questo esempio imposta la durata del lease su 1.440 minuti (un giorno) prima della creazione del progetto e lo imposta su null dopo la compilazione. Se sono presenti più progetti che è necessario per estendere la durata del lease, questa configurazione ciascun progetto.

Problema 8

Quando si utilizzano i postback AJAX in una pagina, in alcuni casi il postback viene reindirizzato a un altro URL. È possibile ottenere il RedirectLocation in un HttpModule tramite HttpContext.Items["System.Web.UI.PageRequestManager:AsyncPostBackRedirectLocation"].

Serve aiuto?

Amplia le tue competenze
Esplora i corsi di formazione
Ottieni in anticipo le nuove caratteristiche
Partecipa a Microsoft Insider

Queste informazioni sono risultate utili?

Come valuti la qualità della traduzione?
Cosa ha influito sulla tua esperienza?

Grazie per il feedback!

×