Improved / different version features

Oct 23, 2008 at 12:43 PM
Hi all.

 I made a different version from scratch before I found this. Gz to me for that. I keep telling people, if you can think of something, it's been done.

Anyway, there are a few points of difference, I would like to bring up, and perhaps post my own code to have a different version of the thing.

Points I would like comments on:
1. I don't like to post my aspx pages to any other location than under _layouts, due to access to application.master, and allowing to run inline / codebehind code without changes to the pageparsers / web configs / CAS settings
- please comment on this, as I intend to keep my version that way for simplicity
- being allowed to use application.master, and run direct codebehind from the file system is just too good for me to make the aspx pages "published". Also one would have to GAC the precompiled dll.

2. I would like, the possibility of automating the configuration of my sharepoint web apps to use the new 404.html page, BUT, see it as too heavy / intrusive. Thus I currently just run 4 lines of powershell code to do it.
- so, I intend to keep my version as not automating the webapp.pagenotfound value. Yeah, manual labor.
- question, does that always entail code in the GAC, to automate this? Because that is what I am trying to avoid.

3. Skipping the feature receiver, will at least remove some of the automatic deployment.
- personally I see having to manually configure the redirectlist a bit, as a good thing. One needs to configure security anyway. And the default view ain't too bad to reconfigure also.
- can someone define what I lose in terms of automation here, versus the cost of automation (event receiver, code signing, CAS, GAC, multiserver deployment etc)
currently the cost of this automation is just too high for me to "do it".

4. Parameters.
- I would like to parameterize, the following in resource files:
- incoming vanityUrl list static / internal name
- outgoing target actual URL list static / internal name
- display names for the above
- list group name (for the internal deployment stuff, and the column group name?)
- list url
- aspx page deployment module url ( in my case currently /Layouts/MyRedirect [not really, but like that])


Please comment on this, and I shall post my code as an alternate version here, if allowed by the great master of this project, or perhaps (anyway) post it as an alternative method of smart vanity pages / landing pages.

As always, lost in the confusion of mankind,
Myyz.
Coordinator
Apr 8, 2009 at 11:03 PM
I apologize for the late response to your inquiry. I had thought I had notifications turned on but I guess they never reached me. Answering your questions below:

1) I generally deploy code based pages to layouts as well for the benefits you described. In my case I wanted to cover scenarios where more fine grained customizations were necessary. For example if the smart 404 would be used on multiple sites on the same farm that have different branding. By placing the page in a code behind within the site collection the out of the box branding will be applied. Additional (and possibly just as important) the pages can not be personalized which allows webpart zones to be present. This allows different sites to have additional webparts (and content) that may be desired for the 404 page. Also its worth mentioning that as long as you don't customize the page with designer you won't have to mess with the safe mode settings to add an exclusion for the page. So in summary, its mostly for flexiblity.

2)No not at all. Once again I was covering some scenerios where the 404 would be shared so I placed the assembly in the gac for that reason. Its more important who is running on the code not that the code is running in the GAC.

3) So it really comes down to what you as a developer or admin are more proficient at. The goal for this project has been to make this a no-brainer. Install a wsp activate a feature and poof you get a nice friendly 404 (plus the extras I continue to add). Your milage and value in automation may vary but my end goal is to not have to require any manual steps.

4) Adding resource files for strings for multi-language support has been on my todo list. As for the parameters I am not quite following your goal with that.

Once again  I apologize for the late response here. Hopefully its still of some use. I hope you had good luck in your implemenation.

Josh