I'm lead dev on a new project at work to build a combination web and mobile app for internal project management. The descriptor "internal project management" is generic and may mean different things to different people, so please don't focus too much on that. Most of our stuff is M$ and C# is the future (compared to my company's history with VB, VBA, VBS), so I'm thinking C# and Xamarin. Know any good literature on making the most of shared codebase for mobile/web with Xamarin/C#.NET?
To my knowledge, Xamarin does not support web app development, only "iOS, Android, and Windows Phone 8.1, Windows 8.1, and the Universal Windows Platform (UWP) for Windows 10". Unless we have a reliable timeline for the entire company upgrading to Windows 10 (we don't) we shouldn’t build in that direction. We can maintain two closely related codebases of C#.NET and Xamarin. The trick is how closely?
Thoughts? Thanks!
I would highly recommend reading the new bits to .NET: https://learn.microsoft.com/en-us/dotnet/articles/standard/library or https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md
Xamarin now supports .NET Standard:
https://blog.xamarin.com/net-standard-library-support-for-xamarin/
Because of this, you can leverage the use of .NET Standard as a Shared layer across your applications. You would then treat each stack (Web, Desktop, Mobile, etc) as a platform specific stack that you would implement native features/UI/etc into. However you can completely leverage all of your shared code via the standard library.
This is a common question answered in the FAQ here:
https://www.xamarin.com/faq#q2
Or expanded upon via our documentation:
https://developer.xamarin.com/guides/cross-platform/application_fundamentals/building_cross_platform_applications/sharing_code_options/ (Note: This will be expanded in the future to include .NET Standard)
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.
I started work on porting an application I've written for deployment in the Windows 8 app store. This requires that the application be written against the subset of the .NET framework. My application follows an architecture where the core functionality is in it's own dll, and things like file system access are done through IoC. Basically, this means that the only dependency for the core dll is System. Because of this, I thought that porting would be a breeze - setup my IoC values and wire up a GUI then I'll be good to go. Only, I can't even reference my core dll from the windows store app (a.k.a. metro app).
Have I missed something? Do actually have to rewrite my core dll just for inclusion in the windows 8 app store? We're told that if you use a good architecture, then porting will be a breeze, and that's what I've done. Has that just been a big lie?
Windows store apps(formerly called metro style app) are limited to using the .NET Core Profile. I put some details about the Core Profile in my answer to this question. See Converting your existing .NET Framework code in this article more details. It's not your architecture, it's the subset of the .NET Framework that is available to a Windows store app. You may have to supplement some of the types you use in .NET with WinRT types instead.
I don't have an extensive knowledge and will try to stict to facts as I understand them. The Metro framework adds functionality, and limits functionality. There are heavy security restrictions and vast segments of the full .Net framework that are not available (for instance, you cannot use System.Data, some of the System.IO and file access methods have drastically changed). A Metro app is isolated, you're not going to be able to recurse all the files on the hard drive like you could in a standard application (my opinion that is, on top of security by isolation it's an encouragement to push you into the cloud for storage needs).
Unless things have changed, PInvoke is limited to "approved" Win32 API methods.
See this link for some alternatives to common Win32 API needs: http://msdn.microsoft.com/en-us/library/windows/apps/hh464945.aspx
See this link for approved Win32/COM API's: http://msdn.microsoft.com/en-us/library/windows/apps/br205762.aspx
It's hard to say whether a "good" architecture will be a breeze to port without knowing what's in the code in that architecture. In my utility framework I've had things that ported very easily (or at least were straightforward) and things that were a complete wash that required a lot of rewriting (The loss of System.Data for instance is a sore spot for me). There are things that can be designed well but when you take out the underlaying code in the framework or API it was written with it will require rewriting.
I had the same problem: a project for Metro app don't load dll create with framework .4. I changed the framework from 4 to 3.5 for the dll and now the Metro project see them.
I'm pretty excitet about all the new stuff coming up in Windows 8, but at the same time a bit worried about how and if I can continue use the code and custom components I have already built up using .NET and C# during my time as a Windows dev. I've got some general mixed questions about this. Hope you don't mind I'm putting them together in one post:
Will Windows 8 Store be for both metro-style apps and regular WPF-desktop apps? Including pushing updates and making apps available for company employees?
Will the new App Contract-thingy also be available for WPF-apps? And is AppContract based on WCF-services with perhaps UDP-discovery on the network? Can I make my own contracts between my own apps using the App Contract framework?
I'm not particularly worried about if WPF will be ditched or not. I can live without it. The thing that worries me is if I still can write presentation and business-layer code in C# and use it as a backend for my apps, no matter what UI-framework I'll be using, HTML, Silverlight, WPF or what have you. If I'm still able to write logic in C# and present it using X UI-framework, I'm a happy developer. I've heard I can access the .NET-framework from JavaScript. But what about custom assemblies?
It has been announced that non-Metro apps can appear in the store but the store will just link to the publisher's website - not actually manage the sale/install/DRM/etc stuff.
What's been announced so far is that the contracts are only for Metro apps but I'd be shocked if this doesn't change. It would be crazy for Microsoft not to allow desktop apps to, for example, add commands to the Settings charm, support PlayTo or printing through the Devices charm, or act as Share sources. We'll have to wait and see where they draw the line on what desktop apps can/can't do.
Sharing code between Metro and non-Metro apps is going to be very difficult. A lot of the core concepts and conventions are the same but even basic stuff like file I/O rely on a totally new API. There aren't a ton of interesting things you can do with in code that will work on both sides of the fence. Best bet would be to define interfaces for your business layer stuff and then use dependecy injection to dynamically select desktop vs. winrt implementations at runtime
Store: there is no final information but as far as I understood it, it's for metro style applications only
The app contracts are a metro thing. I know a code snippet that documents usage from desktop apps (eg http://www.heise.de/developer/artikel/WinRT-in-klassischen-NET-Anwendungen-nutzen-1366039.html (sorry, German)), but I do not know if it will have support from Microsoft
WinRT compiles libraries to WinRT components. You might be able to reuse code and compile them to a component as long as you're not using a namespace that isn't available for WinRT
This question is heavy on guessing as there is no official beta available. And even then we can't be absolutely sure...
I'm developing an application for a Windows based tablet PC. This application is pretty much a port of an application I already developed on a Windows Mobile device using .NET CF. I want to write the application from scratch, taking advantage of all of the knowledge I've gained in software development.
I'd also like to write this new application in such a way that if I so desire, I can modify my existing Windows Mobile app to use the new libraries. Ideally, I'll have a shared set of business logic and data access libraries, with the only real difference being the UI layer - WPF for the tablet version, and just a standard CF interface for the Windows Mobile app.
Taking this into account, I'll need to make sure that all of the projects I create are compatible with the .NET Compact Framework. Is there an easy way to ensure this? One thought I had was to use a Smart Device Project for each class library that I create.
As well as this, is it easy for me to reference these libraries written for a .NET CF application from a standard windows application?
Is developing an application for a tablet PC the same as developing any normal windows forms application? Is there a different version of the .NET Framework to take into account, or are tablets pretty much standard windows pcs?
There isn't a special version of .NET Framework for Tablet PC. The question of sharing code between Windows Mobile and Windows has been asked before and the accepted answer is excellent.
The tablets I've seen are running standard Windows with the "full" .NET, but I expect you can get some light-weight devices, too. One interesting possibility might be "client profile" (a subset of the regular "full" .NET dlls) - but I haven't seen much use of that myself.
CF and regular .NET share a lot of things, but ultimately there are differences; neither is a strict subset of the other. I've found that in general the only way to write code for 2 frameworks is to keep both active... for protobuf-net (which has this problem) I keep a project file for each framework so that I can quickly test that the build works everywhere (i.e. there are no missing methods etc).
You may find you need to use #if blocks to run slightly different code on the two frameworks, especially if you want to use "full" .NET features for performance reasons (that don't exist in the CF version). One way of making this easier it to hack the proj files to use recursive file inclusion:
<Compile Include="**\*.cs" />
Now you don't have to keep adding new files to both projects - it'll get picked up automatically (caveat: in the IDE you may need to unload/reload the project).