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.
Related
My company wants to try out the library "Thinfinity Virtual UI", to run a Windows Forms application in a browser.
It seems to more or less work, though the application crashes everytime an embedded browser is attached to the form (Cefsharp), see attached image.
I am not able to catch the error in the try/catch.
Any ideas how to remedy/debug this issue?
I tried searching the web for a solution/alternative to CefSharp, looking at error logs, inserting the try/catch. I also wrote to the company, but so far I get no reply.
This is Luke and I work at Cybele Software where we developed Thinfinity VirtualUI to help Windows developers converting their Legacy Windows Applications into modern Web Applications by just modifying one single line of code and adding our libraries.
Unfortunately, as it is, WebView and Chromium are not supported in our propietary protocol. But do not worry, we have 2 valid workarounds.
Using our HTMLDOC demo. Link to our GitHub HERE
This demo shows how to programatically create an iframe inside your application (using HTMLDOC.CreateComponent) , and how to communicate back and forward between the application and the website running inside that iframe, using Javascript Remote Objects (JSRO)
Using our 'Third Party Applications' Feature. Link on how to enable this HERE
Be aware that to enable this feature, you'll need to have our Thinfinity Broker and your app running on a Windows Server. Basically, with this option, you'll be using a Microsoft feature called 'Desktop Duplication' where we can eventually render any Third Party application with the help of Remote Desktop Services.
I hope this does the trick for you and don't hesitate on contacting us about this or any other doubt you may have about our products :)
Thank you!
A few days ago I updated a wpf program from .net4.8 to .net5. Some users now get an error message that can be seen in the picture.
These users have .NET Desktop Runtime 5.0.x installed. Apparently that is not enough. The program will not work until the SDK is installed.
My question now is, is there any way I can quickly tell whether I'm using classes or methods that need an SDK?
Do I have to adjust the publish config?
I would not like to deliver the whole framework with the program together.
Appearantly your app has a dependency on the ASP.NET runtime as well.
You will either have to download and install this one separately or remove any references to it from your app.
Check for any framework reference to Microsoft.AspNetCore.App in your project files (Project Sdk="Microsoft.NET.Sdk.Web">) or under Dependencies->Frameworks in Visual Studio.
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 convert a WPF oneclick installed application and so everything should be pretty straight forward. However, whenever I run the debug project, I get
'The parameter is incorrect'
in a message box popup and I can never run the app.
This happens for my app while trying to debug, all the samples from github, and even the DAC application from the Windows Store. The error pops up even once the app is installed and showing in my application list.
I'm on the latest build of the Creators Update.
There are various errors in the event viewers, but they seem to be a common occurence for WinRT apps.
Any ideas at all?
If you have the WPF project in VS2017, I'd recommend to package directly from VS without using the DAC. see the article for more information https://learn.microsoft.com/en-us/windows/uwp/porting/desktop-to-uwp-packaging-dot-net
The problem appears to be related to the May Security Update. I restored Windows to the factory defaults and everything works fine.
However, once I install the the May Security Update to address this bug with Sql Server and Filestreams, the Desktop Bridge Debugging project stops working.
I'm going to throw out a random guess that it's related to the Microsoft Malicious Software Removal Tool, as the event viewer logs mentioned an issue with the 'parameter is incorrect' referring to the Microsoft.MRT.
Of course it could be anything, and as only 7500 people have even downloaded the Desktop Bridge Debugging project in the first place, I doubt it's high on the list of Microsoft Developer Priorities.
And to be completely honest, it's really probably my fault for not rewriting the app as a UWP app, after rewriting it as a Windows Forms app, and as a Silverlight app, and as a WPF app and on and on and on. Although, I'm not sure how many glasses of Kool Aid are left in the punch bowl for me.
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!