Question Problem using custom C# dll from Access VBA

[novelty]

Hi. Tearing my hair out with this one!


I've created a simple C# class library using Visual Studio 2010 to compress/decompress files using .NET GZip. It works fine on my development machine but I need to deploy it as part of an Access application solution for clients, and I can't get it working no matter what I try.


When I build in VS2010 with "Register for COM interop" checked, the dll works fine (I can call its methods after adding a Reference in Access VBA). However, if I try to register it using RegAsm.exe, and not VS2010, the utility reports success, but I get error 429 when I try and run the VBA code that calls my dll's methods. I used the /codebase and /tlb flags.


1) I need to understand why RegAsm.exe doesn't seem to register it 'successfully' for use!


2) I need to know how to deploy my dll for clients.
Help appreciated! (so I don't go completely bald :-/)

 

[DJkarl]

Which framework are you targeting in VS 2010? If it is .NET 4.0 then you may have to switch to an earlier version as many machines do not have that deployed yet; 3.0 should be safe and 2.0 is almost guaranteed to be installed. Also where are you trying to register the DLL? If it is a network location then you have to add that location as a trusted location otherwise it can throw a security violation.

 

[novelty]

Hi DJkarl. Thanks for your response.

The machine I'm testing it on has .Net 4.0, the same as the development machine, so that's not the issue. (My clients also have v4.0.)

The location of the application's dll is a folder on the C: drive, so I don't think it is a trusted location issue either.

Any other ideas?

 

[Banana]

Are you sure you used the right RegAsm? There are multiple versions of RegAsm for different .NET versions as well different RegAsm for 32-bit and 64-bit.

 

[novelty]

Banana, you're a genius!


Turns out I was using the wrong version of RegAsm.exe. Nothing I have read could have alerted me to this. Presumably because I built the dll with "Any CPU" as the target platform, the Framework64 version of RegAsm.exe does not work. Thus:


C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe - works
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\RegAsm.exe - doesn't work.


Now I just have to figure out the best way to install the dll on the client machines.


Can you recommend the best method to install the dll on client machines? Should I call RegAsm.exe (which would require it to be intalled on each machine, but I would need to know the exact .NET framework), or perhaps create an executable to register it from code? Never done anything like this before so any help appreciated.

 

[Banana]

No problem. I had the exactly same problem myself and like you, nothing exactly screamed "watch out for different version of RegAsm!" Glad it was the solution you needed. BTW, when your dll is compiled to run "Any CPU", it will be 64-bit if it's registered on a 64-bit OS. That may not be desirable if you're not running 64-bit Access since 32-bit Access cannot use 64-bit dll and 64-bit Access only is available with 2010 and even so Microsoft is encouraging people to install 32-bit Access regardless of whether it's a 64-bit OS or not and for a good reason.

If my memory serves, you should be fine building with "Any CPU" but you need to make sure it's registered with 32-bit RegAsm. You can change it to "32-bit" to be safe but in reality, "Any CPU" should run just fine - it's the RegAsm that matters.


In my case, I simply gave my users a zipped folder with a .bat file that did the regasm for the "installation". You can do same thing with a Packaging Wizard, MSI installer or a freeware installer (e.g. Install Creator is one good freeware I've used in past). Since you're targeting .NET 2.0 and you probably want 32-bit, you can also use the .bat file (or installer program) to do a check and if this fail, assume that .NET 2.0 is not installed and either download it or prompt the client to download it.

HTH.

(to be sure - don't try and "blindly" run .NET 2.0 installer to work around this. Last time I tried that, I found that it would bomb out with errors if it tried to run on a computer that already had .NET 2.0 installed. Caveat Programmer. )

 

[novelty]

Banana, that's all good advice. I had come across warnings about 32 vs. 64 bit versions before, so I'll have to check out a few installations on different client machines to be confident it will work as expected for different .NET versions.

Since my last post here I created an .msi that registers the dll properly using the regfile output from RegAsm. Works a treat. I've set a .NET prerequisite in the installer as well, so should be fine from here.

Thanks again!

 

[Banana]

Banana, that's all good advice. I had come across warnings about 32 vs. 64 bit versions before, so I'll have to check out a few installations on different client machines to be confident it will work as expected for different .NET versions.

Maybe I'm misunderstanding what you mean by "different .NET versions", but when you build a assembly targeting say, 2.0, you must use 2.0's RegAsm and not any other RegAsm even if the same machine has different version available. You can't just take a 2.0 assembly and register it with 4.0 RegAsm, so you need to choose a version that suits you well and target that version only.

Since my last post here I created an .msi that registers the dll properly using the regfile output from RegAsm. Works a treat. I've set a .NET prerequisite in the installer as well, so should be fine from here.

Great - it's definitely simpler to use .msi. In my case, we didn't have any license to full version of Visual Studio back then so I had to go the "poor man's route"

Best of luck!

 

[novelty]

Hi Banana. Thanks again for your interest and help. I'm sure I confused you by saying "different .NET versions". I will be insisting on a common .NET framework version on all client machines as a prerequisite for my installation. And I've decided to build a 32-bit dll for now to make sure the registration works on all target platforms. My release date will be sometime next week so hopefully everything will work fine!

 

[Banana]

Great, I was sure I was just reading too much into it and thought it wouldn't hurt to be explicit for others' benefit.

Best of luck with the installation!