If you try to get an app from Windows App Store, in System Requirements there is OS build number. Which says something like 'Windows 10 version 14393.0 or higher is required'. Who decides this? As a developer I have not coded anything OS specific. I want to make my app work in OS having lower version than this, what should I do?
When you create a universal windows application project visual studio show you a box like below to set your Target Version and Minimum Version of windows which your project run on it.
You can also change your project Target Version and Minimum Version when your app had been created, to do that go to project Properties , in Application tab on the Targeting section change your target and minimum version.
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 have VS.NET 10.0.40219.1 SP1 in 2 computers and when I create a new C# Winform app only do it with Properties/Build/Platform x86, and the target let me choose AnyCpu/x64, but can't set it in the configuration (however, libraries work fine).
If I try to change it in the project file manually, I get a lot of nasty errors. Is this normal behavior, a bug or a problem in my installation?
P.D: When I change manually the project, this happend:
Warning 1 The OutputPath property is not set for project '*.csproj'.
Please check to make sure that you have specified a valid combination
of Configuration and Platform for this project. Configuration='Debug'
Platform='x86'. This error may also appear if some other project is
trying to follow a project-to-project reference to this project, this
project has been unloaded or is not included in the solution, and the
referencing project does not build using the same or an equivalent
Configuration or
Platform. c:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets
When I reopen the project, ALL the references become invalid
It is normal for Visual Studio to create WinForms projects with just an x86 platform. I have no idea if that's because historically x86 was the only platform type or because x86 is the most commonly used value or for some other reason.
It's also normal to have problems when the project file is manually modified, try to avoid doing that where possible.
To create another platform configuration in a C# project
Select Build | Configuration manager
Select <New...> in the Active Solution Platform field
Select the new type you want
Click on OK
Visual Studio used to create AnyCPU apps by default. I think both VS2005 and VS2008 did this, though they may have changed it for VS2008. Here's what happened: a lot of AnyCPU apps ended up broken on 64-bit systems, because they were built with dependencies on 32-bit libraries. If you tried to run an AnyCPU app that had a 32bit dependancy on a 64bit system, you got a 64bit process that would crash as soon as it tried to load your 32bit dll.
To fix this, the default was changed to use the x86 option. If you want to use AnyCPU, you must now setup the environment for it.
My task is to make a simple application that connects to the internet (using Wininet) and downloads a text file. It then displays the data in a listBox widget. The requirement was to make a GUI based application, so I used Windows Forms in Visual Studio Express 2010.
The application runs fine on my PC, however I realized that it runs only on my PC. I installed .Net 4 and Visual Studio 2010 redistributables on another PC and it worked fine there. Now, the person for whom I'm making this wants maximum compatibility on windows PCs. I'm totally stuck here.. should I switch to an older version of VSE?
From what I could search, using /MT instead of /MD would cause the application to link statically, however my app also uses /CLR and these are incompatible.
Any ideas?
Note: I've previously made a similar app (downloading and displaying) with console output and it works perfectly fine everywhere.
Dependens on what is meant by "maximum compatibility on windows PCs". If you can bundle the required redistributables, your program should run (as you found on the second PC), as long as the windows on the PC is capable of executing the binaries (e.g. not a 32 bit PC trying to execute 64 bit binaries)
I have been in your situation.
I can give you my free .NET-application-runner (RunNetApp.exe) that automatically installs .NET Framework 4 before running your application for the first time. If the framework is already installed on target machine, it only runs your application.
I also suggest changing application's framework to ".NET Framework 4 Client Profile". It's setup is about 40MB (in comparison to 200MB of full ".NET framework 4").
Is it helpful?
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.