Why does BinRelease not contain Office DLL's?

ic2 · Post by **ic2** » Mon May 10, 2021 10:09 am

When I add a new reference in a .Net project I see that if extra DLL's are involved, these are copied to ..Release and ..Debug directory. Apart from the poor organization that all these files are copied double, it at least helps to collect the necessary DLL's to install for users of my products.

However, for a client I implemented an Excel import. But the program didn't do anything when I clicked the button where it performs:

oWorkBooks:=oExcel:Workbooks
ofd:=Microsoft.Win32.OpenFileDialog{}

I solved this eventually: I noticed that the 2 Excel references involved OFFICE.DLL and Microsoft.Office.Interop.Excel.dll. I copied these 2 to the client and it worked.

But why aren't these 2 DLL's to the bin subdirectories, contrary to all other DLL's?

Dick

wriedmann · Post by **wriedmann** » Mon May 10, 2021 10:15 am

Hi Dick,
DLLs that are in the GAC are not copied (and do not need to be copied).
Wolfgang

ic2 · Post by **ic2** » Mon May 10, 2021 10:39 am

Hello Wolfgang,

Indeed these DLL's were in my GAC. But on my client's Server 2016, my program didn't work. Until I copied these 2 DLL's from my GAC to their work directory of my project.

So why did I have to do that if these needn't to be copied?

Dick

FFF · Post by **FFF** » Mon May 10, 2021 10:50 am

probably because for whatever reason they were NOT in GAC at your user?

robert · Post by **robert** » Mon May 10, 2021 10:53 am

Dick,

These DLLs are installed on your machine as part of the Visual Studio installation (Office Developer Tools)
They are not part of windows.

Robert

g.bunzel@domonet.de · Mon May 10, 2021 10:59 am

Dick,

have a look at that tool to work with Excel-files:
https://www.libxl.com/

Easy to use - very fast - no need of a office license for the user - no fight with office-files

HTH

Gerhard Bunzel

wriedmann · Post by **wriedmann** » Mon May 10, 2021 12:09 pm

Hi Dick,
Visual Studio (and XIDE) is not able to understand which DLL that is in the GAC makes part of the customer system and which not.
So if you are using DLLs from the GAC you as developer have to make sure this DLL is also installed on the users PC or makes part of your installation procedure.
Wolfgang

ic2 · Post by **ic2** » Mon May 10, 2021 1:34 pm

Hello Robert,

robert wrote: These DLLs are installed on your machine as part of the Visual Studio installation (Office Developer Tools)
They are not part of windows.

All X# DLL's are also not part of Windows. But as soon as I include them, they are copied to binrelease and bindebug.

So that still leaves the question: why aren't these Excel DLL's copied to releasebin after including them as resource, in the same way as all those other DLL's?

Dick

ic2 · Post by **ic2** » Mon May 10, 2021 1:38 pm

Hello Gerhard ,

g.bunzel@domonet.de wrote: have a look at that tool to work with Excel-files:
https://www.libxl.com/
Easy to use - very fast - no need of a office license for the user - no fight with office-files

Hmmm, probably this a lot better than the Excel classes of Office. It works, but it is dreadfully slow (it can read only maybe 5 rows in 1 second containing 30 columns). Written by Microsoft, what else would one expect....

For now I won't change it but if speed will be an issue in the future I will certainly consider this, thanks.

Dick

robert · Post by **robert** » Mon May 10, 2021 1:42 pm

Dick,
The office DLLs are different. They are so called "primary interop assemblies". They do not contain code but are a managed wrapper around a COM object. Normally you would reference the COM object in your project directly and then a special tool (TlbImp.exe and/or AxImp.exe) would generate this DLL in the context of your project.
Primary Interop assemblies are pre-generated managed wrappers.
You can find more info about these DLLs here:
https://docs.microsoft.com/en-us/visual ... ew=vs-2019

Unfortunately this topic does now tell you why they are not copied to the output folder.

Robert

Main menu