Writing TestComplete Plug-in with C# - c#

Is it possible to write Test Complete plug-ins in C#? I see that you can write some extension for WPF controls in their documentation. However, can I write full fledged plugins? I am on version 8.5

TestComplete is a native COM-based application and, therefore, a custom plug-in should be a native dll with the COM architecture as well. Theoretically, it is possible to create it in C#, but I think that a possible result does not worth efforts. Information on the supported platforms (Visual C++ and Delphi) can be found in the Supported Development Tools article.
Please note that there are some samples included in the TestComplete SDK and some user-contributed examples for older versions of the tool:
Real-world TestComplete Plug-ins, Part I
Real-world TestComplete Plug-ins Part II
Real-world TestComplete Plug-ins Part III - Extended Colors Plug-in
Real-world TestComplete Plug-ins Part IV - ODT Declaration Generator
I guess the current API is mostly the same, for the sake of backward compatibility.

Related

Xamarin - Compile AOT in Community edition?

I wanted to obfuscate my application, but I couldn't find a free obfuscator for commercial use. I saw that mono supports AOT compilation, so is there a was to compile my app ahead of time using the community version of Xamarin?
If not: is there a free obfuscator for C#(xamarin) for commercial use?
NOTE:
I'm targeting Android
I want to clarify the licensing restrictions that come with Dotfuscator Community Edition (CE). UUioP writes "I know about Dotfuscator, but I was actually looking for a free obfuscator for commercial use." Dotfuscator CE most certainly comes with license restrictions that preclude most commercial use scenarios, but there is one exception (granted - it is a very narrow exception, but one that might work for some). Dotfuscator CE can be used to release commercial software if the code being obfuscated is written and owned by the Dotfuscator CE user. In other words, if you develop your own app (and it's your app - not your employer's), you can use Dotfuscator CE to obfuscate your app - even if it is for sale or other "commercial/production" use. See (Re) Introducing Dotfuscator CE - the licensing terms are explained towards the end of the post.
The AOT Compilation option requires an Enterprise license or higher. AOT compilation is available only when the project is configured for Release mode, and it is disabled by default.
Source: https://developer.xamarin.com/guides/android/deployment,_testing,_and_metrics/publishing_an_application/part_1_-_preparing_an_application_for_release/#AOT_Compilation
As for obfuscation, Xamarin.Android does not support obfuscation out of the box. You will need to use a third party obfuscation tool like Dotfuscator. They have a tutorial on this here.
Many people think Proguard will obfuscate their code in a Xamarin.Android project, but it only works on the Java end.
The Xamarin.Android ProGuard configuration does not obfuscate the APK, and it is not possible to enable obfuscation through ProGuard, even with custom configuration files. If you wish to use obfuscation, please see Application Protection with Dotfuscator.
Source:
https://developer.xamarin.com/guides/android/deployment,_testing,_and_metrics/publishing_an_application/part_1_-_preparing_an_application_for_release/#ProGuard
AOT in Xamarin:
It depends whether you are targeting Android or iOS.
As #Jon Douglas states in his answer, Android AOT in Xamarin is unfortunately currently limited to Enterprise licenses. (tip: You can test out this Enterprise feature using a limited-time Enterprise license trial.)
iOS AOT in Xamarin, on the other hand, is part of every iOS build, so you get it with the Community license for free. Note however, that the full .Net assemblies are still included in iOS release builds, so that defeats the purpose of AOT "obfuscation" in iOS. :/
Obfuscation:
ConfuserEx is a great .Net open-source obfuscator with an MIT License:
https://github.com/yck1509/ConfuserEx/
I still haven't tested ConfuserEx end-to-end in a Xamarin app, but it looks promising so far... (Beware, as many people point out, ConfuserEx is a little "confusing" to use...)

Library compatibility between C# .NET vs C# Mono

