Live PowerShell With Karl Prosser

I was having an odd behavior with Portable PowerShell where if i started it from CMD it would take turns between giving a CMD.exe prompt and a PowerShell Prompt and take turns running them.

So in this test app, you can see we are first in CMD, then we run this application then after than its alternating between CMD and PowerShell Prompts and you see the expression 1 worked in PowerShell while having a problem in CMD.EXE

So i hear you say what’s the source code for this little demo? – I’m glad you asked

class Program
    {
        static void Main(string[] args)
        {
            var p = new System.Diagnostics.ProcessStartInfo("powershell");
            p.UseShellExecute = false;
            System.Diagnostics.Process.Start(p);
        }
    }

So why is this happening. Well normally when a console application calls another and they run using the same console window the first one is effectively paused while the 2nd one is running, then when the 2nd one exits it resumes.

so the flow here if it were working would be

CMD –> TESTAPP –> POWERSHELL

CMD naturally is waiting for testapp to exit, then in the sample code TESTAPP starts powershell, but i forgot to waitfor powershell to exit before proceding, so TestApp and PowerShell are sharing the same console for a split second then TestAPP Exits, and when TestApp exits CMD regains control of the console.. Now you have too totally separate programs CMD and POWERSHELL competing and using the same physical console window.

The fix is really simple.

.

class Program
    {
        static void Main(string[] args)
        {
            var p = new System.Diagnostics.ProcessStartInfo("powershell");
            p.UseShellExecute = false;
            var proc = System.Diagnostics.Process.Start(p);
            proc.WaitForExit();
        }
    }

Not really a biggie, but i thought it would be an interesting thing to share, and probably the cause of a bit of hair pulling  by many.

When we were selling PowerShell Analyzer and PowerShell Plus we used a standard shopping cart that we managed ourselves, generated license files with our own code, and emailed the customer. Managing these orders took a fair bit of time, but the biggest problem was often the emails that contained the purchased keys etc, didn’t get through. They got caught in spam filters and what not. It took A LOT OF EFFORT to manage these failures, and then when we sent out updates to our customers, because they were all sent out at the same time, services like hotmail thought they were spam and they never got through. This of course wasted our time as a vendor whose speciality is software, and frustrated our customers and wasted their time, and to those affected customers made us seem that we weren’t doing support or communicating with them, or even worse ripping them off.

So with us soon bringing Portable PowerShell to the market (as well as some other products including an exchange pop connector product) we want something better. Something that is less frustrating, that we don’t have to worry about building the sales software infrastructure or PCI stuff, something that just works well, is good value for money, is good for the customer etc. I know there must be untold services you there, that are tried and true and proven their worth to small software ISVs so we are asking for some suggestions.

Thanks in Advance,

Karl

UPDATE FEB 2010 We don’t need to rely on things like thinapp or app-v anymore. At ShellTools we have build our own Portable PowerShell framework. Its currently in Beta – see http://www.portablepowershell.com for more details.

What is it?

Portable PowerShell is software that allows you to run PowerShell on machines that don’t have PowerShell installed that you can run from a Machine that doesn’t have PowerShell on it, from a USB stick, on a machine that has a different version of PowerShell, a preinstall environment like BartPE, or WinPE or when booted to a windows 7 recovery DVD.

Why would I want it?

Administrators often cannot get their key tools, such as PowerShell installed in the environments they are working. This may be because a server installation has not yet been tested or approved, or the IT pro is working on a client’s environment, or a desktop support engineer is working on a machine that will likely not ever have PowerShell installed or enabled. Additionally you may want to run a different version of PowerShell than that installed, being able to do side by side work or comparisons when developing scripts. Having a thumb drive with portable PowerShell and all your own custom scripts with you at all times would be a dream come true to many administrators and IT pros.

How does it work?

You simple take our “PortablePowerShell” zip file and unzip it on a computer that already has PowerShell and Run “MakePortable.exe” and that will produce a folder containing everything you need to run PowerShell portable. From there you can just run it, or then copy it onto other computers, or onto a USB stick.

Does it use App-V or Thinapp?

Though we experimented with ThinApp and App-V for this very purpose a few years ago, we do not use either of those technologies as the past on licensing costs would be prohibitive for the majority of our customers. Instead we have crafted our own “Application Virtualization” particularly targeting the needs of the PowerShell engine.

What about PowerShell V2

In the future after the full release of PowerShell V2 we will release a version that will be able to produce a Portable PowerShell V2, however we made a Portable WinRM so V2 remoting will be limited or non-existent, however we are investigating what is needed to ensure that PowerShell V2 remoting will work.

What about Third Party Snapins?

Snap-in DLLs can be distributed with Portable PowerShell, and we have a configuration tool, and an XML configuration file that ensures that snapins get registered with the Portable PowerShell. However if the third party snapin’s installer puts other files in different places and maintains its own product registry , those snapins may not work. We do however provide a way that you can create and maintain virtual registry settings. We will set up a forum where instructions of including different snapins can be shared with the community. We are confident the majority of Third Party snapins will be able to be run, and we are willing to update the product to accommodate important but “difficult” snapins.

Other Features include ability to produce “custom portable PowerShell’s with special logging, specific scripts build in, scheduling etc.

So when can I get this and how much will it Cost?

ShellTools debuted with bring PowerShell Analyzer then PowerShellPlus, which is now produced and sold by Idera, successfully to market. We have a commitment to our customers, and we want to ensure that what we make lasts, and is feasible to maintain and support. We also learnt that bringing a product to market requires a lot more effort that just excellent software engineering. So basically we are now starting the process of working out whether ShellTools Portable PowerShell is commercially feasible and that we should bring it to market, or whether we just keep it as our own internal tool.

To help us decide could you please fill out the following survey? Additionally if you leave your email address with us in the survey you will likely be invited into the private Beta.

Link to Survey

Embedded Survey

Thanks,
The ShellTools Team.