SPSource Wiki & Documentation Rss Feed

Updated Wiki: Home

richfinn — Wed, 07 Apr 2010 14:53:51 GMT

Project Description
SPSource is a tool for SharePoint developers to assist in the creation of WSS Solution Packages (WSPs) allowing for the use SharePoint Designer and the SharePoint web UI to make quick changes to items, then push those items into Visual Studio for later compilation into a WSP.

Creating Features which contain custom Content Types or file provisioning modules requires developers to write a lot of XML based on the wss.xsd. Content types require custom columns and content type definition files, along with the proper creation of the content type IDs. File provisioning modules require the creation of module elements which contain the information that will help properly push the files into the correct lists when the Feature is activated.
More over, List Templates are am absolute pain to code from scratch with a simple Generic List Template with one column and one view having a schema.xml file well over 2500 lines long with the out of the box Features!

This XML can be fairly daunting, time consuming, and frankly, not very exciting for developers who just want to test their code. This holds especially true for developers who are writing custom Features based on SharePoint's Publishing Feature.

SPSource helps by alleviating the need for developers to write these files by allowing them to use the SharePoint UI and SharePoint Designer (SPD) as the source for the files defined in the module elements, along with custom content types, and is meant to be integrated with WSP creation tools such as WSPBuilder, STSDev, and the WSPProjectTemplate as part of the build process, but it can also be executed as a CMD or BAT file at the root of your project to get you moving quicker. Executing BEFORE the creation of the WSP, any file that can be created using SharePoint Designer in a document library, and any site content type created in the SharePoint UI can be targeted and pulled down into Visual Studio for addition in a new or pre-existing WSP project. SPSource will also create the file provisioning module and site Content Type/Column definition files. The only thing the developer is left with is to add the ElementManifest and ElementFile lines to the Feature.xml file.

Why use it over VSeWSS Solution Generator?

Solution Generator uses a different approach to reverse engineer List Templates using the RPC Web Services, which requires some XPATH hacking to remove some illegal attributes and add some needed elements. The SPSource approach is based on the documented schema and generates the required elements and attributes based on the targetted instances to provided a much cleaner end solution. One example of this is the fact that it will intelligently try and fix up same-site lookup columns to list within the schema.xml file to save having to create these in a programmatic fashion.

Example scenarios

Some examples of what can be done using SPSource:

Completely define a custom Publishing Feature using SPD and the SharePoint UI, creating the master pages, page layouts, content types, style sheets, and images directly in the content database. Once at a point where it's ready for deployment, run SPSource against the project and pull everything into a pre-existing WSP. If changes are needed in the markup, make them using SPD, and re-run SPSource. The files in the WSP will be updated and ready for a solution upgrade.

Implement a class on an ASPX page (code behind) in SPD, and code that class in Visual Studio, or add custom server controls to the markup in SPD. Push your assembly directly to the GAC or bin as part of the build process, and the code-to-test time is much faster, as the markup files are already in the content database. Once everything is set, run SPSource again the project, and pull everything together into the WSP.

Add a custom Content Query Web Part (CQWP) .webpart file to the web part gallery, and change the properties and settings for the new CQWP via the UI and SPD to use custom XSL files that you add to the Style Library/XSL Style Sheets folder. Create new ItemStyles, change the Headers, or add new parameters to the Main XSL. The XSL files can be updated quickly using SPD, and changes can be seen right away. When all is ready for integration into the WSP, execute SPSource against the new files and create a new Feature for the new web part in minutes.

Create a complex List instance with Content Types and related Site Columns and reverse the whole lot out to a Feature to deployed to another environment as a Solution Package (wsp) using your favourite tool: VSeWSS, WSPBuilder or STSDev.

Handy extras

hook SPSource up to Visual Studio Projects

Walk throughs

Screencasts

Eventually, other Feature elements such as Workflow will be available. Please feel free to discuss other future features in the Discussions section!

Updated Wiki: Home

richfinn — Fri, 22 Jan 2010 16:03:08 GMT

Why use it over VSeWSS Solution Generator?

Example scenarios

Some examples of what can be done using SPSource:

Completely define a custom Publishing Feature using SPD and the SharePoint UI, creating the master pages, page layouts, content types, style sheets, and images directly in the content database. Once at a point where it's ready for deployment, run SPSource against the project and pull everything into a pre-existing WSP. If changes are needed in the markup, make them using SPD, and re-run SPSource. The files in the WSP will be updated and ready for a solution upgrade.

Implement a class on an ASPX page (code behind) in SPD, and code that class in Visual Studio, or add custom server controls to the markup in SPD. Push your assembly directly to the GAC or bin as part of the build process, and the code-to-test time is much faster, as the markup files are already in the content database. Once everything is set, run SPSource again the project, and pull everything together into the WSP.

Add a custom Content Query Web Part (CQWP) .webpart file to the web part gallery, and change the properties and settings for the new CQWP via the UI and SPD to use custom XSL files that you add to the Style Library/XSL Style Sheets folder. Create new ItemStyles, change the Headers, or add new parameters to the Main XSL. The XSL files can be updated quickly using SPD, and changes can be seen right away. When all is ready for integration into the WSP, execute SPSource against the new files and create a new Feature for the new web part in minutes.

