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.

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

Dwight-
I can't point to anything like that because it doesn't exist. It's pretty much implied since you have to connect to a site and your changes are applied at design time, not at some point in the future.

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 5/1/2008 7:13 AM Kieran

Hi Andrew
Could you use this to handle content types or would they be classed as content deployment?
All the best

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

Kieran-
You can use this to move content types, but the challenge is that content type updates are just "broken" in the platform. They aren't updated when the Feature is updated... just no way around this unfortunately.

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 5/1/2008 10:16 AM Kieran

Andrew
That's no surprise but I guess in time these issues will be resolved.

I just tried your above example and deployed a masterpage as a feature - a couple of strange things I noticed:

1. When I try to edit the masterpage in designer from the Manage Content and Structure screen it says it has no associated application.
2. I set my site to use the new masterpage(a copy of default.master), then uninstalled the feature. The site continued to use the masterpage and it remained in the 12 hive?

I'm going to look at setting up subversion (which I love) to source code the files, do you just use subversion in the regular what through the windows gui?

Appreciate your comments

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 5/1/2008 10:24 AM AC [MVP MOSS]

Kieren-
Try opening the master page from SPD instead of via the browser UI. When Features are deactivated, they don't remove the files they provisioned.

I do use Subversion for my source control... including SharePoint stuff. I use the TortoiseSVN shell integration client to work with it and the VisualSVN tool which adds Visual Studio integration. I love this solution!

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 5/1/2008 10:41 AM Kieran

Thanks Andrew

I tried opening it from SPD and yet many of the controls on the page show errors in design view. If I then hit save it seems to break the masterpage - would I need to open the whole sharepoint website rather than just the masterpage itself? Do you use SPD for all masterpage work?

On the subject of uninstalling the feature - how do you deal with the 'oh crap' moment then when you need to get rid of a feature/solutions? I guess what I'm saying is what is the point of uninstalling if it doesn't actually do anything?

Kieran

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

Kieran-
Not sure what's up with your master page... sounds like there's some stuff wrong in the actual file. I wouldn't fret too much over controls not rendering (unless they are controls also used in some of the OOTB masters). That doesn't necessarily mean things are breaking... just means stuff doesn't have a design-time preview. I use SPD to create and edit my masters, then I "Feature-ize" them by pulling them down to the filesystem and deploy with a Feature.

As for uninstalling a Feature... I have a Feature receiver that does some cleanup work when I deactivate it. Leaving the content is by design. Consider if a site was using a master page and the Feature was deactivated and removed? The site would stop working for everyone immediately. Sure you can fix it by knowing the URL to Site Settings and changing it, but it will cause headaches. I would have preferred MSFT give me the ability to shoot my foot off instead of hard coding the saftey to be on, but we can just wish :)

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 5/2/2008 4:14 AM Kieran

Andrew,
I'm working with a team of developers/designers on a MOSS development and am in the process of figuring out a better way to work in terms of source control and working collaboratively. After reading your article I'm thinking that physical files controlled with subversion might be the way to go.

Have you worked using subversion within a team on SharePoint or just individually?

Would be interested to hear your views on this.

All the best

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 5/2/2008 4:49 PM Ian

Hi Andrew,
I deployed my master page, supporting graphics, content types, layout pages via features.

My master page is there and works, I apply it to my main site and all child sites - life is good in Dev,

When I push to Stage - the staging site picks up the default master page for a publishing site - not my custom one.

What do I need to do to get changes in Master page selection to push? Do I need to create custom site definitions with my master page specified? But then if I chnage my master page in the future what would I do?

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

Kieran-
I've worked with it on a team as well as individually. I like it for both and really like the model. I haven't used it for large teams... subscribe to the "Amazon pizza" rule: no dev team should be too big that you can't feed them with two pizzas.

Ian-
That sounds like you are using content deployment to move your changes. CDS has a known bug that it doesn't move the SPWeb.CustomMasterUrl settings... this will get fixed in due time though. You didn't do anything wrong... just a bug.

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 5/3/2008 5:04 AM Kieran

