So back on October 27, 2004, Robert McLaws announced ProviderModel.com. In the announcement, he stated the Interscape USA Provider Model code will be available. So, its now December, and nothing has been done to the site, nor any code released. I ask this, was it a flop? Did Microsoft put their heavy foot down? Is McLaws just too darn busy right now?

This cool little app (pointed to by Ryan) allows you to IM people over MSN from the command line. I, however, won’t divulge Ryan’s thought for a new plugin…but if you grab the idea from the context above, I think you’ll understand.

So this is more of an annoyance than a bug, but you should be aware of the following:

If using SN.EXE to extract your public key information, and you supply an invalid file name or path, SN.EXE just states that your assembly “does not represent a strongly named assembly.”

If you run the same command on a assembly that does exist, but isn’t signed…guess what, you get the same error message. Misleading, very misleading.

Like several others have mentioned, I’ll be taking off later today heading to Iowa for the Heartland Developers Conference. I, however, won’t be presenting but enjoying those that are. If you’re attending, make sure you look for me. I’ll be the geek carrying the laptop bag, hmm…thats not descriptive enough…I’ll be the geek carrying the laptop bag and wearing a Microsoft .NET T-Shirt, hmm….nope, still not enough…I’ll be the geek carrying the laptop bag, wearing a Microsoft .NET T-Shirt, and …. well heck, here’s a picture of me…that will be easier.

BTW, if you’re attending the “get-together” tonight, make sure you look for me. I figure I’ll be arriving between 6–7 PM to the hotel. Otherwise, shoot me an email so we can meet up. I’d like to meet anyone and everyone!

Thanks to Jackie pointing to this entry, I now realize the importance of using throw versus throw ex. How many of you actually realized that?

If you’ve ever used the Regions Add In for VS.NET 2003, you may have noticed a few annoyances (at least, what I call annoyances because it isn’t the way I program). These include:

• When adding a new region, it adds a blank line above and below the region.
• When adding a new region, it doesnt add any blank lines between the region declaration and your code.

To me, this was just a complete annoyance since I like to put spaces between my methods already, and if I come back later to add regions, it starts messing up my source code so that I have several line breaks between my regions. Not to mention its a bit hard to read what the method signature actually is when the region declarations are contained right above your code.

So, with that in mind, I set out this morning (for about 15 minutes) to fix these annoyances. And so, you now have a build of the Regions Addin without these annoyances if you find them to bug you to the end and back.

Download it here! If you need to source, well good luck finding it, its already deleted. However, I modified only a few lines to remove carriage returns and add carriage returns. Something I’m sure you could figure it out too.

So its been about a week since Unleash It 2.3 was released, and so far 2 plugins have surfaced. Talk about getting a good feeling when you see other people start creating things against your product with plugins.

The latest plugin that was released, developed by Josh Kewley, also comes with a thorough article on how he developed the plugin. He also gives his advice on how to debug your plugin (which I will be incorporating into the plugin information).

So, if you get a chance, hop on over to the plugins forums and read up on Josh's experiences. Both of which will help you out in the longrun if you need to create your own plugin for Unleash It!

Preface:
The following is a series on integrating your custom web applications with SQL Server Reporting Services. It is intended to provide useful information for other developers posed with the same problem of integrating these two seamlessly.

For the situation and notes, please view Part 1 of this series.

Utilizing Reporting Services API:
In Part 1 of this series we discussed setting up authentication on your custom web application, reporting services, and the Windows server / Active Directory. Part 2 will be discussing how to utilize the Reporting Services API exposed by Web Services. This API is intended for use by developers for integration scenarios just like this, and it is very important to understand how to actually use it. The entire API is very extensive and exhaustive, and in reality, you will only use 5%. For more information on the API, visit the MSDN documentation.

As the documentation states, the Reporting Services API can be accessed via Web Services at the URL http://<SERVER>/ReportServer/ReportService.asmx. Using Visual Studio .NET (or if you prefer the command line WSDL EXE), you should create a proxy for use in your custom web application. If you're using Visual Studio .NET to create the proxy, you should see the listing of all the classes, methods, and properties that it exposes...which I've subtly named "everything under the sun except for the kitchen sink." Just glancing through the listing, you will want to note the most important class of them all "ReportingService." This class exposes everything that you would really want in just a basic application.

So, enough looking, and add that puppy so we can start working!

The most important item that must be done prior to using the Reporting Services API, is that you need to pass credentials with any call to the API. To do this, the class ReportingService inherits a property called Credentials. And, as you guessed it, is where you will add your credentials. So, exactly how do the credentials fit in, and how do I access them? Well, that was the whole idea behind Part 1 of this series, setting your application up properly so that this daunting task is super easy.