I wanted to tryout C# for general purpose programming (not web development). I program in Windows environment, but I would like to avoid coding specifically for Windows (.NET), because I want to keep the option open for a future migration to Linux.
Are there any specific libraries in C# .NET that wouldn't work in C# Mono for general purpose programming work (not interested in Windows Forms, Silverlight and stuff like that) ?
Is there any internet link of things/features that provides a list that works on C# .NET wouldn't work on C# Mono or vice versa? I didn't readily find anything in google per se.
Note: I would be interested in specific answers, not opinions of which is better or worse (thanks!)
It is possible for a CLR assembly (even in the form of a DLL, as mentioned in the comments) to be read by Mono, as long as it does not have dependencies that do not exist in Mono, because...
...not every piece of code that compiles for .NET will compile for Mono, since there are lots of Windows-specific things in .NET (not strictly part of C#) that aren't implemented (WPF, ASP.NET async stack) or don't make sense at all in Linux (COM is one such example, I think).
Fortunately, there is a list of what .NET features are implemented in Mono. Even more fortunately, it seems they have an app that tells you a priori whether your code makes use of anything not implemented in Mono (but I have never tried it).
if you install xamarin (you need Pro or bigger so you have VS integration) you can create Portable Class Library that targets xamarin (which is based on mono) and visual studio will allow you to only use classes that are compatible with mono.
http://docs.xamarin.com/guides/cross-platform/application_fundamentals/pcl/introduction_to_portable_class_libraries/
apparently you can also use xamarin studio to create a PCL and there is a free version of that.

Where is the difference between Xamarin.Mac and Mono:OSX

Where is the difference between Xamarin.Mac and Mono:OSX. I know Xamarin bought Mono so I thought it should be the same. But Mono:OSX seems to be free, while Xamarin.Mac costs at least 399$. So where is the difference between them both?
Xamarin.Mac -> http://xamarin.com/mac
Mono:OSX -> http://www.mono-project.com/Mono:OSX
The following is an excerpt from an article at xamarin.com (http://docs.xamarin.com/mac/guides Jan 1, 2013) which answers your question.
What are the differences between MonoMac and Xamarin.Mac?
Xamarin.Mac is built on the open source MonoMac project. Xamarin.Mac is being developed by the maintainers of MonoMac, though contributions are continuing to flow to MonoMac as well.
Xamarin.Mac has these additional features:
A commercial license to the Mono Runtime
Bindings to new frameworks
Creates self-contained application bundles, without external dependencies on Mono.
These are described in detail in the following sections.
Bindings to New Frameworks
The following are new frameworks and APIs that are included in Xamarin.Mac:
CoreBluetooth
GameKit
New MountainLion AppKit APIs
SceneKit
StoreKit
Commercial License to the Mono Runtime
Xamarin.Mac also comes with commercial support from the Xamarin team, and the Xamarin.Mac product has a published roadmap of forthcoming features.
The Mono runtime license is a commercial license that allows developers to redistribute their Mono-based applications without being bound by the terms of the GNU LGPL v2. This allows you to publish both to the Apple App Store as well as distributing applications that embed the Mono runtime without having to provide source code or object files for end users to relink.
Creating Self-contained Application Bundles
Xamarin.Mac extends MonoMac by allowing developers to ship an application bundle that includes both their software as well as the required pieces of the Mono runtime, without requiring your users to fetch the Mono runtime on their own and install it separately on their systems.
This feature is used for AppStore deployments as well.
I am not from Xamarin, so below is only my own understanding,
Xamarin.Mac is based on Mono:OSX. It is not something that comes from middle of nowhere.
Xamarin.Mac provides streamlined experience of developing Mac applications, by integrating MonoDevelop, Mono core runtime, MonoMac, and probably some non-open-source addins/utilities. It is easier to use Xamarin.Mac than assembling the whole tool chain on your own.
Xamarin.Mac comes with support contracts. This can attract professional Mac developers, and enterprises, as they need support contracts to ensure their own products' supportability.
Anyway we can sign up the seminar and learn what it is,
http://resources.xamarin.com/intro-to-xamarin.mac.html
BTW, the statement "Xamarin bought Mono" is not that accurate. The proper terms can be found in this blog post by Miguel de Icaza,
http://tirania.org/blog/archive/2011/Jul-18.html
Xam.Mac fills many of the gaps missing from Mono on OSX.
There's bindings to the native OSX APIs for Notifications, for example.
The BIG win for us was a FileSysteWatcher that uses OSX FSEvents. It's awesome.
It also features an OSX compatible version of NetworkAvailability. Mono only has support for Linux/Windows

Converting .NET App to x86 native code

There's a program written entirely in C# that targets .NET Framework 2.0.
Is there a way I could somehow compile (translate) managed EXE to a native one so it could be .NET-agnostic? I know there are probably commercial products for that purpose... but they are a bit expensive.
The problem is that we are to deploy the program on computers running Windows XP with no .NET Framework installed. There's also a requirement that the program's size must not exceed 500Kb (1Mb maximum) for it is downloaded from the web server (now the size is 255Kb). That is why there's no way we could attach a full-fledged .NET FX (or even a reduced one) to the downloaded program's file.
Obviously it is a terrible software engineering error that should have been detected and avoided earlier so we could use native technologies like C++ instead.
We have tried for now Novell's Mono - an open-source implementation of .NET Framework for Linux, MAC and Windows. Mono consists of C# Compiler, IDE, runtime (CLR) and Class Library assemblies (like System.dll and mscorlib.dll - much like .NET's class library assemblies installed to GAC).
What we tried to do is to locate CLR files and ship those along with our program's file and a few assemblies. This way the program can be invoked by running "mono program.exe" (command prompt) on a user's computer.
In addition to the inconvenience of such a use for the end user CLR files (mono.exe and mono.dll) turned out to be about 2.5 Mb in total that is much greater than the desired 500 Kb or even 1 Mb.
So, we have left with no other option but to translate our .NET App to a native one by a compiler, however the question remains - what compiler should we use and where could we find one...
For now I have stumbled upon a Singularity OS Project by Microsoft Research. It is an open-source research OS that is written in managed code (in part at least). The Singularity OS includes a Bartok compiler that the OS uses in order to translate a managed program to a native one (x86 32 bit). It should be noted that Bartok can't translate all the aspects of .NET 2.0 to a native code, but most of them. However I haven't yet learnt how to use the Singularity...
I would be really grateful to you if you could provide me with some useful tips and advice regarding the problem, your own experience with Singularity OS and Bartok Compiler or another approaches to the problem that I have overlooked and ways of solving it.
Thank you very much in advance!
Finally, using Mono's Full AOT feature (on Callum Rogers' advice) I've managed to produce a program.exe.dll that lacks a CLI header.
So it looks to me like a native dll. However I can't figure out how to convert that dll into exe or make it operational.
Also this dll doesn't seem to expose any functions of interest such as main function.
Check out AOT (Ahead Of Time) Compilation from the Mono project. This compiles your managed project into a native exe or an elf executable (depending on which system you target) that does not need the JIT. This is the technique used to get mono apps onto the iPhone (where the JIT/Framework are not allowed) and also has the added benefits of faster startup times, lower memory usage and it makes it harder for people to decompile your code. You said you were already using Mono, so it should be compatible.
Read up about it at the mono-project.com website and at Miguel de Icaza's blog (and iPhone info).
Note that you cannot use dynamic code or generic interfaces like
interface IFoo<T> {
...
void SomeMethod ();
}
And you will have to compile the DLLs of all the libraries you use.
PS: Make sure to use "Full" AOT for your problem.
2018 Update
At Build 2018, Microsoft announced .Net Core 3.0 roadmap that support Windows desktop applications (Winform & WPF)
2017 Update
For console apps, you can use .net core Self-contained deployments (SCD). Even for a hello world app, your package will 50MB+. You still need to install VC runtime though.
Update
As #jenix's comment, .NET Native is only for Windows Store Apps(UWP). After 3 years of it's announcement, this is still true, .net native for desktop may be dropped by microsoft . So this answer is not applicable anymore.
========
Microsoft Announced .NET Native Preview on Build 2014
With the .NET Native Developer Preview, apps will get deployed on end-user devices as fully self-contained natively compiled code, and will not have a dependency on the .NET Framework on the target device/machine. So, no .NET framework required on the target machine with .NET Native.
Announcing .NET Native Preview
Microsoft .NET Native
There is a project called CrossNet that parses .Net Assemblies and generates unmanaged C++ code, that can be compiled in any standard compiler.
Not really a solution for .NET to native conversion, but maybe this helps: http://www.yoda.arachsys.com/csharp/faq/#framework.required
Not quite sure that there is much you can do besides painstakingly rewrite the application. To ease the already burdening process, you could disassemble the .NET application using something like Reflector (into Microsoft C++), and use that as a base to start and just replace managed C++ references with native ones.

