Sdk: COM Wrappers are not copied correctly to publish directory when there is more than one COM reference

[sidatacom]

Repro

With the following project:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp3.1</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <COMReference Include="Microsoft.Office.Access.dll">
      <Guid>4affc9a0-5f99-101b-af4e-00aa003f0f07</Guid>
      <VersionMajor>9</VersionMajor>
      <VersionMinor>0</VersionMinor>
      <WrapperTool>tlbimp</WrapperTool>
      <Lcid>0</Lcid>
      <Isolated>false</Isolated>
      <Private>true</Private>
    </COMReference>
  </ItemGroup>
  <ItemGroup>
    <COMReference Include="Microsoft.Office.Access.Dao.dll">
      <Guid>4ac9e1da-5bad-4ac7-86e3-24f4cdceca28</Guid>
      <VersionMajor>12</VersionMajor>
      <VersionMinor>0</VersionMinor>
      <WrapperTool>tlbimp</WrapperTool>
      <Lcid>0</Lcid>
      <Isolated>false</Isolated>
    </COMReference>
  </ItemGroup>

</Project>

Publish the project (with full MSBuild because that is needed for COMReference support): msbuild /restore /t:publish

Expected

Microsoft.Office.Access.dll and Microsoft.Office.Access.Dao.dll are both present in the publish folder

Actual

Neither is in the output folder, but a file with the names mashed together is: Interop.Microsoft.Office.Interop.Access.dll;Interop.Microsoft.Office.Interop.Access.Dao.dll

Analysis

It appears that the @ needs to be replaced by % here: https://github.com/dotnet/sdk/blob/ac7fd98a7b6f8e625aab8977029813bec6088e70/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Publish.targets#L528

Original issue description

With release 16.5 and SDK 3.1.200 the problem still exists !!!
Now the dll name will corrupted

Why you don't fix this with the new release ???

Interop.Microsoft.Office.Interop.Access.dll;Interop.Microsoft.Office.Interop.Access.Dao.dll;Interop.Microsoft.Office.Core.dll

only one file is copyed with all names inside !!!

Severity Code Description Project File Line Suppression State
Error MSB3094 "DestinationFiles" refers to 3 item(s), and "SourceFiles" refers to 1 item(s). They must have the same number of items. Esi.Bootstrap.Package C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\MSBuild\Microsoft\DesktopBridge\Microsoft.DesktopBridge.targets 692

  <Target Name="_CopyPackageFiles" DependsOnTargets="_ConvertItems">
    <Copy SourceFiles="%(File.FullPath)" DestinationFiles="%(File.CopyToTargetPath)" Condition="%(File.CopyToTargetPath) != ''"/>

    <ItemGroup>
      <FileWrites Include="%(File.CopyToTargetPath)" Condition="%(File.CopyToTargetPath) != ''" />
    </ItemGroup>
  </Target>

I created a new .net core wpf application and add a com dependency.

<Project Sdk="Microsoft.NET.Sdk.WindowsDesktop">

  <PropertyGroup>
    <OutputType>WinExe</OutputType>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <UseWPF>true</UseWPF>
  </PropertyGroup>

  <ItemGroup>
    <COMReference Include="Microsoft.Office.Access.dll">
      <Guid>4affc9a0-5f99-101b-af4e-00aa003f0f07</Guid>
      <VersionMajor>9</VersionMajor>
      <VersionMinor>0</VersionMinor>
      <WrapperTool>tlbimp</WrapperTool>
      <Lcid>0</Lcid>
      <Isolated>false</Isolated>
      <Private>true</Private>
    </COMReference>
  </ItemGroup>

</Project>

On publishing to folder the COM+ reference dll will not copyed to the publishing folder.

WpfApp1.zip

[leecow]

@dsplaisted - have a look?

[sidatacom]

