Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments

I get this question all the time so I finally am taking the time to document the answer I repeat over and over. First the question, then my answer:

Question: How do I move the content I've created in my development environment, such as master pages, page layouts, cascading style sheets, JavaScript, etc. using Office SharePoint Designer 2007 to another environment, such as QA, staging, and ultimately production?
Answer: Use SharePoint Features & Solutions!

Now to explain, let's first take a look at the challenge (note: I'm not calling it a problem, it is a challenge).

When you create files in your Publishing site (aka: WCM site) in a development environment, the files are stored within the site's content database, not on the file system. We call these types of pages "customized" (WSS v2 folk know this as "unghosted"). While this is fine and good for development, you're going to have some challenges in a real MOSS environment where you'll have developers working on developer machines, a shared development environment (aka: build server), a test environment and a production environment. Why? Because you will only get those files in the content database into the different environments in one of two ways:

Open each file in your development environment in SharePoint Designer, copy the contents, create a new file in your target environment (such as production), paste the contents on the clipboard, save, check-in, publish, and approve. Ah... very tedious if you have more than... oh... two files. Yes, I know you can save the file from development locally and upload it into the target environment, but I consider that just a slight variation on the copy-paste technique.
Use MOSS' Content Deployment capabilities to package the files up and deploy them to the new environment. No, I'm not going to turn this post, or the comments, into a discussion on Content Deployment... for more info on this, check Tyler Butler's (PM on the SharePoint WCM Team) excellent post on the SharePoint Team Blog earlier this year.

Either way you go, the files still live in the database, not in the file system. I'd argue this is sub-optimal (not bad, not good, just not ideal). Why? Consider the following reasons:

No true source control: No, I don't mean version control or audit tracking which SharePoint lists give you OOTB, I'm talking real source control... things like branching, tagging, atomic check-ins, etc. Things like VSS (yuck), Team Foundation Server, or my favorite, Subversion give you.
No easy way to change one file used across MANY sites: Nope... only way to do this is to do a variation of #1 above.
No easy way to package up many changes and deploy them at once: Nope... see #1 above again... its a one-by-one operation.
Making changes to many files already deployed to production is manual, thus tedious: It's a one-by-one operation (again, mass uploads is a variation of this).

So, how do SharePoint solutions & features fix this?
You can create a feature that provisions files into the lists & libraries upon activation. Not only will it provision one file, but it can provision many files at once and even supply additional properties for each file such as those preview images you see when you pick a new master page or page layout in a Publishing site.

I demonstrated how to do this in part 2 of my Building an Internet Site with Web Content Management in MOSS 2007 session at SharePoint Connections in November 2006... you can also get the sample code from that session that includes a sample feature that once installed & activated in a Publishing site, you'll find a new master page & page layout in the Master Page Gallery. The concept is simple: create your master pages, page layouts, CSS files, JavaScript, etc... create it all in your development environment using SharePoint Designer where you have a rich development experience. Once you have a working site and you're ready to move stuff, save all these changes to the local file system. You will then take these files, include them in a SharePoint feature, and once the feature is installed, when activated on a Publishing site, it will add these files to your desired libraries (such as the Master Page Gallery).

The magic behind the feature is in the element manifest file. Take a look at this sample elements manifest file:

Sample elements manifest file from a SharePoint feature that provisions files into a Publishing site's Master Page Gallery.

This file is broken into two parts: two <module> nodes. Each one is responsible for adding a file to the Master Page Gallery. In the first <module> node (lines 3-16), you'll see that it specifies the location to upload the master page to in the Url attribute and where the file is within the feature in the Path attribute. The inner <file> node (line 7) tells SharePoint what the name of the file is in the Url attribute, that it's Type is GhostableInLibrary (more on this in a moment), and then proceeds to set a few properties like the content type, URL where it will find the preview image, and the title of the master page. The type GhostableInLibrary tells SharePoint to put an entry in the Master Page Library for this file, but that the file's contents will not be stored in the database... they'll stay on the file system. The second <module> node (lines 18-25) follow the syntax to add the preview image to the Preview Images folder in the Master Page Gallery.

Once you have a feature built that provisions files into your Publishing sites, you're left with quite a few advantages over the two methods described above (in no particular order):

