Are Metro style apps managed or native and if native how can they run on both arm and x86? - managed

I originally assumed that Metro style apps were managed (.NET) assemblies whether they are written in C# or C++ and I thought C++ for Metro style apps would be similar in concept to C++/CLI.
However, I now heard on a DotNet Rocks podcast that Metro style apps written in C++ are native. Nevertheless I understand that Metro style apps run on all three CPU architectures Metro is available for. How is this accomplished? Do Metro style apps come with different binaries and only one is chosen/downloaded? Or is it like on Mac OS X where one binary can contain code for different CPUs?

Code that uses only system or OS services from WinRT can be used
within an app and distributed through the Windows Store for both WOA
and x86/64.
from this MSDN blog page

If you go watch this BUILD video things should start to clear up -- http://channel9.msdn.com/events/BUILD/BUILD2011/TOOL-930C (A .NET developer's view of Windows 8 app development)
Basically there is a CLR (.NET 4.5) running. I didn't say a full CLR. WinRT from a .NET perspective is just a .NET Profile (sort of a way that they can layout the API differently exposing or hiding things). The new WinRT APIs use a new version of [gulp] COM, but it is optimized for use with .NET. I'm not 100% sure on the C++ angle. I suspect with C++, you have a few options. Compile for each platform (arm and x86) or compile to IL. Not sure if this helps you at all (I hope so).

Related

Is .NET Native required for UWP applications?

I am upgrading a Win8 application to UWP. .NET Native is causing a huge amount of issues, and a lot of WCF features that the application uses aren't supported.
Is .NET Native required for UWP applications? Can I just disable .NET Native in the Release build? Apart from some potential .NET Native performance improvements, will I lose anything?
The point is you are migrating to the .NETCore for the UWP, the subset of the .net framework, that leads to lots of your original codes can't fit into.
Are you migrating from a winRT store application or full .net framework based desktop app?
So far as I know the .NET CORE really cut-off lots of stuff from the Full. So if migrating from a Full .net desktop, that's really suffer.
.NET is supposed to increase performance, however it may create serious troubles, in some cases, e.g. if application extensively uses marshalling.
You can disable .NET native for Release in project properties.
Open Project Properties and select Build tab.
Set
Configuration: Release
Platform: All platforms
Untick box 'Compile with .NET native tool chain'
After you build the project, allow to run Certification Kit (WACK), and if is passes, take my congratulations. (I am not that lucky!)

Choosing Windows Runtime Components versus Portable Code Library

When sharing code between Windows Phone 8 and Windows 8, the two core options for developers are 1) Windows Runtime Components and 2) Portal Class Libraries.
Windows Runtime Components use WinRT and can be projected into all the supported languages. They require linked files in separate projects (binaries) when used on different platforms. They, however, share 90% of the available WinRT APIs.
Portable Class Libraries are a subset (sometimes a significant subset) of the BCL that has binary compatibility across platforms. They can be used on WinRT applications but also on other project types like Silverlight, Xbox, etc.
When a developer is choosing a "sharing strategy" which project type is the go-to technique to do the best job sharing code between Windows Phone 8 and Windows 8? Thanks.
It depends what form of sharing you need:
1) If you have a common C++ business logic layer you can use Windows Runtime (WinRT) components to expose this to both Windows Phone and Windows Store app (that's the only use-case for Windows Phone as you can't write a WP8 app using JavaScript or use .NET to author a WinRT component).
You'd have to build two separate WinRT components however, one for Phone and one for Windows Store. It should be possible to share the C++/CX code of your WinRT interop layer using preprocessor directives (#if) to mark the platform specific code.
2) You have business logic in C#/VB that only has dependencies on the .NET APIs which are available in a Portable Class Library. Then you can use Portable Class Library (PCL) to contain that logic. Basically if you can build your library into a PCL DLL then this should work. You can then reference this PCL in binary form in both Windows Phone and Windows Store app.
However as Martin has said you need to take care when using 3rd party libraries as these will also need to be built for PCL. Some 3rd party libraries are already available in PCL form (JSON.NET for example).
3) You want to share code for that has platform API dependencies (or 3rd party library dependencies) which are not supported by PCL. Then you'd need to create separate DLL libraries, one per platform. You can avoid code duplication using linked C#/VB source files and use a build flag (#if again) to allow small code changes between your target platforms.
If you want to share code between Windows Phone 8 and Windows 8, then you cannot use Windows Runtime Components, because there are different components used for Windows 8 and different for Windows Phone 8 and they are not interchangeable.
I would go for either Portable Class Libraries for some simple generic libraries, or for code sharing via links and #if WP8 compilation directives - this just works and is more powerful than Portable libs.
Keep also in mind that most external libraries like MVVM Light cannot be referenced in Portable Libs, so if you want to use them, you have to use the code sharing via file references.
For some guidance on how to effectively use Portable Class Libraries to share code between platforms, see this blog post: How to Make Portable Class Libraries Work for You
This question is no longer relevant with the introduction of Windows
Phone 8.1 Universal Apps in Visual Studio 2013 Update 2 which supports
Shared Projects.
Wait a moment, as for me even in Visual Studio 2013 Update 4 this question is still relevant because there are two types of projects there:
Class Library (Portable for Universal Apps) - PCL
and
Windows Runtime Component (Portable for Universal Apps) - WinMD
I can see only one big difference between them:
WinMD uses only WinRT and PCL could be used also with .Net and Silverlight. But I also want to know more about which one and when better to choose.

