473,321 Members | 1,748 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,321 software developers and data experts.

Installer Auto Run

I developed a C# application and a windows installer application that
properly installs the C# application on a new machine.

After the C# application is installed I would like to automatically start it
on the User's machine.

- How do I instruct the setup program to start execution of the newly
installed program?
- Is there a good general resource that documents the use of the installer?

--
-- Thom Little -- www.tlaNET.net -- Thom Little Associates, Ltd.
--

Nov 16 '05 #1
43 5240
Thom Little <th**@tlanet.net> wrote:
I developed a C# application and a windows installer application that
properly installs the C# application on a new machine.

After the C# application is installed I would like to automatically start it
on the User's machine.

- How do I instruct the setup program to start execution of the newly
installed program?
Funnily enough, I'm after exactly the same thing at the moment. It's
easy enough to start the installed program - just use Process.Start
from a custom installation action. The tricky bit is getting it to only
start when the installer has finished - the custom action gets invoked
before the final dialog box is closed, and I can't see any way of
hooking into that very end bit...
- Is there a good general resource that documents the use of the installer?


I wish... it seems to be very limited in VS.NET. I assume this is a
limitation of VS.NET itself rather than MS Installer, as lots of other
install scripts seem to do much more than is possible frmo VS.NET.
Presumably that's where buying InstallShield comes in, but I'd rather
avoid that if possible...

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #2
> just use Process.Start from a custom installation action.

How do I do that? (Please assume I am "dumb as dirt".)

For your question ... can't you just use a dialog box in the End section
prior to Finished that asks if the application should be run?

--
-- Thom Little -- www.tlaNET.net -- Thom Little Associates, Ltd.
--

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Thom Little <th**@tlanet.net> wrote:
I developed a C# application and a windows installer application that
properly installs the C# application on a new machine.

After the C# application is installed I would like to automatically start it on the User's machine.

- How do I instruct the setup program to start execution of the newly
installed program?
Funnily enough, I'm after exactly the same thing at the moment. It's
easy enough to start the installed program - just use Process.Start
from a custom installation action. The tricky bit is getting it to only
start when the installer has finished - the custom action gets invoked
before the final dialog box is closed, and I can't see any way of
hooking into that very end bit...
- Is there a good general resource that documents the use of the

installer?
I wish... it seems to be very limited in VS.NET. I assume this is a
limitation of VS.NET itself rather than MS Installer, as lots of other
install scripts seem to do much more than is possible frmo VS.NET.
Presumably that's where buying InstallShield comes in, but I'd rather
avoid that if possible...

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Nov 16 '05 #3
> > I developed a C# application and a windows installer application that
properly installs the C# application on a new machine.

.....

At this moment I have the same problems.
It would be nice to have some default setup project that does following
things:

* Determin if there is a correct .NET framework installed.
* If not, then it redirects to the Windows update folder ready to scan the
computer and select the .NET framework installer. (I dont' like
redistributels since a Frenchmen would probably not like an English version
of .NET installed by default) .
* When the .NET is installed, then install the program.
* Finally register the strong key of the assembly automatically so that this
assembly have access to network drives.
* And start up the program when checked.

So the question is: does there exist a setup project that does this
somewhere?

I know I am lazy. ;-)
But this way I do not reinvent the wheel every time. :-)

Thanks.
Nov 16 '05 #4
Thom Little <th**@tlanet.net> wrote:
just use Process.Start from a custom installation action.
How do I do that? (Please assume I am "dumb as dirt".)


I use code like this:

// What directory is our assembly in
string ourDirectory = Path.GetDirectoryName
(Assembly.GetExecutingAssembly().Location);

Process.Start(ourDirectory+"\\Foo.exe");
For your question ... can't you just use a dialog box in the End section
prior to Finished that asks if the application should be run?


No - that happens after all the custom actions have already been run.
Besides, the idea (in my case) is to run the application after the
installer has absolutely finished - after the user has hit "Finish" on
the Finished dialog.

