[WiX-users] How to show custom error text on SetupCompleteError dialog when a deferred CA fails.

[Kashif Md.]

Hi,

I have a deferred Custom action that fails in some scenarios. Since this
custom action is responsible for installling some licensing libraries for
my product hence I cannot continue installation if this CA fails.

I want to show a custom error message to the user if this CA has failed the
installation. To capture the failure from this CA I write a registry value
signifying whether the CA was successful or not. But how do read this
registry, set a property based on this CA and then use that property to
show/hide my text on SetupCompleteError dialog.

As soon as CA fails, rollback starts and then it does not execute any
immediate custom actions. I cannot even use a roll back CA because it
cannot set any property.

Can someone please help and let me know if there is a way to do this other
than throwing up a message box to the user?

Thanks,
-kashif
--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] How to supersede a minor update in next patch.

[Kashif Md.]

I created patches as explained further below. All patches contain
MSIPatchSequence table. None of the patches are full file updates, they all
contain file diff from previous target version. I want P3 to
ignore/supersede P2 so that installer eliminates P2 when applying P3.



P1 (v1.0.1) -> Targets RTM (i.e. the major release) -> Provided to all
customers.

P2 (v1.0.2) -> Targets P1 -> Provided to a select set of customers.

P3 (v1.0.3) -> Targets P1 (not P2) -> Expected to be provided to all
customers.



MsiPatchSequence table for all patches looks as below:

PatchFamily = PatchFamilyID

ProductCode=””

Sequence = 1.0.3.1 (for P3), similarly for P2 it is 1.0.2.1 and for
P1 it was 1.0.1.1

Attributes=1



Ideally, I think it all would have worked if P2 was a QFE but it is not. I
cannot change anything in P1 and P2 since they are already released.
Question is what can I do in P3 to ignore P2?


I have tried putting P2 in ListOfPatchGUIDsToReplace but it is ignored
because as per MSDN it only works if P2 did not have MsiPatchSequence
Table.



I need to Ignore P2 because a fix that was contained in P2 is now part of
P3 (which targets P1).

When applying P3 over P2 Error 1328 is encountered because P3 contains file
diff from P1 but when P2 is applied it changes the file and windows
installer can no longer apply the diff contained in P3.



Can someone help me regarding this?



Thanks
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] How to supersede a minor update in next patch.

[Kashif Md.]

Thanks for replying Guys.

@Nir Bar: No it is not possible to have two patches without significant
effort. And also because our updater is not designed that way.

@Mat: Full file patches are too big in size and hence I moved away from
them. Going back to them is not an option.

@Tunney: I've explained above my MsiPatchSequence table contents for all
patches. Can you please explain how it should have looked like for the
scenario to work?

I think there must be some way (EXECPT a) A patch targeting RTM; (b) giving
a full file update) to force remove a patch from patch application sequence.

On Wed, Mar 25, 2015 at 12:38 AM, Tunney, Stephen  wrote:

> If all have supercede set, then patch 1.0.3 would apply to BOTH 1.0.1 AND
> 1.0.2 as long as ProductCodes and UpgradeCodes match up.
>
> -Original Message-
> From: Nir Bar [mailto:nir@panel-sw.com]
> Sent: March-24-15 1:54 PM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] How to supersede a minor update in next patch.
>
> Is it not possible to create two patches to v1.0.3 - one applicable on
> v1.0.1 and the other on v1.0.2?
>
>
>
>
> -
> Nir Bar
> Freelance Developer
> Mail: nir@panel-sw.com
> Web: www.panel-sw.com
>- C++ On Windows, Linux and Embedded Platforms
>- WiX & InstallShield
> --
> View this message in context:
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-to-supersede-a-minor-update-in-next-patch-tp7599690p7599693.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
>
> --
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> --
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] How to supersede a minor update in next patch.

[Kashif Md.]

No, its not uninstallable. Looks like I'm done for :) Thanks for your help
anyway.

On Thu, Mar 26, 2015 at 2:43 AM, Nir Bar  wrote:

> Is the v1.0.2 patch  uninstallable
>   ?
> If yes you can uninstall it in v1.0.3 by setting  MSIPATCHREMOVE
>    to
> the Patch GUID of v1.0.2 (I haven't tried that but I think it should work)
>
>
>
>
> -
> Nir Bar
> Freelance Developer
> Mail: nir@panel-sw.com
> Web: www.panel-sw.com
>- C++ On Windows, Linux and Embedded Platforms
>- WiX & InstallShield
> --
> View this message in context:
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-to-supersede-a-minor-update-in-next-patch-tp7599690p7599706.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
>
> --
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Restart Manager doesn't preserve folders open in Windows Explorer after restart.

[Kashif Md.]

Hi,

For long I have been working with the old files in use dialog in windows
installer. But now after dropping support for Win XP I wanted to explore
the new restart manager functionality.

I read at couple of places that restart manager is used by shell extensions
to restart explorer.exe process. But now when I try restart manager I find
that it merely closes and restarts explorer.exe process without preserving
its state. For example if I have a few folders open and I restart
explorer.exe using RmShutdown followed by RmRestart then none of my folders
open up automatically.

Is there a way to preserve the state of open folders in explorer?

Thanks,
-kashif
--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] how to pass paramters to a C++ DLL CA and get returned values from it.

[Kashif Md.]

Windows installer doesn't let you capture the return value from a custom
action. How did installshield do it? What type of custom action were you
using in IS (I mean the type number)? They must have implemented a wrapper
that would call your function and set the return value in a property.

On Thu, Apr 23, 2015 at 6:56 PM, Tobias S  wrote:

