> (1) However, placement in the global cache requires strong > name creation > which would be a hassle to do on our various Access 97/2000 client > machines. I have been unable to figure out how to simply use a private > assembly for this purpose. Placing it in either > WinNT\System32 or in the > Access.exe directory fails to get Access to list the assembly in > its "Reference" object list.
I currently do this. I specify the strong named key file in AssemblyInfo.cs as well as in the Project Properties. Also in Project Properties you have to tell VS to Register for COM. Then you can simply create an Install Solution as a new project and Add the dll you've created as the output. The Install Solution will figure out all the dependencies required and create an install program. Then you can just use the msi file created and install on the client machines - everything will be registered. > (2) Furthermore, what I really wish to do is to allow Access 97/2000 > clients to call .NET components residing on a separate box (my gosh, a > pursue, and if so, would I simply wrap the .NET remoting stub in a COM > callable wrapper and call that wrapper from Access? What you should do is write a wrapper in .Net that will encompass everything that you need, as well as making empty classes that extend whatever .Net classes you wish to expose to COM. Then you will have access to all the .Net components you need. It would be best to let .Net do as much work as possible and even do all the database work if possible and just use Access to display information and perhaps access local tables and forms. This works just fine for us. -akshay