Remembering back to Part 1, we're using impersonation of the currently logged in user within the current thread context of the web application when it is running. What this means is that our web application is running as if it my user, thus enabling me to pass the credentials of the web application onto the API. By simply calling a single line of code, we've now setup our instance of the Reporting Services API to be executed as if I were going to it directly via URL:

// create an instance of the reporting service
ReportingService rs = new ReportingService();

// set the URL of our reporting server
rs.Url = http://rptsrv/ReportServer/ReportingService.asmx

// set the credentials
rs.Credentials = System.Net.CredentialCache.DefaultCredentials;

So, now our credentials are being set - which means that we can now start calling methods to do certain functionality. In the application we built, it was necessary to retrieve the reports dynamically based on the users' role and supply these reports in a drop down list for the user to select and run. To accomplish this task, we needed to look at the method ListChildren which takes in a folder path and boolean value indicating if a recursive search should be performed. This method returns an array of CatalogItem classes that allow us to determine if the item returned was a report, and if it was, the path, name, and other important information. Here's an example of retrieving the reports for a given path:

// retrieve the catalog items for the demo reports folder
ReportingServices.CatalogItem[] items = rs.ListChildren("/Demo Reports", false);

// cycle through the items returned and add them to the drop down list if it is a report
foreach(CatalogItem item in items) {
    if(item.Type == ItemTypeEnum.Report) {
        ddlReports.Items.Add(new ListItem(item.Name, item.Path));
    }
}

So, now we have a listing of reports in the Demo Reports folder. Pretty simple right? You betcha. It's now time to take a selected report and view that report in a separate browser window (code which you can figure out!). So, in a button's OnClick method, we open a new window and supply a URL to the reporting server that will automatically display the report. Sounds simple enough right? Well, kinda - it takes some know-how on how to construct the URL properly.

The great thing is that you can pass just about everything in the URL by Query String parameters to control how the report will be rendered to the user. If you're familiar with viewing the reports currently, you'll remember that there are two toolbar items. One being the Toolbar that displays the paging and export interface, and the other being the toolbar containing all custom report properties that can be searched on. By passing just a few parameters in the querystring, you can control if those are displayed or not. Another very important query string parameter handles how the report will be rendered (HTML, PDF, CSV, etc.) when first accessed. So, what exactly are these parameters?

• rs:Toolbar - The toolbar for the paging / export functionality. It is a boolean value indicating if it is visible or not. Supplying True, Default, or leaving it off will commonly display it.
• rs:Parameters - The toolbar displaying the report parameters. It, like the above, is a boolean value indicating if it is visible or not. Supplying True, Default, or leaving it off will commonly display it. In general, we'll be passing the report parameters values by querystring from our application, so I suggest setting this parameter to False.
• rs:Format - The format the report will originally be rendered as when first viewed. If left off, the report will be rendered as HTML. Other values include PDF, HTML4.0, etc. More information on the allowed values can be retrieved from the documentation.

A caveat I found out is that Gecko based browsers (yes, this includes Firefox, Mozilla, and Netscape) don't like to render the Toolbar / Parameter bar properly, basically rendering it useless. So, when developing your URL, I advise that you check to see if it is a Gecko based browser, and render it as PDF. Sure, you loose a lot of functionality of the report (drill downs, etc), but my guess is that these wouldn't have worked in the first place with the Gecko based browser.

Previously, I mentioned that commonly we'll be supplying our own user interface for parameter selection rather than relying on the rudimentary parameter selection interface from Reporting Services. To pass these values, you need only to add additional query string parameters. The name of the parameter being the name of which field it should map to in the report and obviously, the value being what you want to pass. So, that's enough talking about building the URL, I guess you're probably getting ants-y and wanting to see how to do it:

string url = "http://rptsrv/ReportServer/?" + ddlReports.SelectedValue;

if(Request.UserAgent.IndexOf("Gecko") >= 0)
    // this is a gecko based browser, render the report as PDF
    url += "&rs:Command=Render&rs:Format=PDF&rc:Toolbar=False&rc:Parameters=False";
else
    // this is a browser that is supported for paging / exporting, render as HTML
    url += "&rs:Command=Render&rc:Parameters=False";

// add any custom parameters
url += "&year=2004";

// redirect to the report
Response.Redirect(url);

Okay, so assuming you're on a single server environment or using Active Directory as your authentication, you should (upon submitting the form to view the report) be seamlessly passed directly to the rendered report.

Other Rendering Capabilities:
There are other methods of rendering using the Reporting Services API, however these are outside of the scope of this article. If you would like more information on using these methods of rendering, I'd suggest reading this great article on 15 Seconds, as well as checking out the Render method of the API. In a nutshell, the afformentioned method will allow you to stream the report and save / display it in any manner you wish, which could be very beneficial in creating custom reporting solutions for windows applications.

