Debug delopment story

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Debug delopment story

Phill Hogland
I created a debug build of wix in my git branch.  I then modified my project tree to use this debug build.  This is on my development machine, and I generally avoid running any setup on my development machine.  (Maybe you will advise differently?)

I moved the test project's output files to a test pc, which is not remotely accessible by my dev system.  However the test project includes my mba, which immediately causes the bundle to die without displaying the UX.  Verbose log is sparse on info.  I assume due to some strong name issue.  I read the stuff about creating a private official 'Release' build, but trying to create a debug build

Any thoughts on how I should go at creating and testing a 'debug' build?  (I'm guessing that I needs to simplify, simplify.)
Reply | Threaded
Open this post in threaded view
|

Re: [SPAM] Debug delopment story

SeanHall
I recommend testing on a VM where you can use snapshots and easily copy files to.  You can run the same sn.exe commands on the VM that the OneTimeWixBuildInitialization.proj does to get around the strong naming issues.

An "official" build doesn't have to be Release, you can build an "official" debug build.

For strong naming and BootstrapperCore.dll, you might be interested in this thread: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Building-MBA-from-local-build-td7592887.html

On Sat, Nov 15, 2014 at 1:55 PM, Phill Hogland <[hidden email]> wrote:
I created a debug build of wix in my git branch.  I then modified my project
tree to use this debug build.  This is on my development machine, and I
generally avoid running any setup on my development machine.  (Maybe you
will advise differently?)

I moved the test project's output files to a test pc, which is not remotely
accessible by my dev system.  However the test project includes my mba,
which immediately causes the bundle to die without displaying the UX.
Verbose log is sparse on info.  I assume due to some strong name issue.  I
read the stuff about creating a private official 'Release' build, but trying
to create a debug build

Any thoughts on how I should go at creating and testing a 'debug' build?
(I'm guessing that I needs to simplify, simplify.)



--
View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Debug-delopment-story-tp7597968.html
Sent from the wix-devs mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs


------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: [SPAM] Debug delopment story

Phill Hogland
Thanks for the info.  I recall reading that other thread at the time.  I also use VMs and your comments will be helpful.  Since the 4592 issue is a bit complex to setup, I happen to have a none-VM test scenario ready to go.  But I also have a VM server and working to install the various products there also.

I appreciate the information.  Also since this issue is in a wix ca, I added a DebugBreak to the CA, compiled as debug, and then imported that msi into a release build of the bundle, etc.  Just finished building, but should work.
Reply | Threaded
Open this post in threaded view
|

Re: [SPAM] Debug delopment story

Phill Hogland
In reply to this post by SeanHall
So in general do you create your git clone in the VM and do the development on the VM?  Maybe that is the concept that I am missing.
Reply | Threaded
Open this post in threaded view
|

Re: [SPAM] Re: [SPAM] Debug delopment story

SeanHall
No, I do all development and building on my dev machine.  Then I setup a VM for the environment I need to test, and create a snapshot.  Then I copy the MSI/bundle from the dev machine to the VM and test it out, reverting back to the snapshot as necessary.

On Sat, Nov 15, 2014 at 3:09 PM, Phill Hogland <[hidden email]> wrote:
So in general do you create your git clone in the VM and do the development
on the VM?  Maybe that is the concept that I am missing.



--
View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Debug-delopment-story-tp7597968p7597971.html
Sent from the wix-devs mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs


------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: [SPAM] Re: [SPAM] Debug delopment story

Bob Arnson-6
On 15-Nov-14 16:18, Sean Hall wrote:
> No, I do all development and building on my dev machine.  Then I setup
> a VM for the environment I need to test, and create a snapshot.  Then
> I copy the MSI/bundle from the dev machine to the VM and test it out,
> reverting back to the snapshot as necessary.
Another approach, depending on what you're doing, is to use stock
bundles/packages that are safe to use on a real machine. Remote
debugging also works.

--
sig://boB
http://joyofsetup.com/

------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: [SPAM] Re: [SPAM] Debug delopment story

Phill Hogland
Thanks.  I just got to the point in trying the OFFICAL_WIX_BUILD debug build approach, where it correctly informed me that I don't have all versions of VS installed.  And since I have had enough issues with VS2013 and VS2010 behaving, and we are in a critical phase of release, I won't be going down this path any further for now.

The bundle/package which I am trying to debug the wix ca is very stable <smile/>, if I do say so myself, and only a few days away from a release deadline.  So taking that approach and swallowing my 'don't run tests on the dev machine' self imposed rule, seems to be a better alternative.

And yes I need to get these network access issues figured out so I can do remote debugging.  The dev is in a domain and needs to be to access build resources.  The VM server and VMs are not in that domain and VS wanted both systems using a common context.  (But I need to dig deeper into remote debugging.)
Reply | Threaded
Open this post in threaded view
|

Re: [SPAM] Re: [SPAM] Re: [SPAM] Debug delopment story

Hoover, Jacob
Is your ba a custom managed ba? Is your ca managed code?

I've never had to do anything on my test vm's other than run the bundle/package, but I use WixStdBA and I don't use any managed CA's.

> On Nov 15, 2014, at 4:54 PM, "Phill Hogland" <[hidden email]> wrote:
>
> Thanks.  I just got to the point in trying the OFFICAL_WIX_BUILD debug build
> approach, where it correctly informed me that I don't have all versions of
> VS installed.  And since I have had enough issues with VS2013 and VS2010
> behaving, and we are in a critical phase of release, I won't be going down
> this path any further for now.
>
> The bundle/package which I am trying to debug the wix ca is very stable
> <smile/>, if I do say so myself, and only a few days away from a release
> deadline.  So taking that approach and swallowing my 'don't run tests on the
> dev machine' self imposed rule, seems to be a better alternative.
>
> And yes I need to get these network access issues figured out so I can do
> remote debugging.  The dev is in a domain and needs to be to access build
> resources.  The VM server and VMs are not in that domain and VS wanted both
> systems using a common context.  (But I need to dig deeper into remote
> debugging.)
>
>
>
> --
> View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Debug-delopment-story-tp7597968p7597974.html
> Sent from the wix-devs mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
> http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
> _______________________________________________
> WiX-devs mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-devs

------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: [SPAM] Re: [SPAM] Re: [SPAM] Debug delopment story

Phill Hogland
The CA is WixRegisterRestartResources (C++), in WixUtilExtension.  My product uses a WPF mba, so that is what I was using yesterday.  It has been nearly a year since I switched from using WixStdBA (and also developed several C++ CAs) to creating all my projects around a mba.  But today I plan to take a step back, simplify , and write a test setup using WixStdBA.  I have not done anything with managed CAs either as I prefer C++.   C# is still a challenge for me, especially as it relates to debugging.
Reply | Threaded
Open this post in threaded view
|

Re: [SPAM] Re: [SPAM] Re: [SPAM] Debug delopment story

Phill Hogland
I have a simple MSI package project, using WixUtilExtension, which includes the following line:
    <util:RestartResource ProcessName="RmStreaming.exe"/>

This process is running and was launched by a service, which is the scenario which causes the problem.

Originally I compiled the msi against the 3.9 RTM and validated that when it installs it hits the error, and causes the setup to rollback.  For convenience I am using a simple bundle with a WixStdBA.

I then build the wix source as a debug build, and compile both the msi and the bundle against the wix debug build tree.  (I also extracted the wixca binary and compared the file properties with the wixca.dll in the debug\x86 folder and they seem to be identical size.)

But when I run the setup, having set MsiBreak to "WixRegisterRestartResources", it prompts me to attach to the thread but does not allow any breakpoint to be set in RestartManager.cpp.  The symbol manager has the path to the pbd file, and I even included the pdb file in the binary table, but I can never step into the CA.  Yet the CA runs and hits the problem and then rolls back the setup.  So it is like it is running some other version of the dll.  

I am doing this work on a Win 7 x64, with VS2010 and VS2013 (using VS2013).  The thread that I get prompted to attach to is x86.  (I also tried on Win 8 with windbg installed as the default debugger.)

It has been several months ago that I developed several C++ CAs for my project tree.  As I recall it was a simple mater to attach to the CA, set break points and step through the code (even on a remote test system).   I'm not sure what the difference is here.  I think one difference is that in that situation I would open the project in VS and build it with the IDE.  Here I am building the wix build with the MSBuild scripts.
Reply | Threaded
Open this post in threaded view
|

Re: [SPAM] Re: [SPAM] Re: [SPAM] Debug delopment story

Phill Hogland
I have continued to work on this issue every chance I get.  I have tried many approaches but have not found any way to attach a debugger that actually hits my break point in RestartManager.cpp.  (In this case I build a wix debug build, and on same system I compile and run a simple msi with a WixstdBA bundle.  Whether I have 1) a message box in WixRegisterRestartResources (immediate CA), or 2) a DebugBreak(), or 3) pepper the called functions in rmutil.cpp RmuAddProcessesByName and RmuAddProcessById with LogStringLine(REPORT_STANDARD,.....
In all of above cases, when I compile wix, then compile the test msi, the msi runs, hits the 4592 problem and failed posting the following log messages, but without hitting my breakpoint or additional log messages.
Action start 15:24:53: WixRegisterRestartResources.
MSI (s) (20!74) [15:24:53:839]: Note: 1: 2711 2:  
WixRegisterRestartResources:  Entering WixRegisterRestartResources in C:\Windows\Installer\MSIA358.tmp, version 3.10.1115.0
WixRegisterRestartResources:  Registering process name RmStreaming.exe with the Restart Manager.
WixRegisterRestartResources:  Error 0x80070005: Failed to register the process name with the Restart Manager session.
CustomAction WixRegisterRestartResources returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
Action ended 15:24:53: WixRegisterRestartResources. Return value 3.
Action ended 15:24:53: INSTALL. Return value 3.

The msi build log shows that candle and light are using paths to the WixUtilExtension.dll in the debug build which I modified, but the project never hits those changes.

Attempts to use MsiBreak result in attaching a debugger, and even though symbols are loaded the breakpoints are never activated.  It seems like this should be a simple change to make as Rob suggested in the meeting, but if I cannot figure out howto debug the code or use log messages, I do not have confidence that I can make the change.  I have previously step into my own C++ CAs, but I am having difficulty understanding how to build the wix source so that I can step through it.

Another side issue is that I can add the wixca and UtilExtension\wixext projects to my solution and build them in the VS IDE, but I cannot add the UtilExtension\wixlib to my Solution as VS says it has an invalid GUID format.

Also I extracted the code related to  RmuAddProcessesByName into a console app and stepped through that code (in the same scenario that causes a setup to fail) without observing any problem.  There are two instances to the tray app running, one under a service account, and both pids are detected and returned in the array, implying that the failure is downstream.

I don't want to fill the forum with noise but I thought I would provide some update if anyone has any suggestions.
Reply | Threaded
Open this post in threaded view
|

Re: [SPAM] Re: [SPAM] Re: [SPAM] Re: [SPAM] Debug delopment story

Hoover, Jacob
Are you building your bundle via the command line/msbuild, or are you using Visual Studio?  In your test bundle, are you force redirecting the build to your wix build (instead of any installed version of WiX)?
Ex: In your MSI WixProj and your bundle WixProj.

    <WixToolPath>Z:\$(VersionMajorMinor)\wix3\build\ship\x86\</WixToolPath>
    <WixTargetsPath>$(WixToolPath)Wix.targets</WixTargetsPath>
    <WixTasksPath>$(WixToolPath)wixtasks.dll</WixTasksPath>
    <WixExtDir>$(WixToolPath)</WixExtDir>

In your MSI project, is the reference to the CA pointing to your build? (You could also use Orca or similar to just manually replace the CA DLL in the MSI.) Is a bundle required to reproduce the issue?

I always build via MSBuild, and I am able to generate a custom WixStdBA and attach to it.  


-----Original Message-----
From: Phill Hogland [mailto:[hidden email]]
Sent: Wednesday, November 19, 2014 4:34 PM
To: [hidden email]
Subject: [WiX-devs] [SPAM] Re: [SPAM] Re: [SPAM] Re: [SPAM] Debug delopment story

I have continued to work on this issue every chance I get.  I have tried many approaches but have not found any way to attach a debugger that actually hits my break point in RestartManager.cpp.  (In this case I build a wix debug build, and on same system I compile and run a simple msi with a WixstdBA bundle.  Whether I have 1) a message box in WixRegisterRestartResources (immediate CA), or 2) a DebugBreak(), or 3) pepper the called functions in rmutil.cpp RmuAddProcessesByName and RmuAddProcessById with LogStringLine(REPORT_STANDARD,.....
In all of above cases, when I compile wix, then compile the test msi, the msi runs, hits the 4592 problem and failed posting the following log messages, but without hitting my breakpoint or additional log messages.
Action start 15:24:53: WixRegisterRestartResources.
MSI (s) (20!74) [15:24:53:839]: Note: 1: 2711 2:  
WixRegisterRestartResources:  Entering WixRegisterRestartResources in C:\Windows\Installer\MSIA358.tmp, version 3.10.1115.0
WixRegisterRestartResources:  Registering process name RmStreaming.exe with the Restart Manager.
WixRegisterRestartResources:  Error 0x80070005: Failed to register the process name with the Restart Manager session.
CustomAction WixRegisterRestartResources returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox) Action ended 15:24:53: WixRegisterRestartResources. Return value 3.
Action ended 15:24:53: INSTALL. Return value 3.

