How to check for installed compnents?

[deko]

I'm trying to create an MSI in VS.NET that will check for installed Office
System components - so my MDE will only install if requirements are met.
I'm thinking about using VBScript to inspect Registry keys/values. Anyone
travel this road before? Other suggestions?

Thanks in advance.

[David W. Fenton]

Trevor Best <nospam@localho st> wrote in
news:40******** *************** @auth.uk.news.e asynet.net:

Terry Kreft wrote:

I realise these are first attempts but both are flwed to some
extent as the Office folder path is hardcoded.

I don't try to be too clever when writing aircode or modifying
someone elses code for usenet purposes, had I been writing this in
a real app I would have used SysCmd(acSysCmd AccessDir), a bit
easier than snooping around the registry :-)

Wow, I feel dumb.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[David W. Fenton]

Trevor Best <nospam@localho st> wrote in
news:40******** *************** @auth.uk.news.e asynet.net:

deko wrote:

would have used SysCmd(acSysCmd AccessDir), a bit easier than
snooping around the registry :-)

I came up with this, but in testing it never ran - I just got the
"Missing Reference" errors. The start up form never had a chance
to open. Oh well, back to the Installer...

Anyway, thanks for the help.

That's because you're using early binding still, you will need to
uncheck the references and use late binding (use early binding for
development to get intellisense, etc), then for example change:

Dim wb as new excel.workbook
wb.dosomthing

to

dim wb as object
set wb=createobject ("excel.workboo k")
wb.dosomthing

And you'll want to have error correction in there to handle the lack
of Excel being installed.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Trevor Best]

David W. Fenton wrote:

Trevor Best <nospam@localho st> wrote in
news:40******** *************** @auth.uk.news.e asynet.net:

deko wrote:

would have used SysCmd(acSysCmd AccessDir), a bit easier than
snooping around the registry :-)
I came up with this, but in testing it never ran - I just got the
"Missing Reference" errors. The start up form never had a chance
to open. Oh well, back to the Installer...

Anyway, thanks for the help.

That's because you're using early binding still, you will need to
uncheck the references and use late binding (use early binding for
development to get intellisense, etc), then for example change:

Dim wb as new excel.workbook
wb.dosomthi ng

to

dim wb as object
set wb=createobject ("excel.workboo k")
wb.dosomthi ng

And you'll want to have error correction in there to handle the lack
of Excel being installed.

Isn't that the point of the thread? To check that Excel is installed
when first run?
--
Error reading sig - A)bort R)etry I)nfluence with large hammer

[Terry Kreft]

You're right Trevor that syscmd would work in an installed db but I thought
this thread was about installing it?

--
Terry Kreft
MVP Microsoft Access
"Trevor Best" <nospam@localho st> wrote in message
news:40******** *************** @auth.uk.news.e asynet.net...

Terry Kreft wrote:

I realise these are first attempts but both are flwed to some extent as the Office folder path is hardcoded.

I don't try to be too clever when writing aircode or modifying someone
elses code for usenet purposes, had I been writing this in a real app I
would have used SysCmd(acSysCmd AccessDir), a bit easier than snooping
around the registry :-)

--
Error reading sig - A)bort R)etry I)nfluence with large hammer

[deko]

> Isn't that the point of the thread? To check that Excel is installed

when first run?

The Windows Installer, I think, is the best solution for this kind of thing.
I've set up a Launch Condition in the Installer that checks for the .exe
files - seems to work pretty well (I had thought this would require VBScript
in a Custom Action). The install aborts if a component is missing. The
joker in the pack is if the user did a custom install of Office (since I use
a hard-coded path to the exe). Reading the Path value in the InstallRoot
Key and using that in the Launch Condition may take some more tinkering.

The other issue is dealing with References - If I develop in Office 2003,
then my references are to the Office11 libraries. When I make the MDE,
these references are compiled into the app. So the app will only run with
Office 2003. I assume this means I will have to somehow down-rev the app
for Office 2002 and set References for the Office10 libraries if I want to
distribute to clients running Office 2002. So I have to offer 2 different
versions: one for Office 2002 and one for Office 2003. Is this correct?

.... anyone going to Mountain View tonight for the C# Roadshow?

[Trevor Best]

deko wrote:

Isn't that the point of the thread? To check that Excel is installed
when first run?

The Windows Installer, I think, is the best solution for this kind of thing.
I've set up a Launch Condition in the Installer that checks for the .exe
files - seems to work pretty well (I had thought this would require VBScript
in a Custom Action). The install aborts if a component is missing. The
joker in the pack is if the user did a custom install of Office (since I use
a hard-coded path to the exe). Reading the Path value in the InstallRoot
Key and using that in the Launch Condition may take some more tinkering.

The other issue is dealing with References - If I develop in Office 2003,
then my references are to the Office11 libraries. When I make the MDE,
these references are compiled into the app. So the app will only run with
Office 2003. I assume this means I will have to somehow down-rev the app
for Office 2002 and set References for the Office10 libraries if I want to
distribute to clients running Office 2002. So I have to offer 2 different
versions: one for Office 2002 and one for Office 2003. Is this correct?