Secondly, apart of the Reporting Services samples installed on your development machine (which oddly enough I didn't install), is a compiled assembly called "ReportViewer.dll" that is a ASP.NET Custom Control for rendering reports directly within a webpage. If you visit the previously mentioned 15 Seconds article (In part 2) they describe how you can utilize that control. After playing with it though, I realized that it generated an IFrame, which as most of you know is BAD BAD BAD! Thats why I went the alternate route and did the redirection.

So, this currently ends my 2 part series on integrating Custom Web Applications and Reporting Services. I hope you found both parts extremely beneficial, and hope that they provided you with as much information that I lacked when trying to figure this out. Lastly, I did want to give props to my good buddy Ryan Rinaldi who helped me figure some of the authentication issues!

Preface:
The following will be a series on integrating your custom web applications with SQL Server Reporting Services. It is intended to provide useful information for other developers posed with the same problem of integrating these two seamlessly.

Situation:
A new project came up at work, where we had to develop our own custom web application where users will be prompted to easily select reports, their parameters, and view them seamlessly all from one interface. This means, that we couldn't just direct the users to the interface provided by Microsoft and assume they'd know what to do. Also, due to requirements by the client, the reports should be available to only certain users with authentication resorting back to Windows / Active Directory.

Notes:
In part 1, I will discuss the method we took to integrate these two applications seamlessly by only being prompted once for windows credentials, or no prompt at all (using your signed on domain credentials). In our situation, the client is still running Novell, so Active Directory integration was out of question, so windows authentication will need to be handled by the reporting / web server.

An important item to note is when integrating the two items on different servers and not using active directory, seamless integration is not possible unless you manage to keep the users / groups in sync with each server (a challenge upon its own). Therefore, due to this requirement, the rest of the article will be based on single server or Active Directory authentication.

Authentication Methodology:
When developing your application, it is best to use windows groups to control authorization to the various reports and different sections of your web application. In our instance, we needed two different groups - Users and Admins. Users in the Admins group would have access in our application the ability to enter new information, while users in both groups had the ability to view all the reports.

Our first step was to create our groups and add the various users to the appropriate groups through the standard windows management console. Once our groups were setup, configuration of Reporting Services to allow the two groups access to view reports only was our next step (Note, this entry will not describe the methods for doing this as there are lots of resources to help you). Now that we're all ready to go, and the authorization to the reports have been tested properly using the Microsoft user interface in Reporting Services, its now onto configuring our custom web application to use windows authentication (again, we will not go into too much detail, but examples will be shown).

Okay, so open your Web.Config file for your custom web application, and add the following entries under your system.web node:

<authentication mode="Windows" />
<authorization>
    <allow roles="<SERVER_NAME or DOMAIN>\Users" />
    <allow roles="<SERVER_NAME or DOMAIN>\Admins" />
    <deny users="*" />
</authorization>
<identity impersonate="true" />

For any subdirectories that you wish to have different authorization on, follow the same template listed above, but leaving out the "authentication" and "identity" elements. In our instance, we needed a subdirectory called "Administration" that only users in the Admins group can gain access. So, after creating the sub directory, we created another Web.Config file in that subdirectory and added the following to the system.web node (Note that there are other methods of doing this type of configuration using a single Web.Config however for ease of example two Web.Configs are used):

<authorization>
    <allow roles="<SERVER_NAME or DOMAIN>\Admins" />
    <deny users="*" />
</authorization>

To briefly explain what we've done for authentication is told our web application to use the Windows mode of authentication. We then authorized only users in the Users and Admins roles access, and denied everyone else. Lastly, the application will impersonate the user that is currently logged in. This is a key concept since we'll be using credentials in part 2 and sending them with the Reporting Services API.

So, now our custom web application is setup - however there are still some settings within IIS that we need to set. The following settings were those that I found to work with our single server setup with no Active Directory verification, so you may need to fiddle with these if using Active Directory. To set the IIS permissions properly, open up IIS, find your Web Application, and view the properties. Click on the "Directory Security" tab, and hit the "Edit..." button for Authentication control. Once the new dialog has opened, uncheck "Anonymous access", ensure "Basic authentication" is checked, and "Integrated Windows authentication" is checked.

Launch your favorite flavor of an internet browser, go to your custom web application and see the magic work. You should immediately be prompted (unless using Active Directory & Digest mode, in which case if your currently logged onto the domain will pass directly through) for your username and password. After typing your credentials, you should be able to log in successfully to your web application. So, go ahead, take a deep breath and pat yourself on your back.

Part 2 will discuss using the Reporting Services API and your custom web application to provide that seamless look to your application.

I was working with one of our engineers getting our company information completed after we just passed an ISV competency test through Microsoft, and while I was filling out the page, I noticed there's a Calendar control on it. So I clicked it, and hey - it looks like mine. Examining the source of the page reveals that it IS mine. Woah, talk about cool...Microsoft is using MY calendar popup control and MY numeric textbox. That gave me a high for the day, and its only 10AM.