PowerShell, Scripts and Cmd.exe

PowerShell's designers don't seem to be overly concerned about including intuitiveness as a feature.  Consider what it takes to run a PowerShell script from the cmd.exe prompt. Bet

c:\> Powershell blah blah

doesn't do what you would think it would do. PowerShell expects "blah blah" to be code written in Powershell.  the canonical example is the following:

c:\> Powershell 2+2
4

Get it?  Do you ever find yourself typing "Powershell blah blah" at the command line? I didn't think so.  PowerShell is a scripting language, so you might be expecting

c:\> Powershell script.ps1

to run a script named script.ps1. Well if so, you would be wrong. PowerShell instead expects "script.ps1" to be a PowerShell command, which it obviously isn't.  The solution, for some unexplained reason, is to add an ampersand in quotation marks. Thus,

c:\> Powershell "&" script.ps1

BTW, it's more conventional to put the script reference in quotation marks as well. In other words,

> Powershell "& script.ps1"

According to the error message you receive if you type

c:\> Powershell "& blah blah"

the quoted ampersand tells PowerShell that what comes afterward is one of four things:

• cmdlet
• function
• script file
• operable program

Apparently, this error message is the only official instruction from Microsoft regarding the ampersand switch.

Changing .NET App Properties/Settings at Runtime

Visual Studio* provides an application settings (aka properties) feature for console, library or windows applications. Creating and editing application settings at design time is straight-forward and can be managed conveniently thru VS's GUI.

But what if you need to change the settings at run-time? The answer is anything but obvious. The settings are contained in a class called "Settings," which derives from System.Configuration.ApplicationSettingsBase.  You could of course rewrite the code in the settings class, but then if you decide to make a change in VS's GUI all of your handiwork is immediately hosed.

There's one adjustment you can make directly in the GUI that puts you a step closer to your goal.  At the top of the Settings Designer screen, is a drop down box titled "Accessor Modifier."  There are two choices: the default is "Internal." The other choice is "Public." Choose "Public." As we'll see, this one alteration allows us to change the value of the properties in our code.

The application expects there to be a static property called Default, of type Settings, in the class Settings. Default, the only instance of Settings that will be acknowledged by the app, is created for you automatically by VS.  Default is essentially functioning as a singleton. Finally, ApplicationSettingsBase provides an indexer allowing us to reference the individual settings on Default.

Here's an example:

MyApp.Properties.Settings.Default["MyProperty"] = value;

ORA-12154 TNS:could not resolve the connect identifier specified

Hey Oracle enthusiasts. Here's a fun one. I encounter this just about whenever I try to configure, unsuccessfully, TNSNames.ora for ODP.NET. Recently, I decided stopped worrying about TNS and put everything into the connection string, like so:

Data Source=(DESCRIPTION= (ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=LOCALHOST)(PORT=1521))) (CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME = orcl))); USER ID=whatever;PASSWORD=********;"

This works every time.

It just seems as though TNS isn't worth the trouble.