SharePointers

I found there are a lot of instructions on how to create web services but not many that give a best practices approach to doing this inside your solution in a way that is easy to repeat (like when you create new web methods in your custom web service and you don't want to manually re-edit all the wsdl and disco junk). First, you need to download two things to follow along: STSDEV WSS Web Service Helper Next, follow these steps: Create a new project in STSDEV, use the empty project C# assembly Add a new Web Service Application Project to your solution Add your web method to your web service. (If you just want to test this out, the default HelloWorld will work) Run the WSS Web Service Helper against your .asmx file (in your web service project). This will autogenerate your wsdl and disco .aspx files. Copy the .asmx file and the .cs codebehind (your webservice) and the two .aspx files generated by the WSS Web Service Helper and place them into your Rootfiles/ISAPI folder in your STSDe...

I was having a problem where my images in a folder in my RootFiles\Template\Layout\[ProjectName] directory of a feature solution were not being added to my wsp (or .cab) file when I did a build. After much headscratching I have found that the headscratchingly strange solution is that you need to keep the AfricanPith image in there. If I can figure out why this is, from looking at the code, I'll post the code fix.

My new development machine is 64bit and STSDEV has a few things that need to be fixed in order for it to work on 64bit machines - see my $(ProgramFiles) post. The problem I'm talking about here surfaces when you do a DebugRefreshAssemblyInGAC build. Apparently the .vbs script that the $(ISSAPP_SCRIPT) token in the DebugRefreshAssemblyInGAC section is referring to (C:\windows\system32\iisapp.vbs), will not run until you make CScript your default script environment for *.vbs scripts. In order to fix the errors STSDEV gives you follow these steps: Go to C:\Windows\System32 and copy cscript.exe and iisapp.vbs Place the files in another folder (I used 'C:\Utilities\Builds' as you see below) alter your DebugRefreshAssemblyInGac to read as follows <Target Name="DebugRefreshAssemblyInGac" > <Message Text="(Re)installing assembly in GAC and recycling app pool" Importance="high" /> <Exec Command="$(GACUTIL) -if $(TargetPath)...

We've tried our best to document as many gotchas as we've found while working with STSDEV, but we've never done a list as thoroughly as Jian Sun's post . Check it out as it's definitely worth the read.

I just created a development machine that is 64bit. In order to keep using STSDEV you have to go into your build targets and change the $(ProgramFiles) token to the actual hard-coded path of your program files directory, otherwise it defaults to the 32 bit program files directory. Just do a find and replace.

STSDEV uses the MakeCab executable to build its .cab/.wsp solution files. Unfortunately, MakeCab has some holdover default settings from the dark ages of computing, one of which is its generated filesize maximum, which is set to 1.44Mb. This hasn't been a problem for me, as most packages tend to be fairly lightweight. However, when deploying a solution with lots of binary resources (a masterpage or layouts feature, for example), you will need to tell STSDEV and MakeCab that you want to build a bigger file. Deploying without making the adjustments will result in an incredibly unhelpful error from STSADM: The file manifest.xml does not exist in the solution package . A blogger at PointBridge was nice enough to document this here , but the fix is fairly simple so I've added the code below. To fix your solution packages, you'll need the source for STSDEV. Open the file \STSDev\Core\Builders\DeploymentFiles\CabDdfBuilder.cs , and enter the following at the end of the .ddf s...

I've been banging my head for a few days trying to debug a feature receiver that I built and deployed using STSDEV. After scouring the web I found lots and lots of questions, and typically the same, incomplete, answer. To get things to work, this is what I had to do: In VS2008, click on Project->Settings->Debug. When you get to the debug settings for your project, you'll notice each of your build targets in a dropdown at the top of the page. Select a target and then scroll and click the 'Advanced' button. By default, STSDEV doesnt generate a PDB for most of its build targets, so you'll want to change the "Debug Info" drop-down selection to "full". Repeat for each build target that you need debug info to be generated for (at least DebugDeploy and DebugRedeploy). Build and deploy your solution using one of the targets you changed above. Map a drive to \\machinename\c$\windows\assembly. This allows you to see the file structure of the G...

After spending a looong time trying to figure out why my code behind for my page layout wasn't updating after making a simple change and doing an STSDEV Release build, I found out the hard way that you have to do a DebugBuild before you do a ReleaseBuild, otherwise it won't update the dll. Save yourself some frustration and add this to your list of todos each time you do a release in STSDEV. Thanks to fellow SharePointers blogger Grant for providing with technical/emotional guidance as I troubleshooted this issue.

I recently created a Web Part based on the STSDEV Web Part project and found it was very simple to use. I had another Web Part to create but this time I decided to go with the more generic 'Empty Solution' project just to ensure I wasn't getting lazy with all the stuff STSDEV does for me. The project built, and installed properly into the solution store, but doing a 'DebugDeploy' failed with an error. I compared the two projects and they seemed to be configured identically. However upon further inspection, I found that the 'DebugDeploy' section of the Web Part Project (STS DEV generated) is different than the 'DebugDeploy' section of the empty solution. changing this line: <Exec Command="$(STSADM) -o deploysolution -name $(PackageName) -immediate -allowgacdeployment" /> to: <Exec Command="$(STSADM) -o deploysolution -name $(PackageName) -immediate -allowgacdeployment -allcontenturls" /> solved the problem. NOTE:...

So we're upgrading to VS 2008 and, according to the configuration screen in STSDEV you can create STSDEV projects in .NET 3.0 for VS 2008. So we installed VS2008, added STSDEV as an external tool and created a test Workflow Project. The project was created fine but when STSDEV tried to build the project it crashed. We eventually discovered that the error was related to the fact that STSDEV was creating the .csproj file with the following line: <Import Project="$(MSBuildExtensionsPath)\Microsoft\Windows Workflow Foundation\v3.0\Workflow.Targets" /> instead of: <Import Project="$(MSBuildExtensionsPath)\Microsoft\Windows Workflow Foundation\ v3.5 \Workflow.Targets" /> You can manually go into your .csproj file and change this and your solution should build. We're looking into modifying the STSDEV code to rebuild the project so that it will do this automatically, but until we figure that out and get it blogged, here's your quick fix.

I was working on a STSDev project which deployed a feature with a feature receiver. I had the feature working without the FeatureReceiver but as soon as I added the FeatureReceiver related attributes to my <Feature> element I got the following error: Failed to create feature receiver object from assembly "Org.Project.Solution, Version=1.0.0.0, Culture=neutral, PublicKeyToken=c632353d405b3209", type "Org.Project.Solution.MyFeature.FeatureReceiver" for feature 6a9b2358-ea4e-486d-a4e4-4f813c52ce88: System.ArgumentNullException: Value cannot be null. Parameter name: type at System.Activator.CreateInstance(Type type, Boolean nonPublic) at System.Activator.CreateInstance(Type type) at Microsoft.SharePoint.Administration.SPFeatureDefinition.get_ReceiverObject() After much digging around I discovered that STSDEV's Solution config file refers to a namespace as well as the dll. My FeatureReceiver's namespace was not prefixed with the right namespace So just...

Both STSDEV and VSeWSS are very useful tools that, in their own way, give you more simplified elegant development. STSDEV is great in that it gives you a clean, class library project structure so that you have lots of control over your project. VSeWSS on the other hand is a customized solution template that allows you to automatically add in all the necessary files for common WSS elements (lists, content types, etc). I really like the ease of using VSeWSS, but I prefer the project structure of STSDEV. My solution is quite simple. Create your Solution with STSDEV (I usually start with a Empty C# solution with assembly) and then add in a VSeWSS project once you have the STSDEV generated solution open. I basically just use the VSeWSS project as a file generator and once the files are created, I copy them over to the STSDEV project and begin customization from there. The only thing you really have to remember is to copy the Attributes.cs file from the Properties folder in the VSeWS...

I was in the process of blogging about creating workflow features in STSDEV (1.2) when I realized that STSDEV 1.3 is now released! I'm going to redo my post using STSDEV 1.3 to see if it simplifies things.

This next tutorial will show you how to create a page layout. I have to admit that the bulk of the content of this tutorial comes from a tutorial written here , however, there are a few errors in the example code provided and also STSDEV requires a few minor changes as well to get everything working. In addition, I'll try to elaborate on a few more things so that you get a better understanding. Now let's dig in. Introduction If you have no experience with page layouts (and Master Pages), I suggest you read the Page Layouts and Master Pages page on MSDN . In short, page layouts allow you to customize the layout and appearance of content and web parts of pages within a MOSS publishing site. These pages are stored in a special Master Page and Page Layouts document library. Pages that are based off these Page Layouts will be stored in a 'Pages' document library at the root of the site. The nice thing about using the publishing infrastructure is that it lets you sav...

I plan to write a start to finish tutorial on using STSDEV to create a simple page layout and feature receiver, but I don't have the time to do it right now and I wanted to share this tip: When you are creating a feature that contains a page layout and you want that page layout to be copied over to your server, ensure you include the .aspx page as an <ElementFile> element into your feature.xml file. If you are hand writing your own manifest, you don't have to do it, but if you want STSDEV to do it for you you'll need this element.

If you've gotten sufficiently comfortable generating solutions with STSDEV, you've probably found that debugging doesn't seem to work. The reason is because the DebugBuild configuration is the only configuration that includes Debug code. Here's how to set up your project so that you can debug the other builds: Go to your Project Properties, click the 'Build' tab and turn on 'Define DEBUG Constant' and 'Define TRACE Constant'. Then click on the 'Advanced' button at the bottom of the Build configuration screen and change the 'Debug Output' value to 'full'. This tip came from the STSDEV discussion forum .

Today we'll be a adding a custom content type to our site definition we created in this post . The project that we're working with is an STSDEV project, so my project file structure reflects that. If you aren't using STSDEV you may need to make a few modifications. If you don't know what custom content types are, here's a good overview . The content type we develop here will extend the Document content type. We'll call it a Project Proposal. Now let's get to work. Step 1: Project Set up Aside from basing this project on the site definiton I created earlier, we'll need to add the Feature folders that reflect the structure on the server. Right click on the TEMPLATE folder in your project and choose 'Add New Folder', name this folder 'FEATURES'. Then add a folder under 'FEATURES' called 'ProjectProposalContentTypes'. Step 2: The feature definition file Since we want to deploy this as a feature we'll need to create the fe...

This is my second post on creating SharePoint solutions the easy way, with STSDEV. This time around I'll be enhancing my last post's project by adding a custom master page. This master page will start by using a base master page from Heather Solomon's site . If you don't already have it, download it. The base master page simply gives you a stripped down master page that you can enhance. We'll actually do some enhancements to give a taste of the power that you have over the UI when you choose to customize a master page. Step 1: Add the base master page to the project If you haven't already done so, download and unzip the base master page from Heather Solomon's site. Right click on your 'RootFiles\TEMPLATE\SiteTemplates\YourSiteTemplateName' directory and choose 'Add Existing Item' Select the base master page from your file system and click 'Add' Rename the file 'SharePointersDemoCustom.master'. Step 2: Editing the Defa...

In this post I'll give a basic overview of how to create a simple site definition using STSDEV. The purpose of using STSDEV is to give the project a standardized structure and to make use of the solution autogeneration. Here are the steps (Make sure you've downloaded STSDEV and run through the tutorials , or understanding this might be tough) Part 1: Generate the STSDEV solution Open Visual Studio and run STSDEV (should be an option on your tools menu if you ran through the tutorials, see above link) Choose to create an empty solution with C# assembly Click 'Create the Solution' After you create the solution, you'll need to open it from the file system. STSDEV does not automatically open it for you in Visual Studio. Part 2: Set up the project structure Even the most basic site definition needs at least 3 files: a webtemp.xml file, an onet.xml file, and a default.aspx file. So let's create these files in the appropriate places. right click on the 'Root...

I've begun using STSDEV as the start for my projects instead of VSeWSS. I like the simplicity of it, especially as Ted Pattison says in his first of three screencasts that you can load it into any installation of Visual Studio (that corresponds to the project type you created) because you don't rely on Add-ins/Extensions. After running through the screencasts, I decided it was time to do the solution release build and I ran into immediate trouble with a "ERROR: Could not find file DeploymentFiles\SoulutionPackage.ddf ..." error message in the Output Window. The solution, found on the STSDEV discussion board , is as follows: Modify the "ReleaseBuild" target in the DeploymentFiles\Microsoft.SharePoint.targets file as below (fix highlighted in bold red ): <target name="ReleaseBuild"> <message text="Deleting Pacakge File..." importance="high"> <delete files="$(ProjectDeploymentFilesFolder)\$(PackageFile)...