views:

953

answers:

4

Hello,

I wonder what the best practice for this scenario is:
I have a Sharepoint Site (MOSS2007) with an ASPX Page on it. However, I cannot use any inline source and stuff like Event handlers do not work, because Sharepoint does not allow Server Side Script on ASPX Pages per default.

Two solutions:

  1. Change the PageParserPath in web.config as per this site

    <PageParserPaths>
    <PageParserPath VirtualPath="/pages/test.aspx" CompilationMode="Always" AllowServerSideScript="true" />
    </PageParserPaths>

  2. Create all the controls and Wire them up to Events in the .cs File, thus completely eliminating some of the benefits of ASP.net

I wonder what the best practice would be? Number 1 looks like it's the correct choice, but changing the web.config is something I want to use sparingly whenever possible.

+1  A: 

What does the ASPX page do? What functionality does it add? How are you adding the page into the site? By the looks of it this is just a "Web Part Page" in a document library.

I would have to do a little research to be 100%, but my understanding is that inline code is ok, providing it's in a page that remains ghosted, and thereby trusted. Can you add your functionality into the site via a feature?

I would avoide option 1, seems like bad advice to me. Allowing server side code in your page is a security risk as it then becomes possible for someone to inject malicious code. Sure you can secure the page, but we are talking remote execution with likely some pretty serious permissions.

Daniel McPherson
A: 

Well, it's a page that hosts user controls. It's a custom .aspx Page that will be created on the site, specially because I do not want to create WebParts.

It's essentially an application running within Sharepoint, utilizing Lists and other functions, but all the functionality is only useful within the application, so flooding the web part gallery with countless web parts that only work in one place is something i'd like to avoid.

Michael Stum
+1  A: 

So in that case I would wrap it up in a feature and deploy it via a solution. This way I think you will avoid the issue you are seeing. This is especially useful if you plan to use this functionality within other sites too.

You can also embed web parts directly in the page, much like you do a WebControl, thereby avoiding any gallery clutter.

Daniel McPherson
+1  A: 

Thanks so far. I've successfully tried Andrew Connel's solution:

http://www.andrewconnell.com/blog/articles/UsingCodeBehindFilesInSharePointSites.aspx

Wrapping it into a solution is part of that, but the main problem was how to get the code into that, and it's more leaning towards Option 2 without having to create the controls in code.

What I was missing:
In the .cs File, it is required to manually add the "protected Button Trigger;" stuff, because there is no automatically generated .designer.cs file when using a class library.

Michael Stum