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!
Like Philipp, I just noticed that the new simplified 2013 build templates still don't provide an obvious way to prevent a gated checkin build from appending "**NO_CI**" to the checkin comment, preventing subsequent continuous integration or rolling builds from running.
I had a look around and discovered that rather than the old SyncWorkspace activity, the new TfGetSources activity looks like the right place to go to:
I was slightly confused, as reviewing the current class documentation doesn't list the property. And it turns out that indeed for TFS 2013 RTM, this property didn't exist (I found this out the hard way – a workflow that references that property will fail when run on such an environment).
Comparing the two C:\Program Files\Microsoft Team Foundation Server 12.0\Tools\Microsoft.TeamFoundation.Build.Activities.dll files (from two different machines) in Reflector reveals the following:
2013 RTM (File version 12.0.21005.1)
2013 Update 2 (File version 12.0.30324.0)
A useful change introduced in Update 2.