I was trying to convert my awesome WPF app to UWP using the Desktop App Converter.
I converted the app using DesktopAppConverter successfully, installed on my local Windows 10 machine and works like a charm. All good so far.
However when I tried the Windows App Certification process, it fails with the below error.
API _amsg_exit in msvcr100.dll is not supported for this application type.
API _cexit in msvcr100.dll is not supported for this application type.
API _commode in msvcr100.dll is not supported for this application type.
I actually use many essential functionalities via a CPP library which was created using some python code (which I don't have source code for).
(I guess "msvcr100.dll" is Microsoft C++ Re-distributable Package? )
Can any one help resolve this issue?
The WACK tool in the Windows 10 AU SDK is not applicable to Desktop Bridge app. You don't need to run it prior to submission. The error you are seeing here you can ignore.
Upcoming new versions of the SDK will have an updated WACK tool with specific support for Desktop Bridge apps.
Thanks!
Related
I have to use a SDK that targets uap10.0.x from a windows application.
I have tried adding Microsoft.Windows.SDK.Contracts and Microsoft.Windows.CsWinRT but it gives build error Failed CLR.
I did some research and discovered a way to add uap in TargetFrameworks.
https://developercommunity.visualstudio.com/t/net-core-cross-target-with-uap/174053
After I did this, I got errors for Windows.Forms and other libraries.
I also tried creating a .net standard library and add the reference there. The build was successful but I got runtime error for Platform not supported when using the library inside the net5.0 app.
I also tried creating compilation constants to only use the library in windows os but the error was the same.
What is the way to go in this case? Is it possible to use a uwp library inside windows app or should I create a uwp project and find a way to start it from the windows app.
Any suggestion is appreciated.
Is it possible to use a uwp library inside windows app ...
No, if the SDK only targets the uap10.0 target framework moniker (TFM), you cannot use it in an app that targets any other framework than UWP.
A TFM, such as for example uap10 or netstandard2.0, specifies a set of APIs that are available to the library or app. If you want to be able use the SDK from both UWP and .NET apps, it should target .NET Standard.
Please refer to the docs for more information about target frameworks and TFMs.
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
Just last week I exported a zip file from SAP Build (the prototyping tool) and imported this into SAP WEB IDE.
I simply choose 'Fiori Mobile' and 'Build Packaged app' from the menu to create a mobile app.
Unfortunately this doesn't appear to work anymore.
The error returned is
Unhandled Error: 'bPackagedBuild' is undefined
The full error in the log is : (hat) no template id is found, and the project seems not created from WEB IDE. As such, Fiori mobile does not officially support it. The app may encounter issues if you continue with a build.
Why has SAP stopped support?
To my knowledge, this has never been supported. The cloud-based build from the Fiori Mobile context menu always had a white list for supported template types, and it happens to cover most Web IDE application templates. Are you perhaps confusing the cloud-based build with the local Hybrid Application Toolkit? This tool allows you to run builds from your Web IDE and does have those restrictions. The builds are run locally on your machine, and you will need to set up the corresponding software in order to be able to use it.
Edit: I stand corrected. Unsurprisingly, this is supposed to work, and the use case has been documented e.g. in a recent blog post. As Thomas pointed out below, I believe that you are experiencing a temporary issue.
I have .Net Winform project(c#) working in windows.Now,i want to do same project, to work as OSX App in Mac. As per my understanding Microsoft recently launched Visual studio for Mac preview and also it support OSX app development using Xamarin.Mac and also it support .Netcore .
Instead of creating Osx app from scratch,i need to reuse the code which is available in .net winform project.
can i develop UI application using .netcore project? I think .netframework and .netcore more or less same.can i port .netframework to .netcore project and create osx app ?
or
can i use xamarin.mac and reuse the .netframework c# code to create osx app?
I am new to this,so kindly suggest the best way to create OSX app using Visual studio for Mac preview. (Basically i need Tabel view,form controls and graph(there i use zedgraph).Is these view are available here.
In general, the "standard" way of developing cross platform applications is to separate as much of your logic as possible into shared libraries of some type and create "thin" UIs specific to each platform.
Depending on your need, you could easily make that shared code netstandard/PCL/etc compatible and share between platforms or just recompile the project in each solution.
NSTableView will likely solve your needs, but expect it to be significantly more primitive that what you are used to on Windows. Graph controls don't come built in, so you'll need to find a vendor that ships Cocoa controls or draw them yourself.
Here is the quickstart documentation.
Xamarin.Forms support for macOS is coming in the future, currently earmarked for Q2 this year.
I'm trying to port my existing silverlight project to xbox Lakeview.
I got a compilation error saying "System.Windows.Browser" is not supported in ADK
and in Microsoft.Xbox360.Adk.targets "System.Windows.Browser.dll" is listed as the
unsupported assemblies.
I'm using APIs such as "System.Windows.Browser.HtmlPage" and
"System.Windows.Browser.HttpUtility". How can I work around it?
I'm not sure if you've gotten this figured out or not, but my version of the ADK I don't believe supports this namespace. If you would like to send me yours, I'd be more than happy to lend a hand in figuring out what's causing this issue.
LakeView is a profile of the .NET framework that is in accordance with Silverlight, but is not the same as the SL Runtime.
For instance, there is no "Browser" when running a LakeView app on your devkit.
You have a special bootstrapped container in one process that your Title will be contained within, which makes it more like a full-fledged application running in a portable OS than a Silverlight application.
What are you trying to achieve with your interaction with the HTMLPage?
Can you redirect your HttpUtility usage to the System.Net.WebUtility?