Cela semble être un problème connu signalé dans
Instances / connexions SQLite non liées contribuant aux échecs du MOO # 22650 .
Le problème a apparemment été résolu dans Visual Studio 2017 version 15.5 et le correctif a peut-être été rétroporté à 15.4.
La mise à jour de Visual Studio 2017 vers la version la plus récente devrait résoudre le problème (s'il en est de même).
Puisque cela n'a pas résolu le problème, il convient de noter que l'erreur OutOfMemoryException ne signifie pas un manque de mémoire, mais plutôt l'impossibilité d' allouer de la mémoire. Je vais expliquer ci-dessous pourquoi ce ne sont pas les mêmes.
Comme Visual Studio est un programme 32 bits, son espace mémoire est limité à 4 Go. À partir de là, il ne peut "que" utiliser environ 2 Go pour ses données, le reste utilisé par les logiciels Windows et ses programmes. La mémoire physique se voit attribuer des adresses virtuelles dans cet espace, de sorte que certaines adresses sont déjà attribuées et d'autres pas. Il n'y a pas de mécanisme de récupération de place possible, de sorte qu'une adresse, une fois allouée, reste allouée.
Imaginons, par exemple, que sur les 2 Go disponibles, 100 Mo soient alloués et que l’on souhaite allouer 1 Go supplémentaire. Logiquement, la mémoire disponible est bien plus que suffisante. Cependant, si les 100 Mo sont alloués au milieu de l'espace de 2 Go, il n'est plus possible d'allouer 1 Go de mémoire contiguë . Dans ce cas, la condition OutOfMemoryException sera élevée, bien qu'elle semble carrément impossible.
Ce cas peut se produire lorsque la mémoire est allouée et libérée de manière à ce que les fragments de mémoire alloués soient dispersés dans l'espace d'adressage disponible et ne laissent que des "trous" insuffisants pour une allocation importante.
Par conséquent, il n'y a que deux possibilités:
Un bogue dans Visual Studio, comme par exemple lorsque vous essayez d'augmenter la longueur d'une instance de la StringBuilder
classe au-delà de celle spécifiée par sa MaxCapacity
propriété actuelle , provoquera également la condition OutOfMemoryException.
Trop d'allocations sont effectuées, de sorte que même libérée, la mémoire est trop fragmentée.
Votre cas semble mieux correspondre au second cas, mais vos options pour une solution ici sont assez limitées.
Une version 64 bits de Visual Studio résoudrait le problème en élargissant l'espace d'adressage, mais cela ne figure pas dans la
feuille de route de Visual Studio .
Votre autre option consiste à réduire au maximum l'allocation de mémoire. Vous pouvez réduire le nombre de modules complémentaires de Visual Studio ou essayer de diviser cette énorme solution de VS en solutions plus petites. Vous pouvez également fermer et redémarrer Visual Studio, étant donné que certaines allocations de mémoire sont effectuées en parallèle par les threads Visual Studio. Un élément aléatoire est donc impliqué.