La memoria di Visual C++ è gestita dal framework Dot Net
-
09-06-2019 - |
Domanda
Recentemente, ho riscontrato un errore durante l'accesso a MAPI tramite il framework .NET (come descritto in Questo articolo).Ora mi rimangono una serie di errori di violazione dell'accesso alla memoria.
Per superare i problemi, ho cercato di utilizzare questo componente di terze parti, che ha un nucleo Visual C++.Sfortunatamente, stiamo ancora riscontrando gli stessi errori.
Personalmente non ho mai usato Visual C++, ma la mia domanda è:se la libreria C++ viene compilata utilizzando Visual Studio 2005, utilizzando Visual C++ - la memoria del progetto viene gestita anche dal .NET framework, il che lo renderebbe quindi soggetto alle stesse problematiche delle librerie .NET di cui siamo utilizzando?O sto abbaiando contro l'albero sbagliato?
Soluzione
Non sono del tutto sicuro di quello che stai chiedendo, ma ci proverò.
Visual C++ è un compilatore C/C++ puro, quindi non ha la gestione della memoria di .NET, né il suo runtime: devi chiamare manualmente new ed delete.
.NET fornisce anche C++/CLI, che è una versione leggermente modificata di C++ destinata al runtime .NET ed è compatibile con GC, ad es.la sua memoria è gestita dal runtime .NET.
Senza ulteriori dettagli sul tuo bug non posso davvero dare alcun suggerimento, oltre a suggerire di assicurarti di utilizzare le protezioni GC appropriate e di fornire finalizzatori ovunque siano necessari.
Altri suggerimenti
Le due risposte precedenti hanno menzionato "Managed C++", questo è un vecchio tool-on che hanno fatto per consentirti di utilizzare il C++ gestito in un ambiente .NET.Non era un cittadino di prima classe, a differenza di C++/CLI (testo del collegamento.Ma per rispondere alla tua domanda iniziale, no, Visual C++ non è gestito dal runtime .NET.C++ gestito e C++/CLI lo sono.
A meno che tu non stia utilizzando Managed C++ (che non sembra che tu lo sia), allora no, la memoria non è gestita da CLR.
Il metodo consigliato per comunicare con Exchange in .Net è tramite WebDAV.