What's the difference between stdole.dll in the GAC vs. Microsoft's Nuget package?

Question

The C# project I work on has an assembly with a reference to stdole.dll which on my dev PC is located in C:\WINDOWS\assembly\GAC\stdole\7.0.3300.0__b03f5f7f11d50a3a\stdole.dll.

I'm not sure where this assembly came from originally. I noticed that there is a Nuget package that provides it: https://www.nuget.org/packages/stdole/17.0.0-previews-1-31314-256 although we weren't using this.

My assembly had been using the preexisting GAC file; when I switched from the GAC stdole reference to the Nuget version, the following was removed from my CSPROJ:

<COMReference Include="stdole">
  <Guid>{00020430-0000-0000-C000-000000000046}</Guid>
  <VersionMajor>2</VersionMajor>
  <VersionMinor>0</VersionMinor>
  <Lcid>0</Lcid>
  <WrapperTool>primary</WrapperTool>
  <Isolated>False</Isolated>
  <EmbedInteropTypes>True</EmbedInteropTypes>
</COMReference>

and this added instead:

    <Reference Include="Microsoft.VisualStudio.Interop, Version=17.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
      <HintPath>..\..\..\hap\Build\packages\Microsoft.VisualStudio.Interop.17.0.0-previews-1-31314-256\lib\net472\Microsoft.VisualStudio.Interop.dll</HintPath>
    </Reference>
    <Reference Include="netstandard" />

    <Reference Include="stdole, Version=17.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
      <HintPath>..\..\..\hap\Build\packages\stdole.17.0.0-previews-1-31314-256\lib\net472\stdole.dll</HintPath>
    </Reference>

The GAC file had version 7.0.9466.1 and the Nuget package has 17.0.31314.256.

I think it is preferable to use the Nuget source & ensuring we distribute its dependencies rather than just referencing some DLL which happens to be on my system. But I don't really understand what the difference is between them (if anything).

None of the links provided by the stdole package have been useful. They are:

From Nuget within VS: https://aka.ms/vsextensibility (which redirects to a "Visual Studio SDK" page that isn't obviously relevant & seems not to mention stdole)
From Nuget website the Release Notes link goes to "Visual Studio 2015 Update 2 Release Notes", also seemingly irrelevant

So those seem to be dead ends.

Misc / background info

The app does indeed require stdole because it interfaces with some legacy VB6 code and a StdPicture object has to be exchanged.

This question came up because my app had the following error on one PC in particular:

Could not load file or assembly 'stdole, Version=7.0.3300.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.

This error has not occurred anywhere else. Because of this I am concerned that we are leaving out a dependency that should be installed, maybe something that by luck exists on most PCs, but not all.

Are you sure you are currently using the version in the GAC? The COMReference XML is what you would get if you added a COM reference to the DLL (or stdole32.tlb) rather than an assembly reference. Does the machine where it failed have Office installed? its going back a while but iirc stdole.dll only shipped with Office - the version you have in the GAC is a likely part of the Office PIA assemblies. — Alex K., May 26 '21 at 12:54
@AlexK. I was going on what VS showed in the properties window for the stdole reference; the Path property listed the GAC location. Your point about the Office PIA makes sense, as Office is very commonly installed; the one PC with the error does not have it. — StayOnTarget, May 26 '21 at 12:58
Related: https://stackoverflow.com/questions/35478201/could-not-load-file-or-assembly-stdole — StayOnTarget, Jun 28 '21 at 16:45

score 0 · Answer 1 · answered Jun 28 '21 at 16:45

The bottom line seems to be that there is no difference between what might be in the local GAC and what's in the Nuget package. There are Nuget packages for various versions of stdole.dll, presumably the same ones that could be in the GAC (that has been my experience).

The GAC DLL probably was installed there (as mentioned in a comment by Alex K.) when Office or some other application was installed. stdole.dll can be used as a Primary Interop Assembly (PIA) and if its in the GAC, that appears to be it's function.

However if it is not in the GAC then any application which relies on it will fail. Therefore my recommendation is to switch to the Nuget package instead, and deploy stdole.dll as you would any other dependency. (Unless you are developing something like an Office add-in which basically is guaranteed to run only when Office dependencies are going to be present.)

The link above also mentions the following:

... like all Office 2003 PIAs, developers should not re-distribute them.

I interpret this to mean that you definitely should not install stdole.dll or any other PIA in the GAC yourself. I do not think that deploying your own private copy would be harmful, and if you run on PCs which don't have Office installed you would have no alternative if you are not able to embed interop types.

(I guess you could create your own interop assembly for OLE32.dll or anything else, but I don't see a good reason to do that instead of using Microsoft's stdole.dll?)

What's the difference between stdole.dll in the GAC vs. Microsoft's Nuget package?

1 Answers1