I'm trying to get my head around the many application deployment options which Microsoft currently offers.
Doing a little research turned up dozens of confusing terms:
"WPF App"
"ClickOnce App"
"WPF ClickOnce App"
"MSI App"
"XBAP App"
"XBAP App deployed with ClickOnce"
"Installed ClickOnce App"
"WPF Web App"
"ASP.NET Web App"
"ASP.NET MVC Web App"
"Silverlight App"
"Full WPF App"
"ClickOnce with sync framework support"
I cleaned up my findings into seven separate approaches below. Would appreciate feedback:
"WPF App deployed with MSI" (allows lots of installation options)
MSI runtime required on target computer
wizard with options
can specify per-user or per-machine
can modify files and registry on target computer, limited only by access permission set by administrator
can place shortcut on desktop
replacing system files, etc. makes it easy to get into DLL hell on the target computer
updating is a big negative: detecting available updates requires additional tools / custom programming, not built in
user does not have to be online to use application
"WPF App deployed with ClickOnce": (good if you want automatic update but runs in sandbox)
requires two clicks (click hyperlink, click yes), no user input
only for current user, no per-machine installations
no shortcuts on desktop
appears in program list like normal applications
applications files are always copied to ../My Documents/My Applications
a shortcut to your application will be put in Start menu / your company name
cannot modify the target computer, isolated from operating system
automatically detects and updates a newer version
published simply by putting them on a webserver (where clients detect and get them)
requires .NET 2.0 or later
comparable to Java Web Start
solves four problems: (1) easy deployment, (2) easy updating, (3) low-impact on target computer, (4) no need for administrator permissions.
considered "low impact"
if two users have the same ClickOnce application installed on the same machine, they will not break each other
employs CAS for security
user does not have to be online to use application
standalone ClickOnce apps do not work on Firefox and Mac with Firefox now since it needs the .NET runtime
restricted to single-window apps since they run in the browser
building a ClickOnce manifest is much easier than Silverlight etc, since the IDE will do almost all of it for you; you just have to host the files somewhere (could be a web URL; could be a network UNC).
"XBAP App": xcopy deployment of .xbap file, IE and Firefox display it instantly like a web page
the real goal of the XBAP model is to create a WPF equivalent to the traditional HTML-and-JavaScript website (or Flash applet)
the target computer simply runs the application without installation over the web in their web browser (IE or Firefox)
They're good for Intranet applications where you want really easy deployment, the complete .NET Framework (as opposed to Silverlight) and a browser's navigational model.
99% WPF features (as opposed to Silverlight's subset of WPF features)
CAN be automatically deployed via ClickOnce as well but XCOPY is more common
YourApp.xbap is really a ClickOnce deployment manifest
run in sandbox
user must be online to use application
these must be "page-based" applications as opposed to "windows-based" applications
"An XBAP appears to run inside the brwoser simply because it displays all its content in the browser window. This is different from the model used by ActiveX controls (and Silverlight), which are loaded inside the browser process."
XBAPs offers a "prompt-free" experience, as long as .NET 3.5 is installed, it just shows up in the browser like a web page.s
XBAPs are not allowed to use WinForm controls via Interop
not allow to use windows drag and drop
most advanced WCF features are NOT allowed and XBAP can't communicate with any server other than the one where the XBAP is hosted
"if your application requires full trust, you should consider building a stand-alone WPF app and deploying it using ClickOnce" (Pro WPF in C# 2008)
trick: you can embed multiple xbap applications into multiple iframes on one HTML page.
"Silverlight App": runs in client's browser and uses downloaded 4MB subset of .NET framework, i.e. no 3D)
cross browser (applications can be used by Opera and Safari as well)
updating application is as easy as with ClickOnce or XBAP
single window apps
application is in the sandbox of course
async only
"ASP.NET MVC with JQuery/AJAX": a new development platform equal to development in WPF in terms of RAD and TDD
this approach is worth considering along with the WPF/Silverlight approaches
"ASP.NET App": classic web application with ViewState, etc. probably will be used less and less as ASP.NET MVC gains acceptance
"WinForm App": classic windows application, will be used less and less as WPF gains acceptance
I would particularly appreciate feedback on:
how reusable are controls (e.g. if we develop in Silverlight, can we reuse our code/controls in XBAP?)
what is the best approach to clients which are sometimes offline, sometimes online AND need access to WCF (probably clickOnce apps I would think)
Great Summary, Edward.
Much of the code in Silverlight can be directly used in WPF & WPF XBAP apps because Silverlight is a subset of WPF. For XAML, you will have to change the namespace URI and probably have to do some slight manual tweaking.
For XAML to Silverlight conversions, you will have to do change the namespace URI as well but refactoring might be necessary if WPF elements are used that are not in Silverlight.
WPF and the Sync Framework are great options for online/offline applications. See the Syndicated Client Experience Starter Kit for an example of a WPF/Sync Framework app. Also Silverlight + Windows Live Mesh will provide online/offline capabilities.
AppStart experience:
MSI =
Only Windows. Many clicks. Install before use. Good for very huge and resource intensive apps. App can be distributed on dvd. App can do everything. No technology restrictions.
ClickOnce =
Only Windows. Can be activated from webpage. Is downloaded once. Keeps info abouts it origin (Server) and can automatically update. App is restricted. Needs .NET
Silverlight =
Runs on Windows/Max/Linux(soon) and future Mobiles(planned). Is a webpage or can be embedded into html. Code is on Server and will never be installed. Needs Silverligth-Runtime. Provides subset of WPF
XBAP = Like silverlight but only for windows. Nobody will need that. Silverlight is better
Programming technology:
Silverlight =
Runs on client maschine. Uses WPF*
ASP.NET =
Runs on server maschine in .NET but Javascript/html on client maschine.
WinForms = old technology
WCF = won't work for browser based apps. Is for distributed apps. One could open up all doors into client mashine. Using WCF = needs MSI.
WCF provides a good framework for server. You will never need WCF on client when you use REST for interfacing. The client can be connected/disconnected in ClickOnce and MSI installed apps. You have to connect to a webpage for appstart in silverlight and ASP.
XAML can be reused for silverlight/wpf/xbap. Minor changes in wpf/silverlight. No changes in wpf/xbap as I know.
The deployment options MS supports for client applications are
MSI (Any Windows app)
Clickonce (only for .Net client apps)
Clickonce is not WPF specific.
XBAPS are clickonce deployed, browser hosted WPF apps in a trusted security sandbox.
WinForms apps can be clickonce deployed and can be browser hosted.
Silverlight is (mostly) source compatible with WPF. You can recompile SL controls as WPF controls.
Non browser hosted clickonce is probably a good fit for you.
I wouldn't be so quick to dismiss XBAP as "Silverlight for Windows only". Because it uses the complete WPF set, it is possible to use the same codebase for both a WPF App and an XBAP, as long as you work within the Partial Trust restrictions imposed on XBAPs.
Also, as of .NET 3.5, WCF does work in XBAPs under Partial Trust. You can't do as much as in a full trust WPF App, but it is still useful.
You listed "MSI App". Windows Installer is Microsoft's technology for installing and upgrading programs on Windows. The installation packages it creates have the ".msi" extension. (It was originally going to be called "Microsoft Installer". They changed it to "Windows Installer", but keep the extension.) It defines a standard way to create install packages. Packages can be created by many different tools (InstallShield, WiX, Visual Studio, etc). It's not limited to WPF apps. You can use it to install almost any kind of application.
Another deployment option made available by the Live Framework (Live Mesh vNext) is the Mesh-Enabled Web Application (MEWA). This lets you package up Silverlight, DHTML, and Flash apps to run online in the Live Desktop or online/offline on the Windows desktop. You can install a MEWA into your Mesh and have it automatically deployed to all the devices in your Mesh. If a new version of an app is released, the update can be synchronized to all devices as well.
There are hints that in addition to Silverlight/DHTML/Flash, future versions of Live Framework will support MSI and CAB packaged apps, presumably with similar deployment features.
Documentation for Mesh-Enabled Web Apps:
http://msdn.microsoft.com/en-us/library/dd199554.aspx
Related
Is there any difference between Standalone applications and Markup-only XAML applications in respect to WPF?
I am reading the following link where I got reference of these two application however for deployment perspective but is there really any difference between these two?
Deploying a WPF Application
Differences, reasons and scenarios are explained in the official MS documentation. I think there isn't much more to add.
From Deploying a WPF Application (WPF)
Deploying WPF Applications
The deployment options for a WPF application depend on the type of application. From a deployment perspective, WPF has three significant application types:
Standalone applications
Markup-only XAML applications
XAML browser applications (XBAPs)
Deploying Standalone Applications
Standalone applications are deployed using either ClickOnce or Windows Installer. Either way, standalone applications require full trust to run. Full trust is automatically granted to standalone applications that are deployed using Windows Installer. Standalone applications that are deployed using ClickOnce are not automatically granted full trust. Instead, ClickOnce displays a security warning dialog that users must accept before a standalone application is installed. If accepted, the standalone application is installed and granted full trust. If not, the standalone application is not installed.
Deploying Markup-Only XAML Applications
Markup-only XAML pages are usually published to Web servers, like HTML pages, and can be viewed using Internet Explorer. Markup-only XAML pages run within a partial-trust security sandbox with restrictions that are defined by the Internet zone permission set. This provides an equivalent security sandbox to HTML-based Web applications. Markup-only XAML pages can be installed to the local file system by using either XCopy or Windows Installer. These pages can be viewed using Internet Explorer or Windows Explorer.
Deploying XAML Browser Applications
XBAPs are compiled applications that require the following three files to be deployed:
ApplicationName.exe: The executable assembly application file
ApplicationName.xbap: The deployment manifest
ApplicationName.exe.manifest: The application manifest
These files are produced when an XBAP is built. Like markup-only XAML pages, XBAPs are typically published to a Web server and viewed using Internet Explorer.
XBAPs can be deployed to clients using any of the deployment techniques. However, ClickOnce is recommended since it provides the following capabilities:
Automatic updates when a new version is published
Elevation privileges for the XBAP running with full trust
By default, ClickOnce publishes application files with the .deploy extension. This can be problematic, but can be disabled. For more information, see Server and Client Configuration Issues in ClickOnce Deployments.
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.
Can I use Silverlight to build cross-platform desktop widgets?
Silverlight Vs WPF
First of all, WPF is not exactly Silverlight. They essentially require different run times. Silverlight Runtime is a subset of .NET, and needs to be installed by the client, to view your SL applications over a browser. Presently SL runtime is available for Windows and Mac. Moonlight is still not full fledged, and is evolving, for Linux.
WPF, on the other hand, is purely on top of .NET runtime, and is available only for Windows.
You can use XAML to develop user experiences in Silverlight and WPF, and as long as you stick to the Silverlight subset, you can compile your XAML in WPF as well.
Desktop Widgets
Now, your thought about building cross platform 'desktop' widgets - Do you want to host a Silverlight application in a desktop window? Silverlight 3.0 provides support for hosting silverlight controls out of the browser.
Otherwise, see my blog entry on hosting Silverlight using a browser shell. http://amazedsaint.blogspot.com/2008/12/thinking-outside-silverlight-sandbox.html.
This post is revolved around
Hosting the HTML Page with Silverlight
in a Winforms/Webkit desktop application
using a web browser control, and
communicate to and fro using HTML
DOM
Embedding a light weight web server
with in the Host application, and
handle requests to perform such
operations
But remember - it is not WPF. Hope this clarifies.
In Silverlight 2.0, you won't have any such luck.
In Silverlight 3.0 (currently in beta), however, support has been added for Out of Browser Capabilities, which means you can download and run Silverlight apps from your desktop.
The Silverlight platform in general is cross-platform, so external (desktop) aplications in Silverlight 3.0 will be exactly the same.
Quoted from the What’s New in Silverlight 3 Beta? section of the release page:
Out of Browser Capabilities. The new out of browser experience in
Silverlight 3 enables users to place
their favorite Silverlight
applications directly onto their PC
and Mac, with links on the desktop and
start menu—all without the need to
download an additional runtime or
browser plug-in. Further, the new
experience enables Silverlight
applications to work whether the
computer is connected to the Internet
or not—a radical improvement to the
traditional Web experience. Features
include:
Life outside the browser. Silverlight applications can now be
installed to and run from the desktop
as lightweight web companions. Thus,
users can take their favorite Web
applications with them, regardless of
whether they are connected to the
Internet or not.
Desktop shortcuts and start menu support. Silverlight applications can
be stored on any PC or Mac computer’s
desktop with links in the start menu
and applications folder, and so are
available with one-click access.
Safe and secure. Leveraging the security features of the .NET
Framework, Silverlight applications
run inside a secure sandbox with
persistent isolated storage. These
applications have most of the same
security restrictions as traditional
web apps and so can be trusted without
security warnings or prompts,
minimizing user interruptions.
Smooth installation. Because Silverlight applications are stored in
a local cache and do not require extra
privileges to run, the installation
process is quick and efficient.
Auto-update. Upon launch, Silverlight applications can check for
new versions on the server, and
automatically update if one is found.
Internet connectivity detection. Silverlight applications can now
detect whether they have Internet
connectivity and can react
intelligently including caching a
users’ data until their connection is
restored.