I have seen a few posts recently about other conferences (Adobe Max and Community Server Developer Conference) that made me think hard about how we have positioned the OpenForce conferences this year.  I remember in past years that events like JavaOne developed a reputation for being nothing more than giant sales and marketing event put on by Sun.  This is a trap that I hope we never fall into with the OpenForce conference.  Our goal from the very beginning has been to create an event where the community could come together and share our experiences and learn from other experts in the community. 

While I know that the community is interested in where we are going with the DotNetNuke...

In my last post Getting a Username/Password in PowerShell (cross posted to PowerShellCommunity.org), I was asked why not just use the Add-Member cmdlet.  Having been doing software development for my entire adult life, this is not the first time this question has come up.  Ok.  Maybe not those exact words, but something very similar - why use code X when code Y does the same thing.  Where I come from there is really only one response to this - look at both code alternatives and determine which one is the most efficient at doing the job without also becoming a maintenance problem.  So lets take a peek under the hood a bit so we can see why I chose PSObject.Members.Add over using the Add-Member cmdlet.

Scripting is code - except on the command line When working in PowerShell I try to keep a clear...

As part of getting ready for my PowerShell session at OpenForce '07, I am creating a set of helper functions for working with SMO to manipulate and query the database server.  A common need when working with the database is to pass the username and password to various SMO methods.  When I first started coding my examples, I just passed a username and password as parameters into my functions.  This works, but does not exactly look professional when you are sitting in a presentation and typing out passwords in plaintext.

I decided that it would be better to use Get-Credential in this case since it would provide a professional dialog and keep the password hidden throughout the process.  Since I wanted to support both scenarios, I came up with the below function. 

function global:get-sqluser($username="", $password="") { # We are creating an object to which we'll add custom properties $user...

For the past couple of months I have been playing with PowerShell and it has been a real pleasure to dig-in and get my hands dirty in a command-line interface again.  Not since my early days with the Amiga and ARexx have I enjoyed learning about a new CLI and an associated scripting language.  The PowerShell team has done a great job of bringing windows scripting and the CLI into the 21st century.  Not only has Microsoft been putting in a lot of effort into PowerShell, but you are also seeing an explosion of third-parties who have also jumped onboard to push the new language and hosting environment.  Companies like Sapien, Quest, /n Software, and ShellTools are creating great tools and sponsoring...

Nothing is ever easy in life.  The release of 4.6.0 and the subsequent release of 4.6.1 proved that.  4.6.1 was primarily concerned with fixing a couple of very nasty bugs from the 4.6.0 build.  The two worst bugs included a breaking change to the behavior of ModuleSettingsBase and a defect in the UserSettings page that caused the system to overwrite your usersettings whenever someone logged in.  Unfortunately, when we attempted to roll back the changes to ModuleSettingsBase to the pre-4.6.0 code, we did not get all of the relevant code rolled back.  This only made the breaking change worse.  This prompted us to take the unusual step of completely removing the 4.6.1 download until we could get a new version coded, tested and built to put back online.  Last night we posted the new 4.6.2 version which fixed the breaking change....