I've tried using the process ID of the custom installation action, and
getting the application to wait for that to finish, but it seems that
the action is executed in a different process to the main installation
itself.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #5
Jon Skeet [C# MVP] wrote:
Thom Little <th**@tlanet.net> wrote:

- Is there a good general resource that documents the use of the installer?


I wish... it seems to be very limited in VS.NET. I assume this is a
limitation of VS.NET itself rather than MS Installer, as lots of other
install scripts seem to do much more than is possible frmo VS.NET.
Presumably that's where buying InstallShield comes in, but I'd rather
avoid that if possible...


Well, if simple installer is needed, NSIS 2.0 is a tool to look at -
free installation system, with simple script language,good GUI and such.

Only drawback is that it isn't MSI based.

For MSI there is some free tools to build MSIs but otherwise you have to
stick with commercial tools.

--

Jani Tiainen
Nov 16 '05 #6
Jani Tiainen <ja**********@keypro.fi> wrote:
Well, if simple installer is needed, NSIS 2.0 is a tool to look at -
free installation system, with simple script language,good GUI and such.

Only drawback is that it isn't MSI based.
Mmm... probably a no-no then, at the moment. (Fine for personal
projects though - must look at it some time.)
For MSI there is some free tools to build MSIs but otherwise you have to
stick with commercial tools.


Mmm. The annoying thing is that this is such a *common* thing to want
to do. Why on earth doesn't VS.NET support it? Loads of installers have
a "Start the application" or "View the release notes" or whatever at
the end. With VS.NET, you can't even ask the question at the end of the
installation, let alone actually run the thing when you want it to. :(

We're only actually running a *very* simple installation here - just
copy some files, add a shortcut, and optionally start the app. Nothing
that VS.NET can justifiably claim is "advanced".

(Where we *are* doing relatively advanced stuff is in terms of
installing stuff to a PocketPC, and there the situation is lamentably
worse. Anyone would think that wanting to ask the user some
configuration questions on the desktop and propagate those to the
device was something no-one has even considered before now. The state
of installation on PocketPC is absurd, IMO.)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #7

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Dave <no****************@wi.rr.com> wrote: Unfortunately finding a parent process is easier said than done - it
would require P/Invoking undocumented methods, which might be different
for different operating systems. Horrible.


No Pinvoke required, just use System.Management...

using System.Management;
.....
int parentPid = GetParentProcess(Process.GetCurrentProcess().Id);
......

static int GetParentProcess(int Id)
{
int parentPid;
using(ManagementObject mo = new ManagementObject("win32_process.handle='"
+ Id.ToString() + "'"))
{
mo.Get();
parentPid = Convert.ToInt32(mo["ParentProcessId"]);
}
return parentPid;
}

Willy.
Nov 16 '05 #8
>
I've tried using the process ID of the custom installation action, and
getting the application to wait for that to finish, but it seems that
the action is executed in a different process to the main installation
itself.

--

You might be able to find the parent process of the current process from
within your custom action and then use that ID to wait on. I haven't tried
it (and don't need it for my app); I'd be curious if you can get that to
work. You could also search through all running processes looking for MSI
processes (msiexec) and then wait on them all to terminate. If you're
installing a service then it's InstallUtil.exe that is running and invoking
your custom actions.


Nov 16 '05 #9
>
I use custom actions which are in an assembly on their own, rather than
in anything used by the rest of the application. The only custom action
in the uninstaller is something to remove registry entries - in the
case of an upgrade, it doesn't matter too much whether or not that
happens.

If it's still something I might run into, please let me know!

From what I've seen so far (and I'm still investigating) it appears that
windows installer creates a single appdomain and runs all the managed code
within that appdomain. This is normally not an issue, but when doing an
automatic uninstall/install it appears that it never recycles the appdomain.
The consequence is that even though the assembly on disk that contains the
custom action has been replaced with a newer version, the version of the
assembly that windows installer calls into to run the custom action is the
old assembly that should have been deleted and replaced with a newer
version.

I'm hedging by using "appears" etc. because I'm not precisely sure what it's
doing, but it does look like this is what is happening. I added diagnostic
code to the custom installer that dumped the assembly version that was
executing, and the old version number showed up when running the install
custom action.

I consider this to be a *major* flaw in their implementation.

It also implies that if you get the process id at the time your custom
action executes then you may not need to get the process id of the parent -
it may be the same process. I haven't checked that out yet but I will do
that later today. I will write a simple app with a custom installer action
that just dumps out all the appdomain and process related data.

Dave
Nov 16 '05 #10
> Mmm. The annoying thing is that this is such a *common* thing to want
to do. Why on earth doesn't VS.NET support it? Loads of installers have
a "Start the application" or "View the release notes" or whatever at
the end. With VS.NET, you can't even ask the question at the end of the
installation, let alone actually run the thing when you want it to. :(


You can ask the question at the beginning and save the answer to use later.
For "readme" files I use a custom action that is called during the commit
phase. The downside is that the action executes before the installer is
completely done, but the slight overlap is acceptable. It isn't perfect but
it works well enough for my purposes.

I agree that the install support in .net is weak. I've spent a lot of time
using ORCA to get customized behavior that is not supported in .net.

Nov 16 '05 #11
Dave <no****************@wi.rr.com> wrote:
I've tried using the process ID of the custom installation action, and
getting the application to wait for that to finish, but it seems that
the action is executed in a different process to the main installation
itself.
You might be able to find the parent process of the current process from
within your custom action and then use that ID to wait on. I haven't tried
it (and don't need it for my app); I'd be curious if you can get that to
work. You could also search through all running processes looking for MSI
processes (msiexec) and then wait on them all to terminate. If you're
installing a service then it's InstallUtil.exe that is running and invoking
your custom actions.


Unfortunately finding a parent process is easier said than done - it
would require P/Invoking undocumented methods, which might be different
for different operating systems. Horrible.

I've solved it in a pretty foul way in the end, but it works: the
installer will have the name of the product as its main window title. I
just search for any msiexec.exe processes with that main window title,
and wait for them to exit. Nasty, but it seems to work.

Cheers for your ideas though.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #12
Dave <no****************@wi.rr.com> wrote:
Mmm. The annoying thing is that this is such a *common* thing to want
to do. Why on earth doesn't VS.NET support it? Loads of installers have
a "Start the application" or "View the release notes" or whatever at
the end. With VS.NET, you can't even ask the question at the end of the
installation, let alone actually run the thing when you want it to. :(
You can ask the question at the beginning and save the answer to use later.


Yes, but that's contrary to common installer usage, where it's the last
thing asked (on the very final dialog). It's just another annoyance.
For "readme" files I use a custom action that is called during the commit
phase. The downside is that the action executes before the installer is
completely done, but the slight overlap is acceptable. It isn't perfect but
it works well enough for my purposes.
In our case it just looks horrible, unfortunately. It's not a slight
overlap - it's however long the user waits before clicking "Close".
I agree that the install support in .net is weak. I've spent a lot of time
using ORCA to get customized behavior that is not supported in .net.


:(

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #13
Thanks for the lead.

I created a new class and successfully launched the application during the
install. The code ...

public class tlaSystemTrayLaunch
{
public static void Main( string[] args )
{
ProcessStartInfo psi = new ProcessStartInfo( );
psi.FileName = "tlaSystemTray.exe " ;
psi.WorkingDirectory = String.Join(" ",args );
Process.Start(psi );
}
}

How do I connect this class to a custom two-button dialog box?

--
-- Thom Little -- www.tlaNET.net -- Thom Little Associates, Ltd.
--

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP***********************@msnews.microsoft.co m...
Thom Little <th**@tlanet.net> wrote:
just use Process.Start from a custom installation action.


How do I do that? (Please assume I am "dumb as dirt".)


I use code like this:

// What directory is our assembly in
string ourDirectory = Path.GetDirectoryName
(Assembly.GetExecutingAssembly().Location);

Process.Start(ourDirectory+"\\Foo.exe");
For your question ... can't you just use a dialog box in the End section prior to Finished that asks if the application should be run?


No - that happens after all the custom actions have already been run.
Besides, the idea (in my case) is to run the application after the
installer has absolutely finished - after the user has hit "Finish" on
the Finished dialog.

I've tried using the process ID of the custom installation action, and
getting the application to wait for that to finish, but it seems that
the action is executed in a different process to the main installation
itself.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Nov 16 '05 #14
Dave <no****************@wi.rr.com> wrote:
If it's still something I might run into, please let me know!
From what I've seen so far (and I'm still investigating) it appears that
windows installer creates a single appdomain and runs all the managed code
within that appdomain. This is normally not an issue, but when doing an
automatic uninstall/install it appears that it never recycles the appdomain.
The consequence is that even though the assembly on disk that contains the
custom action has been replaced with a newer version, the version of the
assembly that windows installer calls into to run the custom action is the
old assembly that should have been deleted and replaced with a newer
version.
Interesting. I'd hope for the old assembly to be used for uninstall and
the new one for install. I'll investigate myself and let you know
whether I see the same effect. I'll let you know - and thanks for the
heads-up.
I consider this to be a *major* flaw in their implementation.

It also implies that if you get the process id at the time your custom
action executes then you may not need to get the process id of the parent -
it may be the same process.


It's not, unfortunately - I assumed it would be, and ran into
problems...

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #15
Willy Denoyette [MVP] <wi*************@pandora.be> wrote:
No Pinvoke required, just use System.Management...


<snip>

Ah, lovely thanks - but what platforms will that work on? I suspect
I'll stick with the grotty hack for the moment, but I'll keep that
snippet for a time when I really, really need the parent process :)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #16
> Dave <no****************@wi.rr.com> wrote:
Mmm. The annoying thing is that this is such a *common* thing to want
to do. Why on earth doesn't VS.NET support it? Loads of installers have a "Start the application" or "View the release notes" or whatever at
the end. With VS.NET, you can't even ask the question at the end of the installation, let alone actually run the thing when you want it to. :(
You can ask the question at the beginning and save the answer to use later.
Yes, but that's contrary to common installer usage, where it's the last
thing asked (on the very final dialog). It's just another annoyance.
For "readme" files I use a custom action that is called during the

commit phase. The downside is that the action executes before the installer is
completely done, but the slight overlap is acceptable. It isn't perfect but it works well enough for my purposes.


In our case it just looks horrible, unfortunately. It's not a slight
overlap - it's however long the user waits before clicking "Close".
I agree that the install support in .net is weak. I've spent a lot of time using ORCA to get customized behavior that is not supported in .net.


:(

--


All agreed with... presumably all this stuff's possible using ORCA, but I
can't seem to justify spending time on stuff that's so seemingly trivial.
There are loads of MSI authoring tools out there but they all seem either a)
massively expensive or b) limited to what VS.NET can do or just slightly
more.

What might be nice is if some people that are good at MSI authoring got
together to make some kind of pluggable project so that actions like the
things you're looking for can be added as people need them - it seems to me
that the whole thing's basically like writing a database front end where you
could expect to slap on a new form and a bit of SQL for it to run. Maybe
there's even money to be made in them thar hills.

It's especially frustrating that Microsoft don't really seem to care about
what is one of the most important parts of any piece of software (at least
as far as an end user's concerned). There're some extremely simple things I
need to do but just don't have the time to learn how to do it.

Steve
Nov 16 '05 #17
Thom Little <th**@tlanet.net> wrote:
Thanks for the lead.

I created a new class and successfully launched the application during the
install. The code ...

public class tlaSystemTrayLaunch
{
public static void Main( string[] args )
{
ProcessStartInfo psi = new ProcessStartInfo( );
psi.FileName = "tlaSystemTray.exe " ;
psi.WorkingDirectory = String.Join(" ",args );
Process.Start(psi );
}
}

How do I connect this class to a custom two-button dialog box?


Look up Custom Installation Actions in MSDN (or something similar -
fiddle around in the index until you find it!). Basically you need to
create a class library, and inside that add an Installer Component
where you put your code. Then in the Custom Actions part of the setup
project, you need to add hooks into your library.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #18
Runs on me, XP, W2K, W2K3 out of the box.
Win98se and NT4 needs the WMI core redistributable installed.

Willy.

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Willy Denoyette [MVP] <wi*************@pandora.be> wrote:
No Pinvoke required, just use System.Management...


<snip>

Ah, lovely thanks - but what platforms will that work on? I suspect
I'll stick with the grotty hack for the moment, but I'll keep that
snippet for a time when I really, really need the parent process :)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Nov 16 '05 #19
I guess I was mumbling.

I tried to say that I already did everything that you suggested and it works
like a champ.

The question I have is how can I make the execution conditional based on a
standard two-button dialog? Put another way ... How do I connect a
two-button dialog to a custom class?

--
-- Thom Little -- www.tlaNET.net -- Thom Little Associates, Ltd.
--

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Thom Little <th**@tlanet.net> wrote:
Thanks for the lead.

I created a new class and successfully launched the application during the install. The code ...

public class tlaSystemTrayLaunch
{
public static void Main( string[] args )
{
ProcessStartInfo psi = new ProcessStartInfo( );
psi.FileName = "tlaSystemTray.exe " ;
psi.WorkingDirectory = String.Join(" ",args );
Process.Start(psi );
}
}

How do I connect this class to a custom two-button dialog box?


Look up Custom Installation Actions in MSDN (or something similar -
fiddle around in the index until you find it!). Basically you need to
create a class library, and inside that add an Installer Component
where you put your code. Then in the Custom Actions part of the setup
project, you need to add hooks into your library.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Nov 16 '05 #20
<"Steve McLellan" <sjm.NOSPAM AT fixerlabs DOT com>> wrote:
All agreed with... presumably all this stuff's possible using ORCA, but I
can't seem to justify spending time on stuff that's so seemingly trivial.
There are loads of MSI authoring tools out there but they all seem either a)
massively expensive or b) limited to what VS.NET can do or just slightly
more.

What might be nice is if some people that are good at MSI authoring got
together to make some kind of pluggable project so that actions like the
things you're looking for can be added as people need them - it seems to me
that the whole thing's basically like writing a database front end where you
could expect to slap on a new form and a bit of SQL for it to run. Maybe
there's even money to be made in them thar hills.

It's especially frustrating that Microsoft don't really seem to care about
what is one of the most important parts of any piece of software (at least
as far as an end user's concerned). There're some extremely simple things I
need to do but just don't have the time to learn how to do it.


Yup. To be honest, I'd be perfectly happy with a reference manual and a
big text file to edit, with a command line tool to build the whole lot
together into an MSI file. So long as the error messages are
intelligible and the documentation is good, I don't *need* wizards, and
frankly they end up making things harder a lot of the time.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #21
Thom Little <th**@tlanet.net> wrote:
I guess I was mumbling.

I tried to say that I already did everything that you suggested and it works
like a champ.

The question I have is how can I make the execution conditional based on a
standard two-button dialog? Put another way ... How do I connect a
two-button dialog to a custom class?


Oh, I see. Sorry.

I don't know about button dialogs, but for checkboxes at least, you set
the property name of the checkbox, and use the same name for the
condition of the action. I'll have a look into buttons, if you like.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #22
> Interesting. I'd hope for the old assembly to be used for uninstall and
the new one for install. I'll investigate myself and let you know
whether I see the same effect. I'll let you know - and thanks for the
heads-up.


I did some more checking today and confirmed the problem; I opened an
incident with MSFT about this. They may already be aware of the problem, and
I may have given them more credit then they deserve - the problem may be
much dumber then my hypothesis :-). I just read on another newsgroup (where
I posted a query) that they will only load a DLL once, so it may not even be
related to appdomain recycling.

The means that I cannot use auto-uninstall/install for my app - too many
things will not work correctly if the wrong assembly is loaded during
installation. We do major things at install time, like generate dynamic
assemblies from types in the assembly, upgrade databases, install security
code groups, generate cache files, etc.

I'll let you know what I find out from MSFT.

Dave

Nov 16 '05 #23
> I don't know about button dialogs, but for checkboxes at least, you set
the property name of the checkbox, and use the same name for the
condition of the action.
If you could point me at an example, this is probably all that I need.

I have not yet found an example that illustrates the connection between the
dialog boxes and the custom action that I have.

(My GUESS it that it is trivial and obvious after you see it once.)

--
-- Thom Little -- www.tlaNET.net -- Thom Little Associates, Ltd.
--

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Thom Little <th**@tlanet.net> wrote:
I guess I was mumbling.

I tried to say that I already did everything that you suggested and it works like a champ.

The question I have is how can I make the execution conditional based on a standard two-button dialog? Put another way ... How do I connect a
two-button dialog to a custom class?


Oh, I see. Sorry.

I don't know about button dialogs, but for checkboxes at least, you set
the property name of the checkbox, and use the same name for the
condition of the action. I'll have a look into buttons, if you like.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Nov 16 '05 #24
Dave <no****************@wi.rr.com> wrote:
The means that I cannot use auto-uninstall/install for my app - too many
things will not work correctly if the wrong assembly is loaded during
installation. We do major things at install time, like generate dynamic
assemblies from types in the assembly, upgrade databases, install security
code groups, generate cache files, etc.


Could you fix it by putting the version number in the *name* of the
assembly containing install actions? Bit of a pain to say the least,
but it might work...

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #25
Thom Little <th**@tlanet.net> wrote:
I don't know about button dialogs, but for checkboxes at least, you set
the property name of the checkbox, and use the same name for the
condition of the action.


If you could point me at an example, this is probably all that I need.

I have not yet found an example that illustrates the connection between the
dialog boxes and the custom action that I have.

(My GUESS it that it is trivial and obvious after you see it once.)


It's pretty simple. When you say "two button dialog" do you mean two
*radio* buttons?

If so, go to the property page for the dialog (where you set the text
etc) and set the ButtonProperty to, say, WHICH_OPTION_IS_SELECTED.

Then for the custom action, set the Condition property to something
like

WHICH_OPTION_IS_SELECTED="First value"

if you only want the action to fire if the first value was selected
(where "First value" here is the value of the radio button - keep the
quotes).

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #26
Maybe you'd find the Windows Installer XML (WiX) toolset useful:

http://sourceforge.net/projects/wix/

From the SourceForge page:

"The Windows Installer XML (WiX) is a toolset that builds Windows
installation packages from XML source code. The toolset supports a command
line environment that developers may integrate into their build processes to
build MSI and MSM setup packages."

This is a Microsoft released project that's been made available via
SourceForge; a blog detailing more information can be found here:
http://blogs.msdn.com/robmen/category/4625.aspx
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
<"Steve McLellan" <sjm.NOSPAM AT fixerlabs DOT com>> wrote:
All agreed with... presumably all this stuff's possible using ORCA, but I can't seem to justify spending time on stuff that's so seemingly trivial. There are loads of MSI authoring tools out there but they all seem either a) massively expensive or b) limited to what VS.NET can do or just slightly
more.

What might be nice is if some people that are good at MSI authoring got
together to make some kind of pluggable project so that actions like the
things you're looking for can be added as people need them - it seems to me that the whole thing's basically like writing a database front end where you could expect to slap on a new form and a bit of SQL for it to run. Maybe
there's even money to be made in them thar hills.

It's especially frustrating that Microsoft don't really seem to care about what is one of the most important parts of any piece of software (at least as far as an end user's concerned). There're some extremely simple things I need to do but just don't have the time to learn how to do it.


Yup. To be honest, I'd be perfectly happy with a reference manual and a
big text file to edit, with a command line tool to build the whole lot
together into an MSI file. So long as the error messages are
intelligible and the documentation is good, I don't *need* wizards, and
frankly they end up making things harder a lot of the time.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Nov 16 '05 #27
Got it. It is working.

Thank you for the help.

--
-- Thom Little -- www.tlaNET.net -- Thom Little Associates, Ltd.
--

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Thom Little <th**@tlanet.net> wrote:
I don't know about button dialogs, but for checkboxes at least, you set the property name of the checkbox, and use the same name for the
condition of the action.


If you could point me at an example, this is probably all that I need.

I have not yet found an example that illustrates the connection between the dialog boxes and the custom action that I have.

(My GUESS it that it is trivial and obvious after you see it once.)


It's pretty simple. When you say "two button dialog" do you mean two
*radio* buttons?

If so, go to the property page for the dialog (where you set the text
etc) and set the ButtonProperty to, say, WHICH_OPTION_IS_SELECTED.

Then for the custom action, set the Condition property to something
like

WHICH_OPTION_IS_SELECTED="First value"

if you only want the action to fire if the first value was selected
(where "First value" here is the value of the radio button - keep the
quotes).

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Nov 16 '05 #28
Ed Courtenay <re*****************************@edcourtenay.co.uk > wrote:
Maybe you'd find the Windows Installer XML (WiX) toolset useful:

http://sourceforge.net/projects/wix/

From the SourceForge page:

"The Windows Installer XML (WiX) is a toolset that builds Windows
installation packages from XML source code. The toolset supports a command
line environment that developers may integrate into their build processes to
build MSI and MSM setup packages."

This is a Microsoft released project that's been made available via
SourceForge; a blog detailing more information can be found here:
http://blogs.msdn.com/robmen/category/4625.aspx


Aha - great, thanks very much. I'd heard about WiX on Slashdot, but
hadn't investigated what it actually was...

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #29
<snip>
I've solved it in a pretty foul way in the end, but it works: the
installer will have the name of the product as its main window title. I
just search for any msiexec.exe processes with that main window title,
and wait for them to exit. Nasty, but it seems to work.

Sometimes nasty is about the only way to get it done in a reasonable period
of time.
Cheers for your ideas though.

Thanks.

Do you use custom actions in your installed assembly? If you do, and if you
use auto-uninstall when doing an upgrade to a newer version, then I ran into
a nasty windows installer bug today that might affect you. If you don't then
I wont bore you with the details.

Dave
Nov 16 '05 #30

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Ed Courtenay <re*****************************@edcourtenay.co.uk > wrote:
Maybe you'd find the Windows Installer XML (WiX) toolset useful:

http://sourceforge.net/projects/wix/

From the SourceForge page:

"The Windows Installer XML (WiX) is a toolset that builds Windows
installation packages from XML source code. The toolset supports a command line environment that developers may integrate into their build processes to build MSI and MSM setup packages."

This is a Microsoft released project that's been made available via
SourceForge; a blog detailing more information can be found here:
http://blogs.msdn.com/robmen/category/4625.aspx


Aha - great, thanks very much. I'd heard about WiX on Slashdot, but
hadn't investigated what it actually was...

If you do have the time to investigate I'd be curious about what you think
about it. I've tried to stick with the builtin .net wizards but there's
usually some wall that you can't get beyond without digging into it a whole
lot further then I'd really like to (and the documentation is weak). MSI
files and the windows installer are a LOT more complicated then just a bunch
of text files strung together.

Dave
Nov 16 '05 #31
Dave <no****************@wi.rr.com> wrote:
<snip>
I've solved it in a pretty foul way in the end, but it works: the
installer will have the name of the product as its main window title. I
just search for any msiexec.exe processes with that main window title,
and wait for them to exit. Nasty, but it seems to work.


Sometimes nasty is about the only way to get it done in a reasonable period
of time.


True, unfortunately.
Cheers for your ideas though.

Thanks.

Do you use custom actions in your installed assembly? If you do, and if you
use auto-uninstall when doing an upgrade to a newer version, then I ran into
a nasty windows installer bug today that might affect you. If you don't then
I wont bore you with the details.


I use custom actions which are in an assembly on their own, rather than
in anything used by the rest of the application. The only custom action
in the uninstaller is something to remove registry entries - in the
case of an upgrade, it doesn't matter too much whether or not that
happens.

If it's still something I might run into, please let me know!

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #32
Dave <no****************@wi.rr.com> wrote:
If you do have the time to investigate I'd be curious about what you think
about it. I've tried to stick with the builtin .net wizards but there's
usually some wall that you can't get beyond without digging into it a whole
lot further then I'd really like to (and the documentation is weak). MSI
files and the windows installer are a LOT more complicated then just a bunch
of text files strung together.


Well, initial reaction after decompiling my pretty simple installer is
that I'll definitely need a lot more than the WiX documentation in
order to get going. I might try to build up some knowledge with a
"build installer in VS.NET, decompile, add a bit, rinse and repeat"
approach, but that'll only get me so far. Without guidance on what is
not only *allowed* where but what is likely to *work* where, I'm not
sure I'd feel comfortable using WiX. As WiX gets more community
involvement, however, I'm sure the documentation will get better and
better.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #33

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Dave <no****************@wi.rr.com> wrote: Unfortunately finding a parent process is easier said than done - it
would require P/Invoking undocumented methods, which might be different
for different operating systems. Horrible.


No Pinvoke required, just use System.Management...

using System.Management;
.....
int parentPid = GetParentProcess(Process.GetCurrentProcess().Id);
......

static int GetParentProcess(int Id)
{
int parentPid;
using(ManagementObject mo = new ManagementObject("win32_process.handle='"
+ Id.ToString() + "'"))
{
mo.Get();
parentPid = Convert.ToInt32(mo["ParentProcessId"]);
}
return parentPid;
}

Willy.
Nov 16 '05 #34
>
I use custom actions which are in an assembly on their own, rather than
in anything used by the rest of the application. The only custom action
in the uninstaller is something to remove registry entries - in the
case of an upgrade, it doesn't matter too much whether or not that
happens.

If it's still something I might run into, please let me know!

From what I've seen so far (and I'm still investigating) it appears that
windows installer creates a single appdomain and runs all the managed code
within that appdomain. This is normally not an issue, but when doing an
automatic uninstall/install it appears that it never recycles the appdomain.
The consequence is that even though the assembly on disk that contains the
custom action has been replaced with a newer version, the version of the
assembly that windows installer calls into to run the custom action is the
old assembly that should have been deleted and replaced with a newer
version.

I'm hedging by using "appears" etc. because I'm not precisely sure what it's
doing, but it does look like this is what is happening. I added diagnostic
code to the custom installer that dumped the assembly version that was
executing, and the old version number showed up when running the install
custom action.

I consider this to be a *major* flaw in their implementation.

It also implies that if you get the process id at the time your custom
action executes then you may not need to get the process id of the parent -
it may be the same process. I haven't checked that out yet but I will do
that later today. I will write a simple app with a custom installer action
that just dumps out all the appdomain and process related data.

Dave
Nov 16 '05 #35
Dave <no****************@wi.rr.com> wrote:
If it's still something I might run into, please let me know!
From what I've seen so far (and I'm still investigating) it appears that
windows installer creates a single appdomain and runs all the managed code
within that appdomain. This is normally not an issue, but when doing an
automatic uninstall/install it appears that it never recycles the appdomain.
The consequence is that even though the assembly on disk that contains the
custom action has been replaced with a newer version, the version of the
assembly that windows installer calls into to run the custom action is the
old assembly that should have been deleted and replaced with a newer
version.
Interesting. I'd hope for the old assembly to be used for uninstall and
the new one for install. I'll investigate myself and let you know
whether I see the same effect. I'll let you know - and thanks for the
heads-up.
I consider this to be a *major* flaw in their implementation.

