Skip to main content
deleted 22 characters in body
Source Link
user avatar
user avatar

We have begun to take an alternate approach to site templating (and SharePoint development in general)solution packaging and deployment, and I wanted to get the community's perspective on it.

We deploy all of our master pages, css, js, and other custom code directly to the file system. We then use an httphandler to re-assign the masterpages on the fly (based on a configuration file).

From our perspective, this gives us several advantages over the native SharePoint deployment model including:

  • simplicity. All deployments are xcopy. No features, solutions, or MSIs necessary

  • isolation from an overly complex packaging & deployment infrastructure that is always radically changed (and therefore broken) across SharePoint upgrades

  • the ability to version our masterpages, css, js, etc. with our other code (and thus revert to any revision at will via automated scripts)

  • the ability to use code-behind with our SharePoint aspx pages

The productivity boosts we've gained by switching to this approach are enormous and we have yet to encounter any issues with it.

So those are the "pros". I'd like to hear about any potential pitfalls there might be to this method. All input appreciated. Thanks!

We have begun to take an alternate approach to site templating (and SharePoint development in general), and I wanted to get the community's perspective on it.

We deploy all of our master pages, css, js, and other custom code directly to the file system. We then use an httphandler to re-assign the masterpages on the fly (based on a configuration file).

From our perspective, this gives us several advantages over the native SharePoint deployment model including:

  • simplicity. All deployments are xcopy. No features, solutions, or MSIs necessary

  • isolation from an overly complex packaging & deployment infrastructure that is always radically changed (and therefore broken) across SharePoint upgrades

  • the ability to version our masterpages, css, js, etc. with our other code (and thus revert to any revision at will via automated scripts)

  • the ability to use code-behind with our SharePoint aspx pages

The productivity boosts we've gained by switching to this approach are enormous and we have yet to encounter any issues with it.

So those are the "pros". I'd like to hear about any potential pitfalls there might be to this method. All input appreciated. Thanks!

We have begun to take an alternate approach to solution packaging and deployment, and I wanted to get the community's perspective on it.

We deploy all of our master pages, css, js, and other custom code directly to the file system. We then use an httphandler to re-assign the masterpages on the fly (based on a configuration file).

From our perspective, this gives us several advantages over the native SharePoint deployment model including:

  • simplicity. All deployments are xcopy. No features, solutions, or MSIs necessary

  • isolation from an overly complex packaging & deployment infrastructure that is always radically changed (and therefore broken) across SharePoint upgrades

  • the ability to version our masterpages, css, js, etc. with our other code (and thus revert to any revision at will via automated scripts)

  • the ability to use code-behind with our SharePoint aspx pages

The productivity boosts we've gained by switching to this approach are enormous and we have yet to encounter any issues with it.

So those are the "pros". I'd like to hear about any potential pitfalls there might be to this method. All input appreciated. Thanks!

Source Link
user avatar
user avatar

Alternate SharePoint Code Deployment Approach

We have begun to take an alternate approach to site templating (and SharePoint development in general), and I wanted to get the community's perspective on it.

We deploy all of our master pages, css, js, and other custom code directly to the file system. We then use an httphandler to re-assign the masterpages on the fly (based on a configuration file).

From our perspective, this gives us several advantages over the native SharePoint deployment model including:

  • simplicity. All deployments are xcopy. No features, solutions, or MSIs necessary

  • isolation from an overly complex packaging & deployment infrastructure that is always radically changed (and therefore broken) across SharePoint upgrades

  • the ability to version our masterpages, css, js, etc. with our other code (and thus revert to any revision at will via automated scripts)

  • the ability to use code-behind with our SharePoint aspx pages

The productivity boosts we've gained by switching to this approach are enormous and we have yet to encounter any issues with it.

So those are the "pros". I'd like to hear about any potential pitfalls there might be to this method. All input appreciated. Thanks!