Trustworthy!!

The other day I landed on a very interesting issue. Before I break in the solution, let me just try and explain the problem the way it came in.

Well, there was this guy who had created a custom web part to fetch a report from some database. He was supposed to be using a SQL database in production, but due to some reason, he had to make do with an Oracle database in test. The web part was using the ADO.NET ODBC and SQL data objects to establish connection and perform data retrieval. The problem as he accounted to me seemed to occur only when he used the SQL objects. Whenever he used the SQL objects and deployed the web part, and then dropped it onto a page, the action took him to an error page which asked him to go to the Web Parts Maintenance page and remove the web part. But if he went back to the drawing board and replaced the SQL objects with the ODBC objects, the same behaviour did not reoccur. His question, do we know this as a bug.

As a good support fellow, I asked him to share his web part. A reproduction was in order. And as I expected, there was nothing darn wrong with his poor little web part. But something was definitely going amiss. I recounted his demonstration of the problem. He was using a setup and deployment project and using the stsadm command line to deploy the web part. On the other hand, I as is widely done in PSS, used the Install Assemblies tool to deploy the web part. So faithfully, I sent the whole thing back, and asked him to use the Install Assemblies tool. A simple GAC deployment worked wonders. Not only did the error go away, but it also, succesfully fetched the results. I was elated. On closer investigation, the problem focus moved from ADO.NET data objects to the install location. As all of us know, there are two locations where one can deploy a web part assembly. One in the GAC the other in the assembly bin folder. These two locations behave quite differently from each other and result in a wide array of different outcomes.

The GAC is considered as a fail-safe option, where anything and everything will run without any issues. The bin folder on the other hand requires a practiced hand and a keen eye to tweak the settings. So the preferred location for a web part always tends to be the GAC. This is because the GAC enjoys a fuller trust level than any other location. Now in this case, it was a requirement to deploy to the Application bin folder. So the workaround would be to tweak the web.config file at the portal root and change the security trust level to 'Full'.

But it couldnt be so simple. This guy now wanted to not change the trust level for the entire portal but only for the particular assembly. Possible? Lets see. In the web.config you would notice that there is a path mentioned pointing to a different config file. Now, there are three config files for WSS_Minimal,WSS_Medium and Full. So the solution looks like adding the safe entry for the assembly into the particular .config file. Needs to be checked, but lets see how it goes.

 

/Harsh

Comments

• Anonymous
  January 26, 2006
  The comment has been removed