i am new to sharepoint. i have a sharepoint application. i have to create a package setup (install shield kind of thing) that can deploy the sharepoint solution on the client machine. in my application we have .dll,.ascx,.xml etc files available. i think i have to deploy the dlls,ascx, xml files.
Can any body help me on this? how shloud i go forward and is there any tool available which i can use for this?
is it possible with VS2005? VS2005 provides a setup and deploy feature. can we use that for sharepoint? if yes can any body help me how to do it?
thanks in advance.
Try and have a look at http://www.codeplex.com/sharepointinstaller. It is a free tool offering a user friendly install/upgrade/uninstall of SharePoint solutions.
The first thing you need to understand is Solution Packages. They are the unit of deployment in SharePoint.
Creating a Solution Package in Windows SharePoint Services 3.0
However, Solution Packages are meant to be deployed by SharePoint Administrators. They don't have a user friendly installation process.
If you want something more like an installer, you can look at the SharePoint Solution Installer CodePlex project.
Related
I have been investigating building web parts for sharepoint 2010 and currently have a single instance of SP2010 on the work servers. I would very much like to be able to test them locally (on my laptop) if possible, without having to install sharepoint 2010 on my laptop (is this even possible?!)
Is there a way to test web parts and do I need to install all/part of sharepoint on my laptop?
Thanks
If your Web part is simply displayed in a SharePoint page, without using the SP API, you could simply host it in an ASP.NET page on your laptop, but this is not a common scenario.
One new feature of SP 2010 is the client API, i.e. a subset of the full API that can be used outside of the farm. If your usage of the API fits in this subset, this could be useful, but you will still need to access a SP server somewhere.
Another option is to put all the code that uses the SP API in something similar to a Database Access Layer which talks to SP on one hand and returns business objects (not lists or lists items). This way, you could simulate this part on your laptop and concentrate on the look of the Web part and its business rules, without SP. If this part is in its own DLL, the only reference to SP DLLs would be there, so the project on your laptop would not need to reference the SP DLLs.
There are two ways: the good one and old-school.
The good way is to install Sharepoint Services (http://technet.microsoft.com/en-us/windowsserver/sharepoint/default.aspx) and deploy WP locally. It works only if you have Windows Vista or Seven. It is the most productive way so i recomend it.
Another way comes from SP2003 era... The idea is to develop custom Web Control, test it locally with IIS or just development server, and then to embed it into web part. The method is described here - http://www.reflectionit.nl/SmartPart.aspx . It's an old and painful method. Unfortunately we can't use (without troubles) Microsoft.Sharepoint.dll etc
P.S. Sorry for my English...
This came up at our office and we ended up installing Sharepoint Foundation on each developer's PC, which allows us to develop and debug locally. Here is the link that I used to get this working.
Setup Dev Env. For Sharepoint Foundation on Win 7
I would say get a virtual machine.. but I dont think you can run 64bit VM's on a 32bit OS.
You'll have to upgrade to 64bit.
I don't think there is a good way around this; you will spend a lot of time on something of questionable value if you do not install SharePoint either on your laptop or in a VM and do it the proper way.
You can just swap out the inheritance from the SharePoint Web Part to the ASP.NET equivalent and back again - all the functionality is the same because the newer version was designed with backwards compatibility in mind. Use the ASP.NET version when testing on your laptop.
Here is some more info :-)
http://weblogs.asp.net/scottgu/archive/2006/09/02/Writing-Custom-Web-Parts-for-SharePoint-2007.aspx
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've created a content type on my local dev server, how can I package this content type, so I can deploy it professionally to live installations?
An option is AC's WCM Custom Commands for STSADM.EXE which adds two commands which is relevant here:
GenSiteColumnsXml
GenContentTypesXml
These allow you to get the XML for Site columns and content types base on ones existing in a site
I would suggest you to look at the WSP Builder. It will help you a lot when creating SharePoint WSP solutions.
I came across this , http://moss2k7ctypesviewer.codeplex.com
SPSource is an open source project that can reverse-engineer quite a few SharePoint artifacts and is actively supported by knowledgeable SharePointers such as Jeremy Thake and Rich Finn. There is a bit of set-up time required however.
There's also SharePoint Solution Generator from the Visual Studio Extensions for WSS (although I would use SPSource over this any day).
Note that both of these options are much more comprehensive than what you've asked for and designed to extract the artifacts from an entire SharePoint site. So if you just want the content types go with Per Jakobsen's answer.
One of our product will consist of multiple SharePoint solutions. Now we're wondering what would be the best way to provide an easy deployment to our customers? At the moment we deploy each solution by hand, which is OK during development process but not acceptable for our customers.
For your information, we're using VSeWSS 1.3 for development and solution packaging.
So how do you offer your solutions to your customers? Do you write installation scripts using STSADM commands? What other options do we have?
WSPBuilder
Personally I use WSPBuilder for packaging and find it much easier to work with than VSeWSS. However if VSeWSS is working for you then that's great.
One of many the benefits I found of using WSPBuilder is that it's easy to integrate into a build system. It's just a simple, but clever, commandline tool.
Batch File
For deploying multiple SharePoint solutions to our customers I usually provide a batch file that contains the necessary STSADM command and prompts them to enter any environment specific data i.e. site collection urls etc...
SharePoint Solution Installer
There is also a nice GUI installer,called SharePoint Solution Installer, that you can use in-conjunction with SharePoint solution files. Check it out it might suit your needs.
alt text http://i3.codeplex.com/Project/Download/FileDownload.aspx?ProjectName=sharepointinstaller&DownloadId=18625
SAF - SharePoint Action Framework
It's worth pointing out SAF; which is an extremely comprehensive framework that can automate installation and configuration tasks, using either MSBuild, Powershell, Stsadm or a custom SharePoint feature.
We just use plain old batch/cmd files. If you need to "productize" this, just wrap up all solutions in a selfextracting rar package and have it run the batch file after unpacking.
Stick to Microsoft products. Powerbuilder is being groomed to gradually take over from STSADM for this type of task. In a farm scenario (remember, yours may have to grow over time), this would be the tool to use to push out solutions to all front-end Web servers.
EDIT:
MS are preparing a final version of VSE 1.3 to ease the migration of 2007 solutions to the 2010 environment.
Have you looked at Microsoft SharePoint Designer?
not sure if it will do all you need, but it does allow you to package sites or individual objects that you can then run on another SharePoint install.
Here's the scenario
I created a Site which in I used custom lists, webparts, custom developed webparts, workflows et cetera. You can see the site as an application.
What I am trying to do is to create a solution package which holds everything I build in that site so that I can give the solution file to an sharepoint administrator who can install the solution to his sharepoint environment.
For example look at the free application templates you can download from MSDN, I am trying to achieve the same as they did. One solution file to hold them all!
Any idea's?
Cheers!
Get STSDev and SharePoint Manager. STSDev is goog for creating the solution you want and SharePoint Manager can be used to get the SchemaXML from the customisations you have already created.
You will need to package up the webparts and everything. Unfortunately, this is a pretty hefty learning curve, so expect to do a lot of reading on this subject and some experimentation. However, this is time well spent as a solution is the "only" way to release a custom site definition.
Workflows created using SPD are not portable across sites - they will have to be recreated. As a result, Nathan's solution is probably going to be the only way to go.
Export the site as a template and include all the content. The workflows will point at the old site and will need to be updated manually, I believe. Everything else should work.