Ability to leverage a rich source control management solution: Because everything is now on the file system, this is no different than your non-SharePoint ASP.NET 2.0 Web projects, or class libraries, etc... they are just files on the file system so you can easily add them to your source control management system of choice! This is HUGE!
Ability to package up the feature (and all it's files) in a SharePoint solution: See where I'm going? If you package up your feature and it's files into a SharePoint solution file (*.WSP) which you can then use to...
Deploy to all SharePoint web front end (WFE) servers in your farm at one time: Solution deployment can be scheduled to run at a future time... and the best part: SharePoint's solution framework will automatically deploy the feature to ~all~ your WFE's in the farm at that time. But that's not the only advantage of solutions...
Ability to retract deployed solutions: Ever had that "oh crap, we gotta get that off the servers NOW!" moment? The solution framework has the ability to yank a deployed solution back at a scheduled time as well (or immediately if you have the "oh crap" moment).
No need for developers to have access to your production environment: Since the files are in a feature that's packaged in a single solution (*.WSP) file, your production administrators can easily add the files to your production environment without developers having to open SharePoint Designer to make changes!
All files remain ghosted (uncustomized) on the file system: Remember, they are provisioned as Type=GhostableInLibrary which means the content doesn't really reside within the content database, they are on the file system. This is HUGE! This way...
Easier to make changes to existing files going forward: Everyone has changes to files once deployed into production. Using this mechanism, you can just upgrade the solution with an updated feature (don't change the solution or feature ID's) and every site that's activated the feature will automatically get the changes applied to their site! This is HUGE!

I could go on, but you get the picture (I hope). I highly advise you at the very least consider this approach over the two others mentioned previously in this post. The subject of uncustomized/customized (or ghosted/unghosted in WSS v2 parlance) and how significant it can be in your environment is one of a very controversial nature, so I don't want to take this post (or the comments) in that direction... I just wanted to share a technique for moving your site's files from one environment to another.

One last thing... before you ask "uh, is this supported by Microsoft?" because 90% of the people that I explain this to who hear it for the first time always ask, I want to point out one thing. How do you think Microsoft got all those default master pages (BlueBand.master, BlackBand.master, etc) and page layouts (ArticleLeft.aspx, ArticleRight.aspx, etc), images, and style sheets into the Master Page Gallery in the first place? Check out the feature PublishingLayouts ([..]\12\TEMPLATES\FEATURES\PublishingLayouts)... specifically the ProvisionedFiles.xml file which does all the provisioning. So, this is how Microsoft actually got all the content into these sites you're already using!

Enough hand waiving! Don't you just hate the posts that talk at this high level, but never really show implementation? Me too! In my next post, I'll show you how I use a single Visual Studio 2005 project to create my feature and package it up in a solution... all the while staying in-the-box with respect to Visual Studio with only a few, yet very easy, steps.

Technorati: sharepoint, moss, wcm, publishing, feature, solution, wsp

posted on Wednesday, December 20, 2006 12:06 AM

Feedback

Provision a _layout file to the LAYOUTS directory via the .wsp file 1/29/2007 5:10 AM Gary

Can anybody here figure me out how to deploy an aspx page to the the TEMPLATE\LAYOUTS directory via the solution package? Thanks.

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 1/29/2007 9:37 AM AC [MVP MCMS]

Gary... no sweat. Look at the <TemplateFiles> node in the solution schema WSS v3 documentation. The Location attribute is relative to the /Templates folder. So, if you wanted to deploy something to Layouts, you'd use Location\File.aspx. You should have the same directory structure within your solution file as well.

re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 1/30/2007 1:11 AM Gary

Great! the <TemplateFiles> element resolved my issue. appreciate it!

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 12/21/2006 9:56 AM Kanwal

Awesome post Andrew

Hope you dont mind but I have included it on our site Sharepoint BUZZ

Visit http://www.sharepointbuzz.com

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 12/21/2006 4:20 PM Meron Fridman

Hi
You mention in your excellent article that "All files remain ghosted". But how do you continue development using the SPD after you deploy the solution? How do you make changes in the masterpages \ page layouts using SPD if your templates stored in the FileSystem what about version control?

Best Regards,
Meron Fridman

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 12/22/2006 9:05 AM AC [MVP MCMS]

Meron - Just update the feature & solution, and redeploy it using the UPGRADESOLUTION option in STSADM. It will re-lay the feature & it's containing files. You can also use SPD if you like to continue updating the site, but once you do that, your files will become customized (unghosted).

re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 1/2/2007 9:36 AM Angel del Olmo

Hi,

When I modify a .master page in SPD I can reset it to site definition.
But if I modify a .aspx page not. Is that correct? Why?

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 1/2/2007 2:55 PM AC [MVP MCMS]

Angel - How were the page layouts (ASPX) created? Did you create them in SPD? If so, there is no underlying site definition file that you can revert to.

re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 1/3/2007 9:22 AM Angel del Olmo

Both, layouts and masters, are deployed in a feature, like you explain in this post. Test it.

Angel

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 1/3/2007 11:10 PM AC [MVP MCMS]

Angel - Did you try it with the sample on the article that referred to this post? The article URL is here: http://www.andrewconnell.com/blog/articles/UsingVisualStudioAndMsBuildToCreateWssSolutions.aspx. I've confirmed that one works.

re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 2/8/2007 11:58 AM Usmani

Hi Andrew,
Thanks for the great post! I have slightly unrelated question. I understand that master pages and page layouts and web part pages can all be ghosted ( uncustomized) but my understanding is that "publishing pages" cannot be part of site definition ( or sit on a file server) rather they have to be created in UI or programmatically to get stored in pages document library to support all desired features of versioning, workflow etc. So even if you migrated these pages from staging to production via solutions/features you will end up copying them to corresponding document libraries not to the file server.

Having said that I think you will still get better performance knowing your master page and page layouts behind these pages are ghosted (and cached) but we should consider that actual pages ( content type values , list items ) will still be stored in database.

In summary would you agree that ghosting is not really applicable to "publishing pages" and even if there is a way to add them in site definition or file server, the moment you mark them for publishing ( approved) , they will become unghosted ( customized). For this reason, we have WCM caching capabilities (asp.net output cache) to improve performance for published pages.

Thanks
Usmani

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 2/8/2007 10:17 PM AC [MVP MOSS]

Usmani-
Darn good write up! Everything you say is correct... masters & page layouts can be kept as ghosted. I believe you can do the same thing with content pages too though... provisioning them into a library the same way you do it with masters & page layouts. While there will be a minor performance benefit to having your layout files (masters & page layouts) ghosted, it's nothing that would be noticed on sites except for the top 20 most visited sites on the internet. Even though you can possibly create content pages via provisioning, I wouldn't suggest going that route because the'd you loose the ease of page creation granted by the UI... a huge beni.

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 2/25/2007 6:06 PM Cornelius J. van Dyk

Awesome post Andrew! I get the same question all the time as well and am glad you took the time to document it here, even though it took me this long to discover it! :)

