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).
Related
I'm trying to move to MSIX to install our application, which is currently deployed to our customers via a ClickOnce installation which requires updating on startup, if there is an update. Its a .Net Framework (4.7.2) WinForms app. I'm a bit lost on how to begin; the documentation seems to start from an existing installer package (including ClickOnce), but I'd like to generate this without an intermediate step on our build server as we want to phase out the ClickOnce installation completely once we've proven MSIX will work for us.
I found the Windows Application Packaging Project, but it seems targeted to UWP app, which ours is not, and we have the need to install on Windows 7 SP1 or higher.
What tool would I use to create an MSIX package non-interactively? Would the WAPP play any role in the process?
Here is a similar thread on MSFT's MSIX community. It's talking about VS 2017, but most of the info applies to 2019 too.
https://techcommunity.microsoft.com/t5/msix-packaging-and-tools/build-msix-from-vs-2017-pro-v-15-9-4/m-p/952246
An extract from the above link:
You should be able to use the windows application packaging project to package MSIX. Please see: https://learn.microsoft.com/en-us/windows/msix/desktop/desktop-to-uwp-packaging-dot-net
Alternatively, you could package your MSIX by hand using: https://learn.microsoft.com/en-us/windows/msix/desktop/desktop-to-uwp-manual-conversion
Additionally, if you want to use the MSIX Packaging Tool, you might be able to leverage our pre-made VM: https://learn.microsoft.com/en-us/windows/msix/packaging-tool/quick-create-vm even if your enterprise is still on an older release of windows.
You can also try partner solutions, like Advanced Installer's VS extension which can build an MSIX and MSI from the same project, if you need to target different users. The extension also supports debugging apps inside the msix container.
Disclaimer: I work on the team building Advanced Installer.
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 have created an .msi installer. I want to further add prerequisites (such as .Net) but when I go to Setup Project properties, the Prerequisites button is disabled. How do I enable it?
Other details:
I'm using VS 2015, SQL Server 2008 R2, .Net 4.5.2, C#, WinForms, Win
10 Pro x64
My setup project is in the same solution as the main project
Prerequisities in Visual Studio Projects
In Configuration at the top of the dialog, did you try to select either Release or Debug? That should enable the Prerequisites... button.
Unecessary, outdated prerequisites?
One pet-peeve of mine: is it really necessary to include the .NET runtime as a prerequisite when most users have it installed by their deployment team (corporations) or via Windows Update (home and small office users)?
If there are security updates for the runtime, your old, embedded runtime is just a nuisance to be honest. Corporate packagers spend a great deal of time removing runtimes and prerequisites for corporate deployment where all runtime components are packaged separately in the corporate standard format. Perhaps consider making a special corporate "large scale deployment" version of your setup bundle? Just a zip with components will be very appreciated, along with a one page PDF on how to deploy them.
For the .NET framework you could just add a launch condition to abort the installation if the runtime is not found, and tell the user to get the runtime via Windows Update or from their system administrator or deployment team.
Just a thought I wanted to share with you. Prerequisites can really bloat a setup - especially when they are almost never needed like the .NET framework. In the future we will certainly pull prerequisite packages straight from online repositories and not embed anything in our main setups (and probably struggle with new security issues from that approach).
What version of the .NET Framework is included in what version of the OS?
Selectively disable versions of the .NET Framework (.NET versions overwrite each other)
WiX and other deployment technologies
Setup projects are rather limited. If you find yourself needing more features, you might want to check out the WiX toolkit.
Here is a previous answer on WiX and other deployment tools that seems to have been helpful for people: MSI vs nuget packages: which are is better for continuous delivery?
MSDN does not list a WPF .exe as a supported type of application for ClickOnce
A ClickOnce application is any Windows Presentation Foundation
(.xbap), Windows Forms (.exe), console application (.exe), or Office
solution (.dll) published using ClickOnce technology.
http://msdn.microsoft.com/en-us/library/t71a733d.aspx
I do find evidence around the web that non-XBAP WPF apps work with ClickOnce, but are they officially supported?
Yes, ClickOnce does support WPF applications compiled to executables. ClickOnce is nothing more than an installation distribution method. The primary difference between creating an installation package and ClickOnce (other than being web-based) is that ClickOnce applications are installed within obfuscated folders within the end user's Windows directory.
The means that ClickOnce applications can be installed with a non-administrator account. The caveat to this method is that an application can not be installed on a PC and shared across other user accounts on the PC-- each user must re-install the application.
WPF requires the .NET 3.0+ framework. When you publish your ClickOnce application, you will need to include the .NET 3.0 (or 4.0) framework. Once you add the prerequisite to your project, ClickOnce will check the user's PC to see if the framework is installed. If not, it will pre-install it before installing and running your application. If it already exists, it will skip the download and installation of the framework.
If you need to install a third-party library or application, custom pre-requisites can be created and added to your projects. It is worth noting, prerequisites may need to be installed by an administrator, depending on the rights of the end user. This may seem a bit counter-intuitive, but it's just the nature of the installation process.
ClickOnce is a very simple, but robust installation mechanism, and I've used it extensively. It's not appropriate for every circumstance, but it can certainly accomplish what you are asking.
For ClickOnce, there is no difference between a Windows Forms executable and a WPF executable. Both are .NET executables and as such fully supported by ClickOnce...
I have personally deployed several WPF desktop applications using ClickOnce, and it worked exactly the same as with my Windows Forms applications...
I have a WPF C# desktop application that will need to be deployed as MSI (Windows Installer deployment, not ClickOnce deployment) in VS2010. My application will generate SQL CE database in run-time, manipulate Excel Workbook, and receive/transmit data from/to COM Port - so I don't know what is the appropriate way to deploy such an application.
I am looking at Windows Installer Deployment Tasks which doesn't help me to get started.
Could anyone show me some resources that give instructions on how to deploy an application as an MSI installer?
If you don't want ClickOnce, then you'll probably need to create your own MSI. In that case, you can use:
The built-in Setup project type in Visual Studio. It does a decent job but has limitations. Works very well if you don't have many dependencies or custom actions.
A commercial tool like InstallShield
WIX (Windows Installer XML)
I've tried both 1 and 3. While WIX has a little bit of a learning curve, it is a very rich way to do what you want to do. There is a fair bit of documentation available and some very nice "out of the box" wizard sequences to handle your standard install scenarios (licenses, feature selection, dependencies, etc). WIX does have some VS integration that works quite well.
You can find out more on WIX at http://wix.sourceforge.net/
Note:
The VS setup project can do custom actions, and install dependencies, but you have to use custom actions. If you want to parameterize the custom actions, then you'll need to find the not-so-intuitive instructions on that topic.
The other limitation of the VS setup project is that the setup project can only be compiled to an MSI by VS (devenv.exe). That means that the MSI cannot be compiled on a build server unless you install Visual Studio there too. This was a show stopper for me, so I switched to WIX and was very happy with the result.
For those like me who found this post after searching high and low for how to deploy an MSI these days, you now need an extension as the visual studio team removed the built in startup project functionality. You now need to download the Visual Studio Installer Projects extension.
See this user voice post for discussion of the removal, and here is a link to the extension.
Useful for people looking for a quick solution to generating an MSI through Visual Studio rather than getting deep into Wix (although if you need more advanced deployment options, definitely go that route).
Configure your WPF application to publish as a ClickOnce application. You can do that in the 'Publish' tab of the project properties.
If you use the 'Publish Wizard' (by clicking on the aptly named button on the properties page) you can specify (on the second page) that the user will install 'From a CD-ROM or DVD-ROM'. This option will produce a setup.exe file in the publish sub-folder of your project output directory. This setup.exe program when launched by your user will install the WPF application. You may choose to include an update functionality (but you don't have to).
The ClickOnce settings also allow you to include additional files (e.g., your SQL CE database file) and pre-requisites if necessary.