Looking at the Windows Runtime reference at the Microsoft site the only relevant collection I can find is the IObservableVector. Does the .NET Projection ObservableCollection get mapped to that WinRT interface? If so, hows does it handle the fact that ObservableCollection implements multiple other interfaces that the IObservableVector does not?
UPDATE: The ObservableCollection does work with Windows 8 Consumer Preview and can be bound to an ItemsSource and will correctly update the XAML control when items are added/removed from the ObservableCollection.
After asking on the Microsoft Windows Runtime Forum it seems that there is no mapping at the moment to the IObservableVector runtime type from any CLR type.
Related
This should not be so difficult!
In normal C++ one can write static or dynamic libraries that can be used in multiple application projects. I want to do the same thing for UWP apps using C++/winRT.
I have written a simple C++/winRT UWP app that discovers Bluetooth Low Energy Devices. I used the Core UWP project template that set up all that pch.h stuff. What I want to do is to make a library out of the code I wrote that did the Bluetooth work so it can be shared across many UWP apps but I have no idea which project template I should use to do that.
I have come to the conclusion that writing a Windows Runtime Component is not what I want. I am not making a run time component though I need to use runtime components for the Bluetooth.
In the end I will be calling that library from a Java application but that's off in the future.
All my problems would be solved if they had a Java/winRT option (a Java language projection in Microsoft-speak).
Note that the project selection interface in Visual Studio 2019 must be very different than 2017 as none of the demos I have seen online look like what I see.
I am building a C# VS2012 app that will be used overseas. I have been using Automapper for years and would like to keep using it. One stipulation handed to me is that all add-ons for my project outside of Microsoft must have a published ECCN (Export Control Classification Number). Microsoft has a published ECCN for .NET Framework 4.5 and Visual Studio 2013. They are trusted for export.
I have been looking for a published ECCN for Automapper, and the closest thing I can find is this Google groups article where Jimmy Bogard personally responded that it is the same for .NET framework. However, I have been asked for a published ECCN from Automapper that would state something official like this:
"The ECCN for Automapper is: [x]".
I have looked at the Automapper GitHub Site but couldn't find what I needed.
Any ideas?
AutoMapper doesn't need an ECCN - it contains no encryption functionality.
I have seen that there are so wonderful ways in Xcode to design your CoreData models - is there a way to make use of this and CoreData in general in MonoTouch 5?
Any tutorials or examples?
Maybe is not the direct answer to your question but might be what you are looking for:
Sqlite-net is an open source, minimal library to allow .NET and Mono applications to store data in SQLite 3 databases. <- the one you are using but for future reference
Vici CoolStorage is a fully typed Object Relational Mapping library for .NET 3.5, Windows Phone, MonoTouch and Mono for Android
Catnap is a basic lightweight ORM for .NET. It uses the ADO.NET API. The project includes an adapter for Sqlite, and it is tested with System.Data.Sqlite and Mono.Data.Sqlite.
MonoTouch.SQLite An abstract UITableViewController to make displaying data from an SQLite table simpler.
Entify is entity framework for desktop and mobile applications. It aims to be stable and easy-to-use library that is effortless to deploy with any application. It has visual designer which allows developer to define application data model easily and quickly.
Just a side note on entify, it has not been updated since Apr 11, 2010 so idk if it still works
The only thing I could find about MonoTouch and CoreData was this blog post.
Hope this helps.
Alex
Here is the documentation for CoreData in Mono.
This blog post is almost two years old, but the only example I could find of using CoreData in Mono.
Most relevant to your question, however, this bug/request is for integrating Xcode's tools into Mono. It doesn't seem to even be under development yet.
Edit:
You can also use /Applications/Xcode.app/Contents/Developer/usr/bin/momc <source xcdatamodel> <absolute path to target> to generate the .momd. I'm still working on getting it integrated better - see this question.
I am trying to port an existing c# .net application that is using MEF extensively to MonoTouch and MonoDroid. Does MonoTouch and MonoDroid support MEF?
Try using PocketMEF.
It is a subset of MEF that can run on PocketPC, WindowsCE, etc.
You will have to create a MonoTouch project from the source, because I would think there would be some minor changes to make it run in MonoTouch.
All the attributes and classes are named the same as standard MEF, you should only have to change a reference and a using statement with #if iPhone to get it working.
According to the list of MonoTouch assemblies and Monodroid assemblies, the MEF assembly (System.ComponentModel.Composition.dll) is not included.
It might still be possible to compile the MEF sources for these platforms, but this would probably require modifications to eliminate unavailable dependencies.
We have an app in progress/development using the Office Fluent UI ribbon control library. It seems that the new RTM release of the Microsoft Ribbon for WPF is going to be the standard for the Microsoft libraries (at least for the next month or so).
Can we install the Microsoft Ribbon for WPF safely on our dev boxes and begin transitioning our WPF xaml to the new control structure while still supporting/running versions of the older Fluent controls?
Can they be referenced in the same project so that we can re-code one window at a time?
The can co-exist on your machine, but they are in the same namespace, so you cannot reference them both in the same project (at least not easily).
The XAML schema is different as well. It's much improved, but you'll have to do a lot of rework of your existing XAML if you've been using the Fluent UI versions.