Executing Console Commands with PowerShell

I'm just starting to master PowerShell . . and I emphasize the word "starting".  Frankly, I'm disappointed with the learning curve required. PowerShell doesn't seem to be optimized, yet, for quick learning, despite that it piggy-backs off of .NET.

Here's a tip. Don't throw away those useful scraps of "DOS" commands you've been carrying around for many years.  You can reuse them inside of PowerShell. Here's an example:

 cmd /c  <PathToCommand> arg0 arg1 argEtc

Getting Started with the 7Zip Command Line

7Zip's command line tool has umpty-um options. Many of them are very useful. But if you are looking only for a command line version of the Windows' "Send to > Compressed (zipped) Folder" command, then you can get by with merely the following:

 7z a -tzip <ZippedFileName>.zip <FolderName>

Using C Sample Code in MSDN

Here's a simple tip for Windows C (and C++) programmers. There's a wealth of C code samples in MSDN. Unfortunately, many of those I've seen and used suffer from the same deficiency: they not unicode friendly and therefore not compatible with recent versions of Visual Studio. It's relatively easy to fix, however. Substitute the _tmain function for main and for _tmain's second parameter use "_TCHAR* argv[]" instead of "char *argv[]."

GOTO May Be Considered Helpful

As it turns out, at least one legitimate use exists for the notorious GOTO statement: breaking out of nested loops. Knowing from first-hand experience the problems that could be caused by "goto programming", I hadn't written a goto in 25 years. Recently, however, when trying to a write function with nested loops, it dawned on me that the most elegant solution would indeed involve a goto, at least when using C#. In fact, Microsoft's C# reference guide specifically recommends using a "goto" when exiting an inner loop, I later found out. (Maybe I ought to be reading Microsoft's online docs more often.)

In reviewing Steve McConnell's Code Complete (Second Edition), as I always do when confronting fundamental coding challenges, I was surprised to find only the vaguest of advice regarding "goto"--never say never, use your head, etc. Earlier in his book, McConnell does mention a Java-only approach. Java, which doesn't implement goto, actually has the nifty solution of named blocks, allowing you to end a break statement with the name of a block. I think this is superior than using a goto, but Java seems to be the only language with this feature.

Another author I consulted in this regard was Jeff Atwood. Atwood also describes beneficial situations for using goto, but in the only in the context of an "early return," rather than as a solution specifically for exiting nested loops. On the other hand,  I really like Atwood's description of "return" and "exit" as being merely tightly scoped goto's.

Loading Image Resources

Here's sample code to load an image resource file, which works even if the resource file is not in the executable assembly, but in a referenced assembly.

Bitmap bmp = new Bitmap(

    System.Reflection.Assembly.GetAssembly(typeof(pick_a_class)).

    GetManifestResourceStream("Dll.Path.Image.jpg"));

pick_a_class is the name of any class in the relevant assembly.

The resource name may not be obvious. Here's code to determine the exact names of the various resources:

string[] all = System.Reflection.Assembly.GetAssembly(typeof(pick_a_class)).

    GetManifestResourceNames();

Manipulating Xml with C#

I'm pretty fond of the XDocument class. XDocument lets you have your way with XML without requiring convoluted syntax, especially when used in conjunction with lambda expressions. Here's an example to change the value of an attribute on nodes that were found through a search criterion.

XDocument xDoc = XDocument.Load(

    new StringReader(

        @"<Customers><Customer ID=""99"" Description=""Just another customer""></Customer></Customers>"));

xDoc.Descendants("Customer").ToList().

    ForEach

    (e =>

        {

            if (e.Attribute("ID").Value == "99")

            { e.Attribute("Description").Value = "Our best customer"; }

        }

    );

Hiding ASP.NET Configuration Files from VSS

All I wanted to do was to keep a few ASP.NET web site files from being versioned by Visual Sourcesafe.  Seemed like a reasonable request.  I'm talking about deployment specific configuration files with things like server names in them that are referenced in web.config using the configSource attribute.  This approach is necessary for real world scenarios, where, for instance, a production server would not know what to do with the name of a database which is located only on my dev box.  Unfortunately neither Visual Studio (current version 2008) nor VSS knows how to ignore any ASP.NET files.  

I wonder what does everyone else does? I've met few ASP.NET developers who actually know about the configSource attribute. And I suspect that the few that do probably struggle originally as I have with an occasional mishap and then turn to batch scripts like as I have done for many months now.

There must be a better way, I mumbled to myself this morning. So a-Googlin' I went. Through a quick search,  I've encountered several blog posts suggesting a hack on the vssscc file for the solution. Suppposedly you can add a line like "EXCLUDED_FILE0" = "filename" and reset the "NUMBER_OF_EXCLUDED_FILES" line. There's only one catch; it doesn't work.  There went 30 minutes down the drain.

After more extensive searching, I was able to find an awkward but workable solution, from a post on a slightly different topic, which is to set the machine specific files as "hidden" in Windows. Never used that feature of Windows before!  Never had a need to.

There you are. Easy, right.  Yeah, it's easy all right, once you know.  Hard if you don't know. I can't decide: Is it surprising that  productivity insights are about the hardest thing in software development to Google for, or is really not surprising at all?  After all, internet "knowledge" seems to be mostly the blind-leading-the-blind.

It took me months to buckle-down and hunt for a solution to this annoying problem. I'm really glad I finally got around to it. I certainly hope, however, that in the future my futility-o-meter becomes more sensitive and I don't wait as long when I run into productivity snags.