SharePointers

A while back I created several page layouts for my company so that we would have a standard format for pages, news stories, etc. We really hadn't had any problems until one of our news stories had a '+' in it's title, and thus the suggested filename had a '+' in it. Apparently you are allowed to create a page with the special character '+' in it, but it will break your page. The behavior we saw was that you could see all the page content in edit mode, but none of it would show up when it was checked in/published. Also, there was some odd rendering of the page in edit mode. I was scratching my head over this for a while and pretty much randomly stumbled onto the solution. In the future, I'd suggest removing any non alpha-numeric characters from file names just to be safe, even though SharePoint doesn't warn you or remove them.

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.

SPFile.MoveTo(), at first glance, looks to be a very straightforward method where a file can be moved from one folder to another. Trying to use it and have an alert triggered by your newly copied file? Forget it. MoveTo() copies the binary to the target library as expected, but fails to recreate the item metadata (created, modified, users, dates, etc.) and will not trigger the alerts that your users set up for the target library. To work around this problem, you can create your own method that uses the SPFileCollection.Add(), which allows you to specify metadata, as described here: http://www.u2u.info/Blogs/Patrick/Lists/Posts/Post.aspx?ID=1141

Most of the time when we create a web service, we get to dictate what the final WSDL will look like and we use that in our application or provide it to other members on a team to consume. A current project I'm working on requires me to create a web service based on an established WSDL that would be consumed by another service. In order for there to be interoperability between the 2, my WSDL and the reference WSDL had to be identical. I went about creating the proxy class using WSDL.exe as I normally would and had my simple service up and running in about 5 minutes. When the external service tried to connect to mine, there was the " Server did not recognize the value of HTTP Header SOAPAction" error . Upon closer examination, my WSDL was identical to theirs with one exception: soap:operation soapAction =" FaultyAction " style =" document " /> Should have been: soap:operation soapAction ="" style =" document " /> After ...

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.

When checking in an item in a custom list, I was being presented with the following error: Value does not fall within the expected range. at Microsoft.SharePoint.SPFieldCollection.GetFieldByInternalName(String strName, Boolean bThrowException) at Microsoft.SharePoint.SPFieldCollection.GetFieldByInternalName(String strName) at Microsoft.SharePoint.SPListItem.get_MissingRequiredFields() at Microsoft.SharePoint.ApplicationPages.Checkin.OnLoad(EventArgs e) at System.Web.UI.Control.LoadRecursive() at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) After much head-scratching and nightmarish debugging, I found that the answer was very simple: Do not have the "Required" attribute set to true in your content type definition, but rather specify this in your custom list schema. Hope this helps!

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.