Create a complex List instance with Content Types and related Site Columns and reverse the whole lot out to a Feature to deployed to another environment as a Solution Package (wsp) using your favourite tool: VSeWSS, WSPBuilder or STSDev.

Handy extras

hook SPSource up to Visual Studio Projects

Walk throughs

Screencasts

Eventually, other Feature elements such as Workflow will be available. Please feel free to discuss other future features in the Discussions section!

Updated Wiki: Home

richfinn — Wed, 06 Jan 2010 17:24:41 GMT

Why use it over VSeWSS Solution Generator?

Example scenarios

Some examples of what can be done using SPSource:

Completely define a custom Publishing Feature using SPD and the SharePoint UI, creating the master pages, page layouts, content types, style sheets, and images directly in the content database. Once at a point where it's ready for deployment, run SPSource against the project and pull everything into a pre-existing WSP. If changes are needed in the markup, make them using SPD, and re-run SPSource. The files in the WSP will be updated and ready for a solution upgrade.

Implement a class on an ASPX page (code behind) in SPD, and code that class in Visual Studio, or add custom server controls to the markup in SPD. Push your assembly directly to the GAC or bin as part of the build process, and the code-to-test time is much faster, as the markup files are already in the content database. Once everything is set, run SPSource again the project, and pull everything together into the WSP.

Add a custom Content Query Web Part (CQWP) .webpart file to the web part gallery, and change the properties and settings for the new CQWP via the UI and SPD to use custom XSL files that you add to the Style Library/XSL Style Sheets folder. Create new ItemStyles, change the Headers, or add new parameters to the Main XSL. The XSL files can be updated quickly using SPD, and changes can be seen right away. When all is ready for integration into the WSP, execute SPSource against the new files and create a new Feature for the new web part in minutes.

Create a complex List instance with Content Types and related Site Columns and reverse the whole lot out to a Feature to deployed to another environment as a Solution Package (wsp) using your favourite tool: VSeWSS, WSPBuilder or STSDev.

Handy extras

hook SPSource up to Visual Studio Projects

Walk throughs

Screencasts

Eventually, other Feature elements such as Workflow will be available. Please feel free to discuss other future features in the Discussions section!

Updated Wiki: Home

jthake — Sun, 22 Nov 2009 05:05:42 GMT

Why use it over VSeWSS Solution Generator?

Example scenarios

Some examples of what can be done using SPSource:

Completely define a custom Publishing Feature using SPD and the SharePoint UI, creating the master pages, page layouts, content types, style sheets, and images directly in the content database. Once at a point where it's ready for deployment, run SPSource against the project and pull everything into a pre-existing WSP. If changes are needed in the markup, make them using SPD, and re-run SPSource. The files in the WSP will be updated and ready for a solution upgrade.

Implement a class on an ASPX page (code behind) in SPD, and code that class in Visual Studio, or add custom server controls to the markup in SPD. Push your assembly directly to the GAC or bin as part of the build process, and the code-to-test time is much faster, as the markup files are already in the content database. Once everything is set, run SPSource again the project, and pull everything together into the WSP.

Add a custom Content Query Web Part (CQWP) .webpart file to the web part gallery, and change the properties and settings for the new CQWP via the UI and SPD to use custom XSL files that you add to the Style Library/XSL Style Sheets folder. Create new ItemStyles, change the Headers, or add new parameters to the Main XSL. The XSL files can be updated quickly using SPD, and changes can be seen right away. When all is ready for integration into the WSP, execute SPSource against the new files and create a new Feature for the new web part in minutes.

Create a complex List instance with Content Types and related Site Columns and reverse the whole lot out to a Feature to deployed to another environment as a Solution Package (wsp) using your favourite tool: VSeWSS, WSPBuilder or STSDev.

Handy extras

hook SPSource up to Visual Studio Projects

Walk throughs

Screencasts

Eventually, other Feature elements such as Workflow will be available. Please feel free to discuss other future features in the Discussions section!

New Comment on "hook SPSource up to Visual Studio Projects"

jthake — Tue, 05 May 2009 08:52:40 GMT

I guess the next step is to do something like WSPBuilder and integrate into the VS Project menu...another task ;-)

New Comment on "hook SPSource up to Visual Studio Projects"

Grumpy_Wookie — Tue, 05 May 2009 05:12:21 GMT

Very clever, I wonder if you could have a parameter for the site "url" - from somewhere within the solution - otherwise, would have to change the above settings for each project. (prompt for arguments ??)

Updated Wiki: hook SPSource up to Visual Studio Projects

jthake — Tue, 05 May 2009 05:05:45 GMT

You can get SPSource to run within the Visual Studio IDE and write messages out to the Output window by following these easy steps.

Select Tools | External Tools...from Visual Studio menu.

Click Add button

