By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,827 Members | 2,277 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,827 IT Pros & Developers. It's quick & easy.

Best place to put a VB dll

P: n/a
ray
Hi folks,

I have developed an MDE file in Access, and as part of it I have also
had to create a fast scheduling
calendar function, as a DLL, in VB.
At the moment the DLL gets installed and registered using Wise
Installer, which works fine but there
is a problem, insofar as whenever I have to update the calendar, I have
to send another
install disk for the dll, and a new version of the front end MDE file
which has the latest version of the dll
file compiled into it.

I am currently experimenting with AutoFEUpdater, which allows you to
store the Front end on the server, and
users automagically get new versions. This is a great little utility,
and it also allows you to copy other files
to the users C drive, such as a DLL for example.

Can I dispense with the need to send a new install disk for the DLL by
getting
AutoFEUpdater to copy the DLL file to the users C drive with the MDE,
and then somehow link to it
explicitly (using a pathname I guess) rather than needing to have it
registered on each PC? That is,
I guess, some kind of late binding scenario? Or would it have to be
registered at least once (I assume that
registration just puts a pathname into the Windows Registry), and then
allow AutoFEUpdater to copy the DLL
into the same folder as the MDE for subsequent updates?

Or should I leave the DLL on the server? If so, how would the MDE know
where it was?

Any ideas gratefully received,

Ray

Nov 13 '05 #1
Share this Question
Share on Google+
1 Reply


P: n/a

When a COM dll is registered a little bit more happens than just storing the
path in the registry.

Firstly, ensure you have binary compatibilty switched on for your VB dll
project. With this on the GUIDs for your COM interfaces are maintained
between versions of your dll (unless you do something to the external
interface to break this, but then you get a warning).

If you have binary compatibility switched on and you do not change the
external interface of your dll then, in theory, once the dll has been
deployed and registered, you can replace it by a simple file copy.
--
Terry Kreft
MVP Microsoft Access
<ra*@aic.net.au> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...
Hi folks,

I have developed an MDE file in Access, and as part of it I have also
had to create a fast scheduling
calendar function, as a DLL, in VB.
At the moment the DLL gets installed and registered using Wise
Installer, which works fine but there
is a problem, insofar as whenever I have to update the calendar, I have
to send another
install disk for the dll, and a new version of the front end MDE file
which has the latest version of the dll
file compiled into it.

I am currently experimenting with AutoFEUpdater, which allows you to
store the Front end on the server, and
users automagically get new versions. This is a great little utility,
and it also allows you to copy other files
to the users C drive, such as a DLL for example.

Can I dispense with the need to send a new install disk for the DLL by
getting
AutoFEUpdater to copy the DLL file to the users C drive with the MDE,
and then somehow link to it
explicitly (using a pathname I guess) rather than needing to have it
registered on each PC? That is,
I guess, some kind of late binding scenario? Or would it have to be
registered at least once (I assume that
registration just puts a pathname into the Windows Registry), and then
allow AutoFEUpdater to copy the DLL
into the same folder as the MDE for subsequent updates?

Or should I leave the DLL on the server? If so, how would the MDE know
where it was?

Any ideas gratefully received,

Ray

Nov 13 '05 #2

This discussion thread is closed

Replies have been disabled for this discussion.