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?
Related
I've been searching around and I can't find any clean ways to render PDFs in a native WPF application. Most solutions are either paid or run with errors or cannot load PDFs for my particular use case in Civil Construction.
Does WPF have any built in PDF renderers?
There's a built in PDF API in the UWP Runtime under the following nuget package:
Microsoft.Windows.SDK.Contracts
If you check under Windows.Data.Pdf there's actually an example link to GITHub for a very barebones PDF Renderer--that just so happens to be robust enough to load up Civil Construction PDFs: https://github.com/Microsoft/Windows-universal-samples/tree/master/Samples/PdfDocument
Of course the example is running on UWP so you'll need to go into the Windows settings (which should be auto-prompted if you've never installed UWP developer packages) and enable developer mode. This will give VS access to run UWP applications on your computer. You can search "developer" in the Windows settings or they're located under:
Settings -> Update & Security -> For developers -> "Developer Mode"
For the build platform in the configuration manager change from ARM to x64 (or x86 if you're on a 32-bit machine) and the program should run (works in VS Community 2019).
We already have a working UWP app for x86, x64 and ARM. Everything is fine regarding store certification, all tests are passed, including with .NET native compilation.
We would like to use the Desktop Bridge (similar to what is specified here: https://blogs.msdn.microsoft.com/appconsult/2016/12/19/desktop-bridge-the-migrate-phase-invoking-a-win32-process-from-a-uwp-app/) to add a small .NET 4.6.1 WPF side-kick app to the main UWP (x86, x64) versions. The WPF app has three dependencies(x86 and x64) on some native dll's which are packaged together with the rest of the app.
We added the WPF.exe app and dll's to the existing UWP package (like specified in the above blog post - using xcopy) and built packages for HockeyApp. Locally and functionally, everything works fine for both x86 and x64. Once uploaded to the ms dev center, the Store certification unfortunately fails with the following error:
"Package acceptance validation error: Apps converted with the Desktop
Bridge and that require the .NET Native framework must be pre-compiled
by the .NET Native tool chain"
-- but native compilation is already enabled for UWP Release x86, x64.
We then tried to create a Windows Application Packaging Project (like described here: https://learn.microsoft.com/en-us/windows/uwp/porting/desktop-to-uwp-packaging-dot-net#generate-packages-for-your-desktop-bridge-app) and add both the UWP app and the WPF as dependencies. Then we created a new app manifest and store association (unfortunately it does not seem possible to reuse the existing manifest from the UWP app). We built the app store packages for (x86 x64 Release) and successfully tested everything locally. We then uploaded the package to win dev center and got again the same errors as before
"Package acceptance validation error: Apps converted with the Desktop
Bridge and that require the .NET Native framework must be pre-compiled
by the .NET Native tool chain".
As a follow up we removed the UWP project from the Windows Application Packaging Project and set the WPF app as an entry point. We then built a store package, uploaded it and the .NET native compilation error disappeared. Which is very weird...
Somehow the combination of UWP and WPF (even with native compilation enabled for UWP) causes this certification error. We have a feeling that something is wrong with the packaging.
We would really want to get this combination working or we will have to fall back to having two separate apps: one pure UWP and one packaged WPF companion app which needs to be installed separately. We truly wish we wouldn't have to do this. I'm not sure what we are doing wrong and for the moment I have run out of ideas.
PS: We also know we need to fill and submit a form regarding the restricted capability: full trust. But before we do that we need to be sure that everything else is fine.
UPDATE 4/21/2018
The workaround explained below is no longer needed, and in fact will not be accepted by the Store anymore. The right way to properly package a UWP app with a Win32 extension is to use the new VS Packaging Project, and then create the store package off of that project in VS. Details are in this blog post, see example #3 for this specific case:
https://blogs.windows.com/buildingapps/2017/12/04/extend-desktop-application-windows-10-features-using-new-visual-studio-application-packaging-project/#uvfV1r7937WrSkX2.97
OUTDATED ANSWER BELOW
You are hitting a known flaw in the Store ingestion process for packages that contain a mix of UWP and Desktop .NET binaries. The Store team is actively working on resolving this, so it will work automatically for submissions of this type. In the meantime you can do the following to get unblocked:
Manually create your.appxupload as follows (see screenshots for clarity below):
Go to the output folder for the AppPackage
Select the .appxsym files and the .appxbundle file
Create a new .zip file from those
Rename the .zip file to .appxupload
Resubmit to the Store with the new .appxupload file
I'm trying to use the LocBaml way (this might be my mistake) to localize a WPF application, but this application is deployed with ClickOnce and the publishing process doesn't pick up the localized .resource.dll.
I do add the files to my ClickOnce manifest, and I can see that this part works because when I launch the application, I get an error saying that the application can't find fr\LocalizationTest.resource.dll. (So at least it knows it should be there...)
The normal way to include a file in a ClickOnce application is simply to add it in the Project Properties -> Publish -> Application Files menu, but my localized resources are not in there.
What can I do ?
Turns out adding a dummy Resources.fr.resx in the Properties folder fixed the problem. With that the publishing process picked up the translated .dll and the ClickOnce application worked as expected.
What I want to do
I've been playing around with the newly released Silverlight 5 and Silverlight 5 Toolkit (December 2011), and I would like to try deploying my 3D Silverlight test application to a third-party hosting server (AppHarbor in my case, but I'm open to other options).
My test application is simply the default Silverlight 3D application that you get when you create a new Silverlight 3D app:
Blog: http://blogs.msdn.com/b/eternalcoding/archive/2011/12/10/silverlight-toolkit-september-2011-for-silverlight-5-what-s-new.aspx
It looks like AppHarbor (and most other hosting sites) require that you copy the required Silverlight 5 DLLs into your project, because they don't have the required SDKs/Toolkits installed on their servers.
Seems fine in theory, but I have no idea how to actually do this with Silverlight.
The problem
The problem is two-fold:
I'm not sure exactly which DLLs need to be manually copied into my project, and I'm not sure how they should be included and referenced.
After some experimentation with copying a few of the Silverlight XNA DLLs into my project and referencing the local project DLLs (instead of the SDK-installed and Toolkit-installed DLLs), the basic 3D Silverlight app now crashes when I run it in the browser -- locally. (The Silverlight plugin crashes.) I didn't have this problem before I started fiddling with the references and DLLs; the default project works just fine. So I haven't even gotten to deploying to a hosting server, because it no longer runs locally.
An aside
On the latter point above (Silverlight plugin crashing), the issue seems to be related to the 3D Silverlight functionality, which apparently requires elevated trust/permissions -- admittedly, I don't fully understand how that all works yet.
Generally speaking -- irrespective of all of this DLL/reference fiddling -- it seems like I need to check "Require elevated trust when running in-browser" in the Silverlight3dApp project properties to get the spinning 3D cube app to show up in the browser. Alternatively, if I leave that unchecked, I need to manually right-click the Silverlight 5 app in the browser and enable 3D graphics on the Permissions tab. (Side note: I'm interested in how this will effect my end-users if I ever do get this deployed. Will they have to manually adjust permissions in the same way? Anyway, that's a question for a different day.)
The point of this aside:
The Silverlight plugin does not crash if I leave everything the way it is by default.
If I copy the Silverlight DLLs into my project and reference them locally, the Silverlight plugin crashes if 3D permissions are enabled.
If I copy the Silverlight DLLs into my project and reference them locally, the Silverlight plugin does not crash if 3D permissions are disabled.
The question
Has anyone successfully deployed that basic Silverlight 5 3D app to a server without Silverlight 5 (and the Silverlight 5 Toolkit) installed?
How did you do it? What files need to be copied into my project and referenced locally? Which references (if any) need to be removed?
Sub-question: If anyone has any insights about the elevated trust/permissions issue, I would love to hear those as well.
For AppHarbor I create a folder in the Silverlight project (lib) and copy all assemblies that I am dependent on and mark all the assemblies with copy to output.
Next I use subst to make a virtual drive that points to this folder and I add all the references to the assemblies on that virtual drive. (This is not needed for AppHarbor but this way I can check out my code to any folder on any machine I want without messing up the paths)
Note that you also need to add these dll's to the repository (git/mercurial) because a standard .hgignore file will skip the *.dll files.
Have you verified you are running the latest runtime for Silverlight? Did you have a previous developer runtime installed? http://www.microsoft.com/getsilverlight/get-started/install/
Hmm... I'm going to go with the above answer. I'm using the latest Silverlight 5 runtime and Silverlight 5 Toolkit and have not had any issues. Here's an app where I'm loading and animating an FBX model in Silverlight (it does require you to right click and set the permissions) and it works fine:
http://www.dustinhorne.com/necodecamp.html
As an aside I'm wrestling with whether to run in elevated trust or force the user to allow 3D acceleration. Personally I hate making the whole app elevated trust just for the 3D stuff from a security standpoint, although if you want to run it out of browser you may want to do that anyway and sign the app with a code signing certificate.
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