Related
I am new to the Winium world. I tried playing with Winium.Cruciatus which seems to be working fine but not perfect.
Hence, I am thinking to try Winium.Desktop.Driver.exe which I understand -
is a Selenium-compatible wrapper for Cruciatus, and
it is required to be running separately while development.
However, I wanted to understand that once the development is done and
if the solution is deployed in production, will it
(Winium.Desktop.Driver.exe) still be required to be running in advance
for the solution to work?
My requirement:
To automate the installation of a software on multiple VMs (domain joined) from one single VM.
If (yes)
{
I think it may block the installation if it requires explicit Admin
permission to run. As we cannot go on each machine to click on 'Yes',
which defeats the purpose of automation.
Because my environments will be Windows Server 2012 R2 and most of
the time they are more restricted than a normal Windows like Win10.
}
If (no)
{
Any specific advantage of using Winium.Desktop.Driver vs only developing with Cruciatus library?
}
Note: Can someone of high reputation please create a new tag - 'Winium' as it seems this is required now as we already have few more questions
on Winium.
Winium.Desktop is a testing tool, it is usually used to automate end-to-end or other functional testing scenarios. When it is used as testing tool, then it is only required during development/testing phase, not in production.
But if you use Winium.Desktop not for testing, but as an automation tool, for example to automate installation of a software, i.e. Winium.Desktop is a core part of solution that runs setup program and clicks next or something, then you will need Winium.Desktop during deployment phase.
Key advantage of Winium.Desktop over Cruciatus is that it provides Selenium interface and works as client-server, which is useful for test automation, as client-server can be scaled, and Selenium interface is well known and there are a lot of tutorials on how to use it.
If you just need to automate installation of some software (i.e. do not need to do actual testing using Winium), I would suggest looking into direction of one of IT infrastructure automation tools like Ansible, Chef, etc.
Regarding admin rights I suggest to open an issues at https://github.com/2gis/Winium.Desktop/issues describing your use case, probably there is a way to run it without admin rights or grant access only once.
In my search for the meaning of life, I stumbled upon a blog post that mentioned that your deployment strategy is not your architecture, it is simply an implementation detail, and as such we need to design for allowing different deployment patterns, whether you want to deploy your system to 1 node or multi-node, or another type of structure.
Do the latest versions of Visual Studio provide some kind of flexibility (besides azure) to be able to deploy services in a variety of strategies?
For example, let's say I have a solution
Acme Solution
--Acme Startup Proj
--Acme Service A.csproj
--Acme Service B.csproj
--Acme Service C.csproj
I want to be able to deploy this entire solution as 1 solution, or I would like to be able to deploy 3 separate binaries, one for each microservice.
AcmeServiceA.exe
AcmeServiceb.exe
AcmeServicec.exe
What does Visual Studio give you in terms of flexibility of deployment configuration?
Deployment techniques will vary with which technologies your app is built. For the sake of an example, I'm going to assume we're dealing with web services or sites.
You've specified two deployment scenarios: deploying a single project (e.g. microservice), and deploying all projects (full rollout). Let's start small...
Deploying an individual project
The main thing to plan for is that each deployable atom (this could be a project or a service + DB backend... something as small as you would prefer not to split it into smaller deployments).
For web projects (either it be Web API projects or other types), Visual Studio's built-in options can be generally summarized as: WebDeploy, Azure, and now with .NET Core, Docker images. I'm not going to go into the details of each, because those are separate questions. But I may refer to some details for you to research if they sound interesting (I'm more familiar conceptually with WebDeploy, so I'll refer to that a lot; but I'm not advocating for or against it).
If you were using WebDeploy for example, you could have each project produce a WebDeploy Package. (Again, look this up for more details on how to do it). This package can be crafted to contain a file payload (the site/service files) as well as a database payload, or other subatoms using the WebDeploy provider model. Visual Studio has pretty decent support for this scenario, and there is documentation on it.
Or you could generate a Docker image. From my understanding (and lack of experience with Docker as yet), if you wanted to deploy your web service and database, they ought to be in separate containers. You'll soon find yourself building these yourself outside of VS. That's not a bad thing, Docker sounds very flexible once you get the hang of it; but you are leaving the IDE for this.
Either way, now you can deploy the atomic package. This was the easy part.
Deploying the solution
So, you've got lots of these atomic deployment packages. How do you roll them all out?
Well, at this point VS doesn't provide a lot for you. And it's hard to justify what VS should do here. Almost every organization is going to come up with slightly different rules. Do you deploy from your CI? Do you create packages and deploy them to different environments in your release pipeline? Or do you do it in the cloud and hotswap environments (like Azure deployment slots)?
A VS native solution has to be either extremely configurable (and hence extremely complicated), or it will be too simple to fit most customers' needs. (As an aside, the initial support for WebDeploy back in VS2010 errored on the first of these. It was extremely configurable, and very difficult for customer or even the product team to wrap their heads around all of the possible scenarios. Source: I was the QA for that feature once upon a time.)
Really at this point you need to determine how and when you rollout your deployments. You need something to orchestrate each of these deployments.
VS generally orchestrates things with MSBuild. Again, I'm not advocating this as your orchestration platform (I actually dislike it for that... it's ok for your project configuration, but IMO not a good fit for task management), but if this is what you want to use, it can work. It's actually pretty simple if you're using it for to the Web Project scenario. You can build your solution and use the parameter /p:PublishOnBuild=true. If you are using WebDeploy to directly publish, you're done! If you're creating WebDeploy Packages, then you still need to push those, but at least you've created them all at once.
If you are using WebDeploy Packages, they will each generate a script to use for publishing. There are ways of passing in different WebDeploy parameters as well, so you can reuse the same package (build output) to publish to different environments. However, you'll have to write your own script to combine all of these into one megalithic deployment.
Ditto for Docker as well. You may get a set of images, but you still need something to orchestrate publishing all of them. Tools like Kubernetes can help you rollout, or in the event of issues, rollback.
There's also more generic orchestration platforms like Octopus Deploy.
How Unsatisfying!
Yeah, it kind of sucks that there isn't an out-of-the-box solution for large scale deployments. But if there was, it wouldn't work for 95% of teams. Most of what VS does provide is enough for an individual or very small development team to get their code to their servers. Any larger of a team, and you'll get better mileage out of building a system that is tailored for how your team operates. There are plenty of tools out there and none of them work perfectly in all cases. Find one that works for you, and you'll be fine. And in the end, it all comes down to pushing files and running scripts. If you don't like one system or tool, you can try another one.
If you are looking for an improved deployment experience in Visual Studio, check out Flexera's InstallShield Limited Edition in-box solution (ISLE, http://blogs.msdn.com/b/visualstudio/archive/2013/8/15/what-s-new-in-visual-studio-2013-and-installshield-limited-edition.aspx). ISLE is a great solution for those customers looking for added capabilities not found in Visual Studio Installer Projects, such as TFS and MSBuild integration, support for creating new web sites and ISO 19770-2 Tagging support, etc.
VS2015: https://marketplace.visualstudio.com/items?itemName=VisualStudioProductTeam.MicrosoftVisualStudio2015InstallerProjects
VS2017: https://marketplace.visualstudio.com/items?itemName=VisualStudioProductTeam.MicrosoftVisualStudio2017InstallerProjects
With the Setup and Deployment project templates you can choose to package all assemblies in the solution or each one individually as MicroService's using Setup, Web, CAB or Merge Module Projects:
Then choose which assemblies are included:
It really kind of depends on the exact use case how to achieve that requested some kind of flexibility and on your definition of an acceptable level of such a flexibility.
Taking your example with these three different executables as separate microservices (Service A, B, C) and as a complete service (Startup) in the context of Web.Api you could do the following:
Each project (Service A, B, C) can be designed as a separate OWIN self hosted executable (as outlined in Use OWIN to Self-Host ASP.NET Web API 2) and provide one or more endpoints to be exposed.
The main project (Startup) could also be an OWIN self host or a regular IIS Web.Api application that references the three projects (Service A, B, C) and load their respective endpoints in its own Startup routine (and optionally additional endpoints of iteself).
You can then use a separate configuration project in Visual Studio (or an external project in a completely different environment) and make use of deployment technologies like Puppet, Chef, or whatever to deploy according to your scenarios.
Your code would then be unaffected by the deployment you are actually wishing to perform and that respective configuration would be managed separately.
If this does not answer your question or if I have misunderstood your question, could you please clarify it and give more details?
When we talk about the meaning of life, here are the two cents about it by a deployment (install) specialist :-)- the answer is (seems :-) long, but it will contain specific information where to look for every point..
First of all, let's state that deployment is NOT a nobrainer, though many developers would like to see it like that (and as a deployment specialist, I observe quite often stakeholders in the software development process actually thinking like this- simple put, deployment is kinda forgotten until the day before shipment :-)
Compare it with coke for a bold and simple example. The "developers" produce the liquid, but it is quite easy to realize here, that the job isn't done yet. :-)
Visual Studio itself has not really support for deployment strategies. Based on several areas of deployment as mentioned in the following list there are of course a lot of technologys, some by Microsoft, helping with that.
What I would do is building setup bundles for different customers or scenarios which install subsets of services like client/server scenarios or others (see no. 3. in the following list.)
Second, as you may have seen from other answers, deployment is not deployment.
Partly, this depends if one sees deployment as just producing binary files by MSBuild or deploying to a test system or deploying to the customer, e.g. by updating the productive web site or producing DVDs or uploading executables to the update web site...
There are several different areas which sure have relations, but every numbered area is large and complicated enough to have own specialists for it:
Deployment seen as part of architecture has to deal with source and binary structures and entities, e.g. project and binary structure (how much .exe, .dll files, how are their dependencies, variation planning.
=> As you mentioned, you are here in the area of (Visual Studio, etc.) solutions, projects, as well namespaces, especially in the WCF area you have contracts, etc., you have (POC#) interfaces, etc. You have Nuget or other tools to resolve and manage dependencies.
.NET has to offer the concept of the assembly to deal with this, the architecture, e.g. if to deploy interfaces and contracts in own assemblies, how to deal with client/server scenarios, how the assemblies depend on each other, is up to you and architecture..
Concerning services, there is an interesting subtask how to host services, They can be hosted on a web server, they can be selfhosted in an .exe, they can be hosted with IIS or OWIN, etc. Links for more information:
Selfhosting in WCF:
https://msdn.microsoft.com/en-us/library/ee939340.aspx
Selfhosting in a Windows service, here with SignalR:
https://code.msdn.microsoft.com/windowsapps/SignalR-self-hosted-in-6ff7e6c3
Hosting with OWIN:
https://en.wikipedia.org/wiki/Open_Web_Interface_for_.NET
Deployment as part of a local Windows or other operating system integration: You have to think about, in which system directories you have to place certain files or data generally. You have to think about shared dlls, shared data, project data, temporary data, user specific data, registry, file system, Windows logo requirements, best practices, service configuration, etc.
Deployment as a process of creating setups, own installations, which, besides other things, accomplishes the needed actions mentioned in 2- with additional tasks like graphical installation front-end (setup GUI), license acknowledgement, what's new section, selection of optional components (just think of Visual Studio setup), uninstall/repair/modify possibilities, and so on.
Deployment as a devops process, e.g. part of continuous integration , continuous delivery and/or continuous deployment. Here are two main points: Technically, to have a defined process which is doing things mentioned in 2. and 3. (or alternatively web deploy steps) automatically as part of the build process ("post-build step").
This can include creating setups or hierarchies of setups- or working without setups at all). The second is to enable testers, developers and managers (or even customers) to see at least every morning or even more often the already installed example of the last nightly or daily build, maybe with several deployment variants (client/server?, basic/prof?) or on different systems.
You are here half in developer world, half in admin world.
Here the main point is often not creating complicated setups like in 3. but primarily to define own "pack" and copy (and sign... etc.) processes, and to automate them as part of the development (and test and delivery) process. Puppet and Chef were already mentioned.
Deployment as web or cloud deployment (can also be the endpoint of a devops process)- others have said something about that, I will omit details here, but an important differentiation is, if you are talking about deployment to the customer or deployment to an intermediary test or staging system.
Maybe one thing making this point worth to be mentioned additionally to devops, is that a deploy to online servers, server farms or a cloud has very own challenges.
Deployment seen primarily as an administrative process of distributing shippable, buyed and/or own programmed software to all the thousands of PCs in a company and it's daughter firms. there are of course special tools for this including update strategy, monitoring, license management and more. You are here in admin world, not in developer world anymore. Microservices will be a new and high challenge to admins which are mostly used to install and distribute "large" packages like MS Office or Oracle or whatsoever.
This topic is not so boring for developers as it seems. Primary because the two "worlds" of developers and admins are merging. And developers have to care about the customer view of "running the software in the real world". Devops is only the beginning. Everybody knows virtual machines, but now we have software defined networking, virtual apps, virtual server farms, the cloud, etc. You can define a deployment architecture by dependendies without any programming just by configuration. So deployment should be part of your application architecture, but mostly it isn't (enough). In fact until now the admin view is nearly nowhere integrated with the view of the software producers/developers. Concerning Microsoft, there is a lot of work done here by the Windows team, esp. in the server product line, and that was never really strategically coordinated with the developer team AFAIK (this is probably valid for EVERY software shop until now :-)
Currently, a lot of people publishing related to devops or the continuous buzzwords are not very experienced with setups. Building setups can be seen as a special technology among the other necessary steps.
Given that you are interested in knowing more about 3. (setups) :
If you don't want only to copy executables, but to have the functionality of full setups, which do more work than just copy, part of setup strategy can be to have bundle setups (sometimes called suite setups or bootstrapper setups) with own selection features. They can call the underlying small setups e.g. for your microservices.
Visual Studio itself has not longer an own support for the more sophisticated setup types like MSI, and especially never had for grouping setups to bundles, what can be one possible solution of deploying a bunch (or variants of bunches) of services- VS has e.g some support for "ClickOnce" deployment, but this has been made more for database ("smart") clients than for services or even microservices.
ClickOnce: https://msdn.microsoft.com/de-de/library/31kztyey.aspx
A replacement for the lack of "real" setup creation in Visual Studio can be the WiX toolset which is an Open Source project formed by Microsoft employees. Or InstallShield Express (which is a free, but a limited variant of the commercial ones).
With both you can create full MSI setups which are maybe the most sophisticated setup type in the windows setup zoo.
a) Of course there are other setups types besides MSI (aka Windows Installer), they are from third party vendors which are more or less proprietary but more simple: , e.g. Nullsoft - NSIS and InnoSetup.
I will not give links for creating single MSI setups because they can be easily found with the given links of creating bundles of MSI setups in the next lines:
b)
The tool for creating setups that select and install other (defined subsets of underlying) in the Wix "world" is called "Burn":
Creating bundles of setups with Burn:
http://wixtoolset.org/documentation/manual/v3/bundle/
Special (paid) support for this you can get for example from the founder of WiX who created a company especially for this:
https://www.firegiant.com/wix/tutorial/net-and-net/bootstrapping/
Rob Mensching, the founder, can be found here on SA as well answering dedicated questions.
c) InstallShield Suite setups:
Another is the already mentioned tool InstallShield, but for this you will need their InstallShield Premium variant which costs bucks:
http://helpnet.installshield.com/installshield21helplib/helplibrary/SteCreatingSuites.htm
d) Setup-Factory :
https://www.indigorose.com/setup-factory/
e) I am sure, many people would advise to take a look into Docker.
Virtual applications are not only setups, but they isolate themselves in the "installed" state from other apps like a sandbox.
See for example https://docs.docker.com/docker-for-windows/
f)
The list would be not complete, if I would not mention APP-V as virtual application installation technology which shares some but not all features with docker. But these technologies are not really made for orchestrating multiple deliveries but to deliver just one app.
And Microsoft has defined a new setup type called AppX.
Especially you have to differ, if you want to create "legacy" (full) desktop applications for Windows where MSI setups are the known technology for or store apps which are the new type since Windows 8 (aka Universal Windows apps aka Windows Store apps aka modern apps aka Metro apps).
AppX:
https://msdn.microsoft.com/en-us/library/windows/desktop/hh446767(v=vs.85).aspx
AppX targets a more simple setup type than MSI.
Universal Windows apps (UWP):
https://learn.microsoft.com/en-us/windows/uwp/get-started/whats-a-uwp
For anything more detailed we have to know more of your requirements.
I am interested in this new platform - Tidekit. But I couldn't find any answer to my questions:
Is it possible to add C# (or at least C++/JAVA) code or Dll libraries to the solution?
Is it possible to make a package with html+js+css and native code (C#/C++/Java) working in one executable file or executable + dlls?
There are already working solutions like CefSharp, Awesomium, but there is a problem to make external resources (html, css, js) embedded inside the project.
I would like to hide my implementation from end users somehow.
I'll appreciate any answer related to my questions.
We don't support C#, but yes to the rest.
Again, no C#, but yes to answer this question.
Further explanation below:
We've developed TideKit to have a small and stable core so that the apps can be built up in a modular way with the functionality you want in your app. TideKit provides simultaneous extension in ObjC++, C++, Java, and JavaScript for web, HTML5 hybrid and native apps.
Generally, developers will consume modules without the need to write lower level code because the functionality already exists both natively and for HTML at the same time. So mostly it is about consuming modules and writing your app in JavaScript.
Modules allow a project to be built for desktop, mobile and web from a single base of code. TideKit is a uniquely develop once, deploy everywhere platform with easy-to-use JavaScript APIs and CommonJS modularity. The best way to write TideKit apps is CommonJS. More than 60K modules of CommonJS functionality is available through npm and components registries. Folks familiar with nodejs will be at home with it. You can also write conventional JavaScript or easily migrate an existing TideSDK app.
Automated packaging, installers, and distribution are part of our solution. There are packaging options that can provide bundled or network installs to take advantage of dynamic libraries for efficient runtime code to keep the amount of installable and distributable code to a minimum.
TideKit has the capability to build in different ways from your project source to optimize for AppStore compliance or even highest HTML5 compliance. You can use it to build HTML5 or native apps for virtually any platform you wish to support. On the backend, we have capabilities for the widest range of mobile and desktop operating systems and for web deployments. Beyond building your app simultaneously for multiple platforms, you can also develop, test, and deploy your APIs from the same base of code.
Our build service protects your code from exposure by encrypting and embedding the sources in a binary. Hope this helps.
I think it is possible to use DLL's with something in between using Ti.Process...
the idea to execute a DLL is to have something in return (a very especific process, only for windows desktop I believe). I'm facing the same challenge but I guess I will approach to Ambiance Air App which uses a DLL to validate the license of the product...
in short it could be
var myScript = Ti.Process.createProcess({
args:['python',Ti.API.application.resourcesPath + "/??????"]
//the unknown command for the exe that uses the dll? it should return an object! not even functions...
});
myScript.myObject;
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 2 years ago.
Improve this question
I'm building an application for multiple desktop platforms: Windows, Mac, and maybe later for Linux.
I was wondering which programming language and IDE combination would be the best for me:
Programming language need to be whether C# (preferred) or Java.
Core libraries must be shared between all platforms, means all platforms must link to a single core library (by library I mean a list of classes and functions).
Windows and Mac are in priority, Linux app is for future plannings.
Design of the app is completely custom, it doesn't follow any guidelines of each platforms.
I'm stuck between these three solutions:
Use Xamarin.Mac + Visual Studio for Windows and link the core classes between them.
Use GTK# for the whole project and compile multiple builds for each platforms.
Use Java for the whole project and compile multiple builds for each platforms.
For #2 and #3, I need an advice that which language is more suitable for me, considering the design of my application. I mean, which one has a better GUI building ability for my goal?
BTW GTK# uses different libraries for each platforms, so that should be an clutter for my core architecture, or not?!
Three years later and Javascript is now also a strong contender in this debate.
There are multiple options within the space.
https://electron.atom.io/
https://github.com/nwjs/nw.js/
And others
Even Microsoft has shipped Visual Studio Code, the cross platform version of their development environment, which is written in Javascript.
What is the Visual Studio Code editor built on
The benefits include utilizing the many available web libraries, and building/using your web development skills.
This sounds like a job for Xojo or something similar: http://www.xojo.com
Mac, Windows, Linux builds with easy GUI design and native apps. Custom UI easily done also, and you'd then have one code base for all three platforms. You can download and use the software for free to develop and test, only requires a license once you decide to build your app.
You can also conside Livecode
Livecode: http://livecode.com
For any platform except web, it is opensource and it includes mobile targets as well, if your code is flexible enough to not being C# or Java.
An option is to build the core logic in a compiled library using C# and GUI independence and then plug it to livecode, leaving the UI work for that tool.
"GTK# uses different libraries for each platforms", do you mean different rendering back ends (such as X11, Cairo)?
You only need to build your GTK# app once. However, you do have to bundle the GTK# runtime (which is different for Windows and Mac) with your app. Banshee is a good example you can follow.
Probably your best bet is to use Nevron Open Vision. It is a cross-platform, C# based User Interface Platform, that implements most of the controls you need to build enterprise-ready applications. It is the framework behind MyDraw (www.mydraw.com) - a professional drawing program similar to Visio. MyDraw is built completely with Nevron Open Vision and does not require any other third-party libraries. We mainly develop it under Windows and just compile it to Mac. Soon we are going to add support for Linux and WebAssembly hosts.
Microsoft just launched .NET MAUI, a cross-platform GUI framework that builds on Xamarian.forms.
As we consider what building device applications will look like in a unified .NET, we see many devices across multiple platforms used, from Android and iOS to Windows and macOS. To address this need we are excited to announce a new first-class UI framework for doing just that: .NET Multi-platform App UI, affectionately call .NET MAUI.
This seems to meet all of your requirements. They do not explicitly mention Linux in their article, but claim to support it in the description on the Github Repo.
It depends on the audience of the app: Consumer mass market or business/IT
If its mass market consumer facing
Electron or native UI, perhaps with shared non-UI code. Visual Studio Code was made with Electron, for example (last I checked). Google Flutter is a new entrant worth evaluating. Dropbox is Python (or used to be). It is a lot of work (a) getting Python packaged properly for smooth x-platform install, and (b) GUI work will take a long time. Sadly, for mass market consumer apps (not utilities for IT people but beautiful designs for the masses like Dropbox, Skype) you will be spending a ton of time getting the installation system to work and getting the app to look and feel appropriate. This is an extremely time consuming endeavour no matter what path you take.
Consumer: Java? I don't think Java is a great fit for consumer desktop although I could be wrong. There are some Java packaging systems that are leaner/all bundled in. I'd also say JVM software companies tend to go under (more on this later). FreeMind the free mind mapper, is a good example of what can be achieved in Java.
Consumer: .NET? Yes, for the Windows side. Then use something native for Mac and shared libraries for non-GUI code. There is ".NET Core" aka Mono but its not fully matured at this time for Mac. Mono has been around for over half a decade and I haven't seen it mature for a consumer app. Ask: How many .NET Core apps are in the Mac app store? I hope it gets better but as of this writing (2020) there's very few notable ones.
Business app or IT tool
If its a basic business app or utility where a basic UI is okay, I'd evaluate Xojo and/or LiveCode mainly for comparison sake. Xojo is fairly close to .NET. Google Flutter as well since it's up and coming. By the time you read this, Flutter may be the best choice.
B2B: Java? This is a pretty tried, tested and true solution for "heavy" enterprise apps. You might not have end-users love you given Java apps tend to eat up memory. But for enterprisey apps the main concern is that the very intense business logic will work. For IT tools, it depends. If it's a 3-screen utility program, avoid Java. If it's a complex ERP then Java is good. Remember to look around for different packaging tools to avoid consumer headaches with the JVM. Again, one Java desktop app I like is Freemind. It's a great example of making a reasonable desktop app in Java. I have used it in both Windows and Mac and it's great. You can also look at Kotlin or Groovy (for test cases) which compile to Java byte code.
B2B .NET? There is so much to unpack here. The key is, in my biased view, .NET Windows desktop development is about 2X-4X faster development time than Windows Java desktop development. From making the GUI, to better code completion, to faster compile times, to less packaging and install snags. That said, at the time of this writing the ".NET Core" or Mono are pretty thin for MacOS. I really, really hope this changes. But I've been waiting years for Mono or .NET Core to provide a full suite for MacOS without the limitations and it hasn't yet happened. If it's an enterprise app, you might be able to get away with using .NET Core for Mac. But please first build a basic .NET Core "hello world" app with all the control/libraries you want to use. Then try building an installer for it on MacOS, and find someone random with a Mac to see if it actually installs and runs. You may find you're struggling in this area today (although I hope it gets better, it hasn't for years).
Overall Notes on Cross Platform
If this is a smaller app which doesn't need a fantastic UX and super-deep OS integration, then I'd consider Xojo or LiveCode, perhaps for the UX elements. Like #merlucin said, you can write the core logic in something shared- perhaps C#, python, etc.
Here's why- Xojo and LiveCode have been around for 10 years now. They are more about keeping things consistent. Whereas I find .NET and QT changes all the time. You have a lot of costs of keeping up with the Joneses and maintaining installers. So for a small app or utility- an XML editor, IT helper tool, Xojo or perhaps LiveCode will help you get there sooner.
When you hit the build button on Xojo, for example, it literally makes 3 executable files for Windows, Mac and Linux. Compare that to the madness of packaging a cross platform Python app, or even packaging a .NET app for Windows, to be honest.
The tradeoff is these tools- Xojo and LiveCode often end to be missing a few critical things you need, requiring a bit of a hack. You can read around their forums. Xojo is a bit like .NET although LiveCode is a different programming paradigm entirely based on "stacks".
Keep in mind developer happiness too. Many developers wont want to code in Xojo or LiveCode because they are lesser known languages. So ensure you get buy-in. What happens if you get laid off and have 5 years of experience in Xojo? Hmm.
In your evaluation, no matter what you choose-- you must compile a basic GUI app in the platform you're evaluating and get 3 people to install it correctly on a Mac. You'll be shocked at the libraries and madness needed. Especially if you're a web developer, you'd see that just maintaining installers is a ton of work across 3 platforms. Never mind GUI consistency.
What is the best continuous integration setup for a Devleopment department that codes in multiple environments?
At my company we write some code in C# and some in Java, I've previously used CC.Net but I've never done CInt with Java.
I'm aware of Continuum and was recently told about Hudson, but I've never used either.
Would it be better to use two CInt services one for each platform or to use a single one for both?
Why don't you try Team City from JetBrains? It is both for Java and C# and Professional version is free up to 20 user accounts and 3 build agents.
You could simply use the Java version of CruiseControl and have two setups.
As you already know how to use CC.Net and CC.NET can run any build task that outputs XML. Why not just use CC.NET with ant for your java code as well as your C# code.
Or do you need to build on none Windows machine? CC.NET may work with mono, I have not checked.
Remember that any continuous integration setup that compiles all your code and run your unit tests give you great benefits. On most projects having the perfect setup only give a smaller improvement over having a continuous integration setup that works. So I would just pick something you are happy with and start using it now.
Imho, its almost alway better to use one CI for all platforms you plan to deploy to - easier to sort out problems that way.
shameless plug: try Bamboo, the CI server from Atlassian. Its one click setup, built-in support for Ant and Maven and works on all platforms with JVM. It can also do distributed builds on different platforms.
It also integrates with Atlassian Jira Issues Tracker and Fisheye Code Repository Browser if you have those products.
Hudson. I've used it for both .NET and Java projects and it works well to have both platforms using the same continuous integration server.
Note this assumes you want to build the same code on multiple platforms. Hardware has gotten cheaper so use virtual machines or multiple physical servers I'd go with virtual machines and just buy one powerful server to run them on but if you have a lot of old mid range hardware that may be a cheaper option. Set up a main source control repository on one server, and set up servers with the client operating systems you want to build for. For example have a svn server containing your operating system of choice, a Linux server to do Linux builds and a Windows server to do Windows builds. Then just install what ever continuous integration software works best for the given code base and operating system.