xsharp.eu

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

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

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

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

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

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

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

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

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

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