The msi build log shows that candle and light are using paths to the WixUtilExtension.dll in the debug build which I modified, but the project never hits those changes.

Attempts to use MsiBreak result in attaching a debugger, and even though symbols are loaded the breakpoints are never activated.  It seems like this should be a simple change to make as Rob suggested in the meeting, but if I cannot figure out howto debug the code or use log messages, I do not have confidence that I can make the change.  I have previously step into my own
C++ CAs, but I am having difficulty understanding how to build the wix
source so that I can step through it.

Another side issue is that I can add the wixca and UtilExtension\wixext projects to my solution and build them in the VS IDE, but I cannot add the UtilExtension\wixlib to my Solution as VS says it has an invalid GUID format.

Also I extracted the code related to  RmuAddProcessesByName into a console app and stepped through that code (in the same scenario that causes a setup to fail) without observing any problem.  There are two instances to the tray app running, one under a service account, and both pids are detected and returned in the array, implying that the failure is downstream.

I don't want to fill the forum with noise but I thought I would provide some update if anyone has any suggestions.




--
View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Debug-delopment-story-tp7597968p7598122.html
Sent from the wix-devs mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: [SPAM] Re: [SPAM] Re: [SPAM] Re: [SPAM] Debug delopment story

Bob Arnson-6
In reply to this post by Phill Hogland
First thing to try: Verify the .msi is being built with your changes.
Stick a string of asterisks in the code that you can search for.

