I've made a WPF Browser Application that hosts old WinForms controls (I haven't migrated fully to WPF yet). Using WindowsFormsHost means my Browser App requires Full Trust to run. This is not a problem for me since this app is only meant to be run on the intranet at my company. However, after I deploy the xbap to a network share, it refuses to run, saying "Trust not granted".
What are the methods I can use to grant Full Trust to XBAP applications stored on my companies intranet?
So far, I've found 2 ways to do this. Through a really complicated method of installing certificates on the target machine.
Or through a simpler method, which is only suitable for intranets here:
Deploy a custom CLR Security policy
that modifies the default
permissionset for the given zone
So I did just that, and it works. Here's the detailed steps how I got it to work:
Open Control Panel > Administrative Tools > .NET Framework 2.0 Configuration
Expand Runtime Security Policy > Machine > Code Groups > All_Code
Right Click All_Code and click New…
Create a new code group, I named mine MyProject_FullTrust_Zone
Choose the URL condition type and specify the path on the network where the apps will be deployed.
Choose Use Existing permission set, and set it to Full Trust.
Now the only problem with this method, is that I have to deploy this change to hundreds of machines. So maybe there's still a simpler way to do this?
It will be possible in .Net 4.0 planning to be released in the first half of 2010. It is now in a beta phase, but it comes with a go live license which allows you to 'go live' even with a beta version of the .Net framework.
Although I haven't tried this, is the path to the XBAP added as a trusted site?
Related
I've created a wpf application. Now I need to make an application to download it from a web site to various client machines with no server software. What are the essential requirements that need to be installed from the web to the client in order for the application to work? I am very new to this and am learning as i go along
As stated by the others you may publish your application using clickonce. An alternative approuch is to use a third party installer like wise(yee old .msi is removed from newer visual studios). MS wants you to use clickonce for deployment it may be done manually using mage, through MageUI or visual studio directly. I only use mage.exe for deployment of WPF and XBAP applications, it's nice if you have a buildserver set up and all. Just make some scripts for the deployment that you may reuse, once deployed check your manifest file to see what's included and not.
General information about clickonce.
Mage.exe located in your windows sdk for manually deployment
MageUI, useless for any live production envirnoment...
Hope it helps you some, I know this can be a pain.
Cheers,
Stian
I am thinking of making a website using a WPF browser application, but would like to know the minimum requirement a client/internet user must have to access this website made by using WPF.
Please state even the very basic requirements, like does he need to run Windows or will even Mac and Linux do, with any browser to view the application?
Three main requirements:
User has to run the application under Windows;
The browser should be either Interned Explorer or Firefox;
The .Net Framework should be installed on user's machine.
One requirement is to have the .NET framework installed (same version as you used to build your application), so that means it will only run under Windows.
Also I think only Internet Explorer and Firefox support XBAP applications.
Also I assume that you know there is a lot of restrictions for you, the developer, on what is allowed or not compared to a full trust program. For example, the file system and registry among other things are restricted in a WPF browser application.
I have a couple questions regarding Silverlight 4:
Does running a Silverlight 4 app, out of browser, in full trust, require the
user to respond to a dialog asking for permission? If so, is there a way around this?
If the answer to #1 is yes, is the user prompted with the same dialog each time
the app is updated?
Is full trust only available in an out of browser app, or is it available via the browser as well?
If an app is installed out of browser, does the user have to actually do
anything to get the app installed? Or is it all transparent?
Are there any other installation issues with Silverlight 4 apps that would
make installation problematic for a user.
The main reason I ask all this is because we're considering Silverlight 4 for our corporate internal apps and we'd like the deployment process to be seamless and transparent. And since they are internal apps, we don't need our users to confirm it's ok to install in full trust.
No way around this, the user will be asked whether they trust the application the dialog includes a warning that the application requires elevated trust.
No the application can update itself without their seeing this same elevated trust warning again.
Currently in SL4 its only available to OOB apps. SL5 will allow administrators to extend elevated trust to in browser apps via group policy.
The inbrowser version needs to give the user a some form of UI (button) to invoke installation (the ability to install is also added to the default context menu for the application). The user will then need to agree to the dialog presented. After that the user will need to close their current usage and manually start the newly installed app.
Not that I know of, a part from the presence of Silverlight runtime there are no other dependencies.
For you requirements you might be better looking at a different technology right now but SL5 may fit your needs in the future.
It's possible to install a Silverlight application as an OOB application with elevated permissions using the command prompt. If you have a system adminstrator controlling what the users get installed on their computers you can install the application without bothering the user.
When the application is installed an update will not prompt the security dialog. But in some scenarios it makes sense to restart the application.
In SL4 elevated trust requires the application to run OOB.
Have a look at this article about signing Silverlight applications it might help you with several of these issues. By signing you could overcome trust issues and the users to be bothered with dialogs.
EDIT Read this too it explains more about trusting the publisher and updating
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
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