Set Name to : SPSource
Set Command to: C:\Program Files\SPSource\SPSource.exe
(NOTE: may differ if installed on x64 machine or if you changed default location)
Set Arguments to: -designsite http://server:81/
(NOTE: this will differ depending on the design site you are currently using
Set Initial Directory to: $(ProjectDir)

Updated Wiki: hook SPSource up to Visual Studio Projects

jthake — Tue, 05 May 2009 05:05:14 GMT

Updated Wiki: Home

jthake — Tue, 05 May 2009 05:02:49 GMT

Project Description
SPSource is a tool for SharePoint developers to assist in the creation of WSS Solution Packages (WSPs) allowing for the use SharePoint Designer and the SharePoint web UI to make quick changes to items, then push those items into Visual Studio for later compilation into a WSP for deployment to another site collection or farm.

Creating Features which contain custom Content Types or file provisioning modules requires developers to write a lot of XML based on the wss.xsd. Content types require custom columns and content type definition files, along with the proper creation of the content type IDs. File provisioning modules require the creation of module elements which contain the information that will help properly push the files into the correct lists when the Feature is activated.
More over, List Templates are am absolute pain to code from scratch with a simple Generic List Template with one column and one view having a schema.xml file well over 2500 lines long with the out of the box Features!

This XML can be fairly daunting, time consuming, and frankly, not very exciting for developers who just want to test their code. This holds especially true for developers who are writing custom Features based on SharePoint's Publishing Feature.

SPSource helps by alleviating the need for developers to write these files by allowing them to use the SharePoint UI and SharePoint Designer (SPD) as the source for the files defined in the module elements, along with custom content types, and is meant to be integrated with WSP creation tools such as WSPBuilder, STSDev, and the WSPProjectTemplate as part of the build process, but it can also be executed as a CMD or BAT file at the root of your project to get you moving quicker. Executing BEFORE the creation of the WSP, any file that can be created using SharePoint Designer in a document library, and any site content type created in the SharePoint UI can be targeted and pulled down into Visual Studio for addition in a new or pre-existing WSP project. SPSource will also create the file provisioning module and site Content Type/Column definition files. The only thing the developer is left with is to add the ElementManifest and ElementFile lines to the Feature.xml file.

Why use it over VSeWSS Solution Generator?
Solution Generator uses a different approach to reverse engineer List Templates using the RPC Web Services, which requires some XPATH hacking to remove some illegal attributes and add some needed elements. The SPSource approach is based on the documented schema and generates the required elements and attributes based on the targetted instances to provided a much cleaner end solution. One example of this is the fact that it will intelligently try and fix up same-site lookup columns to list within the schema.xml file to save having to create these in a programmatic fashion.

Some examples of what can be done using SPSource:

Completely define a custom Publishing Feature using SPD and the SharePoint UI, creating the master pages, page layouts, content types, style sheets, and images directly in the content database. Once at a point where it's ready for deployment, run SPSource against the project and pull everything into a pre-existing WSP. If changes are needed in the markup, make them using SPD, and re-run SPSource. The files in the WSP will be updated and ready for a solution upgrade.

Implement a class on an ASPX page (code behind) in SPD, and code that class in Visual Studio, or add custom server controls to the markup in SPD. Push your assembly directly to the GAC or bin as part of the build process, and the code-to-test time is much faster, as the markup files are already in the content database. Once everything is set, run SPSource again the project, and pull everything together into the WSP.

Add a custom Content Query Web Part (CQWP) .webpart file to the web part gallery, and change the properties and settings for the new CQWP via the UI and SPD to use custom XSL files that you add to the Style Library/XSL Style Sheets folder. Create new ItemStyles, change the Headers, or add new parameters to the Main XSL. The XSL files can be updated quickly using SPD, and changes can be seen right away. When all is ready for integration into the WSP, execute SPSource against the new files and create a new Feature for the new web part in minutes.

Create a complex List instance with Content Types and related Site Columns and reverse the whole lot out to a Feature to deployed to another environment as a Solution Package (wsp) using your favourite tool: VSeWSS, WSPBuilder or STSDev.

hook SPSource up to Visual Studio Projects
view file provision walkthrough
view content type walkthrough
view screencast demo
view listemplate screencast demo

Eventually, other Feature elements such as Workflow will be available. Please feel free to discuss other future features in the Discussions section!

Updated Wiki: Home

jthake — Mon, 04 May 2009 15:11:35 GMT

Project Description
SPSource is a tool for SharePoint developers to assist in the creation of WSS Solution Packages (WSPs) allowing for the use SharePoint Designer and the SharePoint web UI to make quick changes to items, then push those items into Visual Studio for later compilation into a WSP for deployment to another site collection or farm.

Creating Features which contain custom Content Types or file provisioning modules requires developers to write a lot of XML based on the wss.xsd. Content types require custom columns and content type definition files, along with the proper creation of the content type IDs. File provisioning modules require the creation of module elements which contain the information that will help properly push the files into the correct lists when the Feature is activated.
More over, List Templates are am absolute pain to code from scratch with a simple Generic List Template with one column and one view having a schema.xml file well over 2500 lines long with the out of the box Features!

This XML can be fairly daunting, time consuming, and frankly, not very exciting for developers who just want to test their code. This holds especially true for developers who are writing custom Features based on SharePoint's Publishing Feature.

SPSource helps by alleviating the need for developers to write these files by allowing them to use the SharePoint UI and SharePoint Designer (SPD) as the source for the files defined in the module elements, along with custom content types, and is meant to be integrated with WSP creation tools such as WSPBuilder, STSDev, and the WSPProjectTemplate as part of the build process, but it can also be executed as a CMD or BAT file at the root of your project to get you moving quicker. Executing BEFORE the creation of the WSP, any file that can be created using SharePoint Designer in a document library, and any site content type created in the SharePoint UI can be targeted and pulled down into Visual Studio for addition in a new or pre-existing WSP project. SPSource will also create the file provisioning module and site Content Type/Column definition files. The only thing the developer is left with is to add the ElementManifest and ElementFile lines to the Feature.xml file.

Why use it over VSeWSS Solution Generator?
Solution Generator uses a different approach to reverse engineer List Templates using the RPC Web Services, which requires some XPATH hacking to remove some illegal attributes and add some needed elements. The SPSource approach is based on the documented schema and generates the required elements and attributes based on the targetted instances to provided a much cleaner end solution. One example of this is the fact that it will intelligently try and fix up same-site lookup columns to list within the schema.xml file to save having to create these in a programmatic fashion.

Some examples of what can be done using SPSource:

Completely define a custom Publishing Feature using SPD and the SharePoint UI, creating the master pages, page layouts, content types, style sheets, and images directly in the content database. Once at a point where it's ready for deployment, run SPSource against the project and pull everything into a pre-existing WSP. If changes are needed in the markup, make them using SPD, and re-run SPSource. The files in the WSP will be updated and ready for a solution upgrade.

Implement a class on an ASPX page (code behind) in SPD, and code that class in Visual Studio, or add custom server controls to the markup in SPD. Push your assembly directly to the GAC or bin as part of the build process, and the code-to-test time is much faster, as the markup files are already in the content database. Once everything is set, run SPSource again the project, and pull everything together into the WSP.

Add a custom Content Query Web Part (CQWP) .webpart file to the web part gallery, and change the properties and settings for the new CQWP via the UI and SPD to use custom XSL files that you add to the Style Library/XSL Style Sheets folder. Create new ItemStyles, change the Headers, or add new parameters to the Main XSL. The XSL files can be updated quickly using SPD, and changes can be seen right away. When all is ready for integration into the WSP, execute SPSource against the new files and create a new Feature for the new web part in minutes.

Create a complex List instance with Content Types and related Site Columns and reverse the whole lot out to a Feature to deployed to another environment as a Solution Package (wsp) using your favourite tool: VSeWSS, WSPBuilder or STSDev.

view file provision walkthrough
view content type walkthrough
view screencast demo
view listemplate screencast demo

Eventually, other Feature elements such as Workflow will be available. Please feel free to discuss other future features in the Discussions section!

Updated Wiki: Home

jthake — Mon, 04 May 2009 15:01:10 GMT

Project Description
SPSource is a tool for SharePoint developers to assist in the creation of WSS Solution Packages (WSPs) allowing for the use SharePoint Designer and the SharePoint web UI to make quick changes to items, then push those items into Visual Studio for later compilation into a WSP for deployment to another site collection or farm.

Creating Features which contain custom Content Types or file provisioning modules requires developers to write a lot of XML based on the wss.xsd. Content types require custom columns and content type definition files, along with the proper creation of the content type IDs. File provisioning modules require the creation of module elements which contain the information that will help properly push the files into the correct lists when the Feature is activated.
More over, List Templates are am absolute pain to code from scratch with a simple Generic List Template with one column and one view having a schema.xml file well over 2500 lines long with the out of the box Features!

This XML can be fairly daunting, time consuming, and frankly, not very exciting for developers who just want to test their code. This holds especially true for developers who are writing custom Features based on SharePoint's Publishing Feature.

SPSource helps by alleviating the need for developers to write these files by allowing them to use the SharePoint UI and SharePoint Designer (SPD) as the source for the files defined in the module elements, along with custom content types, and is meant to be integrated with WSP creation tools such as WSPBuilder, STSDev, and the WSPProjectTemplate as part of the build process, but it can also be executed as a CMD or BAT file at the root of your project to get you moving quicker. Executing BEFORE the creation of the WSP, any file that can be created using SharePoint Designer in a document library, and any site content type created in the SharePoint UI can be targeted and pulled down into Visual Studio for addition in a new or pre-existing WSP project. SPSource will also create the file provisioning module and site Content Type/Column definition files. The only thing the developer is left with is to add the ElementManifest and ElementFile lines to the Feature.xml file.

Some examples of what can be done using SPSource:

Completely define a custom Publishing Feature using SPD and the SharePoint UI, creating the master pages, page layouts, content types, style sheets, and images directly in the content database. Once at a point where it's ready for deployment, run SPSource against the project and pull everything into a pre-existing WSP. If changes are needed in the markup, make them using SPD, and re-run SPSource. The files in the WSP will be updated and ready for a solution upgrade.

Implement a class on an ASPX page (code behind) in SPD, and code that class in Visual Studio, or add custom server controls to the markup in SPD. Push your assembly directly to the GAC or bin as part of the build process, and the code-to-test time is much faster, as the markup files are already in the content database. Once everything is set, run SPSource again the project, and pull everything together into the WSP.

Add a custom Content Query Web Part (CQWP) .webpart file to the web part gallery, and change the properties and settings for the new CQWP via the UI and SPD to use custom XSL files that you add to the Style Library/XSL Style Sheets folder. Create new ItemStyles, change the Headers, or add new parameters to the Main XSL. The XSL files can be updated quickly using SPD, and changes can be seen right away. When all is ready for integration into the WSP, execute SPSource against the new files and create a new Feature for the new web part in minutes.

Create a complex List instance with Content Types and related Site Columns and reverse the whole lot out to a Feature to deployed to another environment as a Solution Package (wsp) using your favourite tool: VSeWSS, WSPBuilder or STSDev.

Updated Wiki: Home

richfinn — Thu, 14 Aug 2008 14:02:00 GMT

Project Description
SPSource is a tool for SharePoint developers to assist in the creation of WSS Solution Packages (WSPs) allowing for the use SharePoint Designer and the SharePoint web UI to make quick changes to items, then push those items into Visual Studio for later compilation into a WSP for deployment to another site collection or farm.

Creating Features which contain custom Content Types or file provisioning modules requires developers to write a lot of XML based on the wss.xsd. Content types require custom columns and content type definition files, along with the proper creation of the content type IDs. File provisioning modules require the creation of module elements which contain the information that will help properly push the files into the correct lists when the Feature is activated.

This XML can be fairly daunting, time consuming, and frankly, not very exciting for developers who just want to test their code. This holds especially true for developers who are writing custom Features based on SharePoint's Publishing Feature.

SPSource helps by alleviating the need for developers to write these files by allowing them to use the SharePoint UI and SharePoint Designer (SPD) as the source for the files defined in the module elements, along with custom content types, and is meant to be integrated with WSP creation tools such as WSPBuilder, STSDev, and the WSPProjectTemplate as part of the build process, but it can also be executed as a CMD or BAT file at the root of your project to get you moving quicker. Executing BEFORE the creation of the WSP, any file that can be created using SharePoint Designer in a document library, and any site content type created in the SharePoint UI can be targeted and pulled down into Visual Studio for addition in a new or pre-existing WSP project. SPSource will also create the file provisioning module and site Content Type/Column definition files. The only thing the developer is left with is to add the ElementManifest and ElementFile lines to the Feature.xml file.

Some examples of what can be done using SPSource:

Completely define a custom Publishing Feature using SPD and the SharePoint UI, creating the master pages, page layouts, content types, style sheets, and images directly in the content database. Once at a point where it's ready for deployment, run SPSource against the project and pull everything into a pre-existing WSP. If changes are needed in the markup, make them using SPD, and re-run SPSource. The files in the WSP will be updated and ready for a solution upgrade.

Implement a class on an ASPX page (code behind) in SPD, and code that class in Visual Studio, or add custom server controls to the markup in SPD. Push your assembly directly to the GAC or bin as part of the build process, and the code-to-test time is much faster, as the markup files are already in the content database. Once everything is set, run SPSource again the project, and pull everything together into the WSP.

Add a custom Content Query Web Part (CQWP) .webpart file to the web part gallery, and change the properties and settings for the new CQWP via the UI and SPD to use custom XSL files that you add to the Style Library/XSL Style Sheets folder. Create new ItemStyles, change the Headers, or add new parameters to the Main XSL. The XSL files can be updated quickly using SPD, and changes can be seen right away. When all is ready for integration into the WSP, execute SPSource against the new files and create a new Feature for the new web part in minutes.

view file provision walkthrough
view content type walkthrough
view screencast demo

Eventually, other Feature elements such as Workflow and ListTemplate will be available, but for now, it's just Module and ContentType.

Updated Wiki: Home

richfinn — Tue, 12 Aug 2008 15:37:16 GMT

Project Description
SPSource is a tool for SharePoint developers to assist in the creation of WSS Solution Packages (WSPs) allowing for the use SharePoint Designer and the SharePoint web UI to make quick changes to items, then push those items into Visual Studio for later compilation into a WSP for deployment to another site collection or farm.

Creating Features which contain custom Content Types or file provisioning modules requires developers to write a lot of XML based on the wss.xsd. Content types require custom columns and content type definition files, along with the proper creation of the content type IDs. File provisioning modules require the creation of module elements which contain the information that will help properly push the files into the correct lists when the Feature is activated.

This XML can be fairly daunting, time consuming, and frankly, not very exciting for developers who just want to test their code. This holds especially true for developers who are writing custom Features based on SharePoint's Publishing Feature.

SPSource helps by alleviating the need for developers to write these files by allowing them to use the SharePoint UI and SharePoint Designer (SPD) as the source for the files defined in the module elements, along with custom content types, and is meant to be integrated with WSP creation tools such as WSPBuilder, STSDev, and the WSPProjectTemplate as part of the build process, but it can also be executed as a CMD or BAT file at the root of your project to get you moving quicker. Executing BEFORE the creation of the WSP, any file that can be created using SharePoint Designer in a document library, and any site content type created in the SharePoint UI can be targeted and pulled down into Visual Studio for addition in a new or pre-existing WSP project. SPSource will also create the file provisioning module and site Content Type/Column definition files. The only thing the developer is left with is to add the ElementManifest and ElementFile lines to the Feature.xml file.

Some examples of what can be done using SPSource:

Completely define a custom Publishing Feature using SPD and the SharePoint UI, creating the master pages, page layouts, content types, style sheets, and images directly in the content database. Once at a point where it's ready for deployment, run SPSource against the project and pull everything into a pre-existing WSP. If changes are needed in the markup, make them using SPD, and re-run SPSource. The files in the WSP will be updated and ready for a solution upgrade.

Implement a class on an ASPX page (code behind) in SPD, and code that class in Visual Studio, or add custom server controls to the markup in SPD. Push your assembly directly to the GAC or bin as part of the build process, and the code-to-test time is much faster, as the markup files are already in the content database. Once everything is set, run SPSource again the project, and pull everything together into the WSP.

Add a custom Content Query Web Part (CQWP) .webpart file to the web part gallery, and change the properties and settings for the new CQWP via the UI and SPD to use custom XSL files that you add to the Style Library/XSL Style Sheets folder. Create new ItemStyles, change the Headers, or add new parameters to the Main XSL. The XSL files can be updated quickly using SPD, and changes can be seen right away. When all is ready for integration into the WSP, execute SPSource against the new files and create a new Feature for the new web part in minutes.

Updated Wiki: content type walkthrough

richfinn — Tue, 12 Aug 2008 15:32:36 GMT

Creating a Content Type in a Feature is even eaiser than a file provisioner using SPSource.

For this example, I'll just create the files needed to create a Feature for the exisisting Welcome Page Content Type, but this feature is most beneficial when creating a custom Content Type, as yo can use the UI to create the new Content Type in a much shorter time than it takes to create the XML files needed for a new custom Content Type. Remember, we've got two site, one called 'design' and one called 'dev'. Design is where we create items using SPD and the UI, and dev is a mirror of servers further in the deployment cycle.

To start, I create a new file named WelcomePage.spsource

Next, I define the Content Type I want to get out of the Site Content Type list (only Site Content Types are available right now)

When I run SPSource (look at the previous walkthrough to see how) both the column definitions and the content type definitions are pulled down and added to the Visual Studio project. I got started on this part with a little help with code from Andrew Connell, so props go to him for saving me some time.

One of the benefits is that you can see that the Content Type definition file includes the Content Type ID from the design site, so this is somethign else you dont' have to worry about creating. This is important when coupled with a custom file provisioner that is based on your custom Content Types, as the modules created in SPSource will reference the Content Type ID of your custom Content Type.

All that's needed now is to add the files to the Feature.xml file, and when you deploy the WSP and activate the Feature in the dev site, the new content type will be available.

Updated Wiki: walkthrough

richfinn — Fri, 08 Aug 2008 07:49:39 GMT

SPSource Walkthrough

The first thing needed is to set up two site collections - one for design, and one for development. The design site is where changes are made via SPD and the UI, and the dev site is where the WSP is deployed.

design site

dev site

To illustrate a simple example, I'll create a new publishing layout page in the design site based on the Welcome Page content type.

The new page has now been added to the master page gallery as seen in SPD.

I'll add some markup, web part zones, and content placeholders to the page, and save it.

When I create a page in the SharePoint UI, the new page template is now available.

As shown in the UI:

In my Visual Studio project, which is based on STSDev, I'll add a new Feature (STSDev, WSP Builder, and WSPProjectTemplate all have been tested and work)

Now I'll add a new file named PublishingPages.spsource to the feature.

This file is nothing more than a stripped-down version of the file provisioning module that was needed before. I just set the Url of the list where the source file is, and add a File element for each file I want to bring down.

To execute SPSource, I have a CMD file at the root of my project that passes one parameter to the executable, the url of the design site.

Once executed, the both the file provisioning module and the files themselves will be located in the Feature folder. Sub-folders are possible, and multiple spsource files are allowed per folder. The source SharePoint files will be added to the same folder as the spsource file, and the file provisioning module will be placed at the root of the feature.

You can see that the file provisioning module contains the properties set in the document library.

And the source of the ASPX page is the same as what was created in SharePoint designer.

Next, I add the ElementManifest and ElementFile lines to the Feaure.xml file called CustomPublishingPages (only files at the Feature root are needed for WSPProjectTemplate)

When I deploy the WSP and activate the Feature, the new page layout is now available!

Updated Wiki: walkthrough

richfinn — Fri, 08 Aug 2008 07:47:22 GMT

SPSource Walkthrough

The first thing needed is to set up two site collections - one for design, and one for development. The design site is where changes are made via SPD and the UI, and the dev site is where the WSP is deployed.

design site

dev site

To illustrate a simple example, I'll create a new publishing layout page in the design site based on the Welcome Page content type.

The new page has now been added to the master page gallery as seen in SPD.

I'll add some markup, web part zones, and content placeholders to the page, and save it.

When I create a page in the SharePoint UI, the new page template is now available.

As shown in the UI:

In my Visual Studio project, which is based on STSDev, I'll add a new Feature (STSDev, WSP Builder, and WSPProjectTemplate all have been tested and work)

Now I'll add a new file named PublishingPages.spsource to the feature. This file is nothing more than a stripped-down version of the file provisioning module that was needed before. I just set the Url of the list where the source file is, and add a File element for each file I want to bring down.

To execute SPSource, I have a CMD file at the root of my project that passes one parameter to the executable, the url of the design site.

Once executed, the both the file provisioning module and the files themselves will be located in the Feature folder. Sub-folders are possible, and multiple spsource files are allowed per folder. The source SharePoint files will be added to the same folder as the spsource file, and the file provisioning module will be placed at the root of the feature.

You can see that the file provisioning module contains the properties set in the document library.

And the source of the ASPX page is the same as what was created in SharePoint designer.

Next, I add the ElementManifest and ElementFile lines to the Feaure.xml file called CustomPublishingPages (only files at the Feature root are needed for WSPProjectTemplate)

When I deploy the WSP and activate the Feature, the new page layout is now available!

Updated Wiki: walkthrough

richfinn — Fri, 08 Aug 2008 07:46:05 GMT

SPSource Walkthrough

The first thing needed is to set up two site collections - one for design, and one for development.

design site

dev site

To illustrate a simple example, I'll create a new publishing layout page based on the Welcome Page content type.

The new page has now been added to the master page gallery as seen in SPD.

I'll add some markup, web part zones, and content placeholders to the page, and save it.

When I create a page in the SharePoint UI, the new page template is now available.

As shown in the UI:

In my Visual Studio project, which is based on STSDev, I'll add a new Feature (STSDev, WSP Builder, and WSPProjectTemplate all have been tested and work)

Now I'll add a new file named PublishingPages.spsource to the feature. This file is nothing more than a stripped-down version of the file provisioning module that was needed before. I just set the Url of the list where the source file is, and add a File element for each file I want to bring down.

To execute SPSource, I have a CMD file at the root of my project that passes one parameter to the executable, the url of the design site.

Once executed, the both the file provisioning module and the files themselves will be located in the Feature folder. Sub-folders are possible, and multiple spsource files are allowed per folder. The source SharePoint files will be added to the same folder as the spsource file, and the file provisioning module will be placed at the root of the feature.

You can see that the file provisioning module contains the properties set in the document library.

And the source of the ASPX page is the same as what was created in SharePoint designer.

Next, I add the ElementManifest and ElementFile lines to the Feaure.xml file called CustomPublishingPages (only files at the Feature root are needed for WSPProjectTemplate)

When I deploy the WSP and activate the Feature, the new page layout is now available!

Updated Wiki: Home

richfinn — Fri, 08 Aug 2008 07:45:14 GMT

Project Description
SPSource is a tool for SharePoint developers to assist in the creation of WSS Solution Packages (WSPs) allowing for the use SharePoint Designer and the SharePoint web UI to make quick changes to items, then push those items into Visual Studio for later compilation into a WSP for deployment to another site collection or farm.

Creating Features which contain custom Content Types or file provisioning modules requires developers to write a lot of XML based on the wss.xsd. Content types require custom columns and content type definition files, along with the proper creation of the content type IDs. File provisioning modules require the creation of module elements which contain the information that will help properly push the files into the correct lists when the Feature is activated.

This XML can be fairly daunting, time consuming, and frankly, not very exciting for developers who just want to test their code. This holds especially true for developers who are writing custom Features based on SharePoint's Publishing Feature.

SPSource helps by alleviating the need for developers to write these files by allowing them to use the SharePoint UI and SharePoint Designer (SPD) as the source for the files defined in the module elements, along with custom content types, and is meant to be integrated with WSP creation tools such as WSPBuilder, STSDev, and the WSPProjectTemplate as part of the build process, but it can also be executed as a CMD or BAT file at the root of your project to get you moving quicker. Executing BEFORE the creation of the WSP, any file that can be created using SharePoint Designer in a document library, and any site content type created in the SharePoint UI can be targeted and pulled down into Visual Studio for addition in a new or pre-existing WSP project. SPSource will also create the file provisioning module and site Content Type/Column definition files. The only thing the developer is left with is to add the ElementManifest and ElementFile lines to the Feature.xml file.

Some examples of what can be done using SPSource:

Completely define a custom Publishing Feature using SPD and the SharePoint UI, creating the master pages, page layouts, content types, style sheets, and images directly in the content database. Once at a point where it's ready for deployment, run SPSource against the project and pull everything into a pre-existing WSP. If changes are needed in the markup, make them using SPD, and re-run SPSource. The files in the WSP will be updated and ready for a solution upgrade.

Implement a class on an ASPX page (code behind) in SPD, and code that class in Visual Studio, or add custom server controls to the markup in SPD. Push your assembly directly to the GAC or bin as part of the build process, and the code-to-test time is much faster, as the markup files are already in the content database. Once everything is set, run SPSource again the project, and pull everything together into the WSP.

Add a custom Content Query Web Part (CQWP) .webpart file to the web part gallery, and change the properties and settings for the new CQWP via the UI and SPD to use custom XSL files that you add to the Style Library/XSL Style Sheets folder. Create new ItemStyles, change the Headers, or add new parameters to the Main XSL. The XSL files can be updated quickly using SPD, and changes can be seen right away. When all is ready for integration into the WSP, execute SPSource against the new files and create a new Feature for the new web part in minutes.

view file provision walkthrough
view content type walkthrough

Eventually, other Feature elements such as Workflow and ListTemplate will be available, but for now, it's just Module and ContentType.

Updated Wiki: Home

richfinn — Fri, 08 Aug 2008 07:41:45 GMT

Project Description
SPSource is a tool for SharePoint developers to assist in the creation of WSS Solution Packages (WSPs) allowing for the use SharePoint Designer and the SharePoint web UI to make quick changes to items, then push those items into Visual Studio for later compilation into a WSP for deployment to another site collection or farm.

Creating Features which contain custom Content Types or file provisioning modules requires developers to write a lot of XML based on the wss.xsd. Content types require custom columns and content type definition files, along with the proper creation of the content type IDs. File provisioning modules require the creation of module elements which contain the information that will help properly push the files into the correct lists when the Feature is activated.

This XML can be fairly daunting, time consuming, and frankly, not very exciting for developers who just want to test their code. This holds especially true for developers who are writing custom Features based on SharePoint's Publishing Feature.

SPSource helps by alleviating the need for developers to write these files by allowing them to use the SharePoint UI and SharePoint Designer (SPD) as the source for the files defined in the module elements, along with custom content types, and is meant to be integrated with WSP creation tools such as WSPBuilder, STSDev, and the WSPProjectTemplate as part of the build process, but it can also be executed as a CMD or BAT file at the root of your project to get you moving quicker. Executing BEFORE the creation of the WSP, any file that can be created using SharePoint Designer in a document library, and any site content type created in the SharePoint UI can be targeted and pulled down into Visual Studio for addition in a new or pre-existing WSP project. SPSource will also create the file provisioning module and site Content Type/Column definition files. The only thing the developer is left with is to add the ElementManifest and ElementFile lines to the Feature.xml file.

Some examples of what can be done using SPSource:

Completely define a custom Publishing Feature using SPD and the SharePoint UI, creating the master pages, page layouts, content types, style sheets, and images directly in the content database. Once at a point where it's ready for deployment, run SPSource against the project and pull everything into a pre-existing WSP. If changes are needed in the markup, make them using SPD, and re-run SPSource. The files in the WSP will be updated and ready for a solution upgrade.

Implement a class on an ASPX page (code behind) in SPD, and code that class in Visual Studio. Push your assembly directly to the GAC or bin as part of the build process, and the code-to-test time is much faster, as the markup files are already in the content database. Once everything is set, run SPSource again the project, and pull everything together in the WSP.

Add a custom Content Query Web Part (CQWP) web part file to the web part gallery, and change the settings for the new CQWP to use custom XSL files that you add to the Style Library/XSL Style Sheets folder. Create new ItemStyles or add new parameters to the Main xsl. The XSL files can be updated quickly using SPD, and changes can be seen right away. When all is ready for integration into the WSP, execute SPSource against the new files and create a new Feature for the new web part in minutes.

view file provision walkthrough
view content type walkthrough

Eventually, other Feature elements such as Workflow and ListTemplate will be available, but for now, it's just Module and ContentType.

Updated Wiki: Home

richfinn — Fri, 08 Aug 2008 07:35:26 GMT

Project Description
SPSource is a tool for SharePoint developers used to assist in the creation of WSS Solution Packages (WSPs) allowing for the use SharePoint Designer and the SharePoint web UI to make quick changes to items, then push those items into Visual Studio for compilation into the WSP for deployment to another site collection.

Creating Features which contain custom Content Types or file provisioning modules requires developers to write a lot of XML based on the wss.xsd. Content types require custom columns and content type definition files, along with the proper creation of the content type IDs. File provisioning modules require the creation of module elements which contain the information that will help properly push the files into the correct lists when the Feature is activated.

This XML can be fairly daunting, time consuming, and frankly, not very exciting for developers who just want to test their code. This holds especially true for developers who are writing custom Features based on SharePoint's Publishing Feature.

SPSource helps by alleviating the need for developers to write these files by allowing them to use the SharePoint UI and SharePoint Designer (SPD) as the source for the files defined in the module elements, along with ustom content types, and is meant to be integrated with WSP creation tools such as WSPBuilder, STSDev, and the WSPProjectTemplate as part of the build process, but it can also be executed as a CMD or BAT file at the root of your project to get you moving quicker. Executing before the creation of the WSP, any file that can be created using SharePoint Designer in a document library, and any site content type created in the SharePoint UI can be targeted and pulled down into Visual Studio for addition in a new or pre-existing WSP project. SPSource will also create the file provisioning module and site Content Type/Column definition files. The only thing the developer is left with is adding the ElementManifest lines to the Feature.xml file.

Some examples of what can be done using SPSource:

Completely define a custom Publishing Feature using SPD and the SharePoint UI, creating the master pages, page layouts, content types, style sheets, and images directly in the content database. Once at a point where it's ready for deployment, run SPSource against the project and pull everything into a pre-existing WSP. If changes are needed in the markup, make them using SPD, and re-run SPSource. The files in the WSP will be updated and ready for a solution upgrade.

Implement a class on an ASPX page (code behind) in SPD, and code that class in Visual Studio. Push your assembly directly to the GAC or bin as part of the build process, and the code-to-test time is much faster, as the markup files are already in the content database. Once everything is set, run SPSource again the project, and pull everything together in the WSP.

Add a custom Content Query Web Part (CQWP) web part file to the web part gallery, and change the settings for the new CQWP to use custom XSL files that you add to the Style Library/XSL Style Sheets folder. Create new ItemStyles or add new parameters to the Main xsl. The XSL files can be updated quickly using SPD, and changes can be seen right away. When all is ready for integration into the WSP, execute SPSource against the new files and create a new Feature for the new web part in minutes.

view file provision walkthrough
view content type walkthrough

Eventually, other Feature elements such as Workflow and ListTemplate will be available, but for now, it's just Module and ContentType.