Deploying a file to the filesystem using MOSS Solutions and Features - sharepoint

I have a .browser file that I need to deploy to the following location:
c:\browsers\
as part of a moss .wsp file. Can I do this in the manifest.xml or as part of a feature?

It is not possible. You can use the wsp solution to deploy any File to
Inside 12 Hive Folder Hierarchy
GAC
bin Folder of the Web Application.
Rest of the other location you need to look out for the custom solution. One option I can say is to use a Feature Installed event and keep it a Farm Feature.

Related

Restore sharepoint 2007 website on a different sharepoint 2007 server

I'd like to update existing production moss2007 website and to do that I want to create this website on my dev environmen (vhd win 2003EE, MOSS 2007 trial version).
I was given:
some stp files which include(aspx pages, javascript files, etc...)
some aspx pages, masterpage, css file
some wsp files
source code for almost all wsp files.
There is no documentation how to install all this stuff and I'm not a sharepoint developer but Asp.net dev in fact.
I set up local dev enviroment (i had no problems when following http://www.pptspaces.com/sharepointreporterblog/Lists/Posts/Post.aspx?ID=28
) and try to create a website based on given files.
My questions:
Do I need a copy of the database?
I noticed that one of wsp files is not a webpart but a project that contains some web controls and even a master page) - what should I do with it?
I tried to import all stp files. I had to use stsadm, but I can't see them. I can list them using "stsadm -o enumtemplates" - all of them have the same id!
I changed stp->cab->modified the "WebUrl" in the manifest.xml -> created new cab and rename it to stp-> imported to sharepoint but still the same, I can't see them (custom tab is still not visible).
I created a custom site template locally (custom tab appeared with it) and opened its manifest.xml. I noticed that the section contains 17 parameters (manifest.xml files from other stp files 9 parameters only).
I think that my SharePoint (Trial version) works in a different way and that's the problem.
Can it be?
What is the best way to create this site locally?
thx ahead for all answers
if you want to set up development environment containing the same functionality as your production server, you can duplicate your production site collection by:
Copying and attaching production SharePoint content database to your development environment farm
Backuping and restoring it by stsadm tool
By firstly you need to prepare your development environment. If you have any wsp solutions deployed on production farm, deploy it on your development environment.
Then if you prefer first option check this link
If you prefer second option check this link
But if you prefer backup way, you can catch some problems with version difference between production and development revilement, different updates installed, so different assemblies in GAC.
So I advice to use attach database way, it should upgrade attached database if it has different version automatically.
Just google little bit, may be you'll find more complete guide for attaching or restoring site collections. I just give you start point.

Deploying a content type and site columns with a WSP in MOSS

I'm looking for a clean, and repeatable, solution to deploying custom site columns and content types to MOSS using a WSP. I've currently split up my product into two Visual Studio solutions. The first contains the code itself where the second will contain the XML files required to describe the site columns and content types.
We use Vsewss for this, there is also a tool WSP Builder. Both of these tools will help you build the xml and wsp files.
We then create setup projects that build an MSI to deploy these files and run the activation.
You might consider merging the code and the other files into one VS solution. This is often easier to manage and will allow you to leverage either VseWss, WSP Builder, PowerShell or .bat files to aid with building and deploying the .WSP file.

WSPBuilder: How to create a deployment package to deploy .dll and .wsp?