Andrew

I found an interesting issue - if you deploy a masterpage using features and then delete it from manage content and structure screen - then deactivate/activate your feature it doesn't add the masterpage back to the site. I had to rename my masterpage to get it to add it back in to the site masterpages.

Have you experienced this?

As an aside, how would you handle users creating content types through the SP interface and developers using features to deploy content types. If they create them using the interface I guess they are customized and therefore in the database, not the file system?

Best Regards

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

Kieran-
My, this thread has had quite the resurgance in recent days :).

That's odd that deactivation/acitvation didn't reprovision the master page. Any chance you try an activation with the "-force" attribute? That usualy does it for me.

Content types and site columns (as well as list templates & instances) don't fall into the same customization / uncustomized debate IMHO. The Features that deploy these things only define the DEFINITIONS... not templats. Once they are in the site column/content type galleries, the are not linked to the underlying Features. This is always tricky because even trying to update content types via Features is not reliable, unfortunately.

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 5/3/2008 10:54 AM Kieran

Andrew
It certainly seems to have from me anyway :) I've been reading your chapter in 'Real World SharePoint' also.

My interest in your post is primarily because I got so fed up of not having granular control over MOSS. I'm leading our moss project, 2 developers/1 dba/1 boss, I'm the lead developer, the other developer is largely creating sites/libraries/content types via the MOSS interface and I just wasn't happy with the source control and deployment methods. This has led me to investigating how I can better control the roll-out of new code.

I'm trying to figure what files should be source controlled and what shouldn't - would the whole 12 hive be subversioned?

Do any of your other posts deal with SharePoint/Subersion integration? I used your search but didn't spot any.

Best Regards

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

Kieran-
No, I don't have any other posts that talk directly about Subversion & SharePoint. The reason being is that once you work with stuff at the file system level, ~any~ SCM solution will work because none of them care what you're building... they only care that there are files to be versioned.

I applaud your interest in trying to get more granular control over your environment! You're going about it the right way. You might get value out of a paper I did recently on MSDN: http://msdn.microsoft.com/en-us/library/cc406685.aspx

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 5/4/2008 5:39 AM Kieran

Andrew
Yes, I had already read your msdn article, I was also taking a look at this one regarding team development in SharePoint http://msdn.microsoft.com/en-us/library/bb428899.aspx

They seem to promote using source control for Assembly development ONLY and just the inbuilt SharePoint check in/out source control for Artifact development - I think I prefer your approach.

In the past, if you had users creating masterpages/css/content types in SharePoint itself, how would you mix this with developers working with VS and Subversion - are they out of your control?

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 5/4/2008 6:29 AM Kieran

Andrew
On my last point about users creating content types and how would you then source control them - would the answer maybe be your stsadm custom commands? Exporting the content types after they have been created/source controlling them and then deploying them via features?

I'm guessing that is why you have those custom stsadm commands on your other post :)

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

Kieran-
I disagree with that article only encouraging to put things like code into source control. If it goes on the file system, I want to do it like that. Just like my chapter 4 in the "Real World" book.

As for the others creating assets via SPD? Well you should be able to manage and restrict who can do this. On large projects,you should still be able to restrict it. We usually create everything in a disposable environment on our local environments and then "Feature-ize" them. Why? I can create & test these things faster in the browser based UI and with SPD. To your other question, yes... that's the primarly motivation behind my STSADM commands.

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 5/4/2008 4:25 PM Kieran

Andrew

>>I disagree with that article only encouraging to put things like code into source control. If it goes on the file system, I want to do it like that.

I guess though if you have users creating sites/sub-sites/libraires and content types etc.. through the SP interface, then how would you move these if you want them in source control.. Indeed how would you be able to source control sites?

I guess you can make use of the Content Deployment part of SP Admin.

How will your new book differ to the real world one? Is it focused on this topic of management/source control etc..

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

Kieran-
Once the stuff is in the site using these methods (SPD or browser). If they are in use (if a content type is being used in a list and that list contains data), then it is a challenge. This approach to SharePoint development requires a great deal of process in your organization.

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 5/9/2008 3:04 PM Sumant

