I am working on c# desktop windows form application using some 3rd/.net libraries and all forms are not WPF and no MVC.
I searched about this and I have some questions.
I'm expecting to change the whole gui code to wpf/XAML/ html forms.
I have two options now using asp or silverlight.
If I converted the project to asp/silverlight can I use the existing 3rd/.net libraries and I think I won't be able to get source code to recompile it?
knowing that the application contains tons lines of code and 6 projects in one solution.
what do you recommend for less effort?
and I can't use gizmox because its commercial license
If you are moving from a WinForms to a Web Server based architecture, I would definitely recommend the MVC route. Silverlight as a technology is a dead end and in addition would not allow you to reuse .net code without recompilation. Using MVC allows you to re-use your existing code, for good or for ill, in the server tier without recompilation. Even if you did use the Silverlight technology you could wrapper your existing libraries in a WCF service tier on the server and have Silverlight call it as web service.
However; the move to a web based architecture will require you to re-write a lot of your code (almost all the UX code will need to be scrapped) and this raises the question of what you are trying to achieve by moving to a web based architecture; so you need to consider both the costs and effort as being substantial - there are no quick ways to move from WinForms to Web, but depending on your business requirements you might consider using ClickOnce or XBAP to distribute your existing Windows application via a browser.
Related
I got project that will run on windows and web. I wonder if there is a solution to create that as a cross platform application . If you have any experience or any solution please let me know.
Create web service(s) for your business.
Consume them in both windows application and web application.
Configuring is the key here.
When it comes to consuming web services,may be little challenging for authentications, authorizations and marshalling data, but it is possible.
You can choose any programming language for creating web services. But languages like Java, C# or vb.net has good supporting libraries and easy to do. Any how your question tag says C#, dotnet frame work has good support for webservices using WCF.
You can share a lot of UI code between a desktop and web application using a framework like Electron. This is the method that a lot of popular products with both web and desktop apps (like Slack, Discord, and Ghost to name a few) use.
I'm trying to figure out various pieces that need to go into building for the mobile web with .NET / C#. I've so far been working mostly with native app development (iOS / Droid / B'Berry) and have very little experience with web development in general. But for the current project I'm working on, I believe a web-app is the way to go and would like to figure out what I pieces I need to get it working.
To give a brief overview of the application, our company uses SQL Server / .NET / VS for all of our web dev projects. The programmers here are familiar with this stack and I would like to keep it that way if possible. We're building a new product that needs a web + mobile view. The web view is currently being built as a separate project completely, but that can be changed if needed.
I'm just looking for some input on how to design something that handles screen resolutions, device types etc. and creates layouts appropriately in VS. Also, any best practices when trying to do this are much appreciated.
Thanks,
Teja.
handles screen resolutions, device types etc. and creates layouts appropriately
This is all presentation layer and shouldn't be a concern for any development framework. Sadly, it is. For instance, I'm currently working with a JSF team and so much of the presentation layer is produced via the JSF framework and it's a nightmare to maintain a sane presentation layer code base that way.
.net used to be that way too. Much of the early days of asp.net was full of invalid markup, bloated generated JS and the legendary postback cache tag.
Ideally, you'd have a presentation layer team that was independent of the particular framework. Mobile apps, more than anywhere, require the ability to maintain a lean, streamlined presentation layer and the best way to handle that is to let your team write their own HTML, CSS and JS as needed. I've worked with a C# team that was heavily using RESTful services that worked fairly well. We had built our own template framework and all HTML, CSS and JS was completely independent of the back end C#.
Fortunately, MS has gotten better and newer ways to implement via asp.net (such as the MVC model) can hopefully offer you better management of the presentation layer.
I was asked to create a stand alone application from a web app - I have to keep the same look and feel and of course the functionality. Basically, the end result should be the following: a standalone product that looks and does exactly the same thing as its web - based counterpart.
I have been developing for some time with asp.net and c#, but I doubt this is easy to convert to a standalone C# application.
I heard some stuff about xaml - but I am not sure what to use to make my life a little bit easier.
Should I just leave the .Net platform and turn to Java? Or if I keep the .Net what should I use?
better to keep in .net as it would be easier to migrate the code.
and .net is better than java in terms of desktop apps.
Web and desktop apps are fundamentally quite different (as much as ASP.NET Web Forms developers would argue to the contrary), but you should be able to reuse a lot of your business logic (especially if you separated your concerns properly). I'd suggest starting with a new Windows Forms project, building out an equivalent set of controls (buttons, grids, etc), and then looking for opportunities to borrow UI logic (click events, etc).
If your web app is written in ASP.NET, then I would stick with that.
If your web app was built properly and the new app has to have the exact same functionality, then you should be able to re-use most of the code whether you use WPF or Windows forms. You would just need to rebuild the UI.
Keep the .Net code and see how much you can reuse. Tell that you can't make the user interface look and work exactly the same and that there will be a lot of minor and some major differences. Add that the look and feel will be the same with added functionality.
See if you can reuse the basic data loading code. Then simply create a form/panel/tabpage for each page in the web application and see what you can reuse.
Or easier yet, create a simple windows application using a browser window and simply point to the existing app.
I need to build an application in C# that will have multiple UIs, 2 for web and one that will be the same application, but able to be used with no internet access. I am leaning towards MVC for web, then MVVM/WPF for the windows application (Silverlight is not an option). I should be able to inject a different repository implementation for the two paradigms, thus solving the disconnected-from-the-internet issue.
What I am wondering is how best to re-use as much presentation logic as possible. Ideally, I would like to be able to use the same controller/presenter-type entities to run both UIs. I'm looking for an example of a good solution to this problem. I don't see a clear path to re-using MVC's Controllers (they seem too tighly bound to the MVC framework to work), but at the same time I'm not excited about the overhead involved in implementing a custom MVVM or MVP pattern for the web (which I fear is the answer).
Alternatively, am I crazy to even try to re-use those components? Is it not worth the hassle? We can easily share the services underpinning the UIs, but it seems a shame to write such similar UI code twice.
The right thing to do is to share only the Business Layer and Database Access Layer. At least you will have consistency between all the clients.
Then build the clients taking advantage of the benefits of each platform (richness of the desktop app and simplicity in the web app)
Of course it all depends on the budget.
You have the option of using WPF for everything for max re-use. WPF can be deployed as partial trust XBAPs.
There are downsides though
* Download size can be a problem
* Clients need the correct framework version and can only run in Internet Explorer (Firefox through plugin (not working on Windows 7))
I've tried it on a solution with a small XBAP client and a larger Standalone Application - and it is really minor details that cannot be reused (Window in app, Page in XBAP and so on). Makes for nice consistent layout too.
This is slightly hackish (and not really recommended, unless you really understand what you are doing :)), but you could try creating a desktop app, which embeds a browser. This enables you to reuse the GUI. You will also need to package a web-server, which might be a problem though if you are using C#/MVC/.NET.
Why are companies still using Windows Forms and WPF applications instead of web applications?
I don't want a discussion. I want only the reasons, because in the last few days I have had a lack of confidence in my job (Windows Forms/WPF), and I think it is good way to change technology/job.
Windows applications have the best user interface and features, but they are available to the smallest audience, while web applications have the most limited user interface features, but they are available to the broadest audience.
It's up to the companies to decide between web and Windows applications that they must develop for their growth...
Some possible reasons:
Desktop applications are easily made available offline (obviously this is changing with new HTML5 stuff)
Some things are just easier in desktop applications (think complex 3D visualisations, granted you could write some Flash to do some of this stuff)
You may need to access local files / system information / other applications that are not possible from a web application
You can use the local processing power more effectively with native code than via JavaScript (again, changing as browers become better)
The scope of skills required for desktop applications is generally less than the web (think C# vs HTML, CSS, JavaScript, Flash, HTTP, etc.) so it may suit the development resources available
Companies are still using Windows Forms because it allows communication with Windows on a lower level than a web application.
WPF also allows greater data binding and has easier tools to handle complex tasks.
We still use WinForms and WPF because we need to deal with lots of data and need fast performance. And one other thing : We don't want to store our data on web servers (or in the cloud)!
Windows applications are more secured from the external world.
In my case I develop desktop applications because I need to access local resources.
It can be file system, databases, native application APIs, COM components, etc.
The only web solution is to run an inhouse web server, but most of my customers don't have IT staff to maintain that. It is much easier to just ship an EXE file to the customer (via e.g. ClickOnce).
I would love to use Silverlight for the distribution. Silverlight 4 adds access to local COM resources, but access to native code seem to be far away.
WPF and Windows Forms are starting to lose relevance in a lot of use cases. The only places where they still are a compelling presence, would be deep within the Windows/Windows Server ecosystem. For instance, you still can't write professional-grade Office plug-ins, without using WPF or WinForms.
In a more general use case, such as a classic CRUD application, for instance, you could get away with an app written in Angular or React. If you require OS-level privileges, it's easy enough to convert over to Ionic, React Native, or Electron, and get that deep functionality. Sometimes the functionality truly exceeds what you get "out-of-the-box" from WPF or WinForms (toasters, for instance are way more functional with Electron, since it leverages the next-gen HTML5 notifications). The coding experience is more REPL, and the actual code that you have to write is a lot less ceremonial (IMHO) than WPF or WinForms, so that's a big draw.
It's interesting to note, that VS Code is written in Electron. In fact, there is a significant, growing number of mainstream Electron apps.
Well, a Windows or WPF application is by far more powerful in many ways and faster to develop a richer application that is more responsive. Web applications need little more than a log on from almost anywhere but you will usually find then far more clunky and limited in functionality. So, you want a powerful Windows application with easy to use web connectivity? Simple, just create onw. We did and we can deploy a fully powered Windows based application (well WPF with amazing graphics and functionality), that our customers can log in from anywhere with the speed of a web application but without any thin client or expensive networks. My vote, stick to a windows app and leave the grunt of a web solution that provides little to those who want to develop in that technology. Having said that web is the only way depending upon what you are trying to do but if you are delivering a commercial product then say no more.