Yesterday was my last in the office at Eka (formerly MatrixGroup). It was great to catch up with everyone one last time after just over 3 years being on staff. A few final handovers, farewell lunch, attending and presenting at my final Developer meeting and monthly company meeting. I’ll miss working with the people there, but I’d decided it was time to move on. In the meantime, I’m taking a short break. Time to relax, get some kms on the bike, enjoy Adelaide’s beautiful spring weather, one or two jobs around the house and do some family things for the first week of the school holidays. After that I’ll be starting something new – more about that in a couple of weeks time! The photo is from my ride on Tuesday with the Mud, Sweat & Gears blokes heading to Outer Harbour. That turned out to be a handy 93km round trip! I must be doing ok as I pulled up pretty well. It is pretty flat for most of the ride, which probably helped. (Oh yes, it’s also the AFL Grand Final today)
PowerShell has a handy cmdlet named Invoke-WebRequest. I was making use of this in a Script resource as part of a DSC script.
The weird thing was that most of the time it worked, but sometimes the DSC script hung, and as best I could tell, it was within the Script resource that was calling Invoke-WebRequest, but I couldn’t understand why.
Eventually on one particular server, I was able to cause something surprising to happen – calling Invoke-WebRequest caused a modal dialog to appear. The interesting thing was that the server had Internet Explorer Enhanced Security Configuration enabled. Not surprisingly that’s the default for Windows Server.
I posted a question to Stack Overflow and a comment added to the answer made me realise what is actually going on.
I had naively assumed that Invoke-WebRequest is just a nice wrapper around the .NET Framework’s WebClient class, but it turns out it is a bit more than that. It also appears to reference IE-related code.
If you’re curious as to what Invoke-WebRequest actually does, then fire up your favourite IL decompiler and point it at
(that’s the path I found the full assembly at).
While the implementation of Invoke-WebRequest actually uses System.Net.WebRequest, it also creates an instance of the IHTMLDocument2 COM object, and I suspect this is the trigger that causes the IE warning to appear.
So if you just want to hit a web address without requiring all the extra features of IE processing, just call either WebClient or WebRequest directly from PowerShell, or Use Invoke-WebRequest but probably not in a ‘headless’ environment.
First off, run (don’t walk) and go and register for next week’s ADNUG talk.
Great, I’ll see next Wednesday evening!
What? You need more convincing? Ok..
I’ve worked with Ben Laan for a number of years now and I’d have to say he’s probably one of THE best developers I know around the place. He seriously knows his stuff, and is just as comfortable optimising a SQL query on the back-end as he is tweaking CSS layout in the frond-end UI. So I was really pleased when he agreed to come and speak at next week’s Adelaide .NET User Group (ADNUG).
To quote from the presentation summary:
This presentation will review techniques for organising code to meet these goals within an ASP.NET MVC context using RequireJs – a system for dependency management and Qunit – a unit test framework build by the JQuery team.
So now I’ve convinced you, go and register and I’ll see you at there
ADNUG meets monthly on the second Wednesday of the month, at Marcellina Adelaide (273 Hindley St, Adelaide). Pizza from 6pm followed by presentation(s), finishing around 7.30pm
This afternoon I attended a funeral. The church was packed with friends and family, I have to say it was one of the best celebrations of someone’s life that I’ve been privileged to attend.
Yes, there was sadness and grief, but overwhelmingly a sense of joy of a life well lived - a passionate husband, father, and faithful man of God.
In his late 50’s, John was not an old man when he passed away last week, but the impact his life and love for others will continue to be felt for years to come.
Some more PowerShell from me, this time at this week’s meeting of the Adelaide Windows User Group:
If you’re not automating repetitive tasks with PowerShell, you’re probably doing it wrong! In this presentation, after a quick language recap, we’ll look at a number of best practices that will make your scripts even better. We’ll look at tips for reliability, ease of use and making your scripts work just like the built-in cmdlets. To top things off, we’ll also give a brief overview of PowerShell 4.0’s new Desired State Configuration feature.
Yes, it’s similar to the talk I did at the .NET Group last month, but instead of covering hosting PowerShell in your own app, we’ll spend a bit more time looking at DSC.
The group meets this Tuesday August 5th 2014 12-1pm at Microsoft Adelaide, Level 12, Aurora Building, 147 Pirie Street, Adelaide.
RSVP to Pete at [email protected] if you plan on coming. It would be great to see you there!