Develop Reference

Run existing .net 4.5 app on Windows 10 IoT

We have a big application in .Net 4.5, with WPF and a lot of references like NHibernate, Fluent NHibernate, Enterprise Library, Unity and others.
I was asked to investigate whether we can run this (after some work done) on Windows 10 IoT. As far as I know I need to port the app to Windows Universal App, and as I understood this is impossible as NHibernate won't work for Universal App.
WPF is not a problem though as we agreed we can throw frontend away if we have to.
So I wanted to ensure my understanding is correct and the only way to run our app in Windows 10 IoT is to rewrite it without NHibernate and all other 3rd party libraries that currently do not support Windows Universal App. Is this true? If no what should we do to make it work and does it require a big effort?

If you have a core with all the functionality in it and its separated from the front end it should be possible to use that core and then build a new front for it with UWP.
The UWP is more limited regarding access to libraries and frameworks due to it being adaptable by several platforms so might need to rewrite some platform specifik code.
So the answer depends on how coupled and platform specific the code is as it is now.

Xamarin: comparison to native SDK and JS-based frameworks

So, one of the main features of coding using the native SDK provided by Android and iOS is the fact that you get not only a better performance, but also the look and feel of each platform: for example, on iOS, a tab-navigation bar would be located at the bottom of the screen, while in Android it is located at the top (yeah I know it also can be top and bottom, but you get my point), or also the Navigation Drawer dock is an Android navigation style while (as far as I know) there is nothing similar in iOS native sdk. My point being, you can feel the difference of platforms by their design guidelines which is a good thing, since it makes your app looks professional.
So taking that into account, in terms of performance and maintaining the feeling of your app, using JS-based frameworks like Titanium or PhoneGap will not make a wise choice.
Then comes Xamarin. As I read in here: Xamarin how it is getting the Native Look and Feel? it seems it is a C# wrapper for native SDK, which as far as I understand, it should not affect performance. But where's the look and feel part. Since XML layouts are not entirely what gives Android or iOS apps their feel, but also the navigation (which comes from the controller classes) how does Xamarin deals with these? It is said in their website that you can share code between platform, but will that also means I have to share navigation system and similar?
Finally, for the sake of "not writing code for each platform" , is it worth NOT to use native SDK and go with Xamarin (I don't really have a problem writing code for both iOS and Android), or is this framework target for C# developers so they won't have to learn Objective-C or Android.
Any extra explanation would be awesome, and thanks in advance.

I built a large application within the last year (2013) with different components: mainly an API (ASP.NET Web API => C#), a Website (ASP.NET MVC => C# + AngularJS), and both an app for Android (Xamarin.Android => C#) and iOS (Xamarin.iOS => C#). The decision to use Xamarin had its advantages and its disadvantages, but all in all I am more than happy with it.
As you can see in my list above, almost everything was done with C# (okay, the Website is mainly written in JavaScript ;-)). It's a wonderful mature language with really nice features (as LINQ). In my scenario it becomes clear: I did not have to learn and to perfect four languages (Swift/Objective-C, Java, C#, JavaScript) but only two: C# and JavaScript.
That comes especially into play regarding the code sharing aspect: our client applications aren't really thin clients because of some offline functionality which requires a lot of synchronization logic, so the UI part of the two apps is only one side of the medal. As it turned out, I could really use 90% of that non-interface code on both iOS and Android. This is an incredibly huge benefit, as it's not only about some language originalities of Swift/Objective-C or Java, but also about the different frameworks you are using on iOS and Android. To use the .NET Framework/Mono as foundation of every Xamarin app enables you to abstract things like data access or network communication from the underlaying OS.
In terms of speed and UI you don't have any disadvantages, because you're using the native APIs 1:1. Whatever is available on iOS or Android is also available through Xamarin. And whenever Apple for example ships a new version of iOS, Xamarin will ship the update for that within a few days, so you don't have to wait to be able to use newly introduced features by Apple.
Xamarin uses a technique called Ahead of Time Compiling on iOS, so everything you write in C# is compiled into the native iOS stuff before it is deployed to your device. That means there is no difference in what is executed between a "native" Objectice-C application and a Xamarin application (except some small overhead which isn't noteworthy from my experiences).
On Android Just in Time compilation is used as just with any other "native" Android app, too.
That all means you have all the exact same APIs and possibilities you would otherwise have, if you would go with Objective-C or Java. You even use the same objects for building your UI with the exact same types and names (sometimes slightly optimized ;)). So if you want a tab bar navigation for your app - you use a UITabBarController for that. See iOS vs. Xamarin.
After multiple years on my way with Xamarin I only one disadvantage:
Possible memory leaks. Their whole samples out there are a bunch of crap regarding essential basics of preventing memory leaks. If you are working with "expensive resources" like media files within your application, you should take care from day one. I had to get rid of all that problems when an app of mine had already been growing to up to 35 different (complex) dialogs. That took me almost two months or in other words thousands of bucks. They provide some documentation about it, but the tooling is poor at this end. And errors are likely to appear and very hard to be found (example).
But all in all it was one of my best decisions to go with Xamarin.

I have been coding with Xamarin for a while now. Its been great so far. Any problems I've had I figured it out because c# is my native language. The Xamarin site has many examples and API references for many features on all platforms.
Performance - You get native performance from using Xamarin. No questions asked. I have been using it to create audio, video and photo recording features for a new app i'm working on. Xamarin processes the c# code into native byte code for all platforms. Thats how this is achieved.
Look - The look of your app will be native. You literally have to use the Android xml format to make your user interface and the same Goes for IOS. You will still style your elements the same way you did on each platform. All Xamarin does is link a view to an event for you.
Api - The beauty of Xamarin is in the API. They ported the whole Android and IOS namespace to c#. Take a look at their Documentation.
Expensive - My only problem with Xamarin is that it is expensive. If you check their pricing it is outrageous. But you get what you pay for. A premium product that is backed by support.
C# - Sharp is a great language that has loads of support. The new async/await gets ride of the whole thread management issue. Json processing is super easy on the platform. I have uploaded several classes on Github that can be used for many apps.
If you are from a java background, brushing up on your c# skills will be a breeze.
The rdio app was created with Xamarin. Download it on Android and IOS and test its performance and enjoy its native look.
Best of Luck

There is much much more internet content, help, and support for native. That alone helps me make my choice. If you are really good at Xamerin, maybe 70% of the code you write will be usable by both apps, you still have to custom tailor things for each app.
But again, the support for native is so vast, that if you run into a proble, so has someone else.
With xamerin, well, good luck.
When I say app I mean iOS/Android

Use older dlls (.NET) in Windows Store app?

I started work on porting an application I've written for deployment in the Windows 8 app store. This requires that the application be written against the subset of the .NET framework. My application follows an architecture where the core functionality is in it's own dll, and things like file system access are done through IoC. Basically, this means that the only dependency for the core dll is System. Because of this, I thought that porting would be a breeze - setup my IoC values and wire up a GUI then I'll be good to go. Only, I can't even reference my core dll from the windows store app (a.k.a. metro app).
Have I missed something? Do actually have to rewrite my core dll just for inclusion in the windows 8 app store? We're told that if you use a good architecture, then porting will be a breeze, and that's what I've done. Has that just been a big lie?

Windows store apps(formerly called metro style app) are limited to using the .NET Core Profile. I put some details about the Core Profile in my answer to this question. See Converting your existing .NET Framework code in this article more details. It's not your architecture, it's the subset of the .NET Framework that is available to a Windows store app. You may have to supplement some of the types you use in .NET with WinRT types instead.

I don't have an extensive knowledge and will try to stict to facts as I understand them. The Metro framework adds functionality, and limits functionality. There are heavy security restrictions and vast segments of the full .Net framework that are not available (for instance, you cannot use System.Data, some of the System.IO and file access methods have drastically changed). A Metro app is isolated, you're not going to be able to recurse all the files on the hard drive like you could in a standard application (my opinion that is, on top of security by isolation it's an encouragement to push you into the cloud for storage needs).
Unless things have changed, PInvoke is limited to "approved" Win32 API methods.
See this link for some alternatives to common Win32 API needs: http://msdn.microsoft.com/en-us/library/windows/apps/hh464945.aspx
See this link for approved Win32/COM API's: http://msdn.microsoft.com/en-us/library/windows/apps/br205762.aspx
It's hard to say whether a "good" architecture will be a breeze to port without knowing what's in the code in that architecture. In my utility framework I've had things that ported very easily (or at least were straightforward) and things that were a complete wash that required a lot of rewriting (The loss of System.Data for instance is a sore spot for me). There are things that can be designed well but when you take out the underlaying code in the framework or API it was written with it will require rewriting.

I had the same problem: a project for Metro app don't load dll create with framework .4. I changed the framework from 4 to 3.5 for the dll and now the Metro project see them.

.NET in Windows 8: AppContract, Marketplace and WPF/C# from a dev point of view

I'm pretty excitet about all the new stuff coming up in Windows 8, but at the same time a bit worried about how and if I can continue use the code and custom components I have already built up using .NET and C# during my time as a Windows dev. I've got some general mixed questions about this. Hope you don't mind I'm putting them together in one post:
Will Windows 8 Store be for both metro-style apps and regular WPF-desktop apps? Including pushing updates and making apps available for company employees?
Will the new App Contract-thingy also be available for WPF-apps? And is AppContract based on WCF-services with perhaps UDP-discovery on the network? Can I make my own contracts between my own apps using the App Contract framework?
I'm not particularly worried about if WPF will be ditched or not. I can live without it. The thing that worries me is if I still can write presentation and business-layer code in C# and use it as a backend for my apps, no matter what UI-framework I'll be using, HTML, Silverlight, WPF or what have you. If I'm still able to write logic in C# and present it using X UI-framework, I'm a happy developer. I've heard I can access the .NET-framework from JavaScript. But what about custom assemblies?

It has been announced that non-Metro apps can appear in the store but the store will just link to the publisher's website - not actually manage the sale/install/DRM/etc stuff.
What's been announced so far is that the contracts are only for Metro apps but I'd be shocked if this doesn't change. It would be crazy for Microsoft not to allow desktop apps to, for example, add commands to the Settings charm, support PlayTo or printing through the Devices charm, or act as Share sources. We'll have to wait and see where they draw the line on what desktop apps can/can't do.
Sharing code between Metro and non-Metro apps is going to be very difficult. A lot of the core concepts and conventions are the same but even basic stuff like file I/O rely on a totally new API. There aren't a ton of interesting things you can do with in code that will work on both sides of the fence. Best bet would be to define interfaces for your business layer stuff and then use dependecy injection to dynamically select desktop vs. winrt implementations at runtime

Store: there is no final information but as far as I understood it, it's for metro style applications only
The app contracts are a metro thing. I know a code snippet that documents usage from desktop apps (eg http://www.heise.de/developer/artikel/WinRT-in-klassischen-NET-Anwendungen-nutzen-1366039.html (sorry, German)), but I do not know if it will have support from Microsoft
WinRT compiles libraries to WinRT components. You might be able to reuse code and compile them to a component as long as you're not using a namespace that isn't available for WinRT
This question is heavy on guessing as there is no official beta available. And even then we can't be absolutely sure...

Developing a winforms application for both a tablet PC and WindowMobile

I'm developing an application for a Windows based tablet PC. This application is pretty much a port of an application I already developed on a Windows Mobile device using .NET CF. I want to write the application from scratch, taking advantage of all of the knowledge I've gained in software development.
I'd also like to write this new application in such a way that if I so desire, I can modify my existing Windows Mobile app to use the new libraries. Ideally, I'll have a shared set of business logic and data access libraries, with the only real difference being the UI layer - WPF for the tablet version, and just a standard CF interface for the Windows Mobile app.
Taking this into account, I'll need to make sure that all of the projects I create are compatible with the .NET Compact Framework. Is there an easy way to ensure this? One thought I had was to use a Smart Device Project for each class library that I create.
As well as this, is it easy for me to reference these libraries written for a .NET CF application from a standard windows application?
Is developing an application for a tablet PC the same as developing any normal windows forms application? Is there a different version of the .NET Framework to take into account, or are tablets pretty much standard windows pcs?

There isn't a special version of .NET Framework for Tablet PC. The question of sharing code between Windows Mobile and Windows has been asked before and the accepted answer is excellent.

The tablets I've seen are running standard Windows with the "full" .NET, but I expect you can get some light-weight devices, too. One interesting possibility might be "client profile" (a subset of the regular "full" .NET dlls) - but I haven't seen much use of that myself.
CF and regular .NET share a lot of things, but ultimately there are differences; neither is a strict subset of the other. I've found that in general the only way to write code for 2 frameworks is to keep both active... for protobuf-net (which has this problem) I keep a project file for each framework so that I can quickly test that the build works everywhere (i.e. there are no missing methods etc).
You may find you need to use #if blocks to run slightly different code on the two frameworks, especially if you want to use "full" .NET features for performance reasons (that don't exist in the CF version). One way of making this easier it to hack the proj files to use recursive file inclusion:
<Compile Include="**\*.cs" />
Now you don't have to keep adding new files to both projects - it'll get picked up automatically (caveat: in the IDE you may need to unload/reload the project).