Later
C

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 2/25/2007 9:19 PM AC [MVP MCMS]

Cornelius-
Thanks!

re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 3/6/2007 10:58 AM Shashank

Hi I want to upload master page into gallery programmatically ..using C# in Visual Studio 2005..

Kindly help me with that .

re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 3/8/2007 4:39 PM Steve

Sorry for the ignorance, but how do you save all files to the file system from SP Designer?

re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 3/9/2007 3:10 AM Anders Rask

Hi Andrew,

i like your approach -i was wondering if this was an ok way of doing things. :-)

Two questions though:
In a simple development -> production environment how would you go about doing your very first deployment from development to production? Sometimes the content structure itself is a part of the development eg. creating a hierarchy of sites/lists and so using solutions to add features to the site would add functionality and site definitions, but not the content itself.

This ofcourse could be solved by either content deployment or a one-time stsadm restore to the production environment, but wouldnt that result in unghosted master pages etc. in production envirionment, or will those pages become ghosted again when i deploy my master as a feature?

Another thing: on a more complex environment containing both test server, build server, staging server and production server, wouldnt it make sense to combine the solutions approach with Content Deployment?

As i see it CD has some advantages over your approach (just like the other way around), one being automated publishing.

With solution files in such an envirionment you would as a minimum need to run a batch file on each server (true -this could be automated too). However if you used solution files for example when moving new functionality to the build server, or staging server, couldnt you then automate the deployment process from there using CD? -sort of a "best of both worlds" approach.

