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.
Related
Looking for opinions. I'm working on a mid-sized 3-tier ASP.NET project (.NET 2.0 and Visual Studio 2005) with an Oracle on Unix back-end, some beefy MS web servers, and IE browser clients. Performance is pretty bad, and users feel the UI looks outdated as well. We may have an opportunity soon to redesign and rewrite the entire application from the ground up, and I'm wondering what the current or recommended MS platform is.
I was involved with WPF and Silverlight on a different contract when MS downgraded support for Silverlight in favor of "HTML5" for Windows 8 and Windows Phone a few years back. I'm not trying to start a flame war between how long Silverlight or even WPF will be around, but I'm looking for some modern alternatives as of today, April 2013. The one requirement we can't get around is that we can't install something on each and every user PC throughout the client organization.
My own background is in WinForms and C# more so than any of the above, but everywhere I turn it seems developing any new LOB apps in WinForms isn't done much anymore.
Whatever happened to the Application Server platform and apps run thru Remote Desktop? Does it still make sense to develop desktop apps and deploy to app servers and just put a shortcut on each user's desktop, or even map a drive letter like we used to do back in the day?
Your $0.02 would be appreciated!
I would definitely consider doing it as an internal web site.
The UI would be HTML5 using the "single page application" (SPA) for each function you need. Each function would be on a page that is loaded when the user needs it. The javascript/ajax code in the browser would interact with the web server which feeds back the raw data needed to be displayed.
Using Active Directory, you can have full security and customization per person.
If you need lots of interactivity, then you'd also want to consider including SignalR in the mix. (That is one of the "new" MS tools!)
If you can't install anything in the end users' PCs then go ASP.Net. Anything else will require installation.
You can make a web application more appealing to the users by having a good designer and a LOT of javascript. Not remotely comparable to the power and beauty of WPF, but that's your best bet.
WPF is part of the .Net framework and will not run without it installed.
Silverlight could also be an option, but it still requires an installation (although minimal, 4 MB, less-than-2 minute install), but an install anyways.
WinRT only works in Windows 8. It's not supported in lower versions (Vista, XP, 7). So I don't think it's an option as of now (unless all your users have Windows 8, of course).
And no, winforms is not an option. It's also part of the .Net framework, and even if you could get it installed, it doesn't make any sense having to deal with the limitations of it, having many much much better technologies at your disposal.
I am reading about out of browser silverlight applications and cannot think of many use cases for it. One only scenario i can think of is where your application need ability to work offline and when its online then it can synchronize with the server ( or something). But in that case I can simply have a WPF ( or old style Winform) application that is communicating with server. Can anyone help me understanding better uses case for these out of browser applications.
There are some good answers on SO that should give you some background on Silverlight OOB vs. WCF:
Silverlight OOB vs WPF ClickOnce
What are the advantages of silverlight out of browser over wpf or vice versa?
I will add that as a corporate developer Silverlight has its benefits over WPF or WinForms in that there is no need to install the full .NET Framework to run the applications. OOB gives a more desktop like feel w/ Start Menu icons and easy access w/out the need of visiting a URL to run the application. There are a few things that you can do in elevated trust in OOB that you can't do in the browser (though that is changing w/ full trust rights both in-browser and OOB in SL5).
Here's some of the details on the features you get access to w/ elevated trust:
http://msdn.microsoft.com/en-us/library/ee721083(VS.95).aspx
It really comes down to your usage scenarios, ease of framework deployments and the environment you are developing for. Each set of tools has its benefits and drawbacks.
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.
We are planning to build a new integration component that can provide us access to user's machine installed apps from our web site.
The first word that came to me was ActiveX, but our expertise with the technology was not the best in the past.
Thinkink a lit bit more, the work Silverlight also came to my head, but the full trust thing was one of the few things I remembered reading about the technology..
The question is: is there a way that Silverlight (2, 3, 4, whatever) can run as a full trusted application from within the browser?
Links are appreciated.
Filipe
Unfortunately, no. Full trust is a feature of Silverlight 4, currently in beta, and is restricted to out-of-browser applications.
Additionally, full trust SL4 applications do not have unrestricted access to the system (particularly file system), though this may change before before release (if I have anything to do with it).
Edit: If you are considering ActiveX (which is Windows/IE only), you might want to have a look at WPF, since it can run full trust from the browser (if it's in a trusted zone).
No, like Richard said, this is not at all possible inside the browser, even in SL4. There is a sandbox, and you live in it. You can talk to web services, other Silverlight applications or the browser.
By talking to the browser, I mean you can talk to the DOM and the Javascript engine. We needed to launch a Windows application and communicate to it via Silverlight. We accomplished this by putting a small ActiveX control in the web page. It is responsible for launching the WinForms application and handling inter-process communication to it.
This method has many drawbacks: It can only work in IE, and it only works in Windows. You might also run into permissions issues. The ActiveX component needs to be installed along with the desktop application, or as an additional download. The deployment story there is pretty awful, if you ask me.
In our case, the analysts were willing to deal with the restrictions for the re-usability of an existing application, and we consider it to be an optional feature.
Does it have to be a web application? sounds like you want a desktop app. It can be easiliy distributed with one Click deployment. Will work on windows only but since you were considering ActiveX sounds like that's what you need.
Well - if you're hosting the silverlight control from an ASP.NET application - Believe you have access to
Request.ServerVariables["AUTH_USER"];
...and you can pass that on to your control as a parameter.
D