I'm using WSPBuilder and it is being very helpful. However, it was being hard to understand the strength of WSPBuilder because of missing manual. I've to create a solution file to deploy "Return of SmartPart" (.wsp file), "Application Template Core" (.wsp file) and also "AJAX Extensions" (.dll files). So, I won't have to edit the web.config to mark them safe controls. Please, suggest HOW?
Quick answer:
C:\Program Files\WSPBuilder\WSPBuilder.exe.config
(or where ever you've installed it)
add key="BuildSafeControls" value=""
Long answer:
WSPBuilder is great for when you want to do a quick deployment via Visual Studio to your SharePoint installation. I have found that that it gets harder to configure when you need to deploy CAS policies but I'm sure they will do work in this area for future versions.
WSPBuilder in your scenario can automatically build and deploy the safecontrol entries that need to go into your site. Good thing about WSP's are that once you retract a solution, it will also go back and remove the safecontrol entries so you don't need a tidy up job.
Regarding different projects, if you need to install third party wsps, then WSPBuilder hasn't been designed for that purpose, I suggest a simple batch file with some stsadm commands. If some of these solutions are your own code, you should divide each into a different VS project and build their WSP's seperately. You may even need to divide them into different .sln (solution files) but I've not tried this way myself so couldn't say for sure.
Personally, I would only use use WspBuilder to build deployment packages that need to be deployed to live environments if I can be sure its not adding extra bits that may become a problem. Therefore you'll need to think about WSPBuilder wsp's are good enough for you.
Recently I came accross an issue with CAS policies and decided to make my WSP's manually. Under the hood, WSP files are CAB files, you can just create a CAB file and rename its extention to .WSP. I would advise, creating a WSP, rename it to mysolution.cab. Open it and up and extract the files, and have a look to see whether its doing what you want. Key file to look at: manifest.xml.
As far as I know, you can't nest WSP files in other WSP files. You'll have to install those separately.
If you want to install DLLs (other than the one that's built as part of your WSPBuilder project), create a folder in the project called GAC and put them there. All DLLs in that folder will be installed to the GAC when the WSP is installed.
To install a WSP package, you'll need to run:
stsadm -o addsolution -filename MyFeature.wsp
You can then deploy it from SP Central Administration.
You can also create a WSP file manually without WSPBuilder - it's a CAB archive and you can create a WSP file using the makecab.exe utility that comes with Windows and an additional description file that lists the files that should end up in the WSP file.

Use an XML File with a Feature

Currently I have a custom Web Part, deployed as a Feature, and it accesses an XML file as follows:
string sUri = #"C:\inetpub\wwwroot\wss\VirtualDirectories\80" + #"\wpresources\links.xml";
ds = new DataSet();
ds.ReadXml(sUri);
What is the correct way to include an XML file as part of a SharePoint Feature deployment?
Load it into the 12 hive under your layouts directory and link to it via
http://[currentsite]/[currentweb]/_layouts/links.xml
. Or add a subdirectory to group all of your file together. e.g.
http://[currentsite]/[currentweb]/[myFeature]/_layouts/links.xml
how do I include it in the Feature
project...?
I am using STSDEV and that automagically puts an entry into the manifest.xml under
<Templates>
e.g.
<TemplateFile Location="LAYOUTS\[myFeature]\links.xml" />
In my mind there are a few correct ways.
The place you want to deploy your xml file I would not pick however.
It would have to be either:
deployed directly in the 12-hive using a solution file (like Nat suggests, I'd use WSPBuilder though)
deployed to the site using a feature ( see: http://msdn.microsoft.com/en-us/library/ms441170.aspx )
this would make the file be pushed into the content database for your code to read.
To my knowledge there is no simple way of deploying files to the InetPub folder for your website. I needed this once to deploy a .browser file and ended up creating a feature receiver that copied the file from the 12-hive into the InetPub folder.
Maybe if you explain what the xml file is for, the answers can be better :)

Packaging multiple features into a single WSP solution file

I am working on a sharepoint feature which includes a couple of list definitions, 2 webparts, a feature receiver assembly and an InfoPath form.
I have to use WSPBuilder to package these, and the requirement is to package all these features into a single WSP solution file.
Now, WSP builder requires the deployment files in a particular folder structure, same as the 12 Hive of sharepoint.
My problem is that all my features were developed separately, and consist of multiple project files, and these are not necessarily in the same folder structure..
How do I use WSP Builder to package multiple features into a single WSP solution?
Maybe this will help: http://www.codeplex.com/wspbuilder/Thread/View.aspx?ThreadId=43125
Ultimately, I think you gain a lot of flexibility by building your own wsp files by using a tool like NANT.
There's no particular action you need to undertake in wspbuilder to have multiple features in the same solution package.
All you need to do is create a new folder for each feature under the 12\TEMPLATE\FEATURES folder inside your solution in Visual Studio and place the appropriate feature.xml file in that folder. For example, you may have:
12\TEMPLATE\FEATURES\FancyFeature\feature.xml
12\TEMPLATE\FEATURES\ReallyCoolFeature\feature.xml
... and so on.
Upon building the solution, wspbuilder will read the entire tree structure of your 12 folder and append the corresponding nodes in the wsp's manifest.xml file. The same goes for any other possible subfolders inside the "TEMPLATE" folder, including IMAGES, LAYOUTS, etc: at deployment time they will all be copied in the correct folder inside the real 12 hive, because the 12 folder inside your solution is meant to be a replica of the original one.
For a better understanding, create some folders and files inside your 12 folder in the visual studio solution, compile your project and look inside the generated manifest.xml file.
The simple answer is that you are going to have to copy all the files form the individual projects into one master project for your solution. As long as all your individual feature files are in the correct location in your '12' folder then you'll be good to go.
Note: You'll need to check all your references to any assemblies as this solution will create 1 assembly for all your custom logic.
I had trouble adding dlls to the wsp so I wrote a short article about it: How to Add DLLs to a WSP Solution
I usually have one project in the solution designated as the "main" one. I set the dependencies so that this "main" project is built last. Then for the other projects that I want to be included in the wsp package, I edit the "Post Build Events" to xcopy the contents of the 12 folder and that dlls built by the projects into corresponding folders for the main project. Then after I build the whole solution, I can build the wsp package for the main project and know that it contains everything.

Resources