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.
-- 43 5253
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
> 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
> > 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.
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
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
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
"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.
> 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.
> 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
> 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.
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
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
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
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
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
> 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
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
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
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
<"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
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
> 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
> 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
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
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
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
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
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
<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
"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
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
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
"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.
> 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
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
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
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
> 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
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 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
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
> 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 :-)
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 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
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...
|
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...
|
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...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
| |