I am working on deploying an application to a mass of windows mobile 6.1 devices and I need to come up with an automated-as-possible solution.
I need to do the following tasks:
1. Install an application CAB file to the devices (contains within it a CF 3.5 CAB if needed)
2. Run the installation on the devices
3. Change some device settings (background, theme, Items on the "Today" screen, etc)
How much of this can I automate in a script? And what's the best way to deploy it? I would ideally like to get this accomplished over some form of web delivery.
Related
I know from the documentation here that I cannot use Docker to run WPF applications. However I have the use case that I would essentially like to create containers that can easily be shared to then deploy my WPF application onto another Windows computer or VM.
The purpose of this is to be able to quickly deploy new test versions of the WPF application without having to provide testers access to the full code base and expect them to rebuild or have to develop and maintain a full installer at an early stage of development.
The application is MVVM based WPF with Prism, with a target framework of .Net Core 3.1 and a SQLite database.
The bolded text below implies this is possible:
Docker is for server applications—Web sites, APIs, messaging solutions and other components that run in the background. You can’t run desktop apps in Docker because there’s no UI integration between the Docker platform and the Windows host. That rules out running Windows Forms or Windows Presentation Foundation (WPF) apps in containers (although you could use Docker to package and distribute those desktop apps), but Windows Communication Foundation (WCF), .NET console apps and all flavors of ASP.NET are great candidates.
However I have struggled to find clear documentation for how to do this. Is this possible and if so where can I find the appropriate documentation? If I have misunderstood this please let me know, I am also unsure if this question belongs here or on the Software Engineering stack and am happy to move it if necessary.
Thanks!
I have windows phone silverlight app with mvvmcross. This app using in-app purchases. I want to port the application in Windows 10. The best way is probably the creation of universal application for Windows Phone and Windows 10. But I don't have necessary time.I want to realize the transfer in stages:
Porting app to Windows 10 with in-app purchases.
To implement user authorization in app and data synchronization between applications.
Possible upgrade silverlight app to universal app for Windows Phone.
What technology should I choose for stage 1 - WinRt or universal app? If I chose universal app I can not synchronize purchases between applications in the first stage. Synchronize of purchases I can only implement the second phase of the user account. This behavior of the application will not meet the expectations of users. How to solve this issue?
If you want a Windows 10 app, everything is UWP now (choose Universal Windows).
It's probably best to start with a new Windows 10 project and start moving code from you old project to the new one. Most will work. Some need rework. Some XAML definitions are changed, most code should work.
Also have a look at this blogpost with more helpful tips: http://blogs.windows.com/buildingapps/2014/12/17/bring-your-windows-phone-silverlight-apps-to-windows-runtime-xaml-prepare-for-universal-app-development-in-windows-10/
Martin
I have a WPF application, which until now - was an browser-based application. Now - due some changes in project i want to be able to run that application as desktop application. My question is - is it possible, that by using single CSProj file, and adding extra build configuration, to have single WPF Project which would build to desktop and web-based app? I want to be able to choose between options:
Debug (application is building as web-WPF-app, and is launched in web browser)
Release (same)
Debug Desktop (application is building as desktop-WPF-app, and is launched as client-desktop app)
Release Desktop (same)
Kind regards
Szymon D.
The output type of a project is independent from the Build configuration in Visual Studio.
Also, why? Why not factor out the things that are shared into DLLs and creating separate projects per output type?
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.
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