SharePointers

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.

Some good free training info: RAMP UPs: http://msdn.microsoft.com/en-us/rampup/dd221355.aspx These seem pretty helpful. I'm most interested in the workflow (since it's been a while since I've done WF development in SP and SilverLight, because that's just so darn cool. Social Networking features of SharePoint: http://www.microsoft.com/events/series/detail/webcastdetails.aspx?seriesid=92&webcastid=5448 Chances are, unless you're brand new to MOSS, you've probably seen everything in the first 10 minutes, so skip ahead and get to the AdventureWorks demo.

I had a page layout that I liked, but I needed a slightly different version, so I copied the original, made my edits, redeployed my solution and provisioned a page with the new layout. BAM! A big fat error: Only Content controls are allowed directly in a content page that contains Content controls. Whats the deal? Everything looked exactly like the previous, working layout... or so I thought. The copy and paste apparently changed some of the <asp:Content> controls to <asp:content>, which SharePoint does not like. Re-capitalizing my tags fixed the issue.

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.

Sure you can dig all over the 12 hive looking for content type IDs. In fact, you should probably do it at least once to get an idea of what SharePoint does and what files it uses, but after you've done that. Here's the easy way .

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...

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 ...

When mixing html tags and SharePoint controls, like in a custom master page or page layout for example, it's easy to make the following mistake: <img src="<% $SPUrl:~SiteCollection/Style%20Library/MyImage.gif%>" /> Why won't this work? This doesn't work because the inline code is in a standard html tag and not a server control, and it doesn't get evaluated when the page is parsed, so the entire inline expression is just interpreted as a literal string. When this happens, you'll get this error: Literal expressions like ' ' are not allowed. I know this is .Net 101, but if you aren't paying attention it's easy to overlook. So... don't forget to either use server controls, or specify a runat="server" attribute for your html tags.