NOTE: See this blogpost for updated information on this topic.
SharePoint 2003 has a very powerful feature to run pages in the context of a site, this is especially used for the administrative pages. All these administrative pages live in the “/_layouts” folder. If you have two sites, http://server/A and http://server/B, and an administrative page admin.aspx, you can execute this page in site context as follows:
http://server/A/_layouts/admin.aspx executes in the context of site A
http://server/B/_layouts/admin.aspx executes in the context of site B
Within those pages you can directly access the current site with the following line of code:
SPWeb site = SPControl.GetContextWeb(Context);
With this site object as starting point you can access all information that is in your site.
This approach is used in all standard pages in /_layouts, with all pages containing inline code.
All the years I have been working with SharePoint 2003 I had another approach to create web pages to run in the context of a site. I just create a web project, deploy the aspx pages, images, client scripts etc to a directory in /_layouts, and put the "code behind" dll's into /_layouts/bin.
This approach no longer works, and a new adventure begins...
- In SharePoint 2007 the _layouts virtual directory no longer contains a "bin" directory, all pages use inline code. First thing I tried was to add a "bin" directory, deploy my "code behind" dll's there and go to my page http://server/_layouts/myapp/default.aspx. Nothing happened, not even an error, just a blank page.
- I change the name of of the page to a non-existant name: http://server/_layouts/myapps/blabladefault.aspx. Again nothing happened. All url's requested in _layouts that don't exist just give a blank page!!
- After looking at the web.config in SharePoint 2003 I see that the line:
<trust level="Full" originUrl="" />
is missing, so I add that line. Still the same result, a blank page. But at the same time strange things start to happen to other parts of SharePoint. The other administrative pages return a blank page as well, and the pages in the SharePoint administration site start to loose their design. After looking at the source of the page it is not so strange: a lot of assets from the /_layouts path are referenced. But it is strange that with trust level "Full", the highest as far as I know, things stop working!
I remove the "bin" directory, the web.config is as prestine as it was, and I try again. Something happens: I get an expected error, the "code behind" dll can't be found! A nice error is displayed in "SharePoint syle", with the message: Could not load type 'myapp._Default'. Ah, almost there I'm thinking, we just need a probing path.
I add the probing path to give .Net direction on where to look for the dll's:
<runtime>and I hit the refresh button in great expectation... same error. the "code behind" dll can't be found.
One last thing to try that must work, otherwise I'm getting mad: throw the "code behind" assembly into the GAC. I strong-sign my assembly, drag it to the GAC, do an IISRESET and... shoot! I'm mad! Still the same error!
Back to the model that Microsoft uses in the _layouts pages: all code inline in the aspx pages, and this works... I hate this approach, but it seams the only way.
And now my questions!!! There must be someone out there who knows how to solve my problem.
- Is it possible to have pages with code behind in _layouts, and have the code behind assemblies in a bin directory?
- Is it possible to have our own custom"_layouts" like virtual directory that executes "in context" of a page?
UPDATE: I managed to get a 2005 web project working, where the code is not precompiled. You don’t need to deploy your code-behind code deployed as a DLL. One thing to watch out for however: if you have a web.config file in your project, comment out the following line: <authentication mode="Windows"/>.