Is Windows Universal App for me? - UI Migration [c

Question

I have a console app that does some Database management stuff connecting directly to them. It works for MsSqlServer and Oracle (for now).

As you might know, using a console app is not so productive. So I wanted to port the UI part to a Desktop app. I have all core code in a library, console app just manages user interaction.

I did some testing and can't use libraries on UWA. Then tried shared libraries and to my surprise I can't use SqlServer directly.

Are UWA the new way to do desktop apps? I dont want to connect to services and then to the database, it's good for user apps, but dont feel confident for the stuff my software does, i need 100% direct connection.

Should I try with WPF (does it work with sqlserver connections?)? WinForms? What if they drop support for WPF or WinForms like they going to do with WebForms?

Wanted UWA because it looks very good and MS made it look like it's 'the way to go'.

Any ideas?

UPDATE 1

So, some people say I could use web api or middle tier that can handle all the tasks and this way i can get around the restrictiveness of UWA. It's not a bad idea, i also thought about this. Even thought i can just have a service for tasks, and web UI, that way it will be accesible from any device. BUT harder to deploy in private/corporate nerworks.

I think it's too much architecture just for a "simple" tool.

So, after some thinkning found (probably) some middle level answer to this: I will research what projects can help me to do a native integration with Windows and other systems. Since Phones and Tablets are probably out of my targets already, then at least I will target linux and mac os .

Think this new .Net version they are working on it's going to be OSS and also multiplatform. Going to check it out and keep this post updated in case anyone else is interested.

UPDATE 2

Now im really thinking on the middle tier, but it gonna make it more complicated and longer to develop :(

For this i will need: my core library, a windows service or some kind of job/task service, front end probably html5 consuming some webapi.

Any recommendations on the task/job server?

Answer 1

In my opinion you can develop a simple API and then you can use an UWP. With this API you can get the stats data and also make calls for script deployment.

Answer 2

To answer your question, they don't support a lot of the System.Data functionality in the UWA application and you can't use handy tools like DataTable's or DataReaders (even the Sqlite implementation for UWA's doesn't have a DataReader which makes getting dynamic data difficult where you don't know the model in advance).

The recommended approach is to have a middle tier of any sort that you can call that does all of the data access for you (that approach is fine but isn't going to work for everyone's environment).

I see your options as:

1. Create the UWA app with a middle tier somewhere that does the data access calls and exposes an API in whatever flavor you decide that should be.
2. If you want XAML in the UI but UWA is too restrictive, create a WPF app where you have the full framework at your disposal to do what you want as you want. This means you can likely use all of the .Net libraries you've previously used (like your SqlServer and Oracle ADO.Net providers).
3. Use WinForms, still works, less friendly for high DPI apps (but not impossible). WinForms are "mature" as per Microsoft. They don't get a lot of new features but they're not going anywhere soon. You also have the full framework available without the UWA restrictions as with WPF.