It also implies that if you get the process id at the time your custom
action executes then you may not need to get the process id of the parent -
it may be the same process.


It's not, unfortunately - I assumed it would be, and ran into
problems...

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #36
Willy Denoyette [MVP] <wi*************@pandora.be> wrote:
No Pinvoke required, just use System.Management...


<snip>

Ah, lovely thanks - but what platforms will that work on? I suspect
I'll stick with the grotty hack for the moment, but I'll keep that
snippet for a time when I really, really need the parent process :)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #37
Runs on me, XP, W2K, W2K3 out of the box.
Win98se and NT4 needs the WMI core redistributable installed.

Willy.

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Willy Denoyette [MVP] <wi*************@pandora.be> wrote:
No Pinvoke required, just use System.Management...


<snip>

Ah, lovely thanks - but what platforms will that work on? I suspect
I'll stick with the grotty hack for the moment, but I'll keep that
snippet for a time when I really, really need the parent process :)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Nov 16 '05 #38
> Interesting. I'd hope for the old assembly to be used for uninstall and
the new one for install. I'll investigate myself and let you know
whether I see the same effect. I'll let you know - and thanks for the
heads-up.


I did some more checking today and confirmed the problem; I opened an
incident with MSFT about this. They may already be aware of the problem, and
I may have given them more credit then they deserve - the problem may be
much dumber then my hypothesis :-). I just read on another newsgroup (where
I posted a query) that they will only load a DLL once, so it may not even be
related to appdomain recycling.

