У меня есть .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. Перестроен и получил ожидаемые ошибки метода. Переименовал метод обратно в исходное имя, и, эй, до того, как он выглядел исправленным. Поскольку теперь это работает, и я не могу заставить его снова выйти из строя, я не могу попробовать предложенные решения, но мне нравится идея переименования в случае, если это произойдет в будущем.