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.
Related
I have a larger solution that I desire to distribute via ClickOnce. It consists of one main shell executable that directly references only a small subsection of libraries and processes that constitute the solution.
The solution consists of a few other processes and several libraries (some C++). I need to be able to include all of these libraries and processes in one ClickOnce distribution for both local builds and TFS server builds.
I cannot reference every other library and process form the shell project. And I do not wish to push these files into a MSI to be treated as a prerequisite as it would defeat the purpose of using ClickOnce to distribute/update the product.
What is the correct method to incorporate all of our necessary files/projects into a single ClickOnce distribution?
The IDE won't detect native DLLs as dependencies when publishing, but you can run the SDK tools directly to include them manually in your ClickOnce distribution. You can either use mage.exe in your post-build script or run MageUI.exe to have a wizard to guide you through the package generation.
Suggested reading:
Walkthrough: Manually Deploying a ClickOnce Application
Understanding Dependencies of a Visual C++ Application
There is an alternative to Visual Studio for this kind of situation. You could try using Mage, but it can be a little tricky to use. My company wrote an alternative called ClickOnceMore.
ClickOnceMore is a ClickOnce build tool for when you don't want or can't use Visual Studio to do ClickOnce builds.
There is a specific page on the UI for including files (using rules to include anything from a single file to an entire directory trees) so you should be able to do exactly what you need with it.
This is what I have done in a similar situation. I use TFS at work, so convert the terms to whatever you may use (or not use) for source control.
I have a main workspace that I use for all development of my application, I keep this workspace pristine.
I then created another workspace with a proper name (ex: solution-deploy) and in this workspace I do the following:
Get latest and merge everything from source-control into the deployment workspace
I build a Release build of my application
I r-click on the root (I put them in the root, because I need to access them from there, put them in whatever folder you want) project folder for my deployment project and select "Add -> Existing Item"
I browse in the file selector to the Release directory of the assemblies I want to add to my deployment package, select them, then I use the arrow next to the Add button and drop down to "Add As Link", do this for all of the assemblies you want to add and place them wherever you want them to be organized in your deployment
In the Solution Explorer, select the added assemblies and in the Properties window set the Build Action to "Content", this should be all you have to do, but others have had to also set the "Copy to Output Directory" to "Copy Always", I don't do that
Run a Release Build
Go to the Properties view for your deployment Project
Go to the Publish Tab and Click on the Application Files button
Your files should all be available and added to the Deployment
Set up your ClickOnce settings however you need them to be
Publish your ClickOnce package
Your published package should contain all of the assemblies you need now.
Keep your separate Deployment workspace set up this way and never check it in. Do your work in your development workspace. Whenever a new deployment is needed, open your solution in your Deployment workspace and get the latest code, build, then publish.
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.
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.
I have multiple projects/wsp solutions for my different Sharepoint webparts and event receivers. This is fine for development, however I would like to merge the resulting .wsp files into a single one for production deployment.
Is there a way to do so? I am using vsewss 1.2 only.
This is going to be painful, but to really do this correctly for production pushes you should drop vsewss 1.2, re-organize your projects inside of Visual Studio and use WSPBuilder.
WSPBuilder is great because it takes a lot of the manual work out of creating manifest, ddf and compiling the CAB.
You are going to have to do a lot of the work that vsewss is doing in the background your self. there is a artical on MSDN about the basics on creating a WSP Creating a Solution Package in Windows SharePoint Services 3.0
A WSP is a cab file that contains a manifest.xml and a file structure, it is imortant that you place files in the right location in the WSP so they are deployed to the right location in SharePoint.
I agree with JD
This is going to be painful, but to
really do this correctly for
production pushes you should drop
vsewss 1.2, re-organize your projects
inside of Visual Studio and use
WSPBuilder.
This would be a good time to restructure you code and assembly structure so as to minimise the number of assemblies you need to deploy.
If you have any Web Parts be sure to check that the Feature xml files are all corect as vsewss preparses and does text replacment befor generating its WSP files.
It commanly stores a guid in the file where a full assembly name is requierd.
If you are going to be doing a lot of SharePoint dev work it is probly worth spending a bit of time learning how the manafest.xml and rest of the WSP packages work.
I haven't seen a tool which does this, but it shouldn't be hard to create:
Unzip the wsp packages (They're just
cab files with an odd extension)
Merge the directory structures
Merge the manifest.xml files
Zip the combined package
There is an advantage to not having all your code in a single WSP.. you can do partial deployments and you don't have all your code in a single gigantic Visual Studio Solution.
Why don't you script all WSP deployments in 1 script file? It seems a far more transparent solution than fiddling with the WSP itself.
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.