VB and custom actions

[Bob Shirley]

I may have missed this answer in the docs and while lurking here, but...

Can VB.NET (or VB6) be used to create custom actions ? I see in the SDK docs
that DLL-based CA's must be in C or C++ (why?), but does the same hold true
for EXE-based actions ? I suppose I could fall back on scripting; sounds
like it may have advantages over EXEs anyway (access to SESSION, etc.).

TIA,
Bob S.

[Stefan Krueger [MVP]]

DLL based actions must be created with a tool that generates "true" DLLs,
that export functions in the same way that WinAPI does. You cannot use VB
because it creates ActiveX with a .dll extension. To call a function in a VB
dll you would have to register the ActiveX and then call it using COM (also
you need to copy the vb runtime first). I don't know about VB.NET.
For an exe of course it doesn't matter with what tool it was created, as
long as the runtime requirements are met. So you may need to install the
.NET Framework first before you can run the exe.
In .NET there's also Installer classes that you can call from your setup,
but there are some limitations.

--
Stefan Krueger
Microsoft Windows Installer MVP

Please post your questions in the newsgroup or vist one of these web sites:

Windows Installer FAQ
http://www.msifaq.com - http://www.msifaq.de

InstallSite - Resources for Setup Developers
http://www.installsite.org
http://www.installsite.de (GERMAN)

"Bob Shirley" <bob_s...@firstdatabank.nospam.com> schrieb im Newsbeitrag
news:%235awbcE...@tk2msftngp13.phx.gbl...

[Phil Wilson]

The general issue with C# or VB.NET is that they're object-based. In order to call a method you
nearly always need to instantiate an object, so Windows Installer would need to be told what object
to create as well as what method to call.
--
Phil Wilson [MVP Windows Installer]
----
"Bob Shirley" <bob_s...@firstdatabank.nospam.com> wrote in message
news:%235awbcE...@tk2msftngp13.phx.gbl...

[David Barnard]

Is this a problem? I know Windows Installer doesn't support anything like
this yet, but what I expect to see in the future is some interface that
installer classes implement, then the Installer engine directly calls the
methods. Hopefully the supported functionality will be at least as rich as
current MSI dll custom actions.

David

"Phil Wilson" <phil....@unisys.spamcom> wrote in message
news:O8pXFgG...@tk2msftngp13.phx.gbl...

[Phil Wilson]

I wouldn't really call it a problem, just the way it works. As you probably know, the installer
classes work by calling an intermediate DLL first, that then probably uses reflection to find
installer classes and call them. It's not clear to me that making this work directly from the
installer would be high priority because there are installer or similar equivalents of (I think) all
of the .NET installer classes. I see a lot of confusion with .NET programmers using gacutil, regasm,
installutil, installer classes, and knowing nothing about the windows installer. At one time all you
had to say was No, we don't use regsvr32 we populate class/progid tables. Now you have to say No, we
don't need installer classes to install a service, we don't need regasm because the tools put that
stuff in the MSI file, no don't use COMRegisterFunctionAttribute and so on.

--
Phil Wilson [MVP Windows Installer]
----

"David Barnard" <msdn.ne...@didactylos.net> wrote in message
news:uz1ZJqG...@TK2MSFTNGP12.phx.gbl...

[David Barnard]

I would agree with all that. However, there is another wrinkle -
cross-platform .NET. Not so much of a problem now, but it is clear from the
design of the Framework that this is one of the big goals of .NET, and it
seems they have anticipated the problem of installing .NET applications on
systems without Windows Installer being available.

Custom Installer classes can be incredibly useful - they allow installation
code to exist right alongside the application code (making it easy to call
either from the other). It's just a pity the guidelines on using them are so
sketchy, and the provided installer classes (especially ServiceInstaller)
are so useless - buggy, even. Also, since services are a Windows thing, it
makes total sense to leave service installation to the installer.

I'm split two ways on this - either .NET needs an installation solution that
can cope with anything, and that works independently from Windows Installer,
or the installation features of .NET need to be tied more closely to the
Installer service. The later would require (at the very least) an official
managed interface to the Installer API and native support for managed custom
actions (of all types). Of course, it's almost impossible to predict what a
hypothetical Windows Installer 4.0 may look like, and Microsoft either don't
know yet or aren't saying. For all I know, they may throw out the whole MSI
thing, and come up with something based around Yukon.....

David

"Phil Wilson" <phil....@unisys.spamcom> wrote in message

news:uSEnLKHX...@TK2MSFTNGP12.phx.gbl...

[Bob Shirley]

Stefan / Phil / David -

Thanks for the info and comments; I assumed that VB6 wasn't in the running
for that reason but, again, couldn't find a simple statement of that
anywhere in the docs. I agree that it would seem that an EXE from any source
should be valid, but I can't find anyone who has actually used a managed
language for a CA (anybody?).

I'm currently reviewing the Installer namespace docs. Is it just me, or do
they (and the MSI docs) both suffer from a severe lack of any examples and
actual real-world 'how-to' code ? Don't get me wrong - each class / member /
method is described in detail, but trying to get the big picture of how to
assemble the parts into an efficient, working whole is like hunting for
puzzle pieces. Are there any other sources for Installer namespace info ?
I've Googled all morning but mostly found clones of the SDK content.

Thanks again...

Bob S.

"Stefan Krueger [MVP]" <nws...@installsite.net> wrote in message
news:OlM9zXFX...@TK2MSFTNGP09.phx.gbl...

[David Barnard]

You're not wrong. I've spent months looking at this and related issues, and
I've yet to find any definitive (or even helpful) documentation. All I can
say is "do what you have to do to make it work".

I have used managed executables in custom actions. No problem at all.

David

"Bob Shirley" <bob_s...@firstdatabank.nospam.com> wrote in message

news:uEZy90P...@TK2MSFTNGP12.phx.gbl...

[Bob Shirley]

OK - thanks again, David for:

1) making me feel a little less like a blithering idiot for spending what
feels like *way* too much time piecing together MSI info, only to discover
that maybe I should have been looking at the Installer namespace all along.
I understand that MS is doing a beta of MSI 3; whatever features they
add/change, I hope they improve the docs if nothing else... (<RANT> in case
you're listening, MS - not that what you've produced is bad; it just doesn't
go far enough. Example code needs to be provided for everything and the code
shouldn't all be at the member level. Give us more 'how to' topics that
actually show us how the pieces fit - not ones that just include a paragraph
or two of text and a couple of links to more member descriptions. Same goes
for the Installer namespace.</RANT>), at this point, I'm strongly
considering just hard-coding something that will do what I want, without
worrying about how to do it the way that either MSI or Installer want me
to...

2) confirmation that someone has actually gone the managed CA route and
lived ;-)

Bob S.

"David Barnard" <msdn.ne...@didactylos.net> wrote in message

news:OSsKh5PX...@TK2MSFTNGP09.phx.gbl...