No More ASP.NET

I’ve read about this before but just missed something. That Something I missed was pretty important.

In the Visual Studio report project properties there are three items that are important to set correctly:

TargetServerUrl – this is the Url of the SharePoint site.
TargetReportFolder – this is the Url where you want your reports to go, within the SharePoint site.
TargetDataSourceFolder – this is the Url where you want your data sources to go, within the SharePoint site.

Now this is very important so listen closely: the TargetServerUrl is the Url of the SHAREPOINT SITE and is **NOT** EQUAL to the TargetReportFolder or the TargetDataSourceFolder

If you have a SharePoint site at http://www.company.com/sites/Accounting then the TargetServerUrl should be set to http://www.company.com/sites/Accounting.

Now you need someplace to store the reports. Reports can be stored in Document Libraries. So, within the SharePoint site you will either:

1. Create a new Document Library that is setup with Report Builder Report content type, or
2. Use the Shared Documents library and set it up to receive Report Builder Report content type.

You may want to also include the Report Data Source content type in the Library as well.

Let’s say you set up a new Document Library called “SalesReports”, and wanted to deploy reports from Report Designer into that library. Let’s also say that you set up another Document Library called “DataSources” to store your data sources into (just to keep things nice and neat). Here is what you would enter into the Report Designer report properties:

TargetServerUrl:                http://www.company.com/sites/Accounting

TargetReportFolder:          http://www.company.com/sites/Accounting/SalesReports

TargetDataSourceFolder:  http://www.company.com/sites/Accounting/DataSources

It took HOURS to figure this out. Hope it helps someone.

Visual Studio 2005 is the most powerful developer’s tool in existence today, bar none. (the same was true for Visual Studio 2003 in its time)

It is designed with a single goal: to increase developer productivity. Period. How do I know this? Because, you know a tree by its fruit.

So when developers misuse it by handwriting code that VS generates automatically they are wasting their time and money.

For instance, take the XML Schema designer. The Schema Designer, as well as the Data Designer, allows you to visually create a schema and see the relationships between elements as well as attribute and element types. The Designer automatically generates code when you save the schema.

This code is well written, well tested, and efficient.

So why would someone hand code routines to read an XML file? Even worse, why would someone use concatenated strings to save an XML schema in the code?

The usual excuse is: “We want to keep the schema hidden from <insert criminal/customer group>.” This is no excuse. VS will not only automatically generate schema serialization code, but that code will give no impression of the underlying schema it is serializing. In fact, the generated code allows you to ship the software without including the schema file that it’s based on. Furthermore, if the schema must change it is changed in the designer, visually, where any developer can change it without having to study and understand complex serialization code. And he can do it two years from now, when everyone has forgotten how that particular piece of code works.

Hand writing code that VS generates is one of the best ways to waste Visual Studio.