Hey,
This topic has been touched before I know but I couldnt get enough information to do this on my own.
I was trying to delete a Master page and a Layout page while deactivating a feature that installs these pages. I understand that this can be done using a Feature Receiver Deactivating event. What i am looking for is the code to actually delete the files.
Could you provide the code to just delete one file?
Thank you for the excellent post.
Sumant.

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

Sumant-
Without opening Visual Studio, it would be something like:

SPWeb site = //current site;
SPFile file = site.GetFile("/_catalogs/masterpage/foo.master");
file.Delete();

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 5/22/2008 12:11 PM Kieran

Hi Andrew,

When you've created sites on your development machine what method do you then use to move them to a test/production server?

Would be interested to hear your views on this.

Regards

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

Kieran-
This post explains how I do it... I use Features & solutions.

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 5/23/2008 2:15 AM Kieran

Right, so you use features and solutions to move complete sites? For example say you have a blank site on dev, you create a document library and then want to move it to another server. You need the navigation on the target server to work the same way, would using features and solutions work for this?

All the best

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

Kieran-
Yup... your navigation stuff will be defined in the master page (or page layout if it overrides it) and if you provision with master pages & page layouts, it will be portable.

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 5/27/2008 3:34 AM Kieran

Andrew,

I guess then the site would need to exist on the target server before you could provision your master pages and layouts over?

How then would you handle users on production creating sites etc.. If sharepoint is collaborative, allowing users to create sites 'on the fly' then surely this would impact on provisioning in this way.

Would be interested to hear how you would handle this.

Best Regards

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 5/27/2008 8:30 AM AC [MVP MOSS]

Kieran-
Oh yes, obviously the site must exist before you can provision files to it. Sites are just data in the database. What you're deploying are layout assets that are used by these sites.

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 5/28/2008 5:16 AM Kieran

Andrew,

Yes, that makes sense. If users though are adding their content to production and you are working in development, then how would you for example move a newly created sub-site to the production server without overwriting their content (documents etc..)?

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 5/28/2008 6:37 AM AC [MVP MOSS]

Kieran-
So you're asking if someone creates a site in production and adds some data, then you want to creat the same site in development and move it over... well you're certainly going to have trouble doing that. If you want to follow this process (which is very uncommon), the site should be created in dev and then moved to production, or you should be creating it in production and then exporting/importing it into dev using the content migration API.

But if I may, it think you're taking this a bit too far. Recall sites are data. If someone creates a new table in a DB in production and then duplicates that in dev, you'd have the same issues.

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 5/29/2008 5:13 AM Kieran

Andrew,

Imagine you have a virtual dev environment on your pc, you build a SharePoint site, master pages, css etc...

Your team mate also has a SharePoint virtual dev machine, they are responsible for building some other sites and content types...

You then need to move these both to production. You use a backup and restore to do this, or maybe a .cmp import.

Your users then begin to use production and add various word documents, files etc even create a few team sites - It's now out of sync with development, which may not be an issue...

The developers then make some navigation changes to dev and need to move them to prod without affecting the documents, files, team sites that the users have created on production.

Would this pose a problem?

Hope that's clearer.

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

Kieran-
You can do what you describe, but you're looking at something quote complicated IMHO. Typically the creation of sites isn't a two way thing. The complication is that you can't just export/import using STSADM, you'll need to write some custom code using the content migration API doing selective migration, retaining object ID's and reparenting. Look in the WSS SDK for an article about selective content migration.

I would not try to do this if I were you. IMHO I'd try to keep your development enviornment a place where you create code and such, and deploy this code to your production enviornment. you can always backup and restore your production enviornment into development, but I would not try to keep going back and forth.

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 6/23/2008 10:36 PM Macs

i have subsites in an internet facing site. these subsites are created using a feature receiver. Upon creation of the subsites, i would like to copy images to specific subsites. Usually, when you try to provision images, all i do is use the following line of code :