On 19-Nov-14 17:33, Phill Hogland wrote:

> I have continued to work on this issue every chance I get.  I have tried many
> approaches but have not found any way to attach a debugger that actually
> hits my break point in RestartManager.cpp.  (In this case I build a wix
> debug build, and on same system I compile and run a simple msi with a
> WixstdBA bundle.  Whether I have 1) a message box in
> WixRegisterRestartResources (immediate CA), or 2) a DebugBreak(), or 3)
> pepper the called functions in rmutil.cpp RmuAddProcessesByName and
> RmuAddProcessById with LogStringLine(REPORT_STANDARD,.....
> In all of above cases, when I compile wix, then compile the test msi, the
> msi runs, hits the 4592 problem and failed posting the following log
> messages, but without hitting my breakpoint or additional log messages.
> Action start 15:24:53: WixRegisterRestartResources.
> MSI (s) (20!74) [15:24:53:839]: Note: 1: 2711 2:
> WixRegisterRestartResources:  Entering WixRegisterRestartResources in
> C:\Windows\Installer\MSIA358.tmp, version 3.10.1115.0
> WixRegisterRestartResources:  Registering process name RmStreaming.exe with
> the Restart Manager.
> WixRegisterRestartResources:  Error 0x80070005: Failed to register the
> process name with the Restart Manager session.
> CustomAction WixRegisterRestartResources returned actual error code 1603
> (note this may not be 100% accurate if translation happened inside sandbox)
> Action ended 15:24:53: WixRegisterRestartResources. Return value 3.
> Action ended 15:24:53: INSTALL. Return value 3.
>
> The msi build log shows that candle and light are using paths to the
> WixUtilExtension.dll in the debug build which I modified, but the project
> never hits those changes.
>
> Attempts to use MsiBreak result in attaching a debugger, and even though
> symbols are loaded the breakpoints are never activated.  It seems like this
> should be a simple change to make as Rob suggested in the meeting, but if I
> cannot figure out howto debug the code or use log messages, I do not have
> confidence that I can make the change.  I have previously step into my own
> C++ CAs, but I am having difficulty understanding how to build the wix
> source so that I can step through it.
>
> Another side issue is that I can add the wixca and UtilExtension\wixext
> projects to my solution and build them in the VS IDE, but I cannot add the
> UtilExtension\wixlib to my Solution as VS says it has an invalid GUID
> format.
>
> Also I extracted the code related to  RmuAddProcessesByName into a console
> app and stepped through that code (in the same scenario that causes a setup
> to fail) without observing any problem.  There are two instances to the tray
> app running, one under a service account, and both pids are detected and
> returned in the array, implying that the failure is downstream.
>
> I don't want to fill the forum with noise but I thought I would provide some
> update if anyone has any suggestions.
>
>
>
>
> --
> View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Debug-delopment-story-tp7597968p7598122.html
> Sent from the wix-devs mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
> _______________________________________________
> WiX-devs mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-devs
>

--
sig://boB
http://joyofsetup.com/


------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: [SPAM] Re: [SPAM] Re: [SPAM] Re: [SPAM] Debug delopment story

Phill Hogland
Thanks for the comments.  I think I am on the trail of the basic problem.  I have been doing the 'debug' build with the following command (IIRC I got this from and example posted to this list long ago), except that I added the /p:DebugSymbols=true /p:DebugType=full /p:Optimize=false yesterday in my experiments.  (Before building the wix.proj the first time I did OneTimeWixBuildInitialication.proj)                                                 .

call "%_msbuild%" %~dp0\wix3\Wix.proj /p:PlatformToolset=v120_xp  /p:DebugSymbols=true /p:DebugType=full /p:Optimize=false /v:diag /l:FileLogger,Microsoft.Build.Engine;logfile="%~dp0\wix3.log"

So I launched this build a few minutes ago and when I sort the output folder ..\build\debug\x86 it is clear that wixca.dll and many other files have todays date and time from the build just completed, BUT WixUtilExtension.dll is several days old, even though I have made changes to rmutil.cpp and called the above build of the wix.proj.  I have verified, as suggested, that when my msi project is built in the VS IDE, that light.exe is linking to WixUtilExtension.dll in this build path (and not to the RTM also installed on this system).  But since the compile of wix.proj does not update WixUtilExtension.dll this seems to be the problem that needs a solution.  Back to experimenting.
Reply | Threaded
Open this post in threaded view
|

Re: [SPAM] Re: [SPAM] Re: [SPAM] Re: [SPAM] Debug delopment story

Phill Hogland
Also to answer the questions posted:
I build the wixtools using MSBuild script.
I build the test msi and bundle using the VS IDE.  (I also have MSBuild command line scripts for the VS project but have not been using that approach.)
Yes my project is redirected to the wix debug output folder and I have verified in the msi build log that all paths are going to this output folder and not to the RTM install locations.
A bundle is not needed.  The reference to the CA is a reference to WixUtilExtension and util:RestartResourde element.

thanks for the suggestions.
Reply | Threaded
Open this post in threaded view
|

Re: [SPAM] Re: [SPAM] Re: [SPAM] Re: [SPAM] Debug delopment story

Phill Hogland
Apparently this is an ssue with the way I am building a 'debug' build.  I set aside my test msi, and just focused on repeating the wix build process several times and checking the output folder.  After making changes to RestartManager.cpp or rmutil.cpp, whether I build wix.proj or ext.proj (command line call to MSBuild) the wixca.dll in the debug output folder is updated, but the WixUtilExtension.dll (which contains an embedded wixca.dll AIUI, does not get updated.  Here are snippets form one build log.

Compiled a new wixca.dll after changes to RestartManager.cpp.  New wixca.dll in the output folder.

                            Write Tracking Logs:
                            C:\Development\Installs\wix-dev\wix3\build\obj\debug\x86\wixca\wixca.tlog\link.write.1.tlog
                            Read Tracking Logs:
                            C:\Development\Installs\wix-dev\wix3\build\obj\debug\x86\wixca\wixca.tlog\link.read.1.tlog
                            Outputs for C:\DEVELOPMENT\INSTALLS\WIX-DEV\WIX3\BUILD\OBJ\DEBUG\X86\WIXCA\CACLEANUP.OBJ|C:\DEVELOPMENT\INSTALLS\WIX-DEV\WIX3\BUILD\OBJ\DEBUG\X86\WIXCA\CHECKREBOOT.OBJ|C:\DEVELOPMENT\INSTALLS\WIX-DEV\WIX3\BUILD\OBJ\DEBUG\X86\WIXCA\CLOSEAPPS.OBJ|C:\DEVELOPMENT\INSTALLS\WIX-DEV\WIX3\BUILD\OBJ\DEBUG\X86\WIXCA\EXITEARLYWITHSUCCESS.OBJ|C:\DEVELOPMENT\INSTALLS\WIX-DEV\WIX3\BUILD\OBJ\DEBUG\X86\WIXCA\NETSHORTCUTS.OBJ|C:\DEVELOPMENT\INSTALLS\WIX-DEV\WIX3\BUILD\OBJ\DEBUG\X86\WIXCA\OSINFO.OBJ|C:\DEVELOPMENT\INSTALLS\WIX-DEV\WIX3\BUILD\OBJ\DEBUG\X86\WIXCA\PRECOMP.OBJ|C:\DEVELOPMENT\INSTALLS\WIX-DEV\WIX3\BUILD\OBJ\DEBUG\X86\WIXCA\QTEXECCA.OBJ|C:\DEVELOPMENT\INSTALLS\WIX-DEV\WIX3\BUILD\OBJ\DEBUG\X86\WIXCA\REMOVEFOLDERSEX.OBJ|C:\DEVELOPMENT\INSTALLS\WIX-DEV\WIX3\BUILD\OBJ\DEBUG\X86\WIXCA\RESTARTMANAGER.OBJ|C:\DEVELOPMENT\INSTALLS\WIX-DEV\WIX3\BUILD\OBJ\DEBUG\X86\WIXCA\SECUREOBJ.OBJ|C:\DEVELOPMENT\INSTALLS\WIX-DEV\WIX3\BUILD\OBJ\DEBUG\X86\WIXCA\SERVICECONFIG.OBJ|C:\DEVELOPMENT\INSTALLS\WIX-DEV\WIX3\BUILD\OBJ\DEBUG\X86\WIXCA\SHELLEXECCA.OBJ|C:\DEVELOPMENT\INSTALLS\WIX-DEV\WIX3\BUILD\OBJ\DEBUG\X86\WIXCA\TEST.OBJ|C:\DEVELOPMENT\INSTALLS\WIX-DEV\WIX3\BUILD\OBJ\DEBUG\X86\WIXCA\WIXCA.OBJ|C:\DEVELOPMENT\INSTALLS\WIX-DEV\WIX3\BUILD\OBJ\DEBUG\X86\WIXCA\WIXCA.RES|C:\DEVELOPMENT\INSTALLS\WIX-DEV\WIX3\BUILD\OBJ\DEBUG\X86\WIXCA\XMLCONFIG.OBJ|C:\DEVELOPMENT\INSTALLS\WIX-DEV\WIX3\BUILD\OBJ\DEBUG\X86\WIXCA\XMLFILE.OBJ:
                            C:\DEVELOPMENT\INSTALLS\WIX-DEV\WIX3\BUILD\DEBUG\X86\WIXCA.ILK
                            C:\DEVELOPMENT\INSTALLS\WIX-DEV\WIX3\BUILD\DEBUG\X86\WIXCA.DLL
                            C:\DEVELOPMENT\INSTALLS\WIX-DEV\WIX3\BUILD\DEBUG\X86\WIXCA.PDB
                            All outputs are up-to-date.
                          Done executing task "Link".
                          Task "Message"
                            Task Parameter:Text=wixca.vcxproj -> C:\Development\Installs\wix-dev\wix3\build\debug\x86\wixca.dll
                            Task Parameter:Importance=High
                            wixca.vcxproj -> C:\Development\Installs\wix-dev\wix3\build\debug\x86\wixca.dll
                          Done executing task "Message".
                        Done building target "Link" in project "wixca.vcxproj".

from same log as above, UtilExtension is NOT updated in the output folder (so it would still have an old version of wixca.dll)


    Target "_GroupProjectReferencesByParallelization" in file "C:\Development\Installs\wix-dev\wix3\tools\Traversal.targets":
    Done building target "_GroupProjectReferencesByParallelization" in project "util.proj".
    Target "Build" in file "C:\Development\Installs\wix-dev\wix3\tools\Traversal.targets":
      Task "MSBuild"
        Task Parameter:BuildInParallel=False
      Done executing task "MSBuild".
      Task "MSBuild"
        Task Parameter:
            Projects=
                wixext\WixUtilExtension.csproj
                        BuildInParallel=true
                wixlib\UtilExtension.wixproj
                        BuildInParallel=true
        Task Parameter:BuildInParallel=True
        __________________________________________________
        Project "C:\Development\Installs\wix-dev\wix3\src\ext\UtilExtension\util.proj" is building "C:\Development\Installs\wix-dev\wix3\src\ext\UtilExtension\wixext\WixUtilExtension.csproj" (default targets):

        Building with tools version "12.0".
        Target "PackageRestore" skipped. Previously built successfully.
        Target "_CheckForInvalidConfigurationAndPlatform" skipped. Previously built successfully.
        Target "CheckRequiredProperties" skipped. Previously built successfully.
        Target "Build" skipped. Previously built successfully.

        Done building project "WixUtilExtension.csproj".
        __________________________________________________
        Project "C:\Development\Installs\wix-dev\wix3\src\ext\UtilExtension\util.proj" is building "C:\Development\Installs\wix-dev\wix3\src\ext\UtilExtension\wixlib\UtilExtension.wixproj" (default targets):

        Building with tools version "12.0".
        Target "PackageRestore" skipped. Previously built successfully.
        Target "_CheckForInvalidConfigurationAndPlatform" skipped. Previously built successfully.
        Target "_CheckRequiredProperties" skipped. Previously built successfully.
        Target "CheckRequiredProperties" skipped. Previously built successfully.
        Target "Build" skipped. Previously built successfully.

        Done building project "UtilExtension.wixproj".
      Done executing task "MSBuild".
    Done building target "Build" in project "util.proj".

By deleting (or renaming) the output folders, I got both wixca.dll and WixUtilExtension.dll to be updated, but I am still interested in how to reliably build a debug build of wix.