У меня есть .NET DLL, которая имеет некоторые интерфейсы \ классы, которые выставлены на com. во время процедуры сборки создается файл .tlb, и на этот tlb ссылается некоторый код c ++. В результате компилятор генерирует файл .tlh для tlb.

Когда я запускаю сборку локально, одно из свойств в одном из интерфейсов заканчивается соответствующим методом в tlh, который не имеет того же имени. Свойство в .net-коде называется PropertyA и в конечном итоге называется get_propertyA, а PropertyB в конечном итоге называется get_PropertyB. Когда это произошло, я не разбивал веки, просто использовал метод, определенный в tlh, и предположил, что все было просто ужасно, однако, когда я принял эти изменения, сборка не работала ни для кого другого, так как компилятор генерировал свойства с именем get_PropertyA и get_PropertyB (обратите внимание на несоответствие регистра в свойстве A).

Файлы tlb, сгенерированные на обеих машинах, идентичны (согласно шестнадцатеричному компаратору), а файлы tlh сгенерированы одной и той же версией компилятора.

Процедура сборки создает tlb, выполнив: regasm path \ to \ dll \ Mydll.dll -tlb: path \ to \ output \ mydll.tlb

Любые идеи, почему моя локальная версия заканчивается свойство с неправильным именем? Или что я могу сделать, чтобы это исправить?

ОБНОВЛЕНИЕ: я прочитал, что tlbexp будет использовать первую версию строки, которую он находит, и которая может измениться при перекомпиляции. Хотя я не использую tlbexp, я подумал, не в этом ли проблема. Я нашел параметры с тем же именем, что и у моего метода (в других методах), но с заглавной буквой в начале. Поэтому я заменил все это. Перестроен, без изменений. Поэтому я переименовал свой метод COM. Перестроен и получил ожидаемые ошибки метода. Переименовал метод обратно в исходное имя, и, эй, до того, как он выглядел исправленным. Поскольку сейчас это работает, и я не могу заставить его снова выйти из строя, я не могу попробовать предложенные решения, но мне нравится идея переименования на случай, если это произойдет в будущем.