I'm sorry...but everything i've seen about metro is for list based applications targeted for consumers.  Until i see a "real" metro application that is optimized for heavy data entry and reporting, PLEASE don't waste your time.  METRO = Consumer.  Silverlight 5 = LOB (including cross platform).  PLEASE focus on getting your controls to support Silverlight 5.  METRO may some day be a good option, but it will take years...and then it won't be cross platform.  My 2 cents.

Yup, agree. You've clearly see it right. The Metro will be entirely new development platform while Silverlight is untouched because both are targeting different market. Hopefully other developers can see it clear as well, and continue with today's development solutions.

Hello Andre,

Thanks for posting this question. That's a great catch :)

We will, when the time comes, make all our controls available to WinRT which will also works in ARM. However, please be reminded that it's still too early to make any prediction on Microsoft's strategy. The previews in BUILD event were intended to show what Microsoft is doing currently and what they are going to offer in the foreseeable future. However, I suggest you to continue building rich apps using the mature and proven technologies available *today*.

It's best to make it clear that WinRT is supposed to replace WPF, not Silverlight. Silverlight apps run on browsers and works in Windows and Mac. WinRT apps run only on Windows 8 -- so it won't be cross devices nor cross platforms.

Also, since you're going to build apps with Metro style, have you researched user's acceptance on Metro style UI? I have recently seen a growing negative feedback on Metro style (which is the reason why WP7 loses the competition to iOS/Android), but I won't be going deep on this matter here.

Let me know if you have other questions, thoughts, or concerns.

Best,
Jimmy

Hello,

Thanks for your patience. We've discussed your questions with our development team. Here the result goes.

First of all, our SqlReportViewer will not require you to change the topology of your existing SSRS deployment. That's made possible because we will ship a server-side handler for the SqlReportViewer which processes the communication between the client and server. This also means that you can continue to use your existing security settings, whether it is Windows Authentication or Forms.

Secondly, the server component of our SqlReportViewer will use default windows credential when communicating with the actual SSRS web services. You can override both the credentials and the impersonation level by deriving the handler class and overriding the provided virtual properties.

Finally, you can use Forms authenthication to handle the security between the client and the server that hosts the SqlReportViewer's HTTP handler. This allows you to have granular control over how your applications should behave based on user's roles.

I hope you've now got clearer picture on our upcoming SqlReportViewer. Please feel free to let me know if you have any questions.

Thanks,
Jimmy