Distributing an Access App to the Masses

[AccessGeek]

Has anyone out there distributed their Access apps on a wide scale basis? I have developed many Access tools that I've sold to a single business where I was able to be on-site and am wondering about the pitfalls of doing this to a broader audience, such as how some software companies distribute their apps via downloading. I do have the Access developers edition, but have not yet used it beyond seeing if it works. My main concern is with broken references. Should I package the reference files (.dll, .tlb,.olb, etc) and have them copied to a user's system at deployment and then set the references in VB? How have other developers handled this? Are there any other pitfalls I should be aware of? Thanks!

[ajetrumpet]

well, if you are a professional developer, you really should already know this, but...

if you look at other software company websites, you'll notice that there are different downloads for different windows versions, etc, etc...

What that really means, to me anyway, is that they understand the pitfalls and have compensated for them in the quickest manner possible by deploying different packages based on different situations. IMO, you should do the same thing. I've done things like this in the past, but since it wasn't a "life or death" situation for us, I basically used some hair brain ideas. Things like a clickable link on a webpage that runs a batch file that checks for the name of the office folder in the default location. Stuff like that of course doesn't work all the time, but to 99% of people it does, so the risk of error is minimal.

but again, IMO, the biggest problem with producing software from a software app that already exists, like access for instance, is that you have a two-tier system of compatibilities you have to worry about. Example - distributing access apps depends a lot on the OS AND the version of access that the client has (if any). You'll notice on other websites, especially those that offer "source software", rarely ask you about any differences in your system other than the OS that you're running. That's probably because the OS is the only variable factor in the success of installation and operation of their software. And if you look closely during the installation of many other software apps, you'll notice that most of them run at least one batch file, which of course is always compatible with windows.

As far as external files go, like custom olb's, dll's and such, did you know that you can package them right into a distribution pack that's made with the Access extensions? That's one fell swoop, and no work has to be done by you. Now that goes without saying that there are plenty of other tools out there that will do this same thing for you. But IMO, the best thing about using the develop tools from MS is the fact that you can be 99% sure that they've at least reviewed it for errors and troubleshooting spots.

No offense to MS, but that company completely sucks with regard to caring how fine-tuned the software is. That reputation will haunt them forever, I'm sure. But I've personally never had a problem with distributing an app made in Access with it's extensions. No-one has ever complained to me about the program not working.

[AccessGeek]

Adam,
Great info and gives me something to think about - especially the 2 tier compatibility issues. I did see the packaging feature of external features and will have to test it some more. Do you know if I would still need to set references programmatically to the files that are copied over? I love Access but I wish there was more robustness in deploying what we build.
Thanks for your input!

[ajetrumpet]

Do you know if I would still need to set references programmatically to the files that are copied over?

you know, I really have no idea. I have dist'd apps that had more references than the default 4 or 5 that you usually see, but they were all windows based. Soooo...when the file that already had these refs in it was packaged into the extension's packager, obviously they were kept when the client ran the extractor. Otherwise, I would've heard "&%$$&*@&^$#$#^" over a phone call.

My guess would be that, if you have custom externals accompany your app, as in external files that are NOT normall shipped with windows, they will at least have to thrown to the right directory when the extractor runs. If they're not, I'm 99% sure that the client's app will include broken refs.

Windows-based externals are not a problem usually (what I've found anyway), because the majority of them can always be found in the same place. Hence, the address in the references dialog always points to the same location of the file.

I'd test it, if I were you (if you have customs, that is). Put one on a machine, link it in refs, then deploy that file to another machine without that custom external file copied onto it. That'll tell you everything you need to know!