Our latest discoveries: The command 'ngen update /queue', which is issued at the end of the ngen phase of the installer, causes all my .dll files which have previously been ngened to be described by 'ngen display' as:
C:\Program Files\Resolver One\bin\Controls.dll (StatusPending) (Pri 3) This happens regardless of whether the dll in question has been correctly ngened before. So presumably I am mistaken to interpret the above output to mean that the dll is not ngened, but is merely queued at priority three. However, my application startup time immediately after install is lengthy (1m 30s), which corresponds to the dll files not having been ngened. If I wait three minutes (the time it would take for me to manually ngen the dll files at the command line) then my application startup time is now only 0m 40s. So clearly the dll files ARE being ngened in the background after install, not synchronously during the install itself. Puzzled. Thanks for any ideas. Jonathan Hartley wrote: > Hi people, > > I'm asking for my .dll files to be ngened during install, at priority 0, > which I understand should take place synchronously, while the install > progress bar increments. But I must be doing something wrong because > instead, they get queued for ngen at priority 3. > > To my candle and light commands, I added the option: > > -ext WixNetFxExtension > > > To my wxs file's Wix tag, I added the attribute: > > xmlns:netfx="http://schemas.microsoft.com/wix/NetFxExtension"; > > > In the wxs file, my files look like: > > <File Id='Controls.dll' > Name='Controls.dll' > DiskId='1' > Source='..\bin\Controls.dll'> > <netfx:NativeImage Id="NGenControls.dll" > Priority="0" > Platform="32bit" > /> > </File> > > After install, running 'ngen display' on the installed dll files shows > the following: > > >> ngen display Controls.dll >> >> > Microsoft (R) CLR Native Image Generator - Version 2.0.50727.3053 > > Copyright (c) Microsoft Corporation. All rights reserved. > > > > NGEN Roots: > > > > C:\Program Files\Resolver One\bin\Controls.dll (StatusPending) (Pri 3) > > > > Native Images: > > > > Controls, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null > > Controls, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null > > Controls, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null > > > > Adding LOGVERBOSE=1 to our command line shows the following entries in > our logfile for each .dll file: > > ExecNetFx: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\ngen.exe > install "C:\Program Files\Resolver One\bin\Controls.dll" > ExecNetFx: Microsoft (R) CLR Native Image Generator - Version > 2.0.50727.3053 > ExecNetFx: Copyright (c) Microsoft Corporation. All rights reserved. > ExecNetFx: Installing assembly C:\Program Files\Resolver > One\bin\Controls.dll > ExecNetFx: All compilation targets are up to date. > > > If I copy the ngen command from the logfile above, and run it manually: > > >> C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\ngen.exe install "C:\Program >> Files\Resolver One\bin\Controls.dll" >> > > Then the file is ngen'ed immediately and (as far as I can see) > synchronously. > > Does anyone have any idea what I'm doing wrong that the same command > executed by the msi install doesn't seem to work? > > Changing the <File> tag to request priority 1, 2 or 3 does change the > command visible in the logfile, by adding a "/queue:1" (or 2 or 3) > parameter, and the .dll files are then queued at the requested priority. > So the <File> tag priority attribute does seem to be being recognised > and acted on, except when priority=0. > > Many thanks for any suggestions, > > Jonathan > > -- Jonathan Hartley Made of meat. http://tartley.com tart...@tartley.com +44 7737 062 225 twitter/skype: tartley ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