I open 4 weeks ago the first ticket and it was closed. Nice job :(

[dsplaisted]

@sidatacom @rainersigwald @swaroop-sridhar Can someone help me understand what the expected behavior is? In the repro, only Interop.Microsoft.Office.Interop.Access.dll is copied to the output folder. Are more DLLs supposed to be copied?

We were supposed to have fixed something around COM References recently: https://github.com/dotnet/sdk/pull/4038

[sidatacom]

No in the release folder 3 dlls are copied. Everything is right. But on publish folder the name of the only one copied file dll including all names of the three dll files.
So instead of copy 3 files with the right names only one file is copied and the name of this file is a combine of the name of all three dlls.
Bevor in the older versions of vs no file will be copied.

I don't no what you have fixed bevor but not this or not successfully.
To test add access.dao com reference additionally.
It occurs if you add more than one com reference perhaps.
I have accutally 3 dlls as reference.
The sample includes perhaps only one.

[swaroop-sridhar]

CC: @AaronRobinsonMSFT

[AaronRobinsonMSFT]

@sidatacom Thank you for the project.

@dsplaisted In order to reproduce this add the following to the project. A screenshot of the result is below.

<ItemGroup>
  <COMReference Include="Microsoft.Office.Access.Dao.dll">
    <Guid>4ac9e1da-5bad-4ac7-86e3-24f4cdceca28</Guid>
    <VersionMajor>12</VersionMajor>
    <VersionMinor>0</VersionMinor>
    <WrapperTool>tlbimp</WrapperTool>
    <Lcid>0</Lcid>
    <Isolated>false</Isolated>
  </COMReference>
</ItemGroup>

[dsplaisted]

OK, thanks for the info. I think the bug is here: https://github.com/dotnet/sdk/blob/ac7fd98a7b6f8e625aab8977029813bec6088e70/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Publish.targets#L528

The @ should be a %.

[AaronRobinsonMSFT]

The supplied snippet seems to work, but I am concerned about the relative paths. The previous fix was suggested to match the similar approaches above it. What is the correct way to convey relative paths in this sort of situation?

<!-- Copy generated COM References. -->
<ResolvedFileToPublish Include="@(ReferenceComWrappersToCopyLocal)">
  <RelativePath>%(Filename)%(Extension)</RelativePath>
  <CopyToPublishDirectory>PreserveNewest</CopyToPublishDirectory>
</ResolvedFileToPublish>

[AaronRobinsonMSFT]

@dsplaisted Should I submit a PR with the above fix? Does it seem reasonable for this issue?

[dsplaisted]

@AaronRobinsonMSFT Yes please. If possible I'd like test coverage too, though I'm not sure if our CI machines will have Office installed, so they may not be able to build with these ComReferences.

[AaronRobinsonMSFT]

@dsplaisted Okay. What branch? Also, there was talk last time about testing but the COM reference is hard here. I will likely defer that to the SDK team since I don't know how that should be done. I can file an issue if you like?

[sidatacom]

Please do anything but fast ....

Holen Sie sich Outlook für Androidhttps://aka.ms/ghei36

---

From: Aaron Robinson [e-mail]
Sent: Wednesday, March 25, 2020 8:20:41 PM
To: dotnet/sdk [e-mail]
Cc: Alexander Hailfinger [e-mail]; Mention [e-mail]
Subject: Re: [dotnet/sdk] COM Wrappers are not copied correctly to publish directory when there is more than one COM reference (#10908)

@dsplaistedhttps://github.com/dsplaisted Okay. What branch? Also, there was talk last time about testing but the COM reference is hard here. I will likely defer that to the SDK team since I don't know how that should be done. I can file an issue if you like?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/dotnet/sdk/issues/10908#issuecomment-604036362, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AKNROYWDBBYKYH4QOQXR4E3RJJKQTANCNFSM4LO47ZJQ.

[sidatacom]

One week past whats going on ???

[dsplaisted]

@sidatacom This will be fixed in Visual Studio 16.6. It should likely make its way into preview versions of the 3.1.300 .NET Core SDK in the next few days. You can download the preview from the links in the table here: https://github.com/dotnet/installer/

[sidatacom]

Sounds good I'm excited !

[sfoslund]

Fixed by #11100, will be released in 3.1.3xx.