I have been using MFCOM for many years to incorporate Citrix Xenapp management tasks into our custom administration applications that we write mostly in Java and partially in C++.
Our Citrix administrator has informed me now that MFCOM is being phased out, and Powershell Cmdlets are provided as the new Citrix XenApp API. He will be building our next farm without MFCOM support.
(And here is where I complain a litte. But you can skip the complaining if you wish as it is not essential to the questions I ask later: A scripting-only API is difficult and error prone to use from languages like Java/C++/C#. Catching and handling exceptions is unreliable, passing and receiving complicated arguments like collections or objects is cumbersome, and knowing that the script's interpreter exe is where you want it and the version you need requires lots of extra code. Complaining done.)
So I have to rewrite the applications. Here are my questions:
Are Powershell Cmdlets really the only API supported in the future for XenApp?
If so, how are people using non-Microsoft languages like Java/C++/Python/etc accessing this API? Is everyone launching scripts in separate processes?
If we use C# to rewrite the Citrix parts of our application, can we access these Cmdlets without shelling out a script in a separate process? I am amenable to using C#. My main desire is to not launch a separate process every time we need to call a Citrix function.
Thanks
Yes, the PowerShell SDK is the only supported API for XenApp 6 and probably also for future versions.
However, you do not have to start separate powershell.exe processes when working with the API (at least not from managed code). You can either use runspaces or the Citrix XenApp 6 wrapper assemblies. I recommend the latter mainly because of type safety.
Citrix CTP Jason Conger has written a series of articles that explain how to make the transition from MFCOM to the PowerShell SDK. You might want to read especially these two:
Background: Getting Started with the Citrix XenApp PowerShell SDK and C#
Examples: Citrix XenApp 6 PowerShell SDK: Getting a List of Applications with C#
Related
We were using IronRuby in our applications for some simple scripting of biz logic and rules.
We are trying to upgrade everything to .NET 4.5 - and our ScriptRuntime/IronRuby code is not happy with that. It does not lok like IronRuby has had a lot of traction lately, so we are wondering what would be a good scripting engine to switch to that is best supported by a .NET 4.5 environment. We prefer simple - the less third-party stuff we have to bring in the better. OUr scripts are also simple - not a big effort to convert.
Suggestions?
If converting your scripts to C# isn't a problem, I would recommend looking into the Microsoft "Roslyn" CTP and its Scripting API.
Because the .NET compiler developers are currently rebuilding their compilers in the Roslyn architecture and the Visual Studio team intends to consume the Roslyn compilers in the future, it's a safe bet that support for this scenario will remain for quite some time.
If you're not looking to consume the Roslyn architecture, you could also leverage Windows PowerShell by writing a custom host application that can execute PowerShell scripts that contain your business logic.
I'm adding Powershell support to an app as an internal automation/scripting language. One of the things I want to do is have a runtime environment where I can enter commands, get output, etc. So I started looking at implementing my own PSHost.
Then I imagined my future. Over time, I'll implement a prompt/command/execute/response+log loop, possibly a configurable UI, maybe some amount of debugging like simple breakpoints...
Oh no! I'll be writing my own ISE!
So my question is: is it possible to use the ISE for the Powershell scripting in my app? Perhaps through remoting? Perhaps through embedding of certain ISE components?
I haven't seen any way that ISE exposes its interface except as an end-user application. I have written a host, however, and it's not as bad as it sounds.
I've built a set of tools I use in my day-to-day work and I would like to make them look a bit more "professional" in order to sell them to financial institutions.
At the moment these tools are written in Perl and are executed from a DOS command line, it's extremely efficient but it doesn't look very attractive.
So, I would like to add a user interface to it but I don't really know what to use for language knowning that :
A Perl CGI interface hosted on the web is not an option since the information to be given as input is quite sensitive.
It would be ideal to sell it as a package/executable.
I don't really like the Perl/Tk interface.
I'm ok with rewritting the application in another language but I would prefere to reuse the main modules in Perl since it's very powerful with regular expressions and lists/arrays.
What would you advise me to do ?
Thanks,
Lory
If you want a non-web-based GUI, and don't like Tk, there's also Wx, which is a wrapper for the wxWidgets GUI toolkit.
However, web applications nowadays can be really easy to create (using a modern framework). Take a Mojolicious application, for example: Mojolicious carries no dependencies other than Perl 5.12.x, and provides its own web server (Hypnotoad). You can start by generating a "Lite::App", which is a simple self-contained single-file application, and then grow it to a bigger distribution later on as the need arises. It even comes with tools to convert your application to a conveniently packaged distribution that can be installed as easily as any CPAN module.
So that leaves the issue of security. User authentication, IP whitelisting, local network only... there are many ways to make a web application "for internal use only" if that's what you need.
You might just throw together a web-application prototype, and once you determine customer interest in your product, invest the substantial time in writing it as a Windows GUI application.
Continuing on from DavidO's answer, because the current web microframeworks for Perl (I prefer Dancer over his suggestion of Mojolicious, but both are good and largely equivalent) contain their own bundled web mini-servers, they also allow for the app to easily run entirely on the local machine.
Since these mini-servers default to a non-standard port (usually 3000 or 5000) by default and you can easily set them to a different port, they can be isolated by firewalls relatively easily, ensuring that nobody can connect to them remotely. You can also, of course, include and IP address check in the app and have it reject any requests that don't originate from localhost.
My guess is that the target system will be Windows. Use a RAD (Rapid Application Development) platform to develop a GUI. Examples for such a platform are Delphi or .NET with C# or VB. For bundling the Perl part, consider using a tool called perl2exe.
It doesn't sound like your scripts should require a web server. Also, consider the installation hassle. Only guessing as you're not giving much information about what your scripts are doing.
I am using the Cava packager to deploy my Perl-written tools. You can even generate an installer executable with just some mouse-clicks. It works pretty well with strawberry Perl and wxPerl on Windows.
Is Powershell a mature enough tech for enterprise to be using?
Are its many benefits worth the time and effort to convert existing VBS scripts, or would you only use it for new scripting projects?
We are currently using a mixture of vbs and batch files, with a login script as opposed to alot of GPO.
We don't have a huge number of .NET programmers, whereas just about everyone at least knows a bit of VB.
“Mature enough” is slightly subjective and depends on what you mean exactly.
1) Is it powerful enough to get the job done? -- Yes. But it is not the best tool for all the jobs; think, choose.
2) Is it bugs/issues free? -- No. To be prepared and informed you may want to take a look at some most voted bugs/issues in here:
https://connect.microsoft.com/PowerShell/Feedback
3) Is it easy to learn? -- It depends; basically I think it is not easy for not professional programmers. But it is definitely possible, step by step, having fun:
http://blogs.msdn.com/b/powershell/archive/2010/03/09/falling-is-learning-just-focus-on-having-fun.aspx
It’s a good idea to start using PowerShell for new tools. As for the old tools (e.g. VB), I would not convert them into PowerShell unless there are good reasons. In most cases they can be perfectly called from new PowerShell tools.
Yes. PowerShell brings into one environment the power of .NET, COM, WMI, and more. I use it every day to administer a family of 30-or-more servers, and it has proved to be both stable and productive.
I think PowerShell is a powerful thing. Microsoft is going into the "administer everything from powershell" direction (MS Exchange management shell, SharePoint 2010 management shell). This makes me think that this scripting technology will not die soon. Another thing - since the administration scripts are written in PowerShell, you can learn a lot from them, and hence gain more automation of your administrative tasks.
Convert only when needed
Prefer PowerShell for new work
It is enterprise ready and there are gotchas as with anything
Doing work in PowerShell now improves your skill
Doing work in PowerShell now positions for vNext products enabled with PowerShell. Big win.
For learning purposes i'm developing a Class generation application in c# and winforms. I think It could be fine to include a command-line mode that allow to use the application in scripts.
It's a good practice to include a command-line mode in my applications? It would be better to have two different programs, one with GUI in one for the command-line?
Actually having a C# application be both console and GUI is problematic. Console applications (/t:exe) are launched and then the command prompt waits for them to finish. GUI applications (/t:winexe) the command shell launches them and then returns immediately. While you can create and run forms from a 'console' application, it will always have a background console displayed. On the other hand 'Forms' application don't have the stdin, stdout and stderr connected and, while they can behave as command line tools and process command arguments, they have problems when embedded in scripts (because the standard input/output is not hooked up).
If you want to expose the functionality from both GUI driven applications and scriptable/pipe-able batch processing too the best way is to compile your functionality into a class library, then built two separate applications (one GUI one console) that leverage that library.
I'm not a C# programmer, but when I program in C++, I find it most useful to:
1.) Create both a shared library with a C as well as C++ API for performing core app functionality.
2.) Create one or more commandline binaries accessible to the shell interpreter.
3.) Create a GUI application for typical end users, implemented with the library (not by invoking the binaries).
This separates the logic of the application from the interface to the application, and enables thirdparty developers to create alternative interfaces for the same application functionality. It also makes it easy to script, while at the same time catering to typical end users who want a nice, shiny GUI.
Yes. If you think the program will be useful in a scripted environment then include a command line mode (without UI) so it can be used in scripts.
It doesn't have to be a separate application, but it can be. Whether you want to do that or not is entirely up to you. I'd imagine that if you had two applications they'd share the same logic assemblies but the interface (one a GUI the other a command line) would just be different.
I agree with michaelsafyan about creating a library with core functionality.
What I would add is that you should check out powershell cmdlets as well.
Much command line activity will be migrating to powershell and it brings a lot to the table.
http://en.wikipedia.org/wiki/Windows_PowerShell
I very often create such a utility as an API. If I need to use it from a simple command-line utility, that's easy - it just calls the API. If the command-line gets too complex, maybe it's time for a Winforms application - which can also call the API. If I wanted to use it from PowerShell, or from an MSBUILD task, those are still easy - they just call the API.
Creating an application on the windows platform that behaves correctly as a console application can be problematic it's an issue with the windows kernel architecture as they're considered two different types of application (they have a different subsystem that you generally specify in the compiler or linker options). You can still manually redirect the IO and open a console from a win32 application by the win32 function AllocConsole() and friends but this also has some issues. See This Old New Thing post for more information.
If you want your utility/prgram run in scripts you can expose it as COM.
Many script languages for windows had the hability to use COM objects directly.
You should include a command line interface in your application,
if it enhances usability and comfort.
For instance, calling a CLI command might be faster then starting the GUI, navigating through several menu layers to reach the same functionality.
You might ask the users of your application, if they would find it useful to have a CLI mode.
Some words on marrying CLI & GUI on Windows:
A windows application is either a GUI application or a Console application, but not both. This is an OS issue and there is probably nothing one can do about it.
The console subsystem in Windows is horrible and PowerShell didn't change that.
Your implementation options on Windows are:
the two files approach:
Provide two files: one .com with console, one .exe with GUI.
Because of the executable probing on the command line, the com file will get executed before the exe.
the console flickering approach:
Compile your GUI application with console mode on, then immediately after the start of the GUI you might call FreeConsole() to close it.
It's a bit annoying, but works. Bad: now you have a flickering console window. Pro: still one file.
I agree with #Remus Rusanu.
you should create a class library of your core functionality and then build GUI app(wrapper) for that.
and one other benefit of it is you might not even need to create a command line app as you can access your .net dll features using powershell..
you can find one example over here
Another great idea is to embed a scripting language. Then your program can be controlled by a script, and you get all the logic, branching, etc from the scripting language "for free."
There are many choices of what you can embed. Lua is one of the most popular and intended for just that purpose and is an excellent choice.
However, for a general purpose app, I'd take a hard look at embedding Python. Python is so popular, you'd have a larger group of people willing to take the effort to write a script for your app.