I have added desktop extension to my UWP app that gives some extra functionality if it runs on Windows 10 desktop platforms. But for other platforms it won't be used. Hence I want to make sure that the desktop extension isn't installed on other platforms thereby saving users some disk space. I have looked into app extension but it won't be viable for my use cases since the UWP app and desktop component communicate via named pipes and memory mapped files. Is there any other way I can control the installation of desktop component depending upon the platform it is being installed??
Update 1
From researching further I have found that this should be possible with optional packages/related sets, to be accurate related sets for my scenario. The examples provided in docs only show scenarios for packaging uwp apps as related sets and no example for packaging win32 apps as related sets was given. Is there any way to package a win32 application as related sets??
Related
VS 2015, Xamarin Forms, PCL.
I can attach my Android phone by cable, and install to it. I can run "Local Machine" on my windows 10 development machine and test there. I want to give a copy of the UWP project to someone else to test with (on Windows 10 desktop). This is a new application, not in any stores, so...how to do this? Can it be done without using store distribution, and if so, can someone tell me how to do this, or point me to a link that documents this?
You could create package (like for publishing to store) and then with PowerShell install it on another PC. Packaging UWP apps
You can limit the distribution of an app to only a certain group of testers, without first publishing a submission that's broadly available, you can use the same app submission process as any app you submit. To allow only certain people to get the app free of charge, and prevent other customers from seeing its listing or downloading it - read more about Beta testing and targeted distribution
I have an older application that I've converted using Microsoft's "Desktop App Converter" to create a UWP application. The application appears to convert fine, and I can install and run it on my local machine. Unfortunately, when I try to submit the application to the Windows App Store, I get the following errors:
Package acceptance validation error: We don't allow the capability you've specified: runFullTrust.
Package acceptance validation error: You don't have permissions to specify the following namespaces in the appx manifest file of the package DownloadManager.appx: http://schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities.
Are there any ideas what is causing this and what the fix is?
I'm running Windows 10 Enterprise Preview Version 1511, Build 14352.1002
According to this article from the official blog, you cannot submit your Centennial apps to the Store just yet. You have to follow the process they mention in their article:
Windows 10 Anniversary Update SDK Now Available! Windows Store Open for Submissions
"Windows Store Open for Submissions; Including Process for Submitting Desktop Bridge Apps:
In addition, we will begin the process of accepting apps using the Desktop Bridge. While we build the pipeline into the Windows Store to publish these apps, our team will work directly with developers to get their converted apps and games into the Windows Store. Contact our team here if you are interested in submitting an app using the Desktop Bridge to the Windows Store."
You can find in this article Preparing your desktop app for conversion to UWP features that should be removed from codebase.
As I see there is one Your app always runs with elevated security privileges.
Check this one ar may be your app contains some another feature from list
For a new desktop app project I'm researching if it's feasible to create a cross-platform implementation instead of native Windows and OS X apps. Chrome Apps seemed promising, but after browsing through the Chrome APIs there are some things I didn't see that I'll need in my app:
Notifications on changes to files in the local filesystem. (File System Events API on OS X, FileSystemWatcher on Windows.) At first I thought the syncFileSystem API might help with this, but it's apparently only for syncing with Google Drive, which is not what I need. I guess I could workaround this by scanning the directories I'm watching on a timer, but that won't perform well if there are a lot of directories and/or files.
Ability to add context menus in Windows shell and OS X Finder, as I would be able to with a Windows shell extension or OS X Finder plugin.
Ideally (although probably not a hard requirement) get the app into the Windows System Tray / OS X Menu Bar (NSStatusItem).
Can anyone confirm whether it's possible to access this functionality with a Chrome App? If not, can you recommend an alternative cross-platform tool for building an app with these features?
All of the listed features have bugs logged, but no real progress at the moment:
Watch: https://code.google.com/p/chromium/issues/detail?id=148873
File manager integration: https://code.google.com/p/chromium/issues/detail?id=130455
Sys tray: https://code.google.com/p/chromium/issues/detail?id=142450
The first of these to be made available will probably be file manager integration, which is being worked on now.
We'd love to improve watching but it is a significant task to support this on all operating systems and we don't have anyone working on it now.
Sys tray support is something we have no plans to release soon as we're not sure how we want to support this on ChromeOS.
I could not find anything close to the items you have mentioned. I did however find this product: node-webkit that likely would get you onto both your target platforms, use the same basic code-base (HTML5/CSS/JS) and allow some possible per-OS customization. There is even a 'watch' project under NPM that covers your first bullet point. Check node-webkit/wiki for notes on how to add C/C++ extensions to their node build (under using-node-modules.) Project seems active and appears to be backed by Intel (they re-built their XDK product on it to do cross platform.)
I wonder whether there is a performance difference between the .xap package i submitted to the windows phone store and the one served to the end users finally. I am asking because in the book "Windows Phone 8 Development Internals" there is something like
"In Windows Phone 8, this process changes, such that all apps are
precompiled as part of the Windows Phone Store submission process.
This means that when a user downloads an app from the Windows Phone
Store, the app package already contains code that is compiled for ARM.
Because no “JITing” is required when the app is starting up or
running, users should experience faster app load times and improved
runtime performance"
Thanks
To test the app on the same conditions as the store (and using the same kind of pre-JITing), you just have to follow those steps:
http://msdn.microsoft.com/en-us/library/windowsphone/develop/jj585401(v=vs.105).aspx
In a nutshell: either start the app without the debugger attached, or uncheck the "Suppress JIT optimization on module load" in the project properties.
Note that it will work only on a device, not in the emulator (which isn't a reliable way to measure performance anyway).
Source: http://www.silverlightshow.net/items/Windows-Phone-8-Compile-in-the-Cloud.aspx (section "More Details")
I am new to windows 8 app development I just want to know that it is possible to make one app package which will run both on windows tab and windows 8 phone [For example in case of iOS same ipa can be installed on iPhone as well as iPad]?
I know win 8 phone and win 8 tab/desktop have different sdks and and coding sharing can be possible. But can I make one common package to run it on both platform.
No it's not possible. WP8 app packages are .XAP files & Windows 8 apps are .APPX/.APPXUPLOAD files. You can use various code sharing techniques like MVVM, PCL, etc, but you can't create a single file which acts as installer for both.
Maximize code reuse between Windows Phone 8 and Windows 8
As Xyroid explained they have different file name for apps. And since you compared to iOS, let me tell you that iPhone and iPad is basically the same device, with same architecture and same OS, with different screen resolution(if you ignore the calling function), so one IPA which works on iPhone, can work on iPad too.
While Windows 8 and Windows Phone 8 are two different OS, based on some common code and runtime, but they do actually have different app handling layers. They even have some different UI component. You can make a library (dll) which can work for both if it's just fetching data from a particular server or provides some low level functionality. But for creating single package which can run on both is a different thing. Even if they'd be using same file name, the internal codes and runtime can't be changed.
PS: WinRT apps can work on Windows 8 too, since WinRT is a stripped down version of Windows 8(without desktop app).