It doesn't appear that you can use this in a 'normal' .NET app. Any ideas why?
On one hand, they really try to push everybody to upgrade to their newest and shiniest, by making a lot of stuff (like this) only available on Windows 8+.
On the other hand, they don't even bother to put in a box with "What operating systems will this work on", so you don't have to do trial/error, research WinRT, and then be disappointed when you realize this will apparently never work on Windows 7. And maybe only in Metro apps? What is Windows Runtime and am I just supposed to know this?
I really enjoy coding C# and working in .NET. Microsoft has some really great stable techs which work well for years and years - but increasingly if you want anything new and shiny from them, you have to run the newest OS. Which if you work with anything related to enterprise, good luck only targetting Windows 8.
And honestly, despite working almost exclusively with MS tech, I just don't really trust any platform from them that doesn't have significant traction and track record as they all too often just give up and try something new - and sometimes without real replacements available.
Minimum supported client Windows 8.1 [Windows Store apps only]
Minimum supported server Windows Server 2012 R2 [Windows Store apps only]
Minimum supported phone Windows Phone 8
[2] http://msdn.microsoft.com/en-us/library/windows/apps/xaml/wi...
Crazy that it's limited to 8.1, and not even working on 8.0.
I really wonder if there is a valid technical reason, or they just use it to push upgrades.
If you subscribe to MSDN like any Windows developer, this has been explained multiple times in the last two years.
Just for the clueless ones.
Windows Runtime is an evolution of COM, based on the ideas that were on the genesis of .NET. Namely Ext-VOS.
http://blogs.msdn.com/b/dsyme/archive/2012/07/05/more-c-net-...
So a native version of .NET, so to speak. And unless Windows 9 changes it, the future of Windows APIs.
The .NET runtime starting with Windows 8 acquired additional capabilities:
- Ahead of time compilation to native code for Windows Phone apps, with the MDIL binary format
- Consumption and creation of Windows Runtime components
> but increasingly if you want anything new and shiny from them, you have to run the newest OS.
No different from other commercial vendors.
Now it has just been 5 years since Windows 7 and apparently it's already completely outdated. It's only 2 years since Windows 8.0, and it's already out!
If this is the way Microsoft is going, then it's a huge change for anybody dealing with enterprise. I used to be able to develop on the same system using the same techs as my customers - now I may sit on Windows 8.1, but I can't use any new shiny features as my customers are still on Windows 7. Many of them just upgraded.
Sure, this may be the way others are doing it. It may be the new normal. But I still think Microsoft is shooting themselves in the foot big time regarding anything related to businesses.
In this case I'm actively researching an OCR solution. Tesseract is annoying compared to a nicely integrated .NET solution. But I'm not able to choose the solution from Microsoft. It will be at least 5 years until our customers have upgraded again, and by then - well, we're probably not going to switch OCR tech.
Instead we will be relying on third parties, open source projects - things that are not tied as much to Microsoft or the .NET ecosystem. I didn't mind being tightly tied to MS tech, I often preferred it as it was easier and worked great - but in this case I don't even have a choice. Basically I just wish Microsoft would stay Microsoft instead of trying to be Apple.
-- And regarding following MSDN. I develop WPF/C#, and I don't follow anything at all. I don't care about hype or news. I care about solid techs that are mature and sticking around for a long time. Most of the stuff being announced will significantly change or be cancelled anyway. When a product has stuck around for 3 versions and is having a pretty good following, then I might be interested. If my customers are actually able to run it of course.
Up until this post you didn't have it (the Microsoft OCR library) anywhere. You're still free as ever to develop using all the non-RT technologies (Windows Forms, WPF, Silverlight, WF, WCF and so on). All of it's officially supported.
And all said and done, Microsoft is doing no more or less than any other tech company. They release new stuff. And sometimes a new release is constrained in some way, like when an iPhone app is released by some startup that doesn't bother with an Android or Windows Phone equivalent. They may come eventually, or not...
nb: haven't actually tested past installation at this stage.
edit: nope :(
packages\Microsoft.Windows.Ocr.1.0.0\lib\win81
Why would I think they might be .NET libraries if they have 'x86' and 'x64' labels? Because C++/CLI has to be compiled to separate dlls, I believe.
When calling native code outside the CLR the runtime needs to know which type of marshaling code to generate.
It also plays a role when using unsafe code blocks in .NET.