tell me your opinion

regards
Anders

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 3/9/2007 7:50 AM AC [MVP MOSS]

Steve-
Open each file, FILE->SAVE AS (yes, a PITA).

Anders-
Content deployment was more meant for content, not for layout files. So I'd still suggest using this technique for moving layout files (masters, page layouts, images, etc), and use content deployment to move pages and site topology things into production.

re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 3/16/2007 8:11 AM Frank Jusnes

Hi Andrew!

Another great post from you! I have one problem that I am struggling with. That is upgrading page layouts. It seems to me that page layouts are being unghosted when I create a page based on it. So even though I'm able to upgrade (deactivate-uninstall-retract-delete-add-deploy-install-activate) the feature, only page layouts that are not yet in use are upgraded in the site collection. On the file system all files are updated.

Thank you for any input!

Frank

re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 3/21/2007 4:22 AM Magnus Karlsson

Hi Frank!

We were struggling with the exact same problem, the page layouts seemed to be unghosted when creating a page from one of the page layouts.

The problem seems to be that if the page layout contains HTML errors (in our case: div class=the-class" instead of div class="the-class" ) SharePoint seems to detect that error and unghosts the page layout for some reason...

So check that all HTML tags are 100% valid first, that could help? Also, web part zones seems to be another cause to this problem.

Cheers,
Magnus

re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 3/21/2007 4:31 AM Magnus Karlsson

Regarding my comment that web part zones could cause unghosting of page layouts... It seems to be this property in the @ Page declaration that is the source of currrent evil:
meta:webpartpageexpansion="full"

When we deleted that part of the declaration, the page layouts with web part zones started to work again.

Oh, and the really sad part is: I don't know of a good way to re-ghost a page layout when the problem is solved. =(

Cheers,
Magnus

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 3/21/2007 8:22 AM AC [MVP MOSS]

Magnus-
Why couldn't you just use the same Reset Page to Site Definition option in Site Settings to reghost it?

re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 3/26/2007 5:22 AM Magnus Karlsson

Andrew:
I didn't think of that option then, I'll try it next time, though. Thank you.

Cheers,
Magnus

re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 5/2/2007 5:56 AM Muhammad Masood

Hi Andrew,
This is very beutiful post and helpful.

My question is that can I create instaces like Events, announcement instance via feature. Just give some hints.

Thanks.

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 5/2/2007 5:57 PM AC [MVP MOSS]

Muhammad-
Yup... look at the Receivers node within a Feature's elements file for events, and ListTemplate and ListInstance within events for lists.

re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 5/29/2007 9:28 PM Adam

Hi Andrew,

Thanks for this - I love the concepts here but I'm having a problem removing the file again on solution retraction.

I added ACminimal.master through the feature/solution as per your example (in your followup blog).

When I deactivate the feature and retract the solution the ACsFileProvisioningFolder correctly deletes the folder from the Features library...but the ACminimal.master is not removed from the masterpages library! If the file is GhostableInLibrary shouldn't it be deleted when the underlying feature folder is deleted?

The masterpage is not in use, this is straight after deployment. What am I doing wrong? This is so close to being a great solution but at present it is one-way deployement without removal (i.e. the "get this off the servers now" scenario)

Thank you!
Adam

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 5/29/2007 10:05 PM AC [MVP MOSS]

Adam-
That is by design. Deactivation of features does not remove data that was created when the feature was activated. if you want to "clean up" the data that was created, you need to create a Feature receiver handler and have the FeatureDeactivating() event handler manually remove the file.

re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 5/29/2007 10:08 PM Adam

Hi Andrew, A slightly more accurate follow up to my previous comment....the masterpage still APPEARS to stay in the masterpages library after feature deactivation....but it is actually only the list entry that is there because the underlying file is gone. Clicking on the list entry gives an error, either through browser or SPD.

So my question becomes: is there some way to automatically remove the associated library/list entry when deactivating the feature?

Thank you! Adam

re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 5/29/2007 10:13 PM Adam

Thanks Andrew - I see you responded while I was posting my followup.

Thanks for your suggestion. I guess an alternate approach to the eventhandler would be to iterate through looking for "broken" entries in libraries where the underlying file has been removed.

Thanks again, Adam

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 5/29/2007 11:37 PM AC [MVP MOSS]

Adam-
I prefer the more efficient approach of having the receiver get a reference to the XML file in the Feature that actually created the data, parsing it, and removing anything that is left behind.

Keep in mind though, data is left in SharePoint BY DESIGN. What would happen if you had deployed a page layout with a Feature and someone removed it while it was in use by thousands of pages? Oops... blamo!

re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 6/5/2007 9:46 PM Adam

Hi Andrew - Can solution packages be used to deploy themes or other server files that live on the server but not within Sharepoint? Or would I need to create a separate installer for themes? Thanks again, Adam

re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 6/6/2007 12:50 AM Adam

Hi Andrew - once layout files are deployed by this approach, what is the best way of deploying new versions? So far the cleanest method I have found is to - deactivate the feature
- retract the solution (deletes feature folder/files)
- remove the solution
- add new version via stsadm of solution and redeploy (with same ids).
This approach involves "downtime" of the files as they are removed (eg masterpages etc) Is there a way of simply forcing an in-place overwrite of the files with the solution please? Thank you again, Adam

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 6/9/2007 9:14 PM AC [MVP MOSS]

Adam-
WSS solution packages can deploy anything to the /12/ directory. As to your other question... retraction of the solution does not delete folders/files from SharePoint. If activation of a Feature creates data (like provisioning files), it will not remove that data when the Feature is deactivated. What you want to do is upgrade the solution... an option with STSADM which will upload a new WSP file and redeploy the solution.

re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 6/13/2007 4:01 PM Eric

Excellent post....have a question for you andrew. I created a webpart page under a document library through the sharepoint gui (didn't add any webparts). I then went to sharepoint designer and exported this file to a local directory, copied to _layouts folder in the 12 hive and modified the masterpage reference in the .aspx file (MasterPageFile="~/_catalogs/masterpage/default.master" ). I then navigated to this page (site/_layouts/test.aspx). Errored out, check logs and got this...

Exception Type: System.Web.HttpException Exception Message: The referenced file '/_catalogs/masterpage/default.master' is not allowed on this page.

I don't think creating a feature for a custom masterpage will work seeing as the default.master won't cooperate.....any insight would be helpful

Eric

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 6/15/2007 9:49 AM AC [MVP MOSS]

Eric-
You should never specify the master page within the WPP or any content page for that matter. That's something SharePoint does for you. Therefore, the error was expected.

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 6/15/2007 9:50 AM AC [MVP MOSS]

Eric-
To build off my comment, using a Feature to deploy master pages definately works. That's how master pages get into the master page gallery when sites are first created... IOW, this is how MSFT does it.

Problem with page layouts... 6/15/2007 10:21 AM Collin

I created a page layout for our SharePoint site and deployed it with a feature. When I try to create a page with it, I receive the following error:

An error occurred during the compilation of the requested file, or one of its dependencies. Cannot convert type 'Microsoft.SharePoint.WebControls.FieldValue' to 'System.Web.UI.IAttributeAccessor'

Any ideas what I should be checking?

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 6/15/2007 3:37 PM AC [MVP MOSS]

Collin-
Off the top of my head, no. I'd suggest building the page layout in SharePoint Designer, then saving it locally into a Feature.

re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 6/15/2007 4:58 PM Collin

Hmm...would you believe this might have been a result of "exporting" the page layout rather than saving as? I think when I first went in to the site our designer was creating things on, the Save As was greyed out, so I did an export. The exported files contained additional elements like "_designer", which I'm guessing just threw a wrench into the works when activated.

Now I just have to figure out why the designer's page content areas aren't appearing.

re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 6/18/2007 11:26 PM Jeff

I deployed a new master page and a few page layout files with type "GhostableinLibrary" via features in WSP. If I modified the page layout file, what I need to do is overwrite the master file or aspx files or upgrade the wsp solution. It is realy easy to deploy changed code.
But after I checked out, modified and checked in/approved in sharepoint designer, they became customized and be stored in database, is there a way to undo this action or not allow sharepoint designer to customize these Ghostableinlibrary type of files? Thanks.

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 6/20/2007 12:10 AM AC [MVP MOSS]

Jeff-
Yes... right-click the file n SharePoint Designer and select revert to site definition.

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 7/5/2007 6:42 PM Raghu Iyer

I was getting the same error "An error occurred during the compilation of the requested file, or one of its dependencies. Cannot convert type 'Microsoft.SharePoint.WebControls.FieldValue' to 'System.Web.UI.IAttributeAccessor'
" while creating master pages and the problem seems to be crop up when teh changes is done using Sharepoint Designer,I made changes using visual studio and the things work fine now

re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 7/12/2007 3:40 AM krystian

I get an error when activating the feature. The path to my page layout is no found. I get the same error when I try to activate the SPConnectionsPart1 example. Any ideas?

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 7/12/2007 11:58 AM AC [MVP MOSS]

Krystian-
Hard to troubleshoot without seeing the error.

re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 7/13/2007 11:22 AM Umbrae

Raghu Iyer,

The "Cannot convert" error can be resolved by checking in/out/approving the file through the Master Page Gallery.

I got this error no matter what tool I used or what method of getting the files into the VS project. By approving another major version and approving it worked.

re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 8/8/2007 12:19 PM Mark van Dijk

Hi Andrew,

Thanks for this useful post.

Even after reading thoroughly through the comments, I still can't find the answer to a question I'm struggling with.

I've created a small feature, scoped on "Site", that provisions a .css file to the Style Library of a Site Collection.
I wrapped the feature in a Solution file and added+deployed this solution in my sharepoint environment (default Litware installation).
As soon as I create a new sitecollection, based on the default "Collaboration Portal" template, I can activate this feature from the "site collection features" gallery. I now see my .css file in the Style Library folder of my Site Content and Structure.

After this, I decided to modify the css file (blue has to be red after all), updated the feature accordingly and put this in a new solution file. I used stsadm -o upgradesolution to upgrade the solution.

Why is it that only NEW sitecollections get the new css file when the feature is activated, while my old sitecollections with the already activated feature still have the old css file?

And... What needs to be done to update these files as well?

I really hope you can help.

Kind regards,

Mark van Dijk

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 8/9/2007 12:02 AM AC [MVP MOSS]

Mark-
When looking at the file in SPD, does it show it as customized? Was the file editted in SPD to make it customized? Have you tried reverting the file back to it's site definition? Also check the SPFile.CustomizedStatus property to see if the file was customized. I've seen many cases where SharePoint has sucked up a file even if it wasn't customized and have yet to get an answer if this is "by design" or a bug.

re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 8/15/2007 3:24 PM John Way

Hey Andrew,

This may be slightly off-topic, but if you modify a customized file (default.master) via SPD, where does the uncustomized file get saved to on the file system?

Thanks,
John W.

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 8/15/2007 10:12 PM AC [MVP MOSS]

John-
Never saved on the file system... the source of the page is saved in the content database.

re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 8/24/2007 2:37 PM Song

Hi Andrew,

I got the same problem as Mark have. The css file have been changed in file system after upgrading solution, but it still uses old one even I have cleaned client and server cache. I wrote a program confirmed that the customizedstatus is uncustomized.

Any idea about this?

Thanks,

Song Yuan

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 9/26/2007 1:18 PM William Rust

Andrew, I am using this method to push out new master pages and page layouts. I am having some problems with the version of the file in SharePoint Designer being correct, but the version listed in the _catalogs/masterpage/Forms/AllItems.aspx list. The version history in SPD is correct but that is not being reflected in the actial site. Have you ever run into this problem? It is almost like SPD and the site are not looking at the same files or different databases? Very strange.

Thanks in advance.

William Rust

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 9/26/2007 2:59 PM AC [MVP MOSS]

Willie-
Long time no see! First, I've seen many issues with SPD... so I wouldn't be surprised if it was a bug. I'd revert to the browser UI for the "REAL" info and chalk it up to SPD being flaky.

re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 10/9/2007 1:22 PM Hardik

hi Andrew,

Very Nice article, but I would like to point out one thing

- You are saying that, in Dev. user SD and then save these all changes to local file system. - I belive it is true in case of if we have new master page or css flie but what if we have modified existing one or lets say we modified AllItems.aspx, or EditForm.aspx of some lists in SharePoint site? Or lets say you did conditional formating with SD for your AllItems.aspx page.

Means, how we are going to do same (Save in local file system) with pages belongs to _layout folder and include them in solution?

Thanks

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 10/9/2007 1:32 PM AC [MVP MOSS]

Hardik-
You bring up a good case. First, if you customize an existing file, then to do this the way I present here, you'd save that local file over the one that it was based off... like the list form pages you mention. Challenge is that just about every list is based off those pages so you can't really do this without affecting all lists. Just how it works.

So what if you want to use this page as an uncustomized instance? Well you'd have to build a whole new list template that uses your file and not the one you customzied as the template. Yes, that's a lot more work.

The point of the post was to provide more guidance in Publishing sites where the form pages are not typically seen by the end users. However the concepts are pervasive across the entire product.

As for stuff in the _layouts directory, those are application pages that don't support customization so they really don't apply here as they are always pulled from the file system.

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 10/26/2007 1:39 PM Paul

Hi the problem than Mark van Dijk and Song Yuan have is distirbingly similar to a issue I had updating a masterpage via the <module> directive in features. If the file to be updated by the feature has been updated on the site via "publish as a major version", then the feature will not update the file.

Please feel free to repro.. you can find my notes on my experience here.

http://www.cleverworkarounds.com/2007/10/27/sharepoint-branding-part-5-%e2%80%93-feature-improvements-and-bugs/

p.s solutionising it all actually fixes the issue, but not the feature on its own..

re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 11/2/2007 10:12 AM puri

Hi Andrew,

It was great article.

We have a site created under site collection. For migrating it to the pre-prod box, I wrote a feature and feature receiver. And feature receiver had the following lines of code in Activated method

this.currentWeb = properties.Feature.Parent as SPWeb;
currentWeb.MasterUrl = "/_catalogs/masterpage/appsupport.master";
currentWeb.CustomMasterUrl = "/_catalogs/masterpage/appsupport.master";

We are activate the feature in site (under site collection). After activation when we open any page of the site, we are getting following error.

'File not found"

I know for sure that this is because of the setting wrong path for master page.

Any idea for solving this would be of great help.

Thanks,
Puri

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 11/2/2007 1:56 PM AC [MVP MOSS]

Puri-
Did you provision the file as GhostableInLibrary? Don't have access to a SP install right now, but I'm also sure that you would need to enter the full path to the file, not a relative/absolute one (including the http://).

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 12/7/2007 3:35 AM Simanta Parida(MCAD)

Hi Andrew,

It was great article.

re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 3/7/2008 4:25 AM Craig

Nice article. My question is about web parts. It seems to me that it is not possible to really use webparts in WCM and product valid HTML markup at the end of it? I don't know about everyone else but we cannot give a client a site that does not produce valid html! How do you get around this?? MOSS is very poor for this compared to MCMS :(

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 3/7/2008 9:31 AM AC [MVP MOSS]

Craig-
The OOTB RTE field control in Publishing sites does not produce valid XHTML markup... neither does the Content Editor Web Part. But if you have a MOSS license, you can use the Telerik RadEditor Lite for MOSS (http://www.telerik.com/sharepoint) which does include a RTE that generates valid XHTML as well as a special Web Part that does the same.

re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 4/21/2008 10:53 AM Dwight

Hi Andrew,
I have a question. I am using Disigner to create an aspx page in which a sharepoint list is a datasource. I am then deploying the page using solutions and features but when I deploy to prod, it says it cannot find the list. This is because the GUID of the list is different in Prod. What do you suggest in such a scenario. How can I create pages in designer in dev environment when Specific values of Guid are required.

Thanks for not only this article but many from which I have benefited.

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 4/22/2008 9:08 AM AC [MVP MOSS]

Dwight-
I think there's a way to reference a list in the datasource by name... but I'm not sure. Generally speaking SPD is used for live editing... not for building stuff like this you then deploy as it wasn't built for a redeployment experience such as this.

re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 4/22/2008 10:26 AM Dwight

Hi AC,
Yes I did use the list Name and it worked fine. I agree that SPD is not the best for building stuff that can be then later deployed to production. But my client is very adamant about not using Visual Studio. I have no idea why??? In any case I am creating the code behind in Visual Studio. Can you point me in the right direction to an article or a blog that says that SPD is for live editing and not for deployment?? Thanks again for all the good articles.