2010-03-04 4 views
4

J'essaie donc de verrouiller un fichier de stockage isolé dans mon application client C#, de sorte que plusieurs copies de mon application ne puissent pas y accéder en même temps. J'utilise la syntaxe suivante:Le verrouillage du fichier de stockage isolé .NET déclenche NRE

lockStream = new IsolatedStorageFileStream("my.lck", FileMode.OpenOrCreate, isoStore); 
lockStream.Lock(0, 0); 

Ce code provoque ma demande de jeter un NullReferenceException à l'intérieur de la méthode FileStream.Lock du cadre. J'ai essayé d'utiliser une valeur non nulle pour la longueur. J'ai essayé d'écrire un octet dans le fichier et de verrouiller juste cet octet. Peu importe ce que je fais, cette même NullReferenceException continue de me tourmenter. Est-ce que quelqu'un sait si cela est possible avec un stockage isolé?

Je suis également intéressé par l'utilisation de cette technique dans une application Silverlight, est-ce que Silverlight prend en charge le verrouillage de fichier? Les documents MSDN semblent indiquer que ce n'est pas le cas, mais j'ai vu this post d'un MVP C# qui le dit.

Mise à jour: Microsoft a corrigé le bogue que j'ai soumis sur Connect, mais il n'a pas été publié dans la version 4 du framework. Il devrait être disponible, espérons-le, dans le prochain SP ou version complète. Essayez une valeur supérieure à 0 pour la quantité de données à verrouiller.

+0

j'ai pu contourner ce bug en utilisant la réflexion pour appeler la méthode de verrouillage sur le champ 'm_fs de privé du IsolatedStorageFileStream comme ceci: lockStream = new IsolatedStorageFileStream (« q.lck », FileMode.OpenOrCreate, isoStore); FileStream m_fs = typeof (IsolatedStorageFileStream) .InvokeMember (("m_fs"), BindingFlags.GetField | BindingFlags.NonPublic | BindingFlags.Instance, null, lockStream, null) en tant que FileStream; m_fs.Lock (0, long.MaxValue); – bsiegel

Répondre

4

Cela ressemble à un bug dans le cadre. Je peux me tromper, parce que c'est vraiment trop grand pour être vrai. Si l'on regarde le code source de .NET 3.5 SP1 avec Reflector, on constate que IsolatedStorageFileStream appelle le constructeur de base sans paramètre (FileStream()), ce qui aboutit à une classe de base non réellement initialisée. IsolatedStorageFileStream crée une instance d'un FileStream et l'utilise dans toutes les méthodes qu'il écrase (Write, Read, Flush, Seek, etc.). Il est étrange qu'il ne profite pas directement de sa classe de base.

Mais le verrouillage et le déverrouillage ne sont pas remplacés et nécessitent un champ privé (_handle) qui est toujours nul (car le constructeur utilisé est le paramètre sans paramètre). Ils supposent qu'il est non nul et le déréférencent et provoquent le NRE. Pour résumer, le verrouillage et le déverrouillage ne sont pas pris en charge (ou buggés).

Je suppose que vous êtes obligé d'utiliser d'autres méthodes de verrouillage comme un Mutex ou un Sémaphore.

L'implémentation est la même dans .NET 4 RC. Dans Silverlight, Lock an Unlock ne sont pas présents du tout (mes excuses pour avoir contredit un MVP).

+0

Merci, j'ai regardé à travers le réflecteur et je suis sûr que vous avez raison. J'ai déposé un bug sur Connect, n'hésitez pas à voter: https://connect.microsoft.com/VisualStudio/feedback/details/539486/certain-method-calls-on-an-isolatedstoragefilestream-throw-an -exception – bsiegel

0

Aussi, est-il des données dans le flux, il n'y a rien à verrouiller qui pourrait être le problème ....

lockStream = new IsolatedStorageFileStream("my.lck", FileMode.OpenOrCreate, isoStore); 
lockStream.Write(.....) 
lockStream.Lock(0, 10); 
+0

J'ai également essayé ce qui suit: lockStream = new IsolatedStorageFileStream ("my.lck", FileMode.OpenOrCreate, isoStore); lockStream.WriteByte (0xFF); lockStream.Lock (0, 1); Ceci a échoué exactement de la même manière. – bsiegel

+0

comment déclarez-vous isoStore? – Hogan

+0

Je fais juste un IsolatedStorageFile de base isoStore = IsolatedStorageFile.GetStore (IsolatedStorageScope.User | IsolatedStorageScope.Assembly, null, null); – bsiegel

Questions connexes