The means that I cannot use auto-uninstall/install for my app - too many
things will not work correctly if the wrong assembly is loaded during
installation. We do major things at install time, like generate dynamic
assemblies from types in the assembly, upgrade databases, install security
code groups, generate cache files, etc.

I'll let you know what I find out from MSFT.

Dave

Nov 16 '05 #39
Dave <no****************@wi.rr.com> wrote:
The means that I cannot use auto-uninstall/install for my app - too many
things will not work correctly if the wrong assembly is loaded during
installation. We do major things at install time, like generate dynamic
assemblies from types in the assembly, upgrade databases, install security
code groups, generate cache files, etc.


Could you fix it by putting the version number in the *name* of the
assembly containing install actions? Bit of a pain to say the least,
but it might work...

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #40
The means that I cannot use auto-uninstall/install for my app - too many
things will not work correctly if the wrong assembly is loaded during
installation. We do major things at install time, like generate dynamic
assemblies from types in the assembly, upgrade databases, install security code groups, generate cache files, etc.


Could you fix it by putting the version number in the *name* of the
assembly containing install actions? Bit of a pain to say the least,
but it might work...

Yah, that would definitely be a pain all right. It would probably work
technically but I think it would cause more problems then it would cure.

We'd have to change the name of the assembly for every release build. I use
an fully automated build system, so I'd need to rewrite my build program to
automatically calculate an assembly name based on the version, and then
modify the project file configuration so that not only would that assembly
name change, but all assemblies that reference it would also need to change
as well as all custom actions that refer to that assembly. And then update
all the documentation that contains the name of the assembly. And then try
to explain why we are doing this to everyone....technical people, salesmen,
and customers.