<Module Name="MenuImages" Url="PublishingImages/menuimages" RootWebOnly="TRUE">
<File Url="AA.PNG" Type="GhostableInLibrary"
Path="Styles\Images\partnerprogramme\AA.PNG"/>
</Module>

Im trying to do the same in a subsite, with the ff code:


<Module Name="MenuImages" Url="Subsite1/PublishingImages/menuimages" RootWebOnly="FALSE">
<File Url="AA.PNG" Type="GhostableInLibrary"
Path="Styles\Images\partnerprogramme\AA.PNG"/>
</Module>

but i encounter an error, Server Error (null) Subsite1.

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

Could anyone give me any tips on the best method of "comparing" my development and prod environments. I would like to take a "snapshot" of both environments before we start deploying anything - in case we have issues with our features and solutions… and also to ensure we don’t miss anything… or does anyone have any better ideas on ensuring I don’t miss anything prior to deploying to staging & prod?

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 7/30/2008 1:51 PM Norman Mann

But wait ... there is more ... since the File -> Export or File -> Save As approach can be really painful and is a lot of work if you have to move several files I created a little Powershell function that will simply export items that 'live' either in the Master Page Gallery or the Style Library and have been checked out to the file system.

I chose to use the 'Checked out' status as an indicator that the file was probably modified and needs to be transfered to the solution (wsp).

This sample exports the files to 'C:\Exported SharePoint Files' if not specified. With some slight modification you might just as easy update your VS project solution directly.

Here is the Powershell function :
<snip>
function Export-CheckedOutItems {
param(
[string]$url = $(Throw "Parameter 'Url' cannot be empty."),
[string]$path = "C:\Exported SharePoint Files"
)

$listNames = "Master Page Gallery", "Style Library"

$site = new-object Microsoft.SharePoint.SPSite($url)
$web = $site.RootWeb

foreach($list in ($web.lists | where-object {$listNames -contains $_.Title})) {
foreach($listItem in $list.Items | where-object {$_.File.CheckOutStatus -ne "None"}) {
$file = $listItem.File
$file.Name
$childPath = Join-Path -path $path -childpath $file.ParentFolder.Url
if((test-path $childPath) -eq $False) {
new-item -path $childPath -type directory
}
$fileName = Join-Path -path $childPath -childpath $file.Name
$stream = new-object IO.FileStream($fileName, [IO.FileMode]::Create, [IO.FileAccess]::Write)
$bytes = $file.OpenBinary()
$stream.Write($file.OpenBinary(),0,$bytes.Length)
$stream.Close()
}
}

Write-Host "Process completed !"
}
</snip>

To use it you will have to make a Sharepoint assembly accessible in Powershell :