> what about using dark.exe on the IS MSI: Then you should see in plain the
> usage of this C++ DLL and how it is implemented in IS.
>
> --
> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
> Develop your own process in accordance with the BPMN 2 standard
> Learn Process modeling best practices with Bonita BPM through live
> exercises
> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
> event?utm_
> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Restart Manager doesn't preserve folders open in Windows Explorer after restart.

[Kashif Md.]

No one using Restart Manager to close explorer.exe :(

On Wed, Apr 22, 2015 at 8:28 PM, Kashif Md.  wrote:

> Hi,
>
> For long I have been working with the old files in use dialog in windows
> installer. But now after dropping support for Win XP I wanted to explore
> the new restart manager functionality.
>
> I read at couple of places that restart manager is used by shell
> extensions to restart explorer.exe process. But now when I try restart
> manager I find that it merely closes and restarts explorer.exe process
> without preserving its state. For example if I have a few folders open and
> I restart explorer.exe using RmShutdown followed by RmRestart then none of
> my folders open up automatically.
>
> Is there a way to preserve the state of open folders in explorer?
>
> Thanks,
> -kashif
>
>
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] No reboot for locked files during uninstallation.

[Kashif Md.]

I don't think Windows installer does any re-mapping. It just moves the
locked files to config.msi folder. There is nothing specific with installer
infact we can do it ourselves using MoveFileEx.

My take would be that whenever windows installer moves a file it should let
user know of a pending reboot because user machine is now in an
inconsistent state. Think of what will happen when this locked DLL tries to
load another DLL which is now deleted by uninstaller. There will be errors
or even crashes. For applications  files in use dialog works however if
DLLs are loaded in explorer then a reboot becomes necessary. Windows
installer decision to not prompt user to reboot seems like a wrong choice.

On Wed, May 6, 2015 at 12:37 AM, Phil Wilson  wrote:

> Windows Installer goes to a lot of trouble to make sure that you can
> avoid a reboot at uninstall time by re-mapping in-use Dlls etc. In
> general, a running app can continue running after uninstall, and some
> cleanup will occur when the app shuts down, the rest after the next
> reboot. The point is that if Windows Installer can remap the in-use
> Dlls to another location, keep any apps running, and replace the ones
> that were in use (but remapped) and all that's required is deleting a
> bit of non-essential junk at the next reboot then why force a reboot?
> ---
> Phil Wilson
>
>
> On Tue, May 5, 2015 at 9:17 AM, Rob Mensching  wrote:
> > Why do you want to force a restart? Your application is safely gone.
> Those files will be cleaned up whenever the users chooses to restart again.
> >
> > _
> >  Short replies here. Complete answers over there:
> http://www.firegiant.com/
> >
> >
> > -Original Message-
> > From: Akshat Goel [mailto:aksg...@adobe.com]
> > Sent: Tuesday, May 5, 2015 5:03 AM
> > To: wix-users@lists.sourceforge.net
> > Subject: [WiX-users] No reboot for locked files during uninstallation.
> >
> > Hi,
> >
> >
> > Our product installs DLLs as part of installation. Most of the DLLs are
> used by our application but couple of these are also used by other
> processes and applications. When we uninstall the product, our main
> application is closed and DLLs are freed. However, other processes may
> still be running and thus, some DLLs may be locked.
> >
> >
> > During uninstallation, Windows installer copies these files to
> C:\Config.msi. When uninstallation completes, there is no message for
> reboot or cleanup. However MSI log shows the entry  Info 1903. Scheduling
> reboot operation: Deleting file C:\Config.Msi\3f6c9d1.rbf. Must reboot to
> complete operation.
> >
> >
> > My problem is how to show the user that a reboot is required to cleanup
> the files. Currently uninstallation finish screen doesn't show any message
> that a reboot maybe required.
> >
> >
> > I have a sample package which demonstrates the issue, if anyone needs.
> >
> >
> > Thanks & hoping for a reply.
> >
> >
> > Regards,
> >
> > Akshat
> >
> >
> --
> > One dashboard for servers and applications across Physical-Virtual-Cloud
> > Widest out-of-the-box monitoring support with 50+ applications
> > Performance metrics, stats and reports that give you Actionable Insights
> > Deep dive visibility with transaction tracing using APM Insight.
> > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> --
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] How to set Version and Publisher fields in "Installed Updates" on 64 bit machine?

[Kashif Md.]

Hi,

My msp patch is missing Version and Publisher info in "Installed Updates"
window in ARP for 64 bit machines. I've populated all the fields in PCP
correctly but still it doesn't show up. It works fine on 32 bit machines.
My MSI is a 32 bit MSI so that might be one reason why it fails for 64 bit
machine but I couldn't find any info on this on MSDN.

Even some of MS patches are also missing this info on my 64 bit machine.

Issue is exactly same as described at
http://stackoverflow.com/questions/17231864/setting-the-publisher-in-installed-updates-for-a-msp-patch


Does any one has any idea about this?


Thanks and Regards,
-kashif
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[wix-users] (deprecated) Does parent of a companion file always need to be from same feature?

[Kashif Md.]

I’ve been facing issues while updating a few companion files in a windows
installer patch for which size does not change but checksum does change.
I'm not going into details here because I know why bug happened and what
was the core reason.


The problem is that I went to MS paid support and they say that for
companion file logic to work companion and its parent must be in the same
feature. If parent and companion are in two different features then it is
not a supported scenario.


The documentation on MSDN does not say that both files must be from same
feature. They also said that they won't document this on MSDN because
anyone with basic installer knowledge will know it already. I don't
consider myself a beginner and didn't know it.


So I have come to the experts here (some of whom have probably earlier
worked with MS on core installer engine):



 “Is it really mandatory that companion and its parent should always be in
same feature”? How do I take advantage of companion file logic if my
feature does not have any versioned file?



Thanks and Regards,

-kashif
--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users