Этот действительно меня озадачил.Я работаю с другим разработчиком, который позвонил мне, потому что он не мог поверить в то, что видел.Мы пошли вместе с отладчиком, и я тоже это видел, и у меня не было никаких объяснений.Вот сценарий.Он пишет метод, который взаимодействует с сторонним COM-объектом через автоматически сгенерированную оболочку COM (генерируемую простым добавлением COM-компонента в качестве ссылки. Вот верх его метода:
public bool RefolderDocument(ref IManDocument oDoc)
{
string strCustom1 = (string) oDoc.GetAttributeValueByID(imProfileAttributeID.imProfileCustom1);
string strCustom2 = (string) oDoc.GetAttributeValueByID(imProfileAttributeID.imProfileCustom2);
Целькода состоит в том, чтобы получить номер проекта и номер подпроекта из объекта «документ» (oDoc).
Вот что происходит, когда вы проходите шаг. После первого присваивания strCustom1 имеет ожидаемое значение «32344» (aномер проекта), а strCustom2 пуст, как и ожидалось. После второго назначения strCustom2 получает номер подпроекта "0002" - , но strCustom1 был изменен на 32334 - один символ был изменен!?
Меня поразило какое-то старое переполнение стека на языке C (чего я не ожидал в управляемом приложении, даже если оно взаимодействовало с COM-компонентом). Мы все были сбиты с толку. В попыткевзломать эту причуду, я попытался скопировать содержимое первой строки в другое место, например:
public bool RefolderDocument(ref IManDocument oDoc)
{
string strCustom1 = string.Copy((string)oDoc.GetAttributeValueByID(imProfileAttributeID.imProfileCustom1));
string strCustom2 = string.Copy((string)oDoc.GetAttributeValueByID(imProfileAttributeID.imProfileCustom2));
Те же результаты!В этот момент мы ухватились за соломинку и сбросили код с .NET 4 до .NET 3.5 (CLR 2), но без изменений.Возможно, один важный момент заключается в том, что это услуга, и мы подключаемся к процессу обслуживания.Сборка нацелена на x86, а расположение службы определенно находится в папке сборки вывода отладки.
Есть ли логическое объяснение этому?Я озадачен тем, как действовать.