0

I have a VB.net project that builds and registers a COM library that I can open and use in Excel on my development machine. That machine happens to have 32-bit Excel. On my other machine Excel installed in 64-bit and will not open the library, 429.

Other threads have suggested that the code itself is likely fine, as long as I compile under "Any".

Is that correct? Is code compiled for "any" generally able to run on 32 and 64-bit?

The same threads suggest that the only real problem is the tlb/registration, and point to articles that suggest manually calling regasm to avoid this.

Is this correct?

If so, am I supposed to have two tlb files? Or two COM libs? Or just one?

Maury Markowitz
  • 9,082
  • 11
  • 46
  • 98
  • I don't think you can use 32-bit and 64-bit libraries together. If your application is running in 64-bit, you can't use the 32-bit COM library (and vice versa). Also read [this answer on SO](http://stackoverflow.com/questions/128445/calling-32bit-code-from-64bit-process/128477#128477). – Styxxy Nov 25 '13 at 20:38
  • No, that's not the same. I want to load 64-bit into 64-bit, and 32-bit into 32-bit. They were trying to load 32-bit into 64-bit. – Maury Markowitz Nov 25 '13 at 21:15
  • Correct me if I am wrong: you want to run your app as 32-bit if the 32-bit version of Excel is installed; else if the 64-bit Excel is installed, run your app as 64-bit? – Styxxy Nov 25 '13 at 21:30
  • Correct. But it's a DLL, not an app. – Maury Markowitz Nov 25 '13 at 23:23
  • If you compile the DLL with "Any CPU" settings, it should be able to run under both 32-bit and 64-bit. The "main" application that will use this DLL, will determine whether it will run under 32 or 64 bit. I would say, give it a go and see if it works. – Styxxy Nov 25 '13 at 23:27
  • that was my impression too, but it doesn't seem to work. It has something to do with registration, but I'm lost trying to figure it out. – Maury Markowitz Nov 25 '13 at 23:50
  • Ok so it seems the problem is inside VS itself, I think. After considerable experimentation with various switches and such I was able to get TLB's in both 32-bit and 64-bit versions. I'm not entirely sure where to go from here though, but I'm still playing – Maury Markowitz Nov 26 '13 at 16:38
  • Ok so what I did was produce the DLL using the "Any CPU" setting, then manually ran the regasm on that machine to get it working in Excel. I then moved the DLL over to the 64-bit machine and ran the 64-bit version of regasm, which had no complaints, but trying to run it in Excel results in a "System cannot find the file specified". Anyone know what file it's looking for? – Maury Markowitz Nov 26 '13 at 18:56

1 Answers1

1

Ok, it's working. I still don't understand why this solution works, but here it is:

  1. compile the DLL using the "Any CPU" setting
  2. turn OFF COM registration, it doesn't hurt but it will just confuse things later

  3. add two lines to your VS project's post-build:

    "%Windir%\Microsoft.NET\Framework\v4.0.30319\regasm" "$(TargetPath)" /tlb:DCFPropery32.tlb

    "%Windir%\Microsoft.NET\Framework64\v4.0.30319\regasm" "$(TargetPath)" /tlb:DCFPropery64.tlb

  4. copy the DLL and TLB's to the target machine

  5. determine the bit-ed-ness of the target machine's office:

    http://www.howtogeek.com/howto/24259/

  6. run the correct version (32 or 64) of regasm on that machine with the following switch:

    FOR 32-BIT OFFICE c:\windows\microsoft.net\frameworks[version number]\regasm [path to dll] /codebase

    FOR 64-BIT OFFICE c:\windows\microsoft.net\frameworks64[version number]\regasm [path to dll] /codebase

  7. open Excel on the target platform and navigate to the VBA editor's References dialog. Browse… to the location of the files, and select the correct bit-edness version of the TLB for your platform.

And hopefully that works for all of you too!

This solution is far from ideal. For one, Microsoft keeps moving the location of regasm, so there's no simple way to script this. For another, I have no idea idea why I need to call /codebase, but it appears to have something to do with the naming of the files. Finally, this means that all such work will require at least a little manual work on each and every machine you want to run it on, or you'll need to go through the trouble of making an installer!

Maury Markowitz
  • 9,082
  • 11
  • 46
  • 98