I think I'll wait for MSFT to fix this :-)

Cheers,
Dave
Nov 16 '05 #41
Dave <no****************@wi.rr.com> wrote:
Yah, that would definitely be a pain all right. It would probably work
technically but I think it would cause more problems then it would cure.

We'd have to change the name of the assembly for every release build. I use
an fully automated build system, so I'd need to rewrite my build program to
automatically calculate an assembly name based on the version, and then
modify the project file configuration so that not only would that assembly
name change, but all assemblies that reference it would also need to change
as well as all custom actions that refer to that assembly. And then update
all the documentation that contains the name of the assembly. And then try
to explain why we are doing this to everyone....technical people, salesmen,
and customers.


Gosh - how much stuff do you have going on in that assembly? Is it an
assembly which is used for other things than installation? For our
installation, we've got an assembly which contains installation actions
and *nothing* else - so there's no need to really document it etc, and
nothing references it.

Use NAnt to build that one assembly, with appropriate properties, and
I'd think you'd be done.

I agree it's still a pain though - and if your setup is somewhat
different to ours, I can understand your reluctance :)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #42
>
Gosh - how much stuff do you have going on in that assembly? Is it an
assembly which is used for other things than installation? For our
installation, we've got an assembly which contains installation actions
and *nothing* else - so there's no need to really document it etc, and
nothing references it.
It's pretty complicated. Perhaps in retrospect I should have put it in its
own assembly but at the time it made sense to put the code that called
private/internal methods in the same assembly. It also started as something
small and simple that grew over time (evolution is never pretty). The
assembly that is called by the custom action is actually the web service
assembly. All the types that the client application uses are defined in this
assembly (exported to the client side via a proxy dll), and the
installation/upgrade process directly accesses these classes as well as
calling database code. The custom action does a lot more then just database
upgrades, but that is one of the major chores.

