Кнопка .Net Winform как COM для ошибки FoxPro C00005

мы создали COM-элемент управления .net (3.5) для foxpro (9 с SP), в соответствии с руководствами, которые вы можете найти в Интернете (например, из блога Рика Страла)

теперь иногда в foxpro мы получали C000005 при освобождении объекта.

Поэтому мы попытались воспроизвести этот сценарий. При создании и выпуске объекта сотни/тысячи раз мы получили ту же ошибку.

Мы используем пустую форму FoxPro SCX и простую кнопку .net без какого-либо кода.

Если мы не удалим объект .net, мы получим аналогичное исключение .net «Попытка чтения или записи в защищенную память».

".(полное исключение см. внизу)

здесь код VFP:

Local lnAnzahl as Number, ;
 lni as Number

set procedure to DummyProcedure.prg

lnAnzahl = val(inputbox("wie oft", "oft","0"))

for lni = 1 to lnAnzahl
 thisform.newobject("cntTest","netcontrol","c0005nativetest.vcx")
 thisform.RemoveObject("cntTest")     
endfor

сообщение об ошибке .net

System.AccessViolationException: Es wurde versucht, im geschützten Speicher zu lesen oder zu schreiben. Dies ist häufig ein Hinweis darauf, dass anderer Speicher beschädigt ist. в System.Runtime.InteropServices.ComTypes.IAdviseSink.OnViewChange (аспект Int32, индекс Int32) в System.Windows.Forms.Control.ActiveXImpl.ViewChanged() в System.Windows.Forms.Control.ActiveXImpl.ViewChangedInternal() в System. Windows.Forms.Control.OnInvalidated(InvalidateEventArgs e)
в System.Windows.Forms.Control.NotifyInvalidate(Rectangle invalidatedArea) в System.Windows.Forms.Control.Invalidate(Boolean invalidateChildren)
в System.Windows. Forms.Control.WmUpdateUIState(Message& m) из System.Windows.Forms.Control.WndProc(Message& m) из System.Windows.Forms.ScrollableControl.WndProc(Message& m) из System.Windows.Forms.ContainerControl.WndProc(Message& m) ) из System.Windows.Forms.UserControl.WndProc(Message& m) из System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m) из System.Windows.Forms.Control.ActiveXImpl.System.Windows.Forms.IWindowTarget. OnMessage(Message& m) в System.W indows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
в System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

Это известная проблема? любой совет, как мы можем решить это?


person Boas Enkler    schedule 07.12.2012    source источник
comment
Похоже, вы используете элемент управления ActiveX в своей форме. Похоже, это глючит. Обратитесь за поддержкой к поставщику или автору элемента управления.   -  person Hans Passant    schedule 07.12.2012
comment
Я бы согласился, вероятно, проблема с управлением ActiveX. Если вы создали этот элемент управления, попробуйте внести в него запись журнала, чтобы узнать, сможете ли вы зафиксировать ошибку или проблему.   -  person Jerry    schedule 07.12.2012
comment
его базовая кнопка .net только стала видимой и установила соответствующие атрибуты.   -  person Boas Enkler    schedule 10.12.2012
comment
Вы упомянули блог Рика. Можете ли вы отредактировать свой вопрос и вставить ссылку на него, чтобы я мог его просмотреть. В прошлом я создал много элементов управления VFP COM для веб-целей, но не знаю контекстной основы, которую вы пытаетесь сделать.   -  person DRapp    schedule 10.12.2012


Ответы (1)


У нас была эта ошибка в производственной среде.

По-видимому, невозможно по-настоящему освободить компонент .NET COM из среды VFP: он хранится в памяти до тех пор, пока приложение не прекратит работу.

Рик Страл предлагает очень элегантное решение проблемы, с которой мы здесь столкнулись:

Размещение среды выполнения NET в Visual FoxPro

... который ссылается на другие сообщения, в которых обсуждаются вопросы, кратко изложенные ниже:

Среда выполнения .NET привязана к VFP: как только вы загрузите компонент .NET COM, вы не сможете полностью выгрузить этот компонент. Это означает, что во время разработки .NET COM вы должны закрыть Visual FoxPro, чтобы перезагрузить компонент .NET COM.

Компоненты .NET не могут выгружать связанные ресурсы: сборщик мусора .NET очищает объекты и состояние объектов внутри работающего экземпляра .NET. Это означает, что когда вы удаляете объект, фактический объект и связанные с ним ресурсы могут быть немедленно выгружены. Например, если вы загружаете объект Bitmap, который имеет связанные буферы памяти, и просто очищаете ссылку, связанные данные буфера памяти не освобождаются немедленно. Использование метода Dispose(), когда он доступен, может помочь в явной выгрузке связанных ресурсов.

Не все типы работают в Visual FoxPro: некоторые типы данных, особенно типы значений и некоторые специализированные типы коллекций, не работают в Visual FoxPro при доступе через COM. Также некоторые типы массивов, переданные из COM в Visual FoxPro, нельзя изменить и отправить обратно с новыми или удаленными элементами.

Передача типов из FoxPro в .NET обычно небезопасна с точки зрения типов: если у вас нет COM-компонентов VFP, которые вы передаете в .NET, вы не сможете легко передать строго типизированные объекты, созданные в Visual FoxPro, в .NET. Объекты FoxPro передаются как общие ссылки на «объекты», и в большинстве случаев к ним нужно обращаться с помощью Reflection.

person Community    schedule 09.01.2015
comment
После долгих исследований и многочисленных обсуждений с другими разработчиками и тестов мы обнаружили, что эта проблема действительно неразрешима. Мы также добавили код Marshall.ReleaseCOMObject, который улучшил поведение. но в связи с некоторыми версиями .net и windows проблема все еще возникает. Подводя итог, можно сказать, что лучшим решением является прекращение использования FoxPro. Поскольку он больше не поддерживается, не получает новых исправлений ошибок и в то же время представляет собой потенциальную угрозу безопасности. - person Boas Enkler; 09.01.2015
comment
Лучшее решение — прекратить использование FoxPro. Согласен :) Однако это не всегда хорошо работает на встречах по разработке продукта. - person ; 12.01.2015