Почему нативный код, вызываемый из .net, дает другой результат, нежели вызов из нативной программы?

Question

У нас есть собственная библиотека, которую мы используем для выполнения задач, связанных с безопасностью. Мы написали библиотеку взаимодействия, чтобы мы могли использовать ее из .NET.

У нас есть два тестовых приложения, первое приложение написано на C ++ (неуправляемое), а второе написано на C #. Они генерируют точно такую ​​же последовательность вызовов в нативную библиотеку, но дают разные результаты.

Я потерян и не могу найти явную ошибку в определениях импорта .NET. Я уже ошарашил, чтобы я работал только с очень простым интерфейсом. Я ищу идеи, почему вызов собственной библиотеки из среды .NET может повлиять на результат.

EDIT: У меня нет глубоких знаний о библиотеке, поэтому я не могу многое рассказать о том, что делается в нативном коде. Я знаю, что это поддерживает (тепловой удар) поток. Другая часть библиотеки, которая используется для определения того, выполняется ли приложение на виртуальной машине, также демонстрирует такое же поведение. Это не обязательно связано.

Я написал другое тестовое приложение на C ++ / CLI, так как немного проще использовать нативную библиотеку, чем из C #, и он также дает тот же результат, что и C #.

Answer 1

Дикая догадка: вы назначаете функцию, переводящую bool в функцию, принимающую bool. Это дает разные результаты при вызове из нативного кода и управляемого кода, потому что bool не должно быть преобразовано в bool

Answer 2

Одна из возможностей может быть, если собственная библиотека использует локальное хранилище собственных потоков. Не существует (обязательно) однозначного сопоставления между управляемыми потоками и собственными потоками.

Чтобы исключить эту возможность, вы можете попробовать обернуть всю последовательность вызовов внутри вызовов в BeginThreadAffinity / EndThreadAffinity (то есть, одну пару этих вызовов по всем вызовам в библиотеку, а не пара вокруг каждого отдельного вызова в библиотеку)

Answer 3

Это может быть проблемой с сортировкой / взаимодействием, как предлагали другие.

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

Есть много способов сделать такие предположения. В качестве случайного примера метод в библиотеке MFC, который не вызывает макрос AFX_MANAGE_STATE, может делать предположения, которые недопустимы при вызове из кода .NET.

Answer 4

Ключевые слова:

Мы написали библиотеку взаимодействия, чтобы мы могли использовать ее (собственную библиотеку) из .NET.

Это источник ваших ошибок, а не родной библиотеки.Определенный собственный вызов (вызов конкретной функции с определенными параметрами) будет возвращать одинаковые результаты независимо от того, как он вызывается.Проблема заключается в том, что ваша обертка может вносить незначительные ошибки, когда вы «думаете», что делаете один и тот же вызов, но версия взаимодействия делает немного другой вызов (таким образом, разные результаты).модульное тестирование вашей библиотеки взаимодействия на самом низком уровне.Нативная функция foo (int x, int y).Назовите это родным, назовите это через библиотеку.Результат должен быть таким же.Продолжайте, пока не найдете вызов функции там, где их нет. Если есть разница, чем проблема в том, что ваша сортировка и взаимодействие не связаны с собственной библиотекой. Если вы нашли отдельный вызов, который возвращает результаты различий, и вы не можете найти источник ошибки во взаимодействии, тогда отправьтеиндивидуальный звонок как вопрос по СО.