Недавно я имел дело с ошибкой доступа к MAPI через .NET Framework (как описано в этой статье ). Я теперь остался с рядом ошибок нарушения доступа к памяти.
Чтобы обойти проблемы, я пытался использовать этот сторонний компонент , который имеет ядро Visual C ++. К сожалению - у нас все еще есть те же ошибки.
Лично я никогда не использовал Visual C ++, но мой вопрос: если библиотека C ++ компилируется с использованием Visual Studio 2005, с использованием Visual C ++ - управляет ли память проекта также платформой .NET, что делает Он подвержен тем же проблемам, что и библиотеки .NET, которые мы используем? Или я лаю не на том дереве?
Я не совсем уверен, что вы спрашиваете, но я сделаю это.
Visual C ++ является чистым компилятором C / C ++, поэтому не имеет ни управления памятью .NET, ни его времени выполнения - вам нужно вручную вызывать new и удалять.
.NET также предоставляет C ++ / CLI, который является слегка измененной версией C ++, предназначенной для среды выполнения .NET, и поддерживает GC - например. его память управляется средой выполнения .NET.
Без более подробной информации о вашей ошибке я не смогу сделать никаких предложений, кроме как предложить вам убедиться, что вы используете соответствующие охранники GC, и предоставьте финализаторы в любом месте, где они необходимы.
Если вы не используете Managed C ++ (что не похоже на вас), то нет, память не управляется CLR.
Рекомендуемый метод общения с Exchange в .Net - через WebDAV.
В двух предыдущих ответах упоминалось «Managed C ++», это старый болт, который они позволили вам использовать управляемый C ++ в среде .NET. Он не был гражданином первого класса - в отличие от C ++ / CLI ( текст ссылки . Но, чтобы ответить на ваш первоначальный вопрос, нет, Visual C ++ не управляется средой выполнения .NET. Управляются C ++ и C ++ / CLI.