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.

Getting WSS 3.0 and ASP.NET apps to coexist on port 80 (this includes web services) is pretty straightforward. The toughest part is figuring out how to do it.

I had originally tried and tried to get SharePoint to install on the “Default Web Site” at W3SVC/1. Well, that wasn’t happening–don’t know why, but it wasn’t. I used both SharePoint Central Administration and STDADM with extendvs and it still created a new website named “SharePoint – 80″. Oh well…

So then I started moving the applications from the Default Web Site to “SharePoint – 80″. At first I tried DotNetNuke and a webservice as two separate test scenarios. It took hours of trial and error (and reading Inside Microsoft Windows SharePoint Services 3.0, which has an excellent security section) to finally get both apps to work.

The trick: “Full Trust” on the root web.config.

Selah

Now, don’t go running out and doing that on the WSS site. It’s bad business. Write your applications correctly specifying the proper permissions needed and do your best to make the app run in WSS_Minimal or WSS_Medium trust. Better yet, create a custom trust level and install it in WSS. Then your application is truly enterprise ready.

Ok, with that said, I can’t be sued.

Anyway, adding Full trust to the root web.config and setting up your applications normally (just using the “SharePoint – 80-” website) and you’ve got WSS and ASP.net applications coexisting happily. They even work with WSS managing the root folder (explicitly, that is). That means you can have a SharePoint site on the root of your website and ASP.net applications in other virtual directories.

Enjoy!