I’m looking for solution on architecting modular application model in WPF. For now I was using Devexpress POCO MVVM for architecting my WPF apps but is lack of modular extensibility and I’m looking something to work well with my current design and allow to build application composed with modules. My expectations are:
Modules are placed in remote location
Framework can download latest version when application starts (or demand module)
Application should load only subset of all modules basing on permissions of currently logged user
Framework allow integration with GUI – allowing to load list of modules and put graphical representation of module in some part of my application
Library is live and not closed project
I’m thinking about PRISM but this framework always looked little complex and heavy but maybe it was wrong impression. Another library is MEF but I don’t know if it fits my expectations.
Can I ask of some suggestion for modern library which will be good for my needs?
PRISM is a large library but is made of many optional parts making it easy to adopt just the parts you need (its not all or nothing).
Specifically it does do modularisation, with on demand load, and it does do UI composition from modules.
Its also open source.
Versions are valuable for desktop apps (WPF), Universal apps (Desktop app, tablet, phone and possibly iOS and Android via Xamarin - but I'm not sure about that!) so there should be a PRISM for your chosen platforms!
Related
We need to create an application that can be used via the browser but that can also be used while offline.
The browser Version will be used by our customer to do calculations. Each customer needs to log into the application with a username and Password.
The offline version will be used by our own employees. They need to be able to use this Version while not connected to a Network.
The data that is needed for the application will be stored in XML files.
We are mainly programming with C# and the .NET-Framework. We thought about using WPF for the client version.
I have read that you can use Silverlight or XBAP to create a browser Version of the WPF application. AFAIK Silverlight is a dying Technology. How about XBAP? Would you still invest into this Technology?
The other solution would be to create two front end applications: The WPF application as an offline application and a web application (e.g. ASP.NET MVC) as a web application. Thought, this would mean that we would have to create two frontends (more work).
Is there another alternative?
Would it be better to create an HTML/JavaScript application (e.g. with AngularJ or something similar)?
As a former Silverlight Developer I can only recommend not to use Silverlight for new application development. Microsoft has suspended the further development of Silverlight and you will not get any new features (only security fixes). I really liked the technology and the similarity to WPF but for me it is deprecated.
Even some Browsers (like Chrome) do not support Silverlight anymore and you need a workaround to get it running (See also Chrome doesn't support silverlight anymore? How to solve this?)
Develop a Backendsystem that provides a REST-API (using ASP.NET WebApi as an example) for your clients and develop a Browser client application using modern HTML/CSS/JavaScript Frameworks. If needed/required a desktop application using WPF that consumes the REST-API.
Silverlight may be dying, but that does not mean you should avoid using it. Silverlight is still a viable technology that you can use, however browser trends seem to be phasing out Silverlight support. As far as I know, Microsoft Edge browser is no longer supporting Silverlight, so you will need to use Internet Explorer. This isn't the end of the world, but it's something to think about.
As for WPF, this too is being replaced by Windows Universal Apps, albeit slowly. However this isn't too much of an issue as the skills you have learnt in WPF are easily transferrable. WPF itself is not receiving as many new features as it used to, you could say it's finished.
It isn't always easy to keep up with the latest trends, and there will always be something cool and hip just around the corner, however one thing is for sure, the .NET Platform, including the new refactored Universal App APIs are here to stay, and won't die any time soon.
The current trend sees Web Technologies, such as ASP.NET playing a much bigger role than traditional desktop/tablet/phone applications. I would say that developing for a web browser is certainly a popular choice.
That being said, Windows Universal Apps is also a good choice, in fact, any technology that makes use of the .NET Framework is ideal.
As for my recommendation, I would suggest looking into an ASP.NET web application or Web API to which a desktop application, such as WPF (still a viable technology for enterprise applications) or Universal Windows App can hook into. An ideal scenario would be that both applications share the same back-end code, which is certainly possible as they both use the .NET Framework.
For your requirements, it may even be possible to avoid having to create a desktop application altogether, a web application can be hosted on a machine on the local network and clients can still use the web app. This is assuming that these clients don't have internet access of course.
TL;DR: .NET is legit, use ASP.NET.
Windows.Forms library contain many bugs which effectively prevent applications from working. WinForms Designer is unable to put WebBrowser control on form. NotifyIcon class doesn't work under LXDE (see the bugtracker of KeePass). Clipboard class is incompatible with default manager of Calculate Linux. Drag and Drop have problems in DockPanelSuite. WinForms Designer is not finished because of opacity problems. WPF was never implemented and no plans to do it.
And mono team says "we don't want to develop WinForms, because this is old technology."
How should one port desktop C# application from Windows to Linux? Rewriting it with Gtk# seems to be too hard...
What is easier - to fix mono WinForms, to implement WPF, or to rewrite all applications in the world to Gtk# ?
As you have already found out Mono WinForms implementation is suitable only for very simple applications. Take a look at "Cross-Platform Desktop UIs" blog post from Xamarin employee Mike James who summarizes available solutions:
Traditional approach
WPF or WinForms frontend on Windows, GTK# frontend on Linux and Xamarin.Mac on Mac OS X. IMO this is the best way to go and it may be easier than it looks if you have correctly separated business and presentation layers in your app.
XWT
XWT toolkit uses the same API and provides native look on all platforms but only a limited subset of components is implemented. Its usability for your projects depends on what components you really need.
HTML frontend
Create HTML frontend using simple WebView component or Awesomium HTML UI Engine. This may be a viable option in some cases but I am not sure whether it is possible to implement systray icons with this approach.
QTSHARP
Open source project which aims to implement .NET bindings for multiplatform QT toolkit. I have never tried it but according to project website it seems to be in early stage and currently tested only on Windows.
BTW I am currently using WinForms for Pkcs11Admin application but I plan to use traditional approach as soon as I hit a blocker bug on any of the supported platforms.
We're building a Silverlight 4 LOB application. However, we're concerned that not all our clients will be able to support Silverlight. For example, most of our clients will be large companies and it's possible their IT department hasn't authorized Silverlight to be installed on user machines. And it's possible that some of our clients will have installed 64 bit versions of IE on user machines. Both of these situations would prevent our clients from using our app.
To deal with this possibility, we'd like to build our app in such a way that it could easily be hosted as a WPF application, if we had to drop back to that position. Our middle-tier and backend would be the same, regardless of the client used.
We're going to initially build our app to be a Silverlight app. A WPF version would come a bit later. My question is this. What precautions should we take, when building our Silverlight app (UI), to make sure the app easily ports to a WPF app (using ClickOnce)?
WPF is (near enough) a superset of Silverlight, so it should be easier going from Silverlight to WPF than it is going the other way. As long as you are using an MVVM framework which abstracts over any platform specific features, then porting the code will be simplified (I would recommend Caliburn.Micro).
Rocky Lhotka (the author of the CSLA business object framework) has a nice blog post on some of the differences between Silverlight and WPF, and things to consider when targeting both platforms.
One of your problems will be solved by Silverlight 5, since SL5 plugin will work in the 64 bit IE.
Porting from silverlight to wpf shouldn't be too hard. One thing you can do to guard against possible issues is to get 3rd party library of ui controls that work on both silverlight and wpf. I'd sugest to start with silverlight and move to wpf only if you see real push back from your clients.
I want to create a desktop like app, but I'm kind of confused as to which technology to use. It seems Silverlight functions like a desktop app. Which technology is better suited and has is more future proof?
WPF is the framework to go with if you are building a desktop application. Silverlight is more of a web application framework. It all depends on where and how the application is being used.
This Question compares the two.
Desktop apps should be built with WPF. Silverlight has a lot of security restrictions which doesn't make life easier.
Which technology is better suited and has is more future proof?
This depends a LOT on the purpose and goals of your desktop application.
If your application needs to interop with the system in a "non-standard" way, or provide other types of 3rd party interop, WPF will be a superior solution (at least until SL 5's P/Invoke support).
However, if your application is a LOB application, Silverlight (running OOB) has many advantages - especially if you want to take advantage of things like RIA Services (which hasn't been ported to WPF).
WPF has at its disposal the entire .NET framework while Silverlight in an attempt to be lightweight has a part of the framework (plus some really cool things). So, it really depends on the scope and deployment methods. To me it makes more sense to make a Silverlight application a desktop application than to make a WPF application deploy through the web. But again, let the scope dictate. If you're wondering which to learn, the answer is simple - either one as they are similar enough that when you're good at one you'll be okay in the other.
If you're used to WPF, you'll find that Silverlight lacks a bunch of major and minor features like data triggers, FindAncestor, synchronous WebClient requests, and so on. Probably not deal breakers but definitely annoyances.
For the experienced WPFers out there, how re-usable are WPF, Silverlight and Silverlight OOB applications and components? How much overlap is there?
For example, could I write one application and easily deploy it in the three aforementioned ways?
Ideally, I want to write as little code as possible and have the flexibility of deploying it in a range of scenarios, maybe enabling certain functionality depending on deployment. The WPF family of technologies seems like a good starting point to the casual observer.. but is it really?
The simplified version of the answer is:
1. Silverlight is roughly a subset of WPF.
2. Silverlight in browser apps and Silverlight OOB apps are running on exactly the same framework. It is just a deployment difference.
3. Some OOB apps can be installed as "trusted" apps, and have looser security restraints than in browser apps.
Porting a WPF app to Silverlight is likely going to be very difficult, as a WPF app is likely to use many features of the .net framework that are not available in the smaller subset of the framework available to Silverlight apps. This is something you probably want to avoid.
Porting a Silverlight app to WPF is likely to be significantly easier. It would still be a challenge as there are features in Silverlight not in WPF (though not nearly as many as the converse). In addition to the feature delta, the actual framework that runs the Silverlight/WPF apps are different, so during the porting you would likely run into a certain amount of behavioral differences between the two.
Silverlight and Silverlight OOB apps are running on the same framework. It is possible to have the exact same app binary run in both places. For the most part, they will be behave identically. Some differences: in-browser apps can rely on browser features such as accessing the html dom, invoking javascript, etc. An OOB app doesn't run in the browser so obviously this doesn't apply. Also, if we are dealing with a "trusted" OOB app, it can do things that are prevented for security reasons in the browser (e.g. COM interop).
If you want to create an app that runs in all three places, my advice is to start building the app as an in-browser Silverlight app that is self-contained, i.e. it does not rely on the web page that is hosting it, and includes all the necessary resources inside the xap package (rather than relying on them being next to the package on the web server). Porting such an app to a Silverlight OOB app would be a cinch - pretty much just check a box in Visual Studio and you are done. Porting it to WPF would be a significant amount of work, but it would be much better than going the other way.