hi
i need to develop silverlight application for windows embedded.as i referred some links silverlight for windows embedded supports only native code(C++). for this i build my silverlight application in blend2 and i converted that xaml file into c++ files using XAML2CPP. and now im trying to create win32 smart device project using VS2008 but for that im not getting which option we have to select and how to do can anyone of help me
AFAIK this can be done in two ways:
You can use a SDK provided by the OEM of your device, then create a Smart Device Project based on this SDK, then you can start the development of your Silverlight C++ project.
If you are the OEM of the device (it means, you have a BSP and you configure and generate the OS images and SDKs). Then you can create a subproject of your OS design and even include your application as part of your OS image, or you could just generate a new SDK and use option 1.
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 .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 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!
I'd like to know whether there are any image processing libraries available for Windows Phone 7 apps.
EmguCV (.net wrapper for OpenCV) has all the features I want but I'm unable to use it on Windows Phone development as it encounters a runtime conflict. Is there any way I can convert this to a Silverlight/Windows Phone runtime?
Thanks.
You can't execute unmanaged code in a 3rd party app. Emgucv is just a wrapper and uses the unmanaged OpenCV. There's no real managed port out there. You'll have to port it yourself from the C codebase.