I have some .NET code that I am looking into porting into being a Windows Store app.
This code does a few different things and one of the things it does has a dependency on being compiled as x86 instead of AnyCPU.
Is this going to be a problem? Can a Metro app be compiled as x86 and still be distributed on the Windows Store? Is being compiled as x86 going to stop it from being able to run in Windows RT? Would I have to come up with a version without this subset of functionality to run in Windows RT? If I can get the code into its own assembly can I just have the Windows RT version not use it? (so, the main executable is AnyCPU and this one assembly is x86).
Can a Metro app be compiled as x86 and still be distributed on the Windows Store?
Yes. However, it would only be installable for x86 installations.
Is being compiled as x86 going to stop it from being able to run in Windows RT?
Since Windows RT is designed to run only on ARM CPUs, compiling for x86 will stop it from being able to run on Windows RT.
Would I have to come up with a version without this subset of functionality to run in Windows RT? If I can get the code into its own assembly can I just have the Windows RT version not use it?
You could use conditional compilation symbols to include/exclude functionality as required in your code. https://stackoverflow.com/a/6587823/61385 shows an example of how to do this.
Just compile whatever libs you need and when you upload to app store just upload the one you want to. Check your apppackages folder and look for the .appxupload files.
Related
I have created an Application in Linux 64bit with MonoDevelop, GTK#2 as GTK2-Project.
I am able to make an executable, the platform-target is "AnyCPU" (I have removed Posix references and GetText()-support), but I have also tried "x64".
This executable can be executed on Linux 64bit (terminal: mono App.exe)
This executable can be executed on Windows 32bit (terminal: mono App.exe)
This executable CANNOT be run on Windows 64bit (terminal: mono App.exe)
brings error:
Unhandled Exception: System.DllNotFoundException: libglib-2.0-0.dll
I have installed the GTK+ for Windows Runtime Environment on both machines, Windows 32bit and Windows 64bit.
In fact I have found this DLL libglib-2.0-0.dll on the GTK/bin-path and also have copied it to my executable-folder, even though it is set in the PATH environment variable.
Anyway, I get the same error message, but only in Windows 64bit.
Do I have a chance of making my GTK app to be running with Windows 64bit?
Is there a different libglib-2.0-0.dll for Windows x64 and how can I obtain this?
It's certainly possible to run a Gtk# 2 application on 64-bit windows, but it requires a bit of work. It appears you've already obtained the necessary .Net assemblies, and the native Win64 Gtk+ DLLs that are needed, but you also need an additional set of 64-bit native "glue" DLLs. I have not yet found a good source for these in pre-compiled form in any of my searches, but it is possible to build them from the gtk-sharp source.
This C++/WinRT announcement states "What this also means is that you no longer need to wait for us to update GitHub following the release of a new Windows SDK. Indeed, we will no longer be publishing the updated headers on GitHub at all since you can get them directly from the Windows SDK."
However if one delves one click further one finds that the "Windows 10 Preview Build of the SDK [is] to be used in conjunction with Windows 10 Insider Preview (Build 17025 or greater)" and "Installation on an operating system that is not a Windows 10 Insider Preview build is not supported and may fail."
Right now must one install a Windows Insider Preview of Windows 10? This is either a scary and lengthy process or straight impossible depending on one's admin rights.
Or can one grab the SDK and use the C++/WinRT bits on a box with a standard Windows 10 build?
Is the easiest route for some aspects of the C++/WinRT toolchain still GitHub?
How about if one is developing on a non-Windows-10 box, e.g. Windows 7? Zillions of commercial developers are in this situation and aren't in control of that.
Will the situation change and if so when?
Going forward does one wait for periodic updates to SDK previews, and if so how does one consume them?
Preview versions of the Windows SDK will not install on a non-Insider build of Windows. This is a restriction of the Windows SDK and not specific to C++/WinRT. In the long run (once RS4 ships) this won’t be a problem since you’ll be able to install the final Windows SDK for RS4 without this restriction.
In the short term, you need an Insider build of Windows to install the SDK, but you can then use that to target previous versions of Windows. I’m not sure whether it would work on Windows 7, but I don’t think that any developer using C++/WinRT would care to use Windows 7 when the Windows Runtime isn’t even available on that version of Windows at all.
The cppwinrt.exe compiler also relies on Windows 10 APIs to function. While this isn’t a dependency of code built with C++/WinRT, it is a requirement for building C++/WinRT components. Of course, the resulting binaries can then be executed on older versions of Windows, provided you handle light-up in the usual ways, such as with delay-loading.
I'm developing a C++ application that dynamically link against Qt, boost and Assimp. I compiled it in Release mode with /MD and it works fine on my computer. However, if I try to run it on another machine I get the 0xc000007b error (The application was unable to start correctly). I use Windows 8.1 on both machines but Qt5.3 and VisualStudio2013 are only installed on the 1st machine.
I built boost with
bootstrap.bat
b2 variant=release
I then used Cmake GUI to configure/generate a solution for Assimp that I later built using Visual Studio 2013.
Qt (32-bit version) was installed via the online installer. So everything (including my application) is built with a target 32-bit.
The folder that I copy to the other machine includes:
MyApp.exe
platform/
accessible/
assimp.dll
icudt52.dll
icuint52.dll
icuuc52.dll
kernel32.dll
opengl32.dll
libEGL.dll (cannot be found in Qt/5.3/msvc2012_opengl/)
libGLESv2.dll (same)
msvcp1XX.dll
msvcr1XX.dll
The Qt libs that I need (Core, GUI, Widgets, OpenGL)
If I copy these .dll/folders from Qt/5.3/msvc2012_opengl/, the app requires msvcp110.dll to start. If I add it and run it, I get the 0xc000007b error. But why msvcp110.dll instead of msvcp120.dll???
And if I copy the files from Qt/tools/QtCreator the app actually needs msvcp120.dll to run. But when it runs, it crashes at the beginning with:
QEGLplatformContext::init: eglError: 3005, this: 0x2e806b0
Which I guess is normal as you're not supposed to copy them from this location.
Does anyone know what I am doing wrong?
PS: I also ran vcredist_x86.exe on the machine without VS2013 before running my app. It installed successfully but nothing changed.
Thanks for your time and your help!
So I have a Windows Store app using C# targeting Any CPU so that the single app will run on any Windows 8 x86/x64 desktop/tablet or ARM tablet. I need to add some special code in C++ which doesn't seemto have the option to target Any CPU. The code will compile and run both on x86/x64 and if I change the entire solution to ARM it will compile and run there too. So I'm looking for a way to make the C++ target Any CPU which I think is probably impossible. Or have the C++ library compiled multiple times (x86, x64 and ARM) and have all of them included in the appx package. I have spent about 3 hours reading Windows Store development docs on C++/CX and haven't found any way to do this yet. Of course I'll keep looking, but I'm hoping someone else has seen how to do this and can point me in the right direction.
There's no way you can create a single package targetting AnyCPU when you're calling into a native library. You need to create three different packages, one for each target architecture. When you're uploading the app to the store, you can include all three packages.
To simplify the process of building all three packages, you could create a Visual Studio extension (vsix) with all three builds of your native library. In this case the native library for the right platform will be automatically included in each package. Here's a quick tutorial on how to do it.
I am currently developing a Windows Store App that will eventually be targeted at the ARM devices when they are available. For now, I have been developing and testing from Visual Studio on my desktop computer and everything works fine. However, when I try to create an app package that I can pass along to others within my company for testing purposes, the application will not run properly.
The solution includes two projects. The first is a C++ project that is set to build a dll file. The purpose for this is to expose the Direct2D and DirectWrite libraries that seem to be unaccessible to a C# project. The second project is the C# project that references this dll for drawing functions and includes a XAML interface and most of the program logic. All of this works flawlessly on my development machine from within Visual Studio (and also when installing the package).
When I send the package files to other individuals within the company, the installation appears to work fine by installing with the PowerShell script. The tile appears in the start screen and the program will launch for a few seconds. The C# and XAML interface appears, but the DirectX portion of the application is not visible and the entire application shuts down within a few seconds. This makes me believe that the dll may not be installing or referenced correctly upon installation. I have checked the package file, and the dll file is included in the package after the build process is complete.
I have packaged a few different test programs (MSDN Samples) that have all installed on their machines, but we get the same results that they will not run (again, all samples run fine on my development machine when building them). The only test project that worked properly was a simple C# project that did not use DirectX at all. Any of the DirectX samples that I tried have all failed (including the native C++ samples that do not use C# at all).
To be clear, the process I use for building is going to Project -> Store -> Create App Packages and choosing the No option for uploading to the Windows Store.
Does anyone have any ideas on what might be going wrong with the build or installation process?
Thanks in advance for any help!
Does it work with the Metro Sideloader? I am not sure if it just adds a UI to the Powershell script, but it works for my team and me for testing...
Good luck!
Are you side loading a Debug version of your DirectX app onto a machine that does not have the Windows SDK installed? Visual Studio's default DirectX projects and the samples on MSDN both request the D3D11_CREATE_DEVICE_DEBUG flag when creating the D3D Device. Device creation will fail if the Windows SDK is not installed on the machine running the code.
Here are a few different options that will allow you to unblock yourself. Any one of these should give you the desired result:
Create a Release package and deploy that instead of a Debug package.
or - Go to DirectXBase.cpp and remove the D3D11_CREATE_DEVICE_DEBUG flag from the code.
or - Install the Remote Debugging tools for Visual Studio on the target machines. This will install the necessary SDK components to allow creation of D3D Debug devices. The other cool thing about this option is that once you're set up you won't have to create packages manually and side load them anymore. Just tell Visual Studio the name of your ARM machine and press F5 to deploy it remotely. More information here: http://msdn.microsoft.com/en-us/library/vstudio/bt727f1t.aspx
How are you deploying the native DLL with your project? Are you using project-to-project references? Can you verify that your DLL is ending up in the final package, in the root of the package application directory?
I recommend using Sysinternals Procmon to watch your application load on the target machine. If it crashes or fails, you can look in the log history for which DLL it is trying to load and failing. Typically this will show up as a repeated series of DLL load probes (it will try and load the dll from the application directory, and then proceed to try a number of other paths).