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.
Related
I have some programs (.prg) that operate using .dbf files, as i am migrating to postgresql (personal preferences) i really would like to know if there are ways to "translate" commands from one language to another.
Translating to python would be another possibility
Thank you
There isn't. Visual FoxPro the language is fairly tightly tied into its own object model, and when you start bringing UI elements into the equation the time and work involved in automatic migration means that it's always quicker to re-implement on the new platform.
If you're interested in Python you could take a look at Dabo. This is a Python framework aimed at desktop and web apps, but developed by some long-time Visual FoxPro experts. In that respect it is conceptually similar to Visual FoxPro in a lot of ways.
Dabo's authors, Ed Leafe and Paul McNett, have strong backgrounds in
database application development using the awesome and underrated
Microsoft Visual FoxPro development environment.
While Visual FoxPro shines at developing data-centric applications, it
has one limitation that cannot be ignored: it only runs on Microsoft
Windows, and Ed and Paul both have clients that want their
applications to run on Linux and Macintosh. We are sure we are not
alone in this regard: it is a multi-platform world with more diverse
needs than one vendor can fulfill.
Ed and Paul got to talking one day: Paul had been researching various
multiplatform GUI toolkits for about 18 months, and Ed has lots of
experience developing the Visual FoxPro Codebook framework. We decided
to work together to make a framework for developing robust
data-centric applications for multi-platform deployment. We've come up
with a design that is simple, flexible, and robust, and we've begun
developing our own client applications using the Dabo framework.
Is there any way to include Dapper in metro apps?
It relies on System.Data which is left out in WinRT.
If not is there any similar framework which can be used?
Is there any way to include Dapper in metro apps?
No. As you observe, the lack of System.Data is pretty much a show-stopper, however in addition WinRT also omits meta-programming support, so the entire core would need to be re-written to use regular (i.e. slow) reflection. There are some elaborate hoops you can jump through to get around this, but without System.Data it seems a lost cause.
Basically, the intent with WinRT (as I understand it) is to consume your data from things like web-services, the classic "smart client" rather than "rich client" model.
So you might consider:
server (full .NET)
using "dapper" for data-access
exposing some call/serialization protocol
client (.NET for Windows Store apps, or whatever the term is today)
consuming some call/serialization protocol
Strictly speaking, you can IIRC break all the rules and just reference .NET anyway, but that won't pass any MS validation, and won't be a proper metro Windows Store application.
Any idea what language Citrix products are written in? (XenApp, formerly Metaframe and Presentation Server), XenDesktop, etc? I've been wondering this for years.
AFAIK, C, OCaml, Python.
OCaml and Python are mentioned there: http://caml.inria.fr/pub/ml-archives/caml-list/2009/07/36fee5f2c665901f2dc7d1b647c4eace.en.html.
I agree with the previous answer. Also, recent releases use C#. Notice how the NET Framework is a requirement for most of the Citrix installers. The web components are written in a combination of languages and frameworks including Javascript, ASP NET, and C#. The classic management console is written in Java and I think that most of the command line tools are written in C++.
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.
I have been sold on the fun of using linq in areas other than pure database interaction. (See Calling fellow code nerds - Alternatives to Nested Loops?).
We are stuck on 2.0. I have told the powers that be about the ease of updating to 3.5 (we have already migrated to VS2008) but they are wanting a list of "benefits" for upgrading.
Can those that have experience in 3.5 help provide some talking points for the benefits of updating an existing app to 3.5?
UPDATE: Found an additional reason: Microsoft's inclusion of Charting tools for Asp.Net as a patch on top of 3.5! They get their business value, I get the fun...
Can YOU make a case for it? Sounds like you want it because LINQ is fun. Other people are mentioning features that are fun. I've always had a problem selling fun features to management because they aren't very compelling reasons to potentially disrupt an environment.
Honestly, it really depends on what you are using C# for. Are you a web developer, system admin, something else? Taking a general approach, I would use the following selling points (you will need to do some work to prove these things):
Zero-disruption for end-users when upgrading. Upgrading to the new version will be seamless and we will have a thoroughly reviewed test plan for updating all clients to this version. All of our old applications that require .NET 1.x or .NET 2.0 will still work perfectly.
Programmer Efficiency. You could mention how more of the Windows API is wrapped by .NET classes, thus making programmer more efficient because they don't have to P/Invoke as much. LINQ makes your more productive because of x, y, and z. Lambda expressions make you more productive because of x, y, and z.
Ease pains of future OS migration. Moving to WPF now will prepare us for Vista/Windows 7. We won't have to migrate applications using the now deprecated "Windows Forms" to WPF, because we will already be using it.
More applications purchased from 3rd parties will require it, so we will have to upgrade sooner or later.
In the end, you need to prove that at the very least, this move will not cost you money in terms of increased support or testing costs. If you can show it will make you be more productive and it will be a rather painless switch, then you will get your wish.
Maybe you should talk to some Java developers who are probably still forced to develop using 1.3 or 1.4 despite 1.5 being out for over 3 years and 1.6 for a couple... it appears platform consistency across the business is often of greater importance than the benefits of using the latest and greatest.
Also remember that 3.5 is just additional BCL libraries. You are still running on CLR 2.0. Same is true for 3.0. Usually when people find out that the underlying framework is the same and that you are just adding in new libraries they are more likely to go along with it.
You don't need .NET 3.5 to get LINQ or C# 3.0 features. You can implement your own LINQ for .NET 2.0. I am using C# 3.0 all over the place in my .NET 2.0 application. I don't know the full details on how to start the conversion process because I didn't set it up myself. This might be a good link for you: http://www.danielmoth.com/Blog/2007/05/using-c-30-from-net-20.html.
http://msdn.microsoft.com/en-us/library/ms171868.aspx
Transitioning onto 3.5 would help you reap the benefits/ features of:
LINQ to (Entities/ XML / Objects / Datasets etc ).
WCF, WF and WPF.
ASP.net MVC where MVC is kind of a de facto standard in other
platforms like Ruby/Python which
allow you pure HTML/ Javacript based
development.
ORM options with ADO.net Entity
Framework/ Linq to Sql
4.
With a few addons you can have
support for dynamic languages
like
IronPython/IronRuby.
Oh ya I almost forgot ADO.net Data Services..one of my fav.
These are the few benefits that immediately come to my mind.
In my experience, the addition of LINQ and Extension methods alone have made many previously arduous and/or time consuming tasks much easier and faster. The increased developer productivity from that alone is worth the upgrade effort IMHO.
Lambda expressions are awesome. There is no end to the places where I find that lambda expressions help me out in a very concise and readable way.
Automatic properties, while being a simple concept, really help making the code base smaller and clearer.
Also, I sencond the extension methods.
Before I even opened this question I had my answer: LINQ - it's one of the greatest extensions ever in .NET - I love it. It took me a few days to figure out, but now I've got it, I use it all over the place. The ability to query collections and arrays is worth the upgrade alone in my mind.
Decreased development time (and therefore increased ROI)
Less time wasted finding workarounds for .NET bugs that've been fixed in newer releases.
Extension methods for native types (in a similar fashion to JavaScript prototyping)
LINQ extensions - they take a couple of days to get your head around, but it's awesome!
LINQ to XML makes working with XML so much simpler
LINQ to objects/collections
A nice new 3.5 poster from Microsoft that you can pin up in your cubicle.
As a manager if I have a happier more productive team that is producing more in less time, then its a no brainer.
Ask yourself this: Will the developers be more effective and will their increased productivity actually increase benefit to the company or reduce corporate costs once you've considered the upgrade/transition/installation on the servers/additional testing etc? If the answer is truly yes, then do the upgrade and quit arguing about it.