[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 8/11/2008 5:00 AM Anders Rask

Regarding the error:
Cannot convert type 'Microsoft.SharePoint.WebControls.FieldValue' to 'System.Web.UI.IAttributeAccessor'

I have found that this error occurs because of the pesky __designer attributes that SPD is spreading everywhere when unghosting (sorry, old habit:-) for example a Page Layout:

__designer:Preview="..."
__designer:Values="..."
__designer:Templates="..."

If these tags are not removed when re-ghosting (see? uncustomizing sounds really weird :-) the page you get the above error.

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 10/30/2008 10:54 AM Brian Bilbro

Thanks Andrew,
My team is about a month into learning SharePoint and we've been discussing/discovering how best to create our SharePoint projects.

This method you described here appears to be similar (if not the same) as the Contoso project on codeplex.

http://www.codeplex.com/spg

We are looking into the Contoso project and trying to following that as best practice. Any thoughts with regards to the Contoso project?

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

Brian-
The process in the P&P guidance is just about the same as what I outline here as I was involved in advising and reviewing what the P&P guys have been doing over the last few months WRT SharePoint.

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 6/13/2009 6:25 PM Fred

Andrew, when deploying CSS and image files, you can provision them to the style library or you can put them directly under the layouts folder. What would you recommend?

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 6/16/2009 3:59 PM AC [MVP MOSS}

Fred-
I'd read this: http://msdn.microsoft.com/en-us/library/dd221375.aspx. Personally I stick them in the Style Library.

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 7/7/2009 5:46 PM MOSSBuddy

Hello Andrew,
I had a quick question on your wonderful article on deploying the MP and PLs. BAsically my quesiton is around GhostableInLibrary, my assumption is if we use this attribute for deploying PL and MP thru feature package they will be deployed on the file system as well as in content db, but the file system based PL/MP will be used and performance would be better as oppose to keeping it in the content database alone thru manual upload of files in the catalogs folder.
Can you please confirm my assumption?

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

MOSSBuddy-
Your understanding isn't correct. Ghostable & GhostableInLibrary both provision uncustomized instances to the virtualized file system for the site in the content DB. The difference is that GhstableInLibrary registers the file as actual content in a library.

Neither option puts the source of the file into the content database.

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 7/8/2009 2:42 PM MOSSBuddy

Thank you Andrew, So with the GhostableInLibrary option will I get a performance benefit instead of manually uploading the page layout to catalogs document library?

I had one more question regarding deploying the CSS, Images, XSLT files. Is it ok to say that performance will not be impacted if we store those files in the Styles Library of the Site collection (when all these files are not re-usable i.e. they are only relevant to a site collection and hence not thinking of deploying it to layouts folder). Assuming caching is enabled.

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 7/8/2009 4:44 PM AC [MVP MOSS]

MOSSBuddy-
You're putting too much importance on performance in this scenario... it's so minor it isn't much of a deal. There is no performance benefit to using Ghostable or GhostableInLibrary. Again, the ONLY difference is the latter adds a little flag that essentially tells SP "this is actual contant, not just a file, in this library". For instance, ExpenseReport.xlsx is content in a library, but /Forms/AllItems.aspx is not.

The exact same is true for CSS, images and all other files.

The only performance impact you have is when files are customized as they are subject to the safe mode parser.

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 7/8/2009 9:29 PM MOSSBuddy

Thank you Andrew, this definetly helps, but still a small doubt (really sorry 2 bother on this point just want my basics to be clear rather than having wrong assumptions).

So if a Page Layout is created and instead of deploying it thru a Feature if a user directly uploads the new Page Layout into the catalogs folder (so now the Page Layout is only in the content database and not anywhere on the file system) then will this have any impact on performance (i.e. will it be subject to SAFE MODE PARSER then?)

Thank you for all your help.

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

Again... you are making this to be a much bigger issue than it is. Technically yes, there will be a tiny perf hit.

# Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 7/12/2009 2:34 PM Mahesh Purama

Hi, I am a CMS Architect working for a consulting company trying to implement a SharePoint internet site at one of our client locations. We have a requirement where in the content authors at the client site need to input the content before it is being published to the internet site. All this looks OOTB from SharePoint perspective but the client does not want a regular publishing interface(page layout editing) for the authors. The decision has been made and we need to design custom input forms for publishing. Basically we have to create input forms for the authors to input the content and once they submit the content in input form, the content has to be published automatically from these input forms to the internet site by means of a workflow. On analyzing various avenues, I only found one way to be feasible i.e. to convert page layout publishing to input forms using a webpart. So when a user selects a layout, we need to present him an input form which has a webpart that renders all the publishing page content into that input form using lets say, ASP.net model for that particular publishing page layout. It is the only thought I have arrived so far and I know it is easier said than done. Please let me know your thoughts on this approach and advise me of any better solutions.

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 7/13/2009 5:32 AM AC [MVP MOSS]

Mahesh-
Look at the Edit Mode Panel control... allows you to define the layout of a page in presentation or edit mode. I would not use Web Parts, I'd just render it out using field controls in a form-like layout. See this for more info: http://www.andrewconnell.com/blog/archive/2006/12/23/5535.aspx

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 7/16/2009 10:09 AM Mahesh Purama

Andrew, I am not sure if I posted my question clear. Let me make it in small algorithm. Here is the scenario and we are trying to solve it. Please advise.

We have content types with content in SharePoint --> Lists are created with these content types --> content & metadata entry using List Input Forms --> Assemble the content entered via list input forms automatically to a page layout --> Review team reviews content & web pages --> If approved then publish the page.

The major problem here is that how we assemble the content into page layouts? The page layout is a mixture of field controls from different site columns in different content types. The client has EMC currently and they still want to continue with that kinda interface. The major reason that they want content types is that they want to reuse the content entered in different site columns of content types which in turn will be published.

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 7/16/2009 1:51 PM AC [MVP MOSS]

Mahesh-
You don't write to the page layouts... you write to the page objects. Page layouts simply render the contents of the page. See this for reference: http://andrewconnell.com/blog/archive/2006/11/15/5168.aspx

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 8/27/2009 10:29 AM mossie

Scenario: I've uploaded a pagelayout through GUI to the masterpagegalleri. The customer creates loads of pages based on this pagelayout. Now the customer want's to take care of deployment him self, so I have to deliver a wsp containing a Feature for future pagelayout deployment.

Problem: When I activate the Feature, Sharepoint just ignores the altered page i'm provisioning, and sticks to the one uploaded through GUI.

So atm i'm thinking of renaming the "Feature pagelayout" (to get it registered in the galleri) and write some code that opens ALL pages based on the "old" pagelyout in the entire site and swap layout to the "new" layout provisioned through Feature.

Does anyone have another (read: easy) way of doing this?Any comments would be appreciated!

# Cannot convert type 'Microsoft.SharePoint.WebControls.FieldValue' to 'System.Web.UI.IAttributeAccessor' 4/18/2010 2:50 AM Nayeemuddin

Hi ,

After deplyoing the custom masterpages& pagelayouts, while creating the page using the new masterpage iam getting the follwing error

Couldd you please help me.

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'

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 8/19/2010 10:52 AM Dan Marth

Hi Andrew, great post!

I use features to deploy my custom ASP.NET applications to SharePoint and it works great. I personally like deploying all my files (aspx, images, style sheets.....etc.) to the feature folder of my feature. Others at my company are storing their files in the _layouts directory. Which approach do you recommend?

It would be nice if we were all doing deployments the same way.

Thanks,
Dan

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

@Dan - I don't recommand anything... I can't say one is better of ther other. I prefer to post everything in the Style Library. I would be consistent though.

# re: Moving layout files (master pages, page layouts, CSS, etc.) in a MOSS Publishing site between multiple environments 9/9/2010 2:17 AM Neha

Hi Andrew,

I have a query regarding retraction of features (SP 2010). I have a feature which uploads and applies my custom master page on creation of new personal sites. I have stapled the feature to the “SPSPERS” site template. In the deactivating event, I loop through all the personal sites (as the deactivation code will run on the site I have deployed my feature to, therefore I loop through the personal sites) and point the master url back to v4.master

When I retract my solution, I get a "404 error" on the home page, but I am able to view the settings page of the personal site by typing the error. It is just the home page which is giving an error.

Any help is appreciated.

Thanks,
Neha

Post Feedback

Title:
Name:
Email:	(email will not be displayed)
Url:
Comments:
Please add 7 and 2 and type the answer here: Remember Me?

All Comments Are Filtered & Moderated
Unfortunately comment spammers are just too effecient and are constantly dirtying up blogs with irrelevant and unwanted comments trying to improve their standing on search engines. All comments on this blog are moderated. I do not censor comments, but I don't approve comments with vulger language or those soliciting products. Most of the time comments are approved within a few hours of being submitted with the only exception when I'm traveling.

Why are you asking for my email address?
The only reason I'm asking for your email address, which isn't required to submit a comment, is to provide a gravatar if you've created an account for yourself and associated your email address with a small image. If you have a gravatar created for the email address you submit, it will appear next to your comment. Otherwise nothing will appear.

What is a gravatar?
A gravatar is a "globally recognized avatar." You can get more information about gravatars, as well as create your own for free, at www.gravatar.com. You can also view my gravatar here.

This work is licensed under a Creative Commons License
Site design by Heather Solomon.