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.
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.
I want to know what are the differences between a WPF Browser Application and WPF Desktop Application. I know that the browser application runs on IE and FF, but about the technology, is the same? I mean, we can do exactly the same by the two ways? (Of course, maybe with different UI)
I have this doubt because I'm looking for a book about WPF Browser Applications, but I only see books about WPF (I don't know if is in general or is only for desktop applications :S)
A WPF Browser Application uses exactly the same framework as a WPF desktop application and could run with the same UI, but with restrictions on trust which means that some APIs are not available. There a number of challenges in developing Browser application. A Browser app must be signed with a certificate. Some of the trust restrictions are not enforced at compile time and are only discovered at run time.
In the time since Browser Applications were first introduced, Microsoft developed Silverlight which uses a similar though not identical XAML technology. Silverlight is easier to deploy than a WPF Browser Application and may be appropriate depending upon your requirements.
A Browser Application not only runs in the browser but also with less authority. If you need to read and write local files then go WPF. Browser is good is you want rapid deployment to lots of PCs. Other wise I will take WPF Desktop every time. Most WPF books with have a chapter on XBAP. I like McDonald from Apress.
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 have been using WPF for a while, and I keep on realizing again and again that Microsoft invests its efforst in Silverlight, not in WPF (RIA Services, default theme, controls and more).
I thought it might be a good idea to migrate to Silverlight (i.e. creating standalone desktop apps with Silverlight 4.0), the question is whether this is possible or not.
BTW, I think LightSwitch applications are generated with Silverlight as standalone desktop apps.
From MSDN:
Silverlight 3 applications are no longer restricted to running in a browser. They can be run in a browser or it they can be detached from the browser and run from the desktop. These out-of-browser applications allow you to bring the richness of Silverlight 3 applications directly to the desktop without the restriction of running within a browser.
Link: Building An Out-of-Browser Client With Silverlight 3
It is possible to create standalone desktop apps(Out of browser apps) with silverlight version 3.0 or higher and it works great. Now it is also possible to install the out of browser app even without opening a browser as shown at this blog post .Silverlight is awesome and silverlight apps even run on MACs and Linux(limited support)
However, it is not true that Microsoft is only investing in silverlight. Microsoft is investing in WPF too. Though it is possible to create out of browser applications with silverlight, they have lot of limitations when compared to a full blown WPF applications.Dont forget that silverlight is just a subset of WPF, for example, silverlight doesnt have ADO.NET, Hardware device access etc. So if your application is merely a business application and you dont have to access hardware devices or database directly then silverlight might be an option, however if your application accessing client machines hardware resources directly then you are better off with WPF.
My suggestion is, If you know before hand that it is going to be a desktop application then go with WPF(or may be even XBAP). In my experience, useful applications grow with time, new features are always requested time to time. If in future,a feature is requested that cannot be accomplished with silverlight and can only be accomplished with WPF, then you will be in a big trouble because you need to rewrite your app in WPF and it will be hard for you to convince your CFO to allocate more fund just to implement one feature. Silverlight is not designed to develop desktop applications, its main goal is multi-platform support.
Silverlight 3 supports Out-of-Browser functionality.
Quote from Wikipedia silverlight page :
Silverlight 3 supports Out-of-Browser experiences, i.e., Silverlight applications can be installed to the system for offline access (provided the application manifest is designed to allow local installation) where they run outside the browser.
Also here is a quick howto
Out of browser applications have the same security restrictions as in browser applications.
With Silverlight 4 you can create full trust applications which have full access to the computer.
More on Network Security Access Restrictions in Silverlight
If you mean Out of Browser apps, certainly. The Seesmic Desktop 2 app is an excellent example of one of these apps, with it's own updating mechanism. Seems a no brainer to use the XAP/MEF plug-in Model and Silverlight in this manner.
Seesmic Desktop 2
We're developing an OOB app along the same lines, one internet download and you're done. You're not going to get exactly the same APIs as you get in WPF, though.
As others have pointed out, Silverlight apps can be installed to run 'out-of-browser', but even with elevated trust they still have significant restrictions on what they can do and certainly don't have "full access to the computer".
Creating an app from scratch, you may want to consider parallel Silverlight & WPF builds. The code can more-or-less be shared by adding the .cs files from one project (e.g. WPF) to the other (Silverlight) using "Add As Link". The XAML files cannot be linked this way and need to be duplicated, but that may not involve much more than copying & pasting, depending on your structure. There're good examples of this on the web.
Developing both types in parallel would likely involve a lot less effort than having to abruptly switch types at some point and discovering incompatibilities/limitations too late.
This question already has answers here:
Why change from WPF to Silverlight 4?
(8 answers)
Closed 3 years ago.
If I understand correctly, Microsoft Silverlight is a lightweight .NET implementation meant to run on the client side, inside a browser. So now I hear about "out of browser" silverlight applications and I'm confused.
What is the advantage of an "out of browser" silverlight application, compared to a traditional .NET desktop application?
An out-of-browser install of a Silverlight application still runs in a security sandbox where as a traditional .NET desktop application won't.
The objective of an OOB is to give the user the ability to lift a web-based application out of its browser container and make it easier to access. Its still a web based application. Its worth bearing in mind that this works on a Mac where as a traditional .NET desktop app won't.
This area has become muddier with SL4 OOB that can now ask the user for elevated trust. Now the sandbox is more relaxed and there are greater opportunities to work with the native OS. However there are still many restrictions in place primarily to support multi-platforms. It would not be desirable if it became a defacto that trusted OOBs tend only to work on Windows. It remains to be seen whether that can be avoided.
So if you're thinking of a full-fledge Windows desktop app then you're probably better off using WPF. On the other hand if you don't need full access to the OS, you can deliver via a web page and/or you want to be able run on both Windows and Macs (and possibly other platforms) then perhaps Silverlight 4 OOB+Elevated Trust may be what you need.
Silverlight 3 out-of-browser apps allow any Silverlight app to have a desktop shortcut, and don't require the browser to be opened to run the app (so technically you could now run the app even if you're offline, since you don't have to fetch the SL app via the web).
With SL 4, you can now have elevated privileges, allowing the SL app to access local resources (such as the network stack and file system).
There's also a simple API call for an out-of-browser SL app to check for updates on startup, and download an update from the server. This could be seen as similar to click-once deployment, but it happens automatically and quickly, so it's more efficient and straightforward than click-once.
Compared to a traditional .NET app (in this case let's compare with WPF, since that's effectively the WinForms replacement), there's very little in the way of installation. No setup program, just the xap file, easily hosted on the web and very quickly installable. SL uses a reduced .NET framework, which might seem like a negative. However, the typical pattern for an SL app is to put most of the heavy-lifting in a service tier. Then, in the service tier you have the full .NET framework and can do pretty much whatever you want (such as accessing databases with ADO.NET).
Libraries are another thing to consider between the two applications. For example, Silverlight 4 natively has built in support for talking to a web-camera and microphone out of the box while WPF and the full .net Framework have a very large third party community of libraries to draw upon which you might need source code for if you wish to rebuild them under Silverlight.
Another factor is limitations in the sandbox, for example, you wouldn't be able to write an application that could connect to any server using any socket in Silverlight 4.