The project website does not indicate any support for WinRT.
Is there a way to do this? We (like many others, presumably) had bet on Vici CoolStorage for its cross-platform capabilities.
A version is in the works that will support .NET 4.5, Windows Phone 8, WinRT (Windows 8), Xamarin.iOS and Xamarin.Android. It will be built as a PCL (portable class library). Support for Windows Phone 7 will be dropped because the platform lacks too many common .NET framework features that are available on other platforms.
This new version will be available early December.
Related
I am trying to understand the implications of starting a project on .NET core. One of the requirement I am facing is to use a .NET library that is leveraging COM.
So is COM supported by .NET core (obviously, assuming the OS is Windows)?
I understand that .NET Core is built for interoperability between different OS. But I was wondering if it is to be expected that there are Windows-specific features that may be included for the windows releases such as COM compatibility.
Thanks for your help.
.NET Core is developed to be cross platform and running also on Linux and Mac. COM is a windows specific thing and will not be supported in .NET Core
I want to create an IoT application in VisualStudio 2015 community and want to add a reference to Windows Portable Device, which is a COM library. But the whole COM tab is missing from the references window. Is there a way to include COM libraries in Windows 10 Core IoT, or is that impossible? If the second, does that mean I would have to write drivers for any USB devices myself?
Windows Core libraries are included. Many legacy libraries have been reworked into those core libraries. I suggest checking the core libraries for the functionality you are looking for. Libraries need to be compatible with the Windows Universal Platform.
You will need to write drivers for non-supported devices.
How can I change .Net Framework version in windows store application from 4.5.1 to 4.5 ? Seems like it is only possible when you are creating new project.
You cannot change the .NET framework version on Windows Store apps - you can only choose the targeted Windows version (8.0 or 8.1) like shown in Filip's answer. What's do you want to change the framework version?
Compare empty 8.0 and 8.1 project files and you'll see some very simple difference to change - possibly just
<TargetPlatformVersion>8.1</TargetPlatformVersion>
<MinimumVisualStudioVersion>12</MinimumVisualStudioVersion>
to
<TargetPlatformVersion>8.0</TargetPlatformVersion>
<MinimumVisualStudioVersion>11</MinimumVisualStudioVersion>
I have created a Visual Studio 2012 C++/CX project that targets both WinPhone 8 and WinRT. The solution can be downloaded here (Hybrid.zip) if anyone is interested.
Unfortunately, it doesn’t work as expected with the solution platforms. Two platforms are working properly:
If I select solution platform ARM, a native ARM WinPhone binary is built.
If I select solution platform x64, a native 64-bit Windows binary is built.
However I have trouble with Win32. The Windows Phone SDK understands Win32 as “WinPhone x86 binary for the simulator” whereas the Windows SDK understands Win32 as “Windows x86 native binary”. The same project platform is used for two very different things!
I have tried creating a solution platform WinPhoneEmu. However, I have no idea how to create a project platform that will let me have two different platform configuration choices Win32 and WinPhoneEmu that behave as I expect. How could I do that?
I'm pretty sure this is explicitly not supported. The primary reason being that the XAML syntax between WinRT and Phone is similar, but not exactly compatible (phone is Silverlight-ish, WinRT is some weird new thing).
The best way to target both is to have a total of 3 projects:
A portable class library targeting Phone and WinRT where all your logic goes
A UI layer for WinRT that links to the PCL
A UI layer for Phone that links to the PCL
If I've understood you correctly, in this situation you need to select both platform (x86, x64, ARM) and target (Device, Emulator) manually. You can do it easily by adding platform selector in Visual Studio toolbar. Tools -> Customize -> Commands -> Toolbar -> Standard, then add 'Solution Platforms" command. This is a combo box with x86, x64, ARM, Any CPU, etc. Then you'll be able to select, say, x86 + Emulator WXGA for WP8 emulator, or x86 + Device for W8 device:
... and here how it will look in VS after that:
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.