I need to make a Windows Store application that exchanges xml serialized data over a TCP connection with a server. Since I need to use Direct3D rendering in the application I went for the c++/cx store application template however I ran into issues with xml serialization/deserialization.
My usual approach in C# would be to use the XmlSerializer and classes with DataContractAttribute annotations. However as soon as I try to import System.Xml.Serialization assembly I get the C1114 error - WinRT does not support #using of a managed assembly. However there are lots of examples that mention using this approach in a Windows Phone app from C#.
So the question is - is only c++/cx limited in support for .NET in Windows Store applications and C# can use all the standard components on phone as well or is switching to C# in this case also not a solution and I need to use the WinRT classes for xml serialization/deserialization?
Your confusion is understandable, what with the variety of frameworks Microsoft has put out there.
C++/Cx is a native binding to the Windows Runtime (WinRT). It does not use any managed code or the .NET framework in any way, which is why you're getting the C1114 error.
C# provides a managed binding to WinRT. It does leverage the .NET framework, so in a C# Windows Store application, you can make use of some of the base-class library. This subset is referred to as the .NET Profile. This article talks about this more: http://blogs.msdn.com/b/dotnet/archive/2012/04/17/net-for-metro-style-apps.aspx
In your specific case, you are using a C++/Cx application because you want access to Direct3D. This makes sense, although it means that you will not have access to System.Xml.Serialization. Instead, as you surmised, you will need to use APIs that are available to C++/Cx to read XML, specifically Windows.Data.Xml.Dom: https://msdn.microsoft.com/en-us/library/windows/apps/windows.data.xml.dom.aspx
Related
I'm having issues using the JsonConver.SerializeObject function to serialize a string when using Unity IL2CPP scripting backend. My understanding is that since JsonConvert uses reflection IL2CPP cannot use this function because it is pre-compiled. I'm also using the Holotoolkit which uses the Newtonsoft.dll so I don't believe using the JSON .NET for Unity package is feasible as it will conflict with the Newtonsoft.dll
Anyone run into this or have any suggestions on how to resolve?
I got this to work by deleting the Newtonsoft.dll in the Holotoolkit directory structure as well as the GLTFSerialization.dll that references the Newtonsoft.dll. Then, since I'm coding for the Hololens I was able to comment out all code that referenced the GLTFSerialization.dll. Then I installed JSON for .NET Unity asset from the Unity asset store and all in life is good again.
I believe all of the code that references the GLTFSerialization.dll is used only for Mixed Reality device development so if you are developing for MR this solution may not work and you may want to look into using the extern aliasing method.
Visual Studio provides a "Background Application (IoT)" template which i want to use to create a headless webservice. To persist some data i want to use Entity Framework with SQLite as DB-Engine .
After upgrading UWP to 5.2.2 and installing Sqlite and EFCore.Tools and adding a DbContext i wanted to migrate the first version. It fails:
PM> Add-Migration MyFirstMigration
Project 'BackgroundApplication4' is a Windows Runtime component. The Entity Framework Core Package Manager Console Tools don't support this type of project.
I thinks it's not a problem with EF itself, because it worked for me with a simple "Blank App". Now there are some questions coming up: Is a "Background Application" really a WinRT-Component and has a different (unsupported) handling by EF?
I thought UWP is an extension of WinRT so basically each UWP-App must be a WinRT-Component?
EF in a Windows Runtime component is a no-go; but that is not so bad since WinRT component can depend on class libraries. So move all your EF classes to a own class libary and consume that library from your background task in your Windows Runtime component.
By doing this you can also use the same class library also in the foreground app when needed.
P.s. Check the github page of EFCore and UWP. There are lot of issues especially in combination with .net native. so using EF.core in UWP will cause you lot of headache; but it is possible.
I can't find any deep information about how UWP apps are actually running.
I read on Wikipedia that UWP is based on WinRT. WinRT incorporates some kind of .NET runtime. Is it CLR? Is it some form of CLR or what?
UWP has nothing to do with .NET or the CLR. It is implemented in C++ and uses COM under the hood. It is language agnostic, meaning its API can be consumed by different languages (C#, VB.NET, F#, C++/CX, C++ and JavaScript right now).
If you're using C# to consume the UWP APIs, then the UWP types are projected into equivalent CLR types. For example, if you instantiate a Windows.Web.Http.HttpClient instance, not only do you get a CLR System.Object back, but under the hood the underlying COM object is "activated" a-la RoActivateInstance (or something like that).
I'd like to know whether applications designed for WinRT are run within a Virtual Machine or compiled in bytecode in order to be compiled once and run everywhere as the slogan says.
The slogan isn't that. WinRT apps rely on COM for runtime cross-environment calls and a metadata format (winmd) to describe the types.
A WinRT app can be fully native (as is most/all of the framework and even the XAML engine).
Individual DLLs or the app itself could be written in a .NET language, and it will interop almost seamlessly with the rest of WinRT thanks to the extended interop code added to the CLR. Under the hood, it's mostly COM interop as usual, but with added "projections" of chosen WinRT types. This is what makes a WinRT IVector look like an IList in .NET. They're just automatically wrapped.
The strength of WinRT is the binary method calling abstraction of COM and the metadata system (without which the language "projections" wouldn't exist). But it is definitely native, just like COM is, and you can stay in C++ without revving up the .NET CLR if you like.
I want to use Mvvmcross to make application for several platforms.
I use Profile 104 for PCL library like Mvvmcross, but this profile target .NET 4.5.
I want to target .NET 4.0 to use my application on Windows XP.
To do that, I add the xml files
MonoAndroid, Version = v1.6 +. Xml
and
VSMonoTouch, Version = v1.0 +. Xml
in the profile 143 which allows me to target. NET framework 4.0.3.
However, I have a compilation error because it can not find the ICommand interface.
This interface is not in the same library between version 4.0 and 4.5, is it why it doesn't work ?
Or should I recompile all Mvvmcross libraries with profile 143?
thanks,
This is a Portable Class Library limitation.
See the table on: http://msdn.microsoft.com/en-us/library/gg597391.aspx
Model-View-View Model (MVVM)
Only 4.5
This means that if anyone wants to use MvvmCross on earlier .Net platforms then someone has to build and maintain a non-PCL version.
Since the maintainer of Mvx (me!) has decided to only maintain PCL versions of MvvmCross, then any non-PCL support will have to be created by the community.
For WPF this shouldn't be too large or difficult a job - but it might be...
Alternatively, somebody might be able to do something funky to get the ICommand working... I've retagged this question with portable-class-library to try to lure in some of the MS experts.