Code Access Security and OLEDB

Microsoft have devised a very sophisticated security model for .NET applications to allow fine grained control of permissions.  In theory you can grant an application just the permissions that it needs.

OleDbPermission Class is a good example of how well this has been implemented in practice.

Quote:

This class is intended for future use when the .NET Framework Data Provider for OLE DB is enabled for partial trust scenarios. The .NET Framework Data Provider for OLE DB currently requires FullTrust permission. Currently, using the OleDbPermission class has no effect. For more information, see Code Access Security and ADO.NET.

This is the documentation for the 1.1, 2, 3 and 3.5 frameworks.
This would imply that there is no priority to getting this fixed.

This is a rather key ommision as this is the key component for accessing non-microsoft databases from, say Sharepoint.
I found this while trying to get the BDC to read data from a Sybase database via OLEDB.
At the time of writing (using Sharepoint 2007 which is the latest released version of the product) the tool support for the BDC is sadly lacking.  The tools that have been released do not cope with the OleDb option and the error results are far from impressive.  In order to prove that the problem is in the BDC and not a missing driver I have written a small web part that calls Syabase via OleDb using a connection string.  On my dev box (which I did not know was set to be permissive) this works just fine.  On a UAT environment (natuarlly locked down) the same web part fails.  It would appear that I need to give the web part full trust to allow me to call the database!

Sharepoint Documentation Speaks With A Forked Tongue

The sharepoint documentation is a trap!
There are so many errors, ommisions and inconsistencies in the Sharepoint documentation that you have to resort to direct experimentation to get even the simplest task to work.

Currently I am trying to add a simple web part to a Sharepoint site.  This should be easy.
The documentation claims that you can freely choose to use either ASP.NET web parts or Sharepoint web  parts (both randomly abbreviated to web parts).  Once you get through all of the wierd hurdles required to get a web part to install into sharepoint (Add the manifest file with the correct syntax noting that there are several flavours of manifest files).

There is a lot of cargo cult programming going on with this product (such as rename cab files to dwp before installing them – which is not required).

Once I got a classic asp.net web part installed I was kindly informed by the web page editor that my web part may not be put into a web part zone.

Sharepoint and the BDC

The expensive version of Sharepoint comes with the Business Data Catalog.
This is a means of describing sql commands, stored produres and web services in such a way that Sharepoint can call them to obtain required data.

It is advised not to attempt to use Sharepoint as a high volume transactional system.
The problem is that I need to feed Sharepoint from such a system.

Use of the BDC is ideal for real time lookups of small amounts of data via direct calls.
For static data the use of web services is ideal as you can use the webserver to cache the data that will not change intra day.
However if you have large lists of data you don’t want the transactional system to be hammered with big queries.
As a result we are using a “service” application (OK it’s a GUI – but it could be a service) to update a status table and then push the data into a sharepoint list. This list will then trigger workflows.

I would have liked to use a MSMQ for this but apparently this will not work with our multiple redundant server farm.

Sharepoint – writing to a sharepoint list.

I have started to work with Sharepoint.  This is microsofts portal/integrated search platform.

It requires W2k3 server or higher to run it (and it must be installed to allow you to code against).  This means that most devlopment is performed using virtual pc’s (which is painful).

Some of the documentation is wrong. The bold line was missing from the following:

                using (SPSite oSiteCollection = new SPSite(SiteName()))

                {

                    Debug.WriteLine(oSiteCollection.ToString());

                    using (SPWeb oWebsiteRoot = oSiteCollection.OpenWeb(CoreWebName()))

                    {

                        oWebsiteRoot.AllowUnsafeUpdates = true;

                        SPList oList = oWebsiteRoot.Lists[RawMessageList()];     // Get this from a config file

 

                        SPListItem oListItem = oList.Items.Add();

                        oListItem[“Title”] = Reference;

                        oListItem[“Created”] = DateTime.Now;

                        oListItem[“Modified”] = DateTime.Now;

                        oListItem[“Author”] = AuthorId(); 

                        oListItem[“Editor”] = AuthorId(); 

 

                        oListItem[“MsgType”] = MsgType;

                        oListItem[“Reference”] = Reference;

                        oListItem[“MsgBody”] = MsgBody;

 

                        oListItem.Update();

                    }

                }

This meant that the webservice that I was writing to populate a list was failing with

The security validation for this page is invalid.

I found this article that pointed me in the correct direction.

I am using webservices to abstract the list population so that I can have applications that are not dependent upon Sharepoint yet still can still work with sharepoint.  This will allow them to be tested on any dev machine, not just our Sharepoint farm.