MonoDevelop: same project for MonoMac and GTK# possible?

Perhaps my question is totally naiive and this is the reason why I couldn't find any information with Google or something else - but nonetheless, I think it is worth asking here.
I want to develop a C# application which behaves naturally in Mac and Windows (Linux would also be nice, but is not directly needed). My main operating system for development should be Mac OS X and therefore I want to go with MonoDevelop.
I can setup a project for MonoMac - works fine.
I can setup a different project for GTK# - works fine.
My question is now, what I have to do to get a project with a possibility for a MonoMac and a GTK#-frontend. So I will go with the MVC pattern and want to work in one project. As a result, building my project would result in a Mac executable (based on the MonoMac stuff) and one windows executable (based on GTK#).
Am I completely wrong with my approach?
What do I have to do to achieve my goal?
Yes, for a multi-platform app with the best possible look-n-feel on each platform, you would need one executable per platform. Using an MVC approach is the best way to do this - you can have a solution containing a library project with all the shared code - models, processing code, business logic, etc - and a project for each "frontend" executable containing the platform-specific views and shell.
If a really good native experience on Windows is higher priority than Linux support, I'd recommend using WPF or Windows Forms instead of GTK#. This would mean you'd have to split development between Windows and MacOS - you would need to open the same project in Visual Studio, SharpDevelop or MonoDevelop on Windows, and edit the WPF/WinForms project and the shared library there.
OTOH, GTK# has the advantage you could start off writing a single frontend that would work on all three platforms, and then write the platform-specific ones afterwards.

How to work with 3rd party 32-bit framework in 64-bit Cocoa Application?

I have a 64-bit-only application that I am developing in Objective-C on Cocoa. It includes various plugins that are also 64-bit. One of these plugins needs to use a 3rd party Framework that is only built for 32-bit i386. It is a C-based framework. It is not possible for the 3rd party to produce a 64-bit version at this time.
I do not want to change my entire application and plugin suite to be 32-bit just to accommodate this one 32-bit framework, but I also do not have any alternatives since it provides access to a proprietary piece of hardware and is the only means my application (via the plugin) will have to operate the device.
What are my options for making this all work?
Clearly my plugin needs to be 64-bit, otherwise the main application will not load it. However, In that case I cannot link against the 32-bit external Framework. I have read that I may need a 32-bit helper application that the plugins communicates with, but have no idea if that is a good or recommended approach.
Are there any other ways to do this? If not, can someone point me to any documentation or tutorials on making this work?
An option would be to create a standalone 32-bit application that uses the framework and controls the device. Then have a 64-bit plugin to your app that launches the standalone app and communicates with it through some IPC mechanism.

Does the .Net Mono project support the iPad?

I hear the mono project (for allowing .net apps to run on many O/Ss) has come a long way (Winforms support, etc.)
Does it (or are there plans for it to) support porting to the iPad?
Yes, but it does not appear to be free (or cheap): MonoTouch