Make System.Data available to Metro style apps
Although, it seems clear that some of the decisions with the "Metro" apps are built so that apps will be able to go between devices, I would like to see the System.Data namespace supported in them. An example, you want to connect to a "local" SQL Express database without having to run a middle tier web-site or application that can talk to the database. Why shouldn't a Metro app run on a desktop be able to connect in the same way that a WinForms app can? The framework was supposed to abstract us from hardware and other changes yet as time goes there become more and more one off's (e.g. Silverlight->WPF->WP7 Silverlight/Metro->W8 Metro).
This is absurd that System.Data is not available for a Metro app. I use a Orm tool called LinqConnect by Devart and I could make a Metro app that directly connects to a Oracle or MySQL database. But since System.Data.SqlClient library isn't available in Metro I cannot directly connect to a SQLServer database. That is brilliant Microsoft! Let's push/force our developers to use a different database than SQLServer.
Microsoft XNA commented
Mr. CEO commented
Maybe we could have an API along the lines of System.Data.SendTo.NSA() ???
i think microsoft is a mistake on this,too little namespace in windows store app developping
There are a litany of issues with RT. For example, not allowing OEMs to produce Win8 tablets with smaller resolutions than 1366×768 means MS misses one of the biggest growing sections of the tablet market. Then there is the huge confusion over products and versions and what they can and cannot do.
General confusion around what Windows RT actually is, and MS failing to communicate the differences between the ARM and x86 editions of Windows, has “significantly damaged demand” for RT.
As for how Windows RT will be merged with Blue, who knows. RT is essentially already merged with Windows 8 — the codebases are the same, and they share compatibility with every Metro app. The only real difference is that RT doesn’t support Desktop apps, and that’s more of an intrinsic issue with ARM than the operating system. One exciting, outside possibility is that RT will actually be retired. This might sound a bit stupid given the current lay of the land — ARM is still the better choice for mobile computing — but… what if Microsoft is already experimenting with Intel’s next-generation Atom parts? The upcoming Bay Trail Atom is a brand new, quad-core 22nm SoC that should blow the doors off every ARM chip on the market.
Windows RT was always stupid. And I am amazed that someone in Microsoft actually thought it made sense. If people wanted a OS that wasn't as functional as Windows on x86, they were always going to prefer iOS or Android. Everyone was waiting for the 'Pro' version in any case, so that they could use it almost as a full fledged computer.
Microsoft made a lot of mistakes with Windows 8, forcing unreasonable change on people when they should have allowed people to control the change. When will MS ever learn and get it right?
I would be happy to get rid of the desktop, but unfortunately there's still too much that can't be done on the Metro/Modern side yet.
It would be nice if the OS, that seems designed for hybrid devices, was more of a hybrid itself. Keep the new Start screen, but bring back the desktop Start button as a second option. Let us decide which we want to use. All the effort they put into RT could have been redirected into making that happen instead. Make Windows 8 the all in one OS that they said it would be but without crippling established desktop functionality. It can be done. Windows 9 (or Blue) could be the OS to rule them all once again.
I still hold out some hope for MS. But please get it right sooner than later.
At first I was excited about the possibilities of building touch apps for Metro (RT) but I just discovered the severe limitations - especially no System.Data namespace. This is a huge step backwards that creates more work and cost (aka creating middle-tier Web Services). Almost none of my clients have the ability to do this. Just about every C#/XAML project I've build uses this namespace to do simple querying quickly and easily to SQL databases. There is no way I can get my clients to start building middle-tier services, let alone the job of converting all the code to consume these services instead of communicating directly with a database.
This is an EPIC fail from MS and rules me out of developing apps for RT. Which is a shame because with System.Data I can develop rich powerful data-centric apps quickly and easily and I could have contributed some great apps for my clients to the RT App Store.
Based on this discovery I have put off buying a Windows 8 PC altogether and am now looking to outsource development work to India for apps that will run on iPad, iPhone and Android. I am hugely disappointed in MS. Every time they release a new technology, so much of my previous investment suddenly becomes obsolete.
When Win 8 first came out I had high hopes. But seeing now the severe limitations of development on RT, I have all but given up on MS.
If you bought a car from MS, on the drive home you would discover that the horn sounds good, but doesn't work if one of the windows is more than half way down. You quickly discover that you can only use MS approved petrol...and then, finally, after just one year of owning the car, a key component fails and you're advised that a replacement part is no longer available and you will have to buy a whole new car!
Steve Kerr commented
Totally agree, evolving existing LOB apps to a Metro / tablet platform is a natural progression. It was bad enough managing SQL Server Express installs at each of our customer's place of business... there's no way they could manage a webservice or some other "server-level" type of install (these are basic mom and pop shops). And of course Express doesn't support a built in webservice. Honestly, this is ridiculous that it wasn't included in WinRT.
오류 1 'System.Data.Common.DbConnection' 형식에서 참조하는 'System, Version=22.214.171.124, Culture=neutral, PublicKeyToken=b77a5c561934e089' 어셈블리의 'System.ComponentModel.Component' 인터페이스 또는 기본 클래스를 확인할 수 없습니다. c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\System.Data.dll A-Live
What is a Solution..?!
Jamie Nordmeyer commented
Not having System.Data and SqlCe is a game stopper for me for developing WinRT applications. A good example; I'm trying to write a financial application for tracking accounts (think Money or Quicken). Sure, I can use SQLite, but it doesn't natively support encrypting the database, which is absolutely essential for a finance application. I know there's a SQLite extension library, but last time I checked, it won't pass Windows Store certification. Microsoft, not everyone can afford an Azure license to do cloud based services, and even if they could, a device will not ALWAYS be connected to the internet as it moves. Microsoft, this shouldn't even be a question; System.Data needs to be there. And SQLite guys, it'd be nice to get that encryption support for WinRT. :)
Without system.data WinRT should be renamed to WinPD -- Win Pretty DOS.
Maybe MS could get Sybase to write some code for WinPD and then Ballmer could buy it. MS could then proclaim to the entire universe that they have a new concepts for applicartions -- a way to store structured data.
Seriously, there is a lot of data that is shared and viewable to everyone such as best scored in Angry Birds. Are there any businesses that actually want to send "sensitive" data over the net -- in plain text -- via a web service -- such that anyone can see it?
This is far more idiodic than putting the Metro interface on Server 2012.
@Shawn - In some cases, your approach of web services to talk to a database is great, and works perfect. In other cases, it doesn't and it depends on the application. Why shouldn't a Metro application be able to talk to a full fledged database and run in offline mode? Perhaps it's data that doesn't make sense on a central server. SQLite Tim Heuer pointed out, SQLite fills the void, and in my case, will work fine. The problem for me is that when I put my eggs in Microsoft's basket, they often go missing later. I can't tell you how many times I've bought into a technology that has just up and disappeared later or has been changed so drastically that there is little re-usability to be found.
2003 - SqlCe existed and could run T-SQL commands against it. Very powerful.
Then - Windows 7 on phone - dropped SqlCe.
Then - Windows 7.5 Mango - SqlCe but only LinqToSql interface. Acceptable.
Now - Windows 8 - dropped SqlCe completely.
Those boys at MS just do whatever they want with no consideration of developers who create dataDriven applications.
Put it in the cloud - give me a break; I do not abdicate my data handling to others nor do I want to depend on intermittent internet connectivity on mobile devices.
Geez, yo-yo data.
Shawn Mehaffie commented
Win 8 applications are different than WP8 applicaitons so I do not see an issue with not being able to connect to a SQL database directly. If I want to do that then I can just write a WinForms application that runs in desktop mode. But I have not written a destop application or web application in years that needs direct access to a database. All my application whether web sites or desktop applications use web services on the back-end, so that will not change when I write Win8/Win7 applications.
As far as WP8 applications are concerned no one knows what is supported in that yet becuase the SDK has not been released. I would be surprised if SQLCE is not supported just like it is in Mango. I think a lot of people are getting Win8 apps and WP8 applications confused.
Tim Heuer commented
You can have an embedded database via SQLite. Yes it isn't SQLCE, however it is a very portable/proven embedded database and will also be supported on the Phone.
Mark Ewer commented
WinRT and Metro are all about mobile users. Let's face it, mobile users have spotty network connectivity. There are "dead spots" all over the place and any app that can't store state locally will provide a poor user experience when the user moves through one of them. While I understand the "universal connectivity" vision, people who live outside of the Microsoft campus don't have it yet.
You should definately embed SQLCE and include the Microsoft Sync Framework so we can build apps that store the user's state locally and sync up with an OData feed from the Internet. This would empower a consistent "fast and fluid" user experience and capitalize on fantastic technology that already exists.
We should at least have the ability to connect to an embedded database like the one they added to the WP7 Mango update. That would help a lot just to manage local state in a transactional, secure and efficient way.
@John I can get why there are new UI namespaces. And I even get why IO namspace is new. But I don't get leaving out System.Data.
I don't think you can call it an native app without System.Data.SQLclient. And for sure I don't see how you can put it front and center on the Windows 8 PC UI without System.Data. Many LOB applications have a need for a direct DB connection (.e.g. stand alone app or client server app that needs to support disconnected operation). If Metro is not a LOB platform then there needs to be a Windows 8 UI option for business that Metro is not the default UI. My understanding is that WinRT also does not support streaming XML. Cool yes. LOB platform no.
Further, if an app on WP7 can specify what version it requires, why can't you also specify what type of hardware is required for an app so you could make an app designed for (a tablet, or a desktop). For instance, if a "Desktop" version of Windows 8 has the "System.Drawing" namespace available, why shouldn't it be able to use it? This would allow developers to leverge the 10 years of .Net code they've built up and know how to use (and in some cases, those classes are just easier to use). If you're going to force the Metro interface onto Desktop users then allow the Desktop to excel at what it's good at (which is more processing power, more space and with the full version of the Framework available, more of the Framework to choose from).