Remove custom action files .NET after installation
Frank Dzaebel
1) What is the best practice to delete files which are created
through use of a custom action Assembly DLLs?
(Examples are the assembly itself and the InstallState file)
2) Can WFP be disabled for my MSI?
We cannot use Exclude Property in
Visual Studio .NET 2005 Setup Project (i think)
because its a managed ressource/assembly.
The custom action was created like this (C#):
[Walkthrough: Creating a Custom Action]
http://msdn2.microsoft.com/en-us/library/d9k65z2d(VS.80).aspx
I had a little possibility to remove them by a final script,
but if you start the program WFP (i think) will sense that
Files are missing and restore them.
ciao Frank
--
Dipl.Inf. Frank Dzaebel [MCP/MVP C#]
http://Dzaebel.NET
![Richard [Microsoft Windows Installer MVP]'s profile photo](https://lh3.googleusercontent.com/a/default-user=s40-c)
Richard [Microsoft Windows Installer MVP]
My first question would be: why are you writing a .NET custom action?
Most stuff doesn't need it.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>
Legalize Adulthood! <http://blogs.xmission.com/legalize/>
Frank Dzaebel
thanks fo answering.
> My first question would be: why are you writing a .NET custom action?
Because if you already use a C# Project where all
is C#, this is a near way of choice, while
MSDN example also exists for it.
You mean a unmanged custom action would not
cause this problem - may discuss later - first,
if there is a solution in this scenario. Thanks.
Richard [Microsoft Windows Installer MVP]
Frank Dzaebel <po...@franksseite.de> spake the secret code
<1189704602.6...@r29g2000hsg.googlegroups.com> thusly:
>> My first question would be: why are you writing a .NET custom action?
You misunderstand.
Why are you writing a custom action in the first place?
What does it do?
Frank Dzaebel
> Why are you writing a custom action in the first place?
> What does it do?
It should be as independant as possible from what
i really do there - if you take this into account.
I also ask for people in other newsgroups, but
also have a project, where i could use it.
You can use the following scenario:
In my case, i override commit, to call a .NET
exe (invisible) with a special parameter for having
an easy precompiling effect. Normally it would be
slow the very first time.
Phil Wilson
nodes (Install, Rollback, Uninstall, Commit) the installstate file will be
removed. People get this file left behind when they pick and choose, but the
installstate file carries state through all those situations. By adding your
assembly to all those nodes you let the base class methods do the management
work, and make sure that if you override one of those methods that you call
base.<method> first.
2) You wouldn't have any of these issues if you used a C++ custom action Dll
call because you can exclude it, and they don't use installstate files like
those unspeakable installer classes.
It's not WFP that restores missing files, it's Windows Installer health
check.
--
Phil Wilson
[MVP Windows Installer]
"Frank Dzaebel" <tcnt.D...@daimlerchrysler.com> wrote in message
news:1189680222.6...@w3g2000hsg.googlegroups.com...
Frank Dzaebel
Thanks for your reply.
> 1) I think that if you add the installer class custom action to all the
> nodes (Install, Rollback, Uninstall, Commit) the installstate file will be
> removed. People get this file left behind when they pick and choose, but
> the installstate file carries state through all those situations. By
> adding your assembly to all those nodes you let the base class methods do
> the management work, and make sure that if you override one of those
> methods that you call base.<method> first.
I tried that, but the InstallState remains.
But more important is, that also the DLL should be removed.
I think adding to unistall event makes things even worse
(in this case) because i dont need it for uninstall and if
the user will uninstall the DLL now *have* to be there.
Is there an other solution?
> 2) You wouldn't have any of these issues if you used a C++ custom action
> Dll call because you can exclude it, and they don't use installstate files
> like those unspeakable installer classes.
Yes, i mentioned it. So, there seems to be no other way,
and a *managed* "custom action" DLL is not deletable in
your opinion. (?) (one, which one targets Commit event).
> It's not WFP that restores missing files, it's Windows Installer health
> check.
Yes thanks. If you really want to understand, read this ;-)
http://www.installsite.org/pages/en/msifaq/a/1037.htm
Is there a way to supress "WI health check" already
in the installation project? I mean, that would solve
the problem.
"Health check" is also a little performance decreasing
and in our scenario not important.
Phil Wilson
projects because of the implementation. The setup does not call installer
classes directly. It calls a C++ custom action in a Dll that's added to your
setup in the Binary table of the MSI file. This Dll is streamed out of the
Binary table by the built-in functionality of Windows Installer and then
called. It loads a framework version and ramps up managed installer class
objects that get your assembly and use reflection to find and instantiate
your installer classes.
So if you had a plain C++ Dll call, that could be embedded in the MSI file
Binary table and not installed onto the system just like that Dll that loads
up the framework to run your managed code. The installer class
implementation wants your assembly to be at a known location to do its
reflection etc, so it has to be installed.
That's a long way of saying that installer class assemblies can't be run out
of the Binary table like other custom action code can be so that it doesn't
get installed.
Does it really need to be an installer class? I think a managed code
executable can be excluded, and they have the same functionality as
installer classes if you're just running your own code and not using base
class functionality like ServiceInstaller.
--
Phil Wilson
[MVP Windows Installer]
"Frank Dzaebel" <Po...@FranksSeite.de> wrote in message
news:OuTm%23bk9H...@TK2MSFTNGP03.phx.gbl...
Frank Dzaebel
> Managed code custom actions aren't Excludable in Visual
> Studio setup projects because of the implementation.
1) I have found the solution to exclude managed code
custom actions in VS Setup Project. You can simply
put the DLL in a folder and delete it at the end of the
(managed) Commit custom action.
2) Question for "Health Check" preventing of shortcuts. (not answered)
There are a many possibilities. Firstly:
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2051367&SiteID=1
[DISABLEADVTSHORTCUTS Property]
http://msdn2.microsoft.com/en-us/library/aa368297.aspx
Secondly, you can install normal shortcuts, but delete them
at Commit state and recreate will script. Thats, what i choose.
So now, i end up with all managed code in the project
and with excluded managed custom action DLLs and
no InstallState files any more. Thats, what i wanted.
Thanks for talking with me.
Phil Wilson
that can trigger repair. Also any conflict with another installed app can
trigger one, and there are the plain old ways like right-clicking the MSI
file and choosing repair, or going to ARP and using Repair.
--
Phil Wilson
[Microsoft MVP-Windows Installer]
"Frank Dzaebel" <Po...@FranksSeite.de> wrote in message
news:OzhVM9x9...@TK2MSFTNGP02.phx.gbl...
Frank Dzaebel
> You cannot guarantee that a repair will never occur.
> It's not just shortcuts that can trigger repair.
There is no problem.
A repair *should* repair of course. Thats wanted.
> .. like right-clicking the MSI file and choosing repair
as i said, repair *should* repair and the repair does
what it should - no prob here. It would be bad if not.
The only one are shortcuts - look at my
DISABLEADVTSHORTCUTS link - who should
not repair, but i do it the other WI-Version-
independant way.
So the problem for me is now cleanly solved.
Tested on Vista and XP with repair and deinstall.
Christopher Painter
> You cannot guarantee that a repair will never occur. It's not just shortcuts
> that can trigger repair. Also any conflict with another installed app can
> trigger one, and there are the plain old ways like right-clicking the MSI
> file and choosing repair, or going to ARP and using Repair.
Does MsiZip count? :-)