... anyone going to Mountain View tonight for the C# Roadshow?

Just the lowest common denomiator is needed I think. If your app
references Exec10, then Access 2003 would be old enough and ugly enough
to work out that Excel11 will do.
--
Error reading sig - A)bort R)etry I)nfluence with large hammer

[Trevor Best]

Terry Kreft wrote:

You're right Trevor that syscmd would work in an installed db but I thought
this thread was about installing it?

After reading deko's last response I see that's the case. D'oh!

--
Error reading sig - A)bort R)etry I)nfluence with large hammer

[Don Leverton]

Hi Folks,

This conversation is quite a ways over my head, but I've been following this
thread thinking "I seem to remember something about a program that allowed
you to package all of the required libraries with your distribution". This
is probably similar to the MSI that Deko has been talking about?

Does your program actually require that Excel is installed, or just it's
libraries etc.? I really don't know a lot about the developer aspect and the
associated legalities. If all that is required is the library files, is it
legal to distribute them seperately, if they a dependency of another
application developed using a Microsoft application (Access)?

Anyway, the program that I'm thinking of is called Active Delivery. It
claims to be able to put you in control of the install paths and
modifications to the Windows Registry, etc. If you're interested (and you
guys will understand it better than I do for sure) have a look at:
http://www.activedelivery.com/ad/index.htm

===========
HTH, Don

"Terry Kreft" <te*********@mp s.co.uk> wrote in message
news:py******** ************@ka roo.co.uk...

You're right Trevor that syscmd would work in an installed db but I thought this thread was about installing it?

--
Terry Kreft
MVP Microsoft Access
"Trevor Best" <nospam@localho st> wrote in message
news:40******** *************** @auth.uk.news.e asynet.net...

Terry Kreft wrote:

I realise these are first attempts but both are flwed to some extent

as

the Office folder path is hardcoded.

I don't try to be too clever when writing aircode or modifying someone
elses code for usenet purposes, had I been writing this in a real app I
would have used SysCmd(acSysCmd AccessDir), a bit easier than snooping
around the registry :-)

--
Error reading sig - A)bort R)etry I)nfluence with large hammer

[deko]

> This conversation is quite a ways over my head, but I've been following
this

thread thinking "I seem to remember something about a program that allowed
you to package all of the required libraries with your distribution". This
is probably similar to the MSI that Deko has been talking about?

Does your program actually require that Excel is installed, or just it's
libraries etc.? I really don't know a lot about the developer aspect and the associated legalities. If all that is required is the library files, is it
legal to distribute them seperately, if they a dependency of another
application developed using a Microsoft application (Access)?

I'm not sure how ActiveDelivery differs from the Windows Installer (i.e. an
msi package), but a key feature of this database is it's use of automation
to integrate with Word, Outlook, and Excel, so those apps need to be there.
The Windows Installer (as I am painfully aware) has a steep learning curve,
but is more than powerful enough for what I'm trying to do.

Caphyon offers a freeware wrapper for Windows Installer 2.0 that's great for
making simple msi's - http://www.advancedinstaller.com/download.html

When you build a Setup Project in Visual Studio, it creates an msi (both ver
2 and 3, I think), and also a setup.exe, which is nice. If you can figure
out the Conditional Statement syntax for Launch Conditions, and write
VBScript for Custom Actions, you've got everything you need. Still, some
will say InstallShield is the gold standard... if you've got the gold to buy
it...
http://www.installshield.com/products/comparison.asp

[David W. Fenton]

Trevor Best <nospam@localho st> wrote in
news:40******** **************@ auth.uk.news.ea synet.net:

deko wrote:

Isn't that the point of the thread? To check that Excel is
installed when first run?

The Windows Installer, I think, is the best solution for this
kind of thing. I've set up a Launch Condition in the Installer
that checks for the .exe files - seems to work pretty well (I had
thought this would require VBScript in a Custom Action). The
install aborts if a component is missing. The joker in the pack
is if the user did a custom install of Office (since I use a
hard-coded path to the exe). Reading the Path value in the
InstallRoot Key and using that in the Launch Condition may take
some more tinkering.

The other issue is dealing with References - If I develop in
Office 2003, then my references are to the Office11 libraries.
When I make the MDE, these references are compiled into the app.
So the app will only run with Office 2003. I assume this means I
will have to somehow down-rev the app for Office 2002 and set
References for the Office10 libraries if I want to distribute to
clients running Office 2002. So I have to offer 2 different
versions: one for Office 2002 and one for Office 2003. Is this
correct?

... anyone going to Mountain View tonight for the C# Roadshow?

Just the lowest common denomiator is needed I think. If your app
references Exec10, then Access 2003 would be old enough and ugly
enough to work out that Excel11 will do.

But for the reference to work, doesn't the path have to be the same
for the Excel directory?

Late binding is still the way to go.

Then you could install the application even if Excel is not
installed, and the non-Excel dependent features could still be used.
With references, nothing at all is going to work, ever.

I can't see why anyone would use anything other than late binding,
except if they don't know any better.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc