Posts in 'dotnet'
Background Story In this fictional example, we have a SQL Server/SSRS Server safe behind our firewall, and a web server in the DMZ. Our web server hosts a Silverlight application our field sales team uses for performance analysis. For this sample, we'll create a scheduled report, which will be saved on a network share. For simplicity, we'll save the files directly to the web server, although we could place these reports anywhere that can be accessed with network credentials. We'll create a simple web service, which will provide a list of reports to our application, and deliver the requested report. To perform this full demo on your own system, you'll need an SSRS report server in place. If you don't have that, a folder with some useful PDFs will suffice-just skip the next section. The end result of what we'll accomplish can be seen at http://demo.componentone.com/silverlight/reportviewer/. We're going to build most of this demo (PDF part only) in this post, the rest can be seen in the sample code. The sample code and pre-release bits can be downloaded via the announcement post at http://helpcentral.componentone.com/CS/silverlight_161/f/191/t/86680.aspx. Scheduling the Report Log in to your report server at http://[myserver]/reports/, and select the report you want to schedule. The report will open, and you should see a New Subscription button in the chrome above the report. If the chrome isn't present, check for a Subscriptions tab. If that's not present, check with your SSRS administrator to have your permissions adjusted. On the subscription page, we set the Report Delivery Options. It's simplest to share a folder from the web app, but that may not be the best architecture in your given environment. The most important setting below may be the credentials-this is where a lot of issues arise. These credentials will be used by SSRS to place the report on the file share. It's important to use a domain account, and to make sure that account has at least MODIFY permissions on the destination folder. A best practice is to create an account specifically for this purpose. We can also choose the schedule our report is created. After setting the schedule, click OK. When you get back to the report, it's a good idea to generate a PDF so we have a test file for building the WCF Service. Building the WCF Service Depending on your system architecture, you could either have the WCF and Silverlight apps in separate solutions, or put both in the same solution. Here, we'll do both in the same solution because it's a little easier for demo purposes. Start by creating a new Silverlight Application, targeting Silverlight 4. I've called my solution ReportViewerQuickStart. Since we're creating the WCF and Silverlight project in the same solution, we can choose to host our Silverlight app in a new web application, and add our service to that web application. When we create a Silverlight application in this manner, our solution contains two projects. One is the Silverlight project (named for the solution), and a web application called ReportViewerQuickStart.Web. ReportViewerQuickStart.Web is what will host our WCF service. To the web app, add a Resources folder. This is the folder we'll share to SSRS to save the reports in. Add our sample PDF report to this folder. Add a new WCF Service to the web app; I've named it ReportingService.svc. We need two operations for our sample-GetReportList(), which will provide the list of reports in the source folder to the client, and GetReportStream(), which will deliver the specific report to the client. In ReportingService.svc.cs, we need to add a "using" statement for System.IO, and implement GetReportList and GetReportStream (the complete file is found in the sample): public class ReportingService
Wish you knew more about Silverlight? Join the Silverlight firestarter presented by Microsoft on December 2nd to learn tips and more on using WCF, MVVM, Windows Phone 7, RIA Services, performance and more. It's completely free!
In the wonderful world of WPF development there are some things that are easier to do code and some things better left to XAML. For instance, in my previous webcast Charting 101, most of the work was done in C# code but the DataTemplates were done in XAML. I prefer to do most of my work in code so that it's all in one place, but creating a DataTemplate is something that is much easier to do in XAML. Plus, they can be loaded from code and assigned to other dynamic elements at runtime without much problem. But you might find yourself in a scenario where you need to completely generate a DataTemplate programmatically. How can you do it?
I am here at iPhone Dev Conn in sunny San Diego and just wrapped up my lightning talk on the hot debate of whether to start developing a native iPhone app or mobile web app. I feel strongly on the subject and it seemed like most attendees here liked the idea. So here it is...