Replace obsolete UCOMITypeInfo with recommended System.Runtime.InteropServices.ComTypes.ITypeInfo

[sujitnayak]

Fixes #
AB#2495104

Context

ClickOnce users report an intermittent build failure in Forms projects where the ClickOnce manifest creation task is running.
I was able to reproduce the issue on one of my machines intermittently where the call to System.Runtime.InteropServices.UCOMITypeInfo.ReleaseTypeAttr(...) throws a ComException with random unknown hr values.

From the documenation this type has been deprecated and replaced by System.Runtime.InteropServices.ComTypes.ITypeInfo since .NET 2.0.

Replacing the obsolete type with the recommended type fixes the issue of the random failure while calling ReleaseTypeAttr.

Changes Made

• Replace the obsolete type UCOMITypeInfo with the recommended type ITypeInfo.
• Ignore ComExceptions from ReleaseTypeAttr call.
• Fix memory leak where TypeLib COM object was not being released.

Testing

Validated with private Tasks DLL that the ReleaseTypeAttr call does not fail anymore.
CTI team is also running some tests with a private tasks DLL.

Notes

[Copilot]

Pull Request Overview

This PR replaces the obsolete UCOMITypeInfo with the recommended System.Runtime.InteropServices.ComTypes.ITypeInfo to address intermittent build failures in Forms projects. Key changes include:

• Replacing outdated COM interface types with ComTypes aliases.
• Ignoring COM exceptions during the release of COM resources.
• Fixing a memory leak by ensuring proper COM object cleanup.

[merriemcgaw]

Adding @JeremyKuhne to offer thoughts, but this seems reasonable based on our discussion earlier.

[rainersigwald]

/backport to vs17.14

[github-actions]

Started backporting to vs17.14: https://github.com/dotnet/msbuild/actions/runs/15635906085

[KalleOlaviNiemitalo]

I see ITypeInfo.ReleaseTypeAttr(IntPtr) has [PreserveSig], but UCOMITypeInfo.ReleaseTypeAttr(IntPtr) doesn't. The Win32 documentation of ITypeInfo.ReleaseTypeAttr shows it returning void, rather than HRESULT. Is the problem that the lack of [PreserveSig] causes the .NET COM interop to assume a HRESULT return value, but the method does not actually return one, so the return-value register contains garbage and .NET then throws if the failure bit happens to be set?

[sujitnayak]

It could be the reason why UCOMITypeInfo.ReleaseTypeAttr throws. UCOMITypeInfo however is deprecated and this change removes its usage in favor of using ITypeInfo.