Is it possible to use an ActiveX/COM object from ColdFusion? If so, where's the documentation or samples for it?
(non ColdFusion programmer, asking on behalf of a ColdFusion programmer)
see: Integrating COM and CORBA Objects in CFML Applications
If you're worried about COM object performance, use .NET based CFML Engine like BlueDragon for the Microsoft .NET Framework
You can call both COM objects and .Net assemblies natively in ColdFusion both with excellent performance. Check out the following in the cf docs:
http://livedocs.adobe.com/coldfusion/8/htmldocs/cfobject_01.html
http://livedocs.adobe.com/coldfusion/8/htmldocs/help.html?content=dotNet_01.html
Examples are included in the docs.
Related
I can't seem to figure out how to get F# TypeProviders to work in a Windows Store (C#) app.
As far as I can tell, TypeProviders can only be used in an assembly targeting the full .NET Framework, whereas Windows Store apps must target .NET Portable.
I have created an F# assembly and referenced the F# TypeProviders library, however when attempting to reference this assembly from my Windows Store app, I receive an error stating that the library could not be referenced.
Is there any way around this? I want to use F# TypeProviders to reference various data sources and then use the generated code/types in my Windows Store app. Anyone have experience with this?
UPDATE:
Just to be clear, I am asking if there is a way to use the standard F# TypeProviders (such as WsdlService) in a Windows Store App?
Looking at the other assemblies FSharp.Data.TypeProviders.dll is referencing, I don't think there is a way around this. Since most type providers are used for accessing a database in one way or another (ADO.NET, LINQ to SQL, EF), it references System.Data.dll which is not available in WinRT.
The only data sources supported by built-in type providers that can be used in WinRT are web services and OData services. Their type providers maybe could be supported in a WinRT project if they were implemented in a separate library, but not in their current implementation.
Type providers are design/compile time facility. It should work in Portable library profile. It is maybe dependent on how is type provider library implemented, but in general, it should work.
For more info see F# type providers with Portable Library
I understand that COM is really a way to program (i.e. like structured programming, or OO programming). However it is a little old. So I was just wondering what has really replaced this set of specifications? Will I find this in .NET documentation?
COM has not been replaced. The Component Object Model is a core part of Windows and will remain so for the foreseeable future.
COM provides you with one mechanism of inter process communication (communicating between applications on a machine), it is also used as a much simpler (for the consumer) system of sharing dlls. Its COM (or ActiveX, or OLE - all the same) that enables VBA to work so well in MS Office, it is the foundation of ActiveX controls.
COM is not a way to program (unlike OOP etc) it is a technology that works on windows to make access to other applications during runtime easier.
.NET can use COM object with wrappers, and if you want to allow any app to access your functionality, its still best to provide a COM wrapper.
Other methods of inter app coms now exist such as ZeroMQ.
The original specification for COM is old in age, but the specification as well as the concepts are still in use, and you can still create and consume COM objects.
For .NET, you can start by looking at the following links:
Com Interop Part 1: C# Client Tutorial (C#) # MSDN
Interoperating with unmanaged code # MSDN
In addition, there are other specs that are very similar to COM or have semantics that are the same. Most notably, XPCOM is in use in FireFox for their plugin spec and also used internally to FireFox to connectable objects.
XPCOM # MDN (Mozilla)
WinRT is an upcoming platform update for windows that is also heavy in COM concepts.
There are some useful here: Why is WinRT unmanaged # StackOverflow
For .NET developers, a lot of the declarative overhead is hidden as mentioned here: WinRT demystified - Miguel de Icaza
The head of the spec is here: The Windows Runtime # MSDN
And in the context of COM, developing WinRT components with C++ has similarities, although some syntax is borrowed from managed C++: Creating Windows Runtime Components in C++ # MSDN
Looks like I found a good commercial variant, but I'm looking exactly for Free one. Does someone know some?
How about the OpenNETCF ORM? It's free, lightweight, and was built specifically for the Compact Framework, then ported to other platforms (as opposed to someone shoehorning a desktop ORM into the CF).
I am currently looking for a free .net ORM for use on Windows CE. So far I have found these commerical options:
DevXpress XPO
LLBLGenPro
EntitySpaces
NHibernate sadly is not an option because it uses features that are not available in the Compact Framework (e.g. reflection related functionality).
If using a SQL database as your underlying data store is not absolutely necessary then Karvonite is worth consideration. It is a free (Ms-PL) object persistence framework compatable with the .net Compact Framework. Do you need to use SQL Server Compact or are you really just wanting an easy way to persist your domain?
I will update you if I find more options.
I built DapperLite to work on .NET Compact Framework and full .NET. It's basically a Dapper clone, so it's a single file under 200 lines you can drop into your project.
I had tried OpenNETCF.ORM but found it too opinionated. I love using Dapper in my desktop apps but unfortunately it doesn't work with .NET Compact Framework.
I also built a Micro-ORM layer over the top of DapperLite to make it a bit easier to use, which is essentially a clone of Dapper.Rainbow
I finally found the object model documentation for Microsoft Office.
However it talks about interop assemblies and stuff that sounds like .NET. I don't use .NET directly, and I don't really want to learn much about it. Is there a way to just use plain COM/ActiveX classes/interfaces to automate MS Word/Excel?
Here's a KB article that can help you get started: http://support.microsoft.com/kb/216686/
...and this one: http://support.microsoft.com/kb/307473/EN-US/
Since MS appears to have killed Managed JavaScript in the latest DLR for both server-side (ASP.NET Futures) and client-side (Silverlight), has anyone successfully used non-obsolete APIs to allow scripting of their application objects with JScript.NET and/or can explain how to do so? A Mono/JScript solution might also be acceptable, if it is stable and meets the requriements below.
We are interested in upgrading off of a script host which uses the Microsoft JScript engine and ActiveScript APIs to something with more performance and easier extensibility. We have over 16,000 server-side scripts weighing in at over 42MB of source, so rewriting into another scripting language is out of the question.
Our specific requirements are:
Noteably better performance than the Microsoft JScript (ActiveScript) engine
Better runtime performance and/or
Retention of pre-parsed or compiled scripts (don't reparse on every run)
Lower or equal memory consumption
Full ECMA-262 ECMAScript compatibility
a little porting can be tolerated
Injection of custom objects into the script namespace
.NET objects (not a hard requirement)
COM objects or COM objects wrapped in .NET
Instantiation of COM objects from Script
à la "new ActiveXObject(progid)"
Low priority given the preceeding
Include files
Pre-loading of "helper scripts" into a script execution context
An "include" function or statement (easy to create, given the above)
Support for code at global-scope
Execution of code the global scope
Retention of values initialized at global scope
Extraction of values from the global scope
Injection and replacement of values at the global scope
Calling of script-defined functions
with parameters
and with access to the previously initialized global scope
Source-level debugging
Commercial or Open Source Support
Non-obsolete APIs
I answered a similar question here. Have a look at IronJS, an implementation of JavaScript in F# running on the DLR.
Sooner or later, I imagine someone will write a DLR Javascript. I know that's not very convenient for you right now, but maybe you could start the project. I suspect it would have a better cost/benefit analysis to using JScript.NET.
If moving away from .NET and Microsoft is ok for you then you should try Mozilla's Rhino. It is an open-source implementation of JavaScript written entirely in Java. Alot of modern server side js libraries target this platform.
I have used CSScript.net as it will allow you to run C# as a scripting platform. From the site:
CS-Script combines the power and
richness of C# and FCL with the
flexibility of a scripting system.
CS-Script can be useful for system and
network administrators, developers and
testers. For any one who needs an
automation for solving variety of
programming tasks.
CS Script satisfies all the conditions that you laid out. I have used it in production as a substitute for Boo it has performed really well. You can see it in action here.
The use of Com interop means you are limited to an MS solution Java and Opensource want as little as possible to do with it.
I dont see any solution that supports all your requirements either you ditch all the COM/.NET stuff and go Java (Rhino) /Linux/Open source or you question the use of Javascript as your server language even in the Linux world we use PHP/Python/Ruby more on the server if we cant run Java. Your not going to see big performance gains with Java script as the language is the main barrier.
I wouldnt count on people writing a new DLR as server Java script is dying fast.
Considering you want performance ,what about F# , Microsoft will keep the Jscript engine supported for at least 5 years giving you time to create new stuff in F# while you slowly migrate the code.
Have you seen ROScript?
http://www.remobjects.com/script.aspx
Supports both PascalScript and ECMAScript (Javascript) syntax
The Jurrassic-Engine is alive and kicking.
From their codeplex site:
Supports all ECMAScript 3 and ECMAScript 5 functionality, including ES5 strict mode
Well tested - passes over five thousand unit tests (with over thirty thousand asserts)
Simple yet powerful API
Compiles JavaScript into .NET bytecode (CIL); not an interpreter
Deployed as a single .NET assembly (no native code)
Basic support for integrated debugging within Visual Studio
Uses light-weight code generation, so generated code is fully garbage collected
Tested on .NET 3.5, .NET 4 and Silverlight