Force Run .Net Runtime Optimization Service before boxing about packer-windows HOT 21 CLOSED

I have a hard time justifying being a .net developer sometimes

from packer-windows.

I've seen this myself. According to the article

Important Run these commands immediately before you apply the update. Otherwise, these commands are less effective.

On a computer that is running a 32-bit Windows operating system
%windir%\microsoft.net\framework\v4.0.30319\ngen.exe update /force /queue

On a computer that is running a 64-bit Windows operating system
%windir%\microsoft.net\framework64\v4.0.30319\ngen.exe update /force /queue

This is strange voodoo. How would we even know it's started/finished?

from packer-windows.

IIRC there is a way to do it synchronously, leaving out the /queue argument perhaps. This article covers it a bit more (http://msdn.microsoft.com/en-us/magazine/cc163610.aspx) but the actual tool documentation doesn't indicate anything explicitly about a synchronous operation. (http://msdn.microsoft.com/en-us/library/6t9t5wcf(v=vs.110).aspx)

Worst case scenario, you could write a script that triggers queue with priority 1 and poll it until it completes.

from packer-windows.

Duh yes, take /queue off and it just runs with output.

Microsoft.WSMan.Runtime, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35
    Compiling assembly MSBuild, Version=3.5.0.0, Culture=Neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=amd64 (CLR v2.0.50727) ...
Specify the input as a .EXE for ngen to pick up the config-file
MSBuild, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
    Compiling assembly PresentationBuildTasks, Version=3.0.0.0, Culture=Neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=msil (CLR v2.0.50727) ...

and so on...

from packer-windows.

Yeah -- the only thing I'm questioning is running it "before" updates, seems like you'd want it to run after updates, since they likely update the .Net framework.

from packer-windows.

I agree with you here. Running it at the end of the packer run will spare the poor guy doing the vagrant up, which is where I was seeing the problem.

from packer-windows.

LGTM. Pull Request?

from packer-windows.

Still watching this, Joe. On 2012 R2 it's still running "Windows Modules Installer Worker" (TiWorker.exe) with crazy CPU after ngen exits.

from packer-windows.

Yep, definitely will submit one, but probably won't be this weekend, possibly Monday since I have the day off.

from packer-windows.

FYI my CPU was still at 50% exactly one hour later / 50 minutes after ngen was done. I restarted it and all was quiet again.

from packer-windows.

Windows is so awesome and predictable. 👊

from packer-windows.

👍

from packer-windows.

Come and be a go (golang.org) developer – https://github.com/joefitzgerald/go-plus. It'll feel dirty at first, and then you'll have an epiphany. Requires unlearning OO and then learning to use composition instead of inheritance.

Bonus: output is static binaries and cross compilation is trivial. Windows is a first class citizen.

from packer-windows.

Funny, that project you link to is all Node.js. Also a first class citizen on Windows. 😉

from packer-windows.

Funny, that project you link to is all Node.js. Also a first class citizen on Windows. 😉

from packer-windows.

I agree - the irony is not lost on me!

from packer-windows.

I had no problems running this in a .bat file as part of my windows build - thanks for the tip!

from packer-windows.

This is on my radar, working on it this week likely.

from packer-windows.

Tested this on server 2012R2, seems to work. Spits out a bunch of output to the console to show what it's compiling.

from packer-windows.

What's the current status on this? Is a PR required? Looks like we've already merged one and this can be closed.

from packer-windows.

This should be using the windows-shell provisioner. I was unable to make this work with packer 0.10.2 on Windows Server 2012 R2 until I did. packer always simply hung otherwise. I'd submit a PR, but a lot of other stuff that I won't test (since I don't use vagrant) is bundled in that provisioner step. Someone might want to look into this tho.

from packer-windows.