Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I am now in the process of planning the deployment of a SharePoint solution into a production environment.
I have read about some tools that promise an easy way to automate this process, but nothing that seems to fit my scenario.
In the testing phase I have used SharePoint Designer to copy site content between the different development and testing servers, but this process is manual and it seems a bit unnecessary.
The site is made up of SharePoint web part pages with custom web parts, and a lot of Reporting Services report definitions.
So, is there any good advice out there in this vast land of geeks on how to most efficiently create and deploy a SharePoint site for a multiple deployment scenario?
Edit
Just to clarify. I need to deploy several "SharePoint Sites" into an existing site collection. Since SharePoint likes to have its sites in the SharePoint content database, just putting the files into IIS is not an option at this time.
I would also suggest checking out the SharePoint Content Deployment Wizard by Chris O'Brien.
http://www.codeplex.com/SPDeploymentWizard
Should help smooth the process you describe, and it's a nice tool for your kitbag regardless
We have a BizTalk 2006 with Web Application and Several WebServices that need to go from Dev to UAT to Live.
We use MSBuild right from within VS to build, run tests, dependent on test result, complie, zip and ship to servers.
Small MSBuild script on server to unzip, move the files, install clean web app, unlist biztalk bits, install new biztalk bits, re enlist and then start the stuff.
MSBuild is hugh and more people need to use it as it there now right in the platform =>
Use MSBuild
Note that "solution" has a specific meaning in Sharepoint: a collection of features (like web parts, list definitions and so on) packaged for deployment as a .wsp file.
You typically build sharepoint solutions in Visual Studio and package and deploy them using some tool like Sharepoint SmartTemplates http://www.codeplex.com/smarttemplates
However in your case you already have content in a live sharepoint site which you want to move to another site. It will probably be too cumbersome to use a solution for this, especially if you want to do it more than once (though it is possible to generate a solution from a live site using SharePoint Solution Generator).
The easiest way to deploy all content from one live site to another is to create a backup of the site using stsadm and then restore it to the new site again using stsadm restore. This completely overwrites the new site.
You can move select files/lists using import/export (rather than backup/restore). A tool like SharePoint Content Deployment Wizard makes it easier to select the content to move.
Related
I am working with a customer which have SharePoint 2013 dev, test and prod environments sitting in a datacentre. We are moving the datacentre which means their SharePoint 2013 needs to be moved as is. They have 1 heavly custom build application on top of SharePoint which needs to be moved. I need confirmation, process suggestion on the migration part.
I install SharePoint 2013 like for like in new environment.
Option 1
I take backup for their databases and restore them on new SQL Server. Use Mount-SPContentDatabase to mount database and test if everything is working as expected
Option 2
Recreate web application, site collections, activate custom features, timer job and migrate content.
I personally think that option 1 is more applicable but need input and suggestions. Any road blockers or gotcha are also encouraged.
Thanks for sharing your experience
As its a same version migration it wont be much of an issue but go with option 1.
Re Creating the whole farm is so hard specially if you decide to deploy each and every component.
I've migrations to same version and these are the steps that i follow.
Create a checklist of all solutions and features (WSP etc).
The check list should have the same services that are running in the farm as well.
Install SharePoint in the new farm and update to the same version as the existing farm , having same version will reduce a lot of
problems.
Create the service applications just like the existing farm.
Restore the service application databases (MetaData, UserProfile etc)
Create the web application and restore the content database
Deploy the custom solutions
Confirm that everything in your checklist is deployed and working fine
Fix errors if there are any
This is the flow that i follow and so far i've been successful.
Good Luck
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
Ok, so we have two servers. One with Sharepoint on (amongst other things) and one with our company documents on. Is it possible to link the two together so the documents get stored on the file server but can be displayed through SharePoint on the other server?
We want to be able to access the files through sharepoint when outside the office, but through the windows network when in the office, without having more than one copy of the same document.
Both servers are running windows 2003.
I would suggest the other way around. Place the documents in a SharePoint document library.
You can still access (and manage, update/move/delete/rename) them from a standard Windows Explorer using the WebDav protocol by simply browse to \YourSharePointServer\DocLib
You will benefit from SharePoint access when not in the office (or, by all means, when you are in the office), access them from an Explorer window internally, and have only one copy stored without redundancy.
Plus, version control of the documents (if needed).
You'll need to code some webpart which gets a file list from your file server. When user click that link you must to get that file, by using System.IO, and download it.
Or you could to add that files on your Sharepoint box and to give appropriate rights to users coming from outside.
Sharepoint allows you to save BLOBS (and documents) externally through the ISPExternalBinaryProvider interface which was added in SP1. Unfortunately, no provider implementation is provider so you have to write your own. Check the Creating an External Storage Solution for Sharepoint article from the June 2009 issue of Technet Magazine for a very good explanation and a sample implementation.
A possible drawback of external storage is that it affects the whole farm. All BLOBs from all sites will be stored outside Sharepoint.
I could suggest to look into using links to the external files that are outside WSS. The links could be stored in a list for example. I think this should solve your dilemma of not having duplicate versions or copies.
I would like to start developing a simple Workflow application in Sharepoint. What files should I download?
SharePoint Server 2007 SDK?
SharePoint Server?
SQL Server?
Visual Studio?
other?
Are they all required for workflow development?
I do not have SharePoint anywhere, please include its components in your answer.
If you don't have SharePoint installed, the free WSS 3.0 version is available for download from Microsoft. Follow these steps to install in a single server environment. It will install a basic version of SQL Server. Note this is suitable for prototyping only, not a production deployment, due to restrictions in the basic install.
Then use SharePoint Designer to create the workflows, free from Microsoft. There is no need for any other software. This allows you to configure workflow against a particular list in your SharePoint site with a wizard-like interface. See this topic on Office Online for more information.
If you need to develop a reusable workflow that can be deployed to many different sites or a production SharePoint instance then this is a much larger time investment. Start by reading one of the many other questions on this site for "getting started with SharePoint" that will give resources to how the product works. Be warned: there's a reasonable learning curve. Once you have a solid understanding, you could follow it up with a book such as Professional SharePoint 2007 Workflow Programming (first search result).
Another "warning" on designer...
The workflows you create there are allways fixed to a single list, and you cannot deploy them to a production server. So the "reusable" part from the above answer even includes a "portable" component.
Also those workflows are very static, since they only contain some speciffic actions that you can perform. (So no custom code etc).
I am total beginner in SharePoint and I need some help in starting a project. I have to develop publishing site that will be delivered to the client. I would like to give client deployment experience like he would get when deploying standard ASP.NET application as much as possible. I plan to use Visual Studio 2008 with SharePoint extensions and maybe WSPBuilder or some other tools.
I also need help in structuring whole project.
Here is what I plan to do:
1. Develop minimal site definition
2. Create site from this defionition. How should I do this from code ? Use SharePoint Feature ? How should I activate it ?
3. Develop all the needed infrastructure for the site (master page, layouts, content types, ...) as SharePoint Features.
Is this correct and how should I develop all those parts so I can make a some kind install script so can client create get complete site with one click ?
Site definitions are complex no question about it, but they are very useful if you need to deploy to unrelated enviornments. If you are staying on the same server farm, maybe site definition is overkill. If you are going between domains (i.e. test & prod, then maybe they are worth looking into).
Another advantage to site definitions, esp. if delivering to a client is it feels more like a traditional deliverable. They will have a bunch of files (hopefully in source control) that are their custom site. I think that gives IT dept's a much warmer feeling than an XML file created from the SharePoint UI.
Another benefit of site definitions are you have a lot more control over the pages that make up the site. IMHO its easier to add master pages & custom CSS via site defintion that site template.
I am curious as to what are the 'moving parts' to the site you are trying to deliver? I think that answering that question will determine how to define the project's structure.
Generally, I think you are on the right track. Features and solutions are a must. I would stay away from VSeWSS, its buggy and clunky and generally terrible if you are trying to do anything complex. It tries to be so smart, that it leaves you no control.
That said, it really depends on what you are trying to do. If you are going to build a solution to deploy to the GAC with one assembly, and only building features supported by vsewss you may be fine.
If however, you want to develop, say a timer job wiring that into the VSeWSS feature framework gets tough. Also, if you need multiple assemblies in the solution. YMMV, but I had to junk it and find of a more flexible solution (hello NANT).
A lot of the work you will end up doing is building and checking, and re-checking XML configuration files. Bookmark the Feature Schema reference page on MSDN, you will be spending a lot of time going through it.
Finally, yes, if you have all of the parts packaged as features you should be able to develop a nice install script. Ultimately the script will need to call the STSADM (there are some really nice STSADM extensions here) commands necessary to create the site structure, add & deploy the solution & activate the features. You can start with a batch file, and get as complicated as you want.
Personally I don't find that creating a site definition is really that useful for the sites I have built. They can be very tricky to set up, because of their complex nature.
What I do is use the standard Publishing Site and then using features to add my additional componets (deployed via a SharePoint solution).
You can use Feature Stapling to connect up the feature to the Publishing Site creation.
I've also just done a blog post on how to programmatically modify the workflow which is created by default: http://www.aaron-powell.com/blog/february-2009/programmatically-modifying-sharepoint-workflows.aspx (that also has a link in the comments off to the Feature Stapling concept).
Then I use a combination of SharePoint Solution Installer (http://www.codeplex.com/sharepointinstaller) and batch files to install the components. SSI for all the SharePoint database level installs and batch files for the file system stuff.
Adding another answer, because I have more than 300 characters worth of stuff to say :(
RE: SharePoint solutions generator, again I would say your mileage may vary.
The biggest issue with SharePoint dev is managing all of the "magic strings" across the various configuration files. GUIDs and Fully Qualified Assembly names are the spit and glue that hold the whole thing together, and although it all makes sense its very difficult to manage.
The current crop of tool all try and alleviate the complexity of managing these things, but they require that you work in a certain way, so the tool knows how to inject the appropriate plumbing.
If you plan on doing a lot of work with SharePoint it really behooves you too learn to manage the plumbing yourself. Its painful up front, but really pays dividends.
Basically, I suggest you spend your time learning the platform and not the tools. Once you know the platform, using the tools will be much easier.
If you are doing this as a one-off engagement and just want to get it done, I'm sure you can get any of the tools you've mentioned to do the trick.
I would agree with the use of the out of the box publishing site definition, and then customizing it using Site Collection features (Master Page, Page Layouts, CSS) and site features (create lists, pages, sub sites, defining master pages of sites, etc...).
Feature stapling is great when you want to customize new sites (allow user to create new sites) of well known site templates, like customize the "My Site" look and feel. In this case I don’t think its very useful.
As a tool to help this task, I personally use STSDEV (http://www.codeplex.com/stsdev) to help in creating, programming, debugging and deploying my Sharepoint solutions.
First it creates a good project for Visual Studio (clean, or with some nice "starting point" definitions). Then it includes some “build configurations” that really helps with install, deploy and upgrade in the development machine.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I have been asked to develop some usercontrols in ASP.NET that will at a later point be pulled into a SharePoint site as web parts. I am new to SharePoint and will not have access to a SharePoint server during the time I need to prototype these parts.
Does anyone know of any reasons that this approach will not work?
If this approach is not recommended, what would other options be?
Any suggestions on a resource/tutorial on what to consider when developing an ASP.NET web part with SharePoint in mind?
Thanks
Edit: 12/31/2008
I finally marked an answer to this one. It took me a while to realize that going the SharePoint route right away, though painful at first, is the best way to go about it. The free VPC image makes getting set up to develop relatively painless.
While you can, as I did, develop web parts in ASP.NET without SharePoint, when it comes to developing and deploying SharePoint applications you haven't learned a thing, only pushed the learning curve off into a time when you think you are done, (and have probably informed stakeholders to that effect). To delay the SharePoint learning curve doesn't do you or your project any favors, and your final product will better for the expertise you gain along the way.
ASP.NET web parts work in SharePoint the same as they work in ASP.NET. That's the route I would take (custom control that derives from the ASP.NET Web Part class). This will alleviate any requirement to actually develop on a SharePoint server.
The only issue you are going to encounter is that you will not be able to take advantage of the SharePoint framework. If you are doing anything advanced in SharePoint this is a big deal. However, SharePoint is ASP.NET plus some additional functionality, so anything you can develop using the System.Web.UI.WebControls.WebPart class should work great in SharePoint.
Some considerations that will help ease your pain as you go from pure ASP.NET to SharePoint:
If you can put everything inside of a single assembly, deployment will be easier
try to put everything you need into the DLL's that are deployed to SharePoint
use assembly resources to embed JS, CSS, and image files if needed
Strong name the assembly you are building
Most SharePoint deployments end up in the GAC and a strong name will be required
Here is a relevant blog post; Developing Basic Web Parts in SharePoint 2007
If it's a very short-term thing, Microsoft has a time-limited WSS evaluation VPC image:
WSS3 SP1 Developer Evaluation VPC image
That will get you started if you don't have time/resources to set up your own VPC image right now.
I guess the easiest way is to use the SmartPart for SharePoint from CodePlex. The project description says "The SharePoint web part which can host any ASP.NET web user control. Create your web parts without writing code!", which I guess is exactly what you want to do.
Setting up my machine to develop for Sharepoint took me a couple of days.
See http://weblogs.asp.net/erobillard/archive/2007/02/23/build-a-sharepoint-development-machine.aspx
Build and test the control as you would for a typical .net web site.
Solution 1 = the controls
Solution 2 = dummy website to host the controls.
Deployment on Sharepoint:
You'll need to sign the controls.
Drop the signed DLL into the GAC on the sharepoint server (Windows/assembly)
Mark the control as safe in the virtual server root web.config on the sharepoint site.
i.e.
<SafeControl Assembly="MyControl, Version=1.0.0.0, Culture=neutral, PublicKeyToken=975cc42deafbee31" Namespace="MyNamespace" TypeName="*" Safe="True" AllowRemoteDesigner="True" />
Register the component in your sharepoint page:
<%# Register Namespace="MyNamespace" Assembly="MyControl, Version=1.0.0.0, Culture=Neutral, PublicKeyToken=975cc42deafbee31" TagPrefix="XXXX" %>
Use the control:
<XXXX:ClassName runat="server" Field1="Value1" Field2="Value2" ....></XXXX:Classname>
If you need to replace the control using the same version number, then you'll need to recycle the app pool to reload.
If you don't need to do anything SharePoint-specific (ie accessing lists, other webparts, etc) then you can build your webpart just like a regular webpart (derived from System.Web.UI.WebControls.WebParts.WebPart class) and it will work when added to a SharePoint site.
you need to have access to a sharepoint server because you can't simulate your webpart without it, you have to deploy it to your sharepoint site to test if it's working. debugging would also be a pain. or you can use SmartPart, it's a webpart that acts like a wrapper for your user controls to display in a sharepoint site.
You do not need SharePoint to develop WebParts. You can develop webparts by inheriting from the System.Web.UI.WebControls.WebParts. And this is the preferable way of creating web parts unless you want the following features like
* Connections between web parts that are outside of a Web Part zone
* Cross page connections
* A data caching infrastructure that allows caching to the content database
* Client-side connections (Web Part Page Services Component)
In which case you need to develop webparts by inheriting from Microsoft.SharePoint.WebPartpages.WebPart. You can find more useful info here
Is there any particular reason why your user controls must be deployed as web parts? It is perfectly feasible to deploy user controls directly to Sharepoint sites either through the CONTROLTEMPLATES folder in the 12 hive or to a location in the web app virtual directory, which you can then reference from web pages using Sharepoint Designer.
If however the web part requirement is crucial then I recommend Smartpart for Sharepoint as already mentioned.
Actually, Web Parts should always be deployed to the sharepoint's bin folder due to their 'abusive' nature. Always deploy web parts to the bin if possible and write your own CAS and include it in your manifest.