I could move the functionality into a separate assembly but it would be a
PITA. On a new project I would start with that.

Use NAnt to build that one assembly, with appropriate properties, and
I'd think you'd be done.
My build program uses the DevStudio automation object to drive the build
process. What I like about that is that I do not have to worry about
dependencies, build order, etc. as the solution itself handles all that.
Anyone can change whatever they like in the solution (new projects,
refactoring, etc) and the build program does not need to change at all
(usually). I suppose I'll have to port over to MSBuild someday...


I agree it's still a pain though - and if your setup is somewhat
different to ours, I can understand your reluctance :)

Yah, it's pretty different :-)


Nov 16 '05 #43
Dave <no****************@wi.rr.com> wrote:
Gosh - how much stuff do you have going on in that assembly? Is it an
assembly which is used for other things than installation? For our
installation, we've got an assembly which contains installation actions
and *nothing* else - so there's no need to really document it etc, and
nothing references it.
It's pretty complicated. Perhaps in retrospect I should have put it in its
own assembly but at the time it made sense to put the code that called
private/internal methods in the same assembly. It also started as something
small and simple that grew over time (evolution is never pretty).


Tell me about it :)
The assembly that is called by the custom action is actually the web service
assembly. All the types that the client application uses are defined in this
assembly (exported to the client side via a proxy dll), and the
installation/upgrade process directly accesses these classes as well as
calling database code. The custom action does a lot more then just database
upgrades, but that is one of the major chores.
Right.
I could move the functionality into a separate assembly but it would be a
PITA. On a new project I would start with that.


:)
Use NAnt to build that one assembly, with appropriate properties, and
I'd think you'd be done.


My build program uses the DevStudio automation object to drive the build
process. What I like about that is that I do not have to worry about
dependencies, build order, etc. as the solution itself handles all that.
Anyone can change whatever they like in the solution (new projects,
refactoring, etc) and the build program does not need to change at all
(usually). I suppose I'll have to port over to MSBuild someday...


I'm sure there'll be an element of automation for that. I'm rather
looking forward to MSBuild myself.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #44

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

0
by: SPE - Stani's Python Editor | last post by:
Thanks to Jose Galvez, there is a now a working python installer for python2.4 SPE 0.7.5.b now features a remote, encrypted and embedded python debugger of Nir Aides. Stani Spe is a free...
49
by: Thom Little | last post by:
I developed a C# application and a windows installer application that properly installs the C# application on a new machine. After the C# application is installed I would like to automatically...
2
by: ashishjainism | last post by:
I am unable to install my windows service and the installutil is throwing the following error: Running a transacted installation. Beginning the Install phase of the installation. See the...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.