Monthly Archives: October 2006


Every two weeks we have a knowledge session at Class-A about one or more technical subjects. Last Monday I had to give a presentation about Reporting Services and talked about calculations, parameters, embedded code and custom assemblies in Reports. We discussed about the pros and cons of using code in your report. And when I mentioned the code is a VB-like language a loud discussion started. VB-like languages does exist, but SSRS and SSIS use full blown VB.NET. So why doesn’t everything work full blown. In this blog I try to explain why.

During this session my Virtual PC 2007 gave some strange errors. It looks like I had sticky fingers, because it repeated a character while typing which is very annoying. By the way, I now know this is a known issue at Microsoft. Besides the sticky fingers, my Caps Lock was flipped as well. Maybe this is good moment to introduce my new colleague Pascal Naber who will start in January 2007 and what I think is a complete opposite of my type in IDM (Influencing Descision Makers). I'm an organizer and he's more of controller. He's wants to be in control with all his stuff and he's actually using "Getting things done", to stay one step ahead. Furthermore Pascal has its own casing and thanks to my Caps Lock problem I have my own too. So for this example I'm using mIKEcASING instead of PascalCasing.

Custom .NET code
You may want to add custom code to the report to do more actions than what's provided with the report functions. So it gives you a base for extending your report. You may want to add custom code to implement simple string manipulation task or sophisticated data access manipulation. Code added to Local Report can be one of two types:

  • Embedded Code: Added directly inside the report. If you open the RDL file in notepad, you can see the code inside the <Code> tag.
  • Custom Assemblies: You can add a reference in external assembly and use functions inside it.

Embedded Code.
Embedded code is by far the easiest method to implement for two main reasons. First, you simply add the code directly into the report using the report designers UI. Second, this code becomes a segment within the reports RDL file making its deployment simple because it is a part of your report and will be deployed with it. Reporting Services gives you a number of functions to use in a report. For instance there are functions to sum and average numbers, and functions to count values. Visual Basic functions such as InStr and DateAdd are present, as are Iif and Switch. However, the product designers could not predict your every need, and embedded code allows you to implement functions with custom code.

Emmbeded VB.NET Code

VB-like or VB.NET
You might notice this code is written in VB.NET. All .NET namespaces can be used inside your custom code but be aware that by default only Microsoft.VisualBasic, System, System.Convert, and System.Math namespaces are referenced inside your reporting custom code. Methods in other namespaces, as shown in the example needs to use their fully qualified name.

So why did I think it was a VB-like language?
Code Access Security is in effect in Reporting Services. Since end-users can upload reports with embedded code, it makes perfect sense to protect the server and network from malicious report code. Embedded code executes with the built-in Execute permission by default, which does not allow for much beyond string and math operations on the Reporting Services object model. You would not, for instance, be able to use file or network IO.

If you need additional permissions for your code, you can change the default permission for embedded code but it is not a step to take without very careful thought. Modifying the permissions for embedded code will allow the code in any report to execute with the same permissions. This is another scenario where I would strongly advise using a custom assembly. For more information on code access security in Reporting Services, take a look at Understanding Code Access Security In Reporting Services.

How to use it
The function can be accessed throughout the report as a member of the class called Code. The Code class is instantiated by the report once and its methods can be accessed throughout the report. In place of the expression I could use the following line of code to reference the FormatDateInterval method:


One of the biggest advantages to using embedded code is that you can encapsulate methods required by a report in a single place within the report. The embedded code in the Code window is put inside a special XML element in the report’s RDL file. This means that the code is deployed automatically with the report wherever it goes.

If you prefer C# or another .NET language, you’ll have to access a separate .NET assembly. And keep in mind when using embedded code that the methods can be accessed only by the report that contains them. The embedded code window is merely a large textbox and offers no IntelliSense or built-in debugging features. But for creating quick methods that are intended to be accessed by a single report, the code window is a very simple and effective tool.