Is C# platform neutral?

Today I purchased C# 3.0 Pocket Reference (O'Reilly Publishers).
In that book in the first para of the first page it is given that "The C# language is
platform neutral, but it was written to work well with Microsoft .Net platform"
If I am not wrong, Platform Neutral mean that the softwares made from that language should run in all the OS(e.g.Mac, Windows,Linux etc.).
I know that this characteristic is being satisfied by Java but .Net has not yet been able to do that(Though MONO has made some progress in Linux).
Then what is the significance of that word "PLATFORM NEUTRAL" so far c# is concern?
Thanks in advance
The C#-language itself is platform neutral like C and C++ are - you can implement a compiler et al for it on any platform.
The .Net platform and its associated libraries however, which it was designed to work well with, are not platform neutral in design - they are designed to work on windows, although Mono does compensate somewhat for that.
If you would write a C# program without using any features of any .Net-library it is guaranteed to be platform-independent - you can be sure it will run on any platform that has tools for C#... you just won't have a particularly useful program though ;)
C#, the language, is platform neutral.
But the frameworks usually associated with C#, the dotNEt environment, are not. They run on Microsoft's OS-es.
Mono enables C# on many other (mostly unix-oid) platforms by providing the necessary runtime environment, but it doesn't come with (all) the frameworks needed to run typical C# programs.
Don't forget you can use C# in:
MS .NET (Windows)
.NET Compact Framework (PocketPC, XBox 360)
Silverlight (Windows, Mac)
Moonlight (Mono / Linux)
MonoTouch (iPhone)
MonoDevelop (various including android)
Micro Framework (some watches etc)
Not exactly bad coverage. The language has very few requirements on the runtime / OS.
C# is platform neutral in the sense of OS (i.e., OS neutral) if you count Mono as a reliable runtime on Linux.
But, C# and .Net can run as it is, without recompilation, on both 32 and 64 bit machine. I guess this is the meaning of the author.
In this case, platform neutral is defined as "being able to run on any machine that has a compatible virtual machine". Depending on what language features and compiler you use, C# could be considered able to run on machines running recent versions of Windows, Mac OS and Linux.
C# the language can be implemented on any platform which has a compatible compiler and virtual machine. The language itself has an ECMA standard for implementation, and thus does not itself contain any platform (i.e. Microsoft) specific language elements.
Before answering the question, one must consider that any language these days is useless without its libraries. That said many namespaces that make up part of are windows only. Many are just wrappers around microsoft technologies, like com, win forms, etc.
All things considered just take a look at the adjustments mono has made to provide alternatives to dot net. Miguel has mentioned many times that they hope Silverlight will win rather than other ui toolkits because it is truely platform independent rather than wpf and winforms etc.
If you want a true multi platform language and environment look at Java.
In my view, Microsoft's claim that C# is platform neutral (repeated by the text you are quoting from) is disingenuous.
It is technically correct, but in practice the limited portability of C# applications to non-MS operating systems has happened despite Microsoft rather than because of them. It is pretty clear that Microsoft has no intention of supporting C# / .Net on any non-MS operating system. Indeed, many people think that Microsoft (via its patent licensing deal with Novell) is using C# / Mono as a "wedge" to damage the GNU / Linux ecosystem.
IMO, anyone thinking of using Mono needs to consider: 1) the risks to their project if MS decides to play hardball about .NET patents, and 2) the damage they might be doing to the open-source ecosystem as a result.

Categories

Resources