If you want multiple reports to use the same code, you should consider accessing a .NET assembly from the embedded code, as I’ll demonstrate in the next part. Security policies prevent the report from performing anything beyond basic operations in embedded code, such as accessing external files, databases, or other resources. Your report can reference .NET assemblies from the References tab in the report properties dialog, but any referenced assembly will, by default, have only Execution permission.



An update of this blog is available. In the new blog I explain how to use the Microsoft Office Multi-Language Pack 2007 and how to install extra Proofig Tools for Office 2007.

I'm working with Office 2007 now. Who isn't? Unfortunately Microsoft only released German, French and Chinese language packs. But proofing tools for other languages aren't available yet. When you have installed Office 2003 and you upgraded to Office 2007 Beta 2 you're proofing tools are automatically recognized and added to your new Office Product. Luckily you can install the Office 2003 tools afterwards as well. Just follow the steps and you're Office will be upgraded.

Step 1 Install Office 2003 (Custom Install)
Select only Proofing Tools and deselect all other options

Step 2 Install the additional Proofing Tools of your language
Select only your Language and deselect all other options

Update: Step 2b Deinstall Office 2003 (Tip of Suomi)
Go to Add/Remove programs and remove Office 2003 from the list

Step 3 Open a Office 2007 Product
This product will automatically integrate the Office 2003 Proofing Tools


Step 4 Select your Language options
Check your settings if the language is added

Step 5 Update your machine
This is the worst step, cause your brand new machine will have several Office 2003 updates, including SP2 and all kinds of updates for Word, Excel, e.t.c.
Update: Thanks to Suomi (step 2b), this will only update Proofing Tools, without any other updates for Office 2003 (e.g. the 110MB SP2)

Update: Step 6 Update OCR in documents (Tip of Ho)
Move the *.LNG files from /Program Files/Common Files/Microsoft Shared/MODI/11.0 to .../MODI/12.0.

Microsoft isn't able to deliver the correct Proofing Tools for Office right now. I hope they have solved this problem in the Office 2007 RTM. They don't have to deliver brand new proofing tools. If only they deliver the old ones but not recognized as a Office 2003 product.


Will there be an PTK for Office 2007
There will indeed be a Proofing Tools Kit (PTK), but it will not be marketed as it was in Office 2003. The 2007 PTK will actually be part of the Multi-Language Pack (MLP). This pack consists of 3 CDs. The first two CDs include all the Single Language Packs (SLP), each of which contain proofing tools (spell-checker, grammar checker, hyphenator, thesaurus…) as well as the localized user interface (UI) and localized Help for a given language.  The third disc will contain all the proofing tools by themselves.

If a user just wants to add one or two proofing tools (say, they want to use a Russian or an Dutch speller, which is not part of the default English version of Office), they will be able to download the SLPs for those additional languages in which they are interested. But if someone is deploying many proofing tools languages and does not want the associated UI or are concerned about disc space, they will be able to purchase the boxed MLP and use the third disc. Enterprise customers that purchase the multilingual license will have access to any of these deployment methods.

This flexibility is designed to respond to demand from users. We have regularly seen on newsgroups that many individual users are interested in adding one or two languages to their own configuration. Being able to directly download and purchase a single set of linguistic tools (a speller, a thesaurus and a grammar checker, for instance) for a given additional language will meet many users’ needs.

What is the Microsoft Office Multi-Language Pack 2007?
The Microsoft Office Multi-Language Pack 2007 is an add-in product that can change the entire user experience of Office 2007 desktop applications by enabling each desktop to support many languages.. This includes Menus/User Interface, Help, Dictionary, Thesaurus, and Spell Checker. In addition to enhancing the user experience, a user can elect to use individual aspects of the pack, such as spell checker to proof a document in a language other than the default language set on their computer.

What languages are available?
The MLP will include tools for the following languages:

Arabic, Brazilian Portuguese, Bulgarian, Croatian, Czech, Danish, Dutch, English, Estonian, Finnish, French, German, Greek, Hebrew, Hindi,   Hungarian, Italian, Japanese, Kazakh, Korean, Latvian, Lithuanian, Norwegian, Polish, Portuguese, Romanian, Russian, Serbian Latin, Simplified Chinese, Slovak, Slovenian, Spanish, Swedish, Thai, Traditional Chinese (HK), Traditional Chinese (Taiwan), Turkish, Ukrainian.

-- Thierry Fontenelle (Program Manager) & Jay Waltmunson (Program Manager) --

When exactly the introduction of Windows Vista takes place in the Netherlands, is still a riddle. In Canada the launching will be November 23th. On the Canadian Msdn-website Microsoft announces a large event where Windows Vista, Office 2007, and Exchange server 2007 are launched. The introduction takes place in the Canadian Edmonton.

It's the first time that Microsoft mentions a concrete date when Vista are provided. So far Microsoft have only said that manufacturers and business customers can have Vista in November. For consumers the software is provided in January 2007. The introduction of the operating system Windows Vista has been postponed several times. According to the information on Canadian Msdn-website, Vista is now really tied to a schedule.  

Office 2007 Beta
Microsoft has announced that the Office 2007 beta will end soon. You can read this on Let me summarize the key points:

  • 10/25 the Office Preview site will be closed down. You will not be able to download Beta2TR after 10/25. All other information currently found on the Office Preview site will be migrated to the Office Online website.
  • 10/28 - Technical support gets a new home Beginning October 28, support for Office 2007 products will transition from the Beta support newsgroups staffed by Office employees to the in-market product support provided by Microsoft Customer Service and Support.
  • 10/30 - BetaPlace website and support newsgroups ( close down.
  • 10/31 - SharePoint team sites decommissioned The team site that you have been using at [name] will be shut down on October 31. If you have any important files or information stored on your team site, you need to store a local copy, as all data on your site will be destroyed when the site is decommissioned.

Some other important information include:

There will be no new releases beyond B2TR. The B2TR build is set to expire on March 15, 2007 for all client products and May 31, 2007 for all server products. You may upgrade/migrate server products from Beta2TR to the retail release. However, all Beta version client applications (Office Professional, Visio, SharePoint Designer, etc.) will need to be uninstalled before you install retail versions on your machine.

1 Comment

Several people are complaining it's impossible to install another Office 2007 product on your machine when you've already updated the previous to B2TR. In a few screenshots I'll show you otherwise. In this example I'm using Project Professional 2007 as the second product to install. Of course I slipstreamed my product, so it will automatically upgrades the Beta 2 to B2TR. For a complete reference about slipstreaming watch the screencast on the Dean's Office. This screencast is based on WSS, but is pretty much the same for all other products.

When you try to install Project for the first time with the default settings, an GraphicsFiltersCDRFilesIntl_1033 error will occur. The screens below shows you an exact dump of the error.

Error GraphicsFiltersCDRFilesIntl_1033

To get rid of the error you have to disable all Converters and Filters. These are already updated by B2TR of your first Office product and other Office Beta 2 product isn't able to discover these updates. To disable this option you have to select Customize in the startup screen.

Disable Converters and Filters

When you have disabled the Converters and Filters option and slipstreamed your product, it will automatically update it and installs it successfully.

Successfully installed product

Microsoft isn't able right now to discover it's own updates. I hope this 'feature' is resolved in Office 2007 RTM.


As discussed in my first post Building my own UserControl WebPart part I I'll extend the class model for the UserControl WebPart project. Besides the methods, all fields and properties will be added to those classes too. In this part I discuss why they are added and where they are used for. At the end a screendump is added of the sample ASP.NET 2.0 portal using a UserControl as a WebPart. This UserControl will be the sample UserControl to use in my solution during all my parts.

Class Diagram 

All classes are described below:


  • Properties
    • public string UserControlPath
      Path to the UserControl folder.
    • public string UserControl 
      FileName of the UserControl to load.
    • protected internal Hashtable UserControlProperties
      Stores values of the UserControl properties in a Hashtable. This property is protected internal cause it needs to be called from EditorPart controls.
    • object IWebEditable.WebBrowsableObject
      Gets a reference to the WebPart control to enable it to be edited by custom EditorPart controls.
  • Methods
    • protected override void CreateChildControls
      Composition-based implementation to create any child controls. This method will call LoadUserControl.
    • protected internal void LoadUserControl
      Loads the UserControl dynamically to the page. This methods is protected internal cause it needs to be called from EditorPart controls when properties changes.
    • EditorPartCollection IWebEditable.CreateEditorParts
      A collection of custom EditorPart controls associated with this WebPart control.


  • Methods
    • protected override void RenderContents
      Renders information about this WebPart control.


  • Methods
    • public void RenderPropertyEditors
      Renders all properties of the UserControl in grid formatted table.


  • Methods
    • protected override void CreateChildControls
      Composition-based implementation to create any child controls. Creates a DropDownList when the UserControlPath exists, else TextBox.
    • protected override void RenderContents
      Renders the properties of the EditorPart control using RenderPropertyEditors of the base class.
    • void userControlList_SelectedIndexChanged
      Handles the SelectedIndexChanged event when an user changes the value of the DropDownList. Reloads the selected UserControl to show the properties.
    • void userControlTextBox_TextChanged
      Handles the TextChanged event when an user changes the value of the TextBox. Reloads the given UserControl to show the properties.
    • public override bool ApplyChanges
      Stores the selected UserControl.


  • Properties
    • private ArrayList EditorControls
      A list of all EditorControls of all editable properties.
  • Methods
    • protected override void CreateChildControls
      Composition-based implementation to create any child controls.
    • protected override void RenderContents
      Renders the properties of the EditorPart control using RenderPropertyEditors of the base class.
    • private Control CreateEditorControl
      Creates a TextBox, DropDownList or CheckBox depending on the type of the property.
    • private object GetEditorControlValue
      Gets the value given by the user in the WebEditorZone.
    • private PropertyDescriptorCollection GetEditableProperties
      Checks whether a property in the UserControl contains the WebBrowsable attribute.
    • private string GetDescription
      Gets the description of a property using the WebDescription attribute.
    • private string GetDisplayName
      Gets the displayname of a property using the WebDisplayName attribute.
    • public override bool ApplyChanges
      Stores all property values in UserControlProperties Hashtable.

Constructors and methods not used are not mentioned.

In ASP.NET 2.0 you can use a web user control (ascx) as web part because of the ASP.NET 2.0 GenericWebPart class. If the class implements the IWebPart interface it has some extra properties used in webpart Editor. The GenericWebPart control exists to provide a run-time wrapper for server controls that are not WebPart controls, so that such controls can be used in Web Parts pages and applications.

UserControl in ASP.NET 2.0 Portal using the GenericWebPart

Unfortunately, this GenericWebPart is not available SharePoint 2007. That's why I build my own UserControl WebPart. This WebPart Control needs to be more dynamic than the GenericWebPart class, cause it needs to load UserControls from in- or external Assemblies using in-line code or code-behind files.

UserControl in ASP.NET 2.0 Portal using the My UserControl WebPart

What I like to accomplish is to dynamically load this usercontrol and still are able to modify all UserControl properties which has WebBrowsable attribute.

UserControl in ASP.NET 2.0 Portal using the GenericWebPart

In the next part I'll will complete the aboutEditor and add code to the UserControlWebPart to dynamically load a control and add the editors to the Editor Zone.


Yesterday I was rewriting my two-day Reporting Services 2005 course to a three-day course. The previous times I gave this course I ran out of time and couldn’t explain every module in depth. So I decided to extend the course and add an extra module about Implementing Business Logic with MDX. This new module contains information about using Analysis Services Cubes to create reports. I’ll focus on matrix and graphics data regions as well. Besides adding a new module I was adding some content to the other ones. When I was extending the Programming Reports module I found out about SQL Server 2005 SP2.

As you know, we already have SharePoint Web Parts, and they work well. However, Microsoft will include much deeper integration with WSS/OS in SP2. Some limitations of the current WebParts are:

  • Separate content stores;
  • Different security models;
  • Different management UI;
  • No filter web parts.

The reporting team did a great job to fully integrate Reporting Services into WSS/OS. After installing SP2, you can run Reporting Services in "native mode" (like it’s today), or "SharePoint integration mode". The integration mode will enable publishing, viewing, and management of rich reports.

Integration Architecture

SQL Server 2005 SP2 is installed on a report server along with the SharePoint Object Model (farm install). The Reporting Services feature pack is installed in WSS “v3” and the Report Server web service URL is registered with WSS farm. To create a new Report Server database in “SharePoint Integration mode” you can use the Reporting Services Configuration Tool. In SP2, the tool has been modified to include some additional UI to do this work.

Note: Unfortunately it’s not possible to migrate from existing SQL Server 2005 Reporting Services (SSRS) installations.

Using “SharePoint Integration mode”, most of the objects you're used to store in reportserver database are instead stored in SharePoint database. Some functionality like scheduling, subscriptions, snapshots and caching are still stored in the reportserver database. Lets say they implemented every feature of Reporting Services in SQL Server 2005 Express in WSS.

All other objects like reports, data sources, and report models are published to SharePoint document libraries. When a report is selected in WSS, the report viewer Web Part calls the report server API to process and render the report. Users can manage properties and subscribe to reports through WSS UI which calls the RS SOAP API. New report server delivery extension allows for rendered reports to be delivered to WSS document libraries (including Report Center). Another nice thing is all cool features of SharePoint like versioning, collaboration and workflows are now available to all objects.

Note: Report Manager (Web UI / Management Studio) is not supported in “SharePoint Integration Mode” and it's not possible to run SSRS in both modes at the same time.

Another major change is security. All permissions are set within WSS and will give you a consolidated place to manage security. For Example when using Team Foundation Server you now have to set rights in TFS, SharePoint and Reporting Services. I hope tools like this will fully integrate with SharePoint as well. The design tools (Report Designer, Report Builder, Model Designer) are also updated to work with WSS.

Note: It looks like data-driven subscriptions is cut out. Normally this is really powerful feature. So I hope the Microsoft team is aware of this and will soon add it to the “SharePoint Integration mode”.

SharePoint User Interface
Viewing reports while in integrated mode is like any normal webpage in SharePoint. You can use the Report Viewer WebPart to show a report in full page view or on Web Part Pages. This WebPart wraps the ReportViewer ASP.NET Viewer Control and handles report rendering calls to report server. Besides handling it will give you all the properties by using its own EditorPart and verbs. The properties can be devided by:

  • Report: ReportPath, HyperlinkTarget
  • View: AutoGenerateTitle, AutoGenerateDetailLink, ToolBarMode, ParametersMode, ParametersAreaWidth, DocumentMapMode, DocumentMapAreaWidth
  • Parameter: Default Values

At last is will also support Filter Consumer and Row Consumer interfaces for specifying report parameter values via filter Web Parts. This way you can slice Excel Workbooks and Reports on a single Web Part page. Superb.

Document Library UI

Viewing Reports (Full Screen)

Report Properties (Parameters)

Report Viewer Web Part

Other important changes
Integration will give you new report server SOAP and WMI interfaces endpoints.
The SOAP Proxy is now installed in WSS to support firewall deployment.
Most API’s are mapped to SharePoint object model calls. For example, ListChildren returns items in the content database.
File Extensions are mapped into Report Server types (Report / Data Source / Model / Resource)
Reporting Services security role definitions are replaced with SharePoint principles. CreateRole, DeleteRole, GetRoleProperties, SetRoleProperties are all removed

I think the the team did a great job. They have said they will deliver a version with no differences between the native and the integrated mode, but it won’t happen in SP2. The integrated mode will be very populair with customers deciding to use SharePoint and are using less complex solutions. More complex solutions using subscriptions and lots of administration will still use native mode.


Today I started creating my own UserControl WebPart project. I decided to start from sratch en use the Class Desinger of Visual Studio to model the diagram. I've created five classes where four of them are used for editing the WebPart. Ofcourse I modeled an AboutEditor which inherits from System.Web.UI.WebControls.WebParts.EditorPart to create a top part where the name, version and the author of the control is added.

The other two editors are used to display the properties of the WebPart itself and the UserControl selected / given by the user. Both of the editors inherits form the base class BaseEditorPart which will render the properties and their display names.

Class Diagram

The UserControlWebPart class which inherits from System.Web.UI.WebControls.WebParts.WebPart is used to load the UserControl selected / given by the user. It's very easy to load a control dynamically. The following method will do the trick.

protected override void CreateChildControls()
        this._control = (UserControl)Page.LoadControl(this.UserControl);
    catch (Exception ex)

Besides this, it will also implement the System.Web.UI.WebControls.WebParts.IWebEditable interface. This interface enables you to associate custom EditorPart controls with a server control--such as a WebPart control, a user control, or a custom server control. The EditorPart controls are contained with an EditorZone control, and this zone with its editing controls provides end users with a user interface (UI) for modifying properties, appearance, and behavior on the associated WebPart control.

In the next part I'll will model the public methods in the classes. I also give a screendump of the sample ASP.NET 2.0 portal using a UserControl. This UserControl will be the sample UserControl to use in my solution during all my parts.


I recently checked a couple of blogs about using dynamically loaded User Controls. Some of the blogs mentioned SmartPart v2 (aka SonOfSmartPart) to load ASP.NET 2.0 User Controls. This WebPart is completely targeted to SharePoint 2003, but it will remain working in MOSS 2007. When creating new Web Parts, you have the option of creating Web Parts that inherit from System.Web.UI.WebControls.WebParts.WebPart (recommended) or Microsoft.SharePoint.WebPartPages.WebPart (inherits from). The Windows SharePoint Services WebPart class exists primarily for the purpose of backward compatibility (Web Parts continue to work in Windows SharePoint Services 3.0 without modification), and to provide a small set of features that are not available in the other class.

Besides the targeting it's also not possible to use this Web Part in a ASP.NET 2.0 Portal. I know it's really easy to drag and drop a User Control in ASP.NET 2.0 Portal, but I also want to have this ability in MOSS 2007. Furthermore I like to have an option to add User Controls dynamically (not included in my Portal project). Scott Guthrie has written some astonishing info in one of his blogs about whether it will be possible to host Web Parts built as ASP.NET 2.0 User Controls within SharePoint 2007. He checked with the SharePoint team, and they told him that this will be a supported scenario via an additional component you add to SharePoint and that they'll have a Whitewater and sample on how to-do this published later this year.

I couldn't imagine this option wasn't available in MOSS 2007 and that the SharePoint team will give a additional component only later this year. As Joris Poelmans wrote in his blog Usercontrols (ascx), webparts and SharePoint 2007, it isn't that hard to dynamically load a User Control. Reading this blog I decided to write my own SmartPart fully ASP.NET 2.0 compatible. I heard some rumors that Jan Tielens is writing a Revival of SmartPart too, but I couldn't wait that long.

I'm starting a series of posts about my own UserControl WebPart. The goal of the series is to create a DLL which is public to everyone who wants to use it. While other articles sometimes are too long, I want to keep them very short. That way you're able to read them before your workday begins or perhaps just before you shut down. 🙂

From every post I'll refer to this post and I'll keep an index here so you can easily find your way.

Complete index

  1. part I (Startup project)
  2. part II (Class Diagram and test UserControl project)
  3. part III (WebPart project)
  4. part IV (About EditorPart, displaying a info about the WebPart)
  5. part V (WebPart EditorPart, selecting a UserControl)
  6. part VI (UserControl EditorPart, discovering properties of UserControl)
  7. part VII (Consumer / Provider)

I try to keep you informed and eventually will post my UserControl WebPart as a DLL.