Jan Tanis

Last week I struggled again with (some of the most unpredictable features within the the SharePoint code base:) SPWebConfigModification. I just couldn't apply multiple mods at once. So after few hours of trial and error I discovered that this was the solution:

BAD CODE (will apply only 1 mod):

SPFarm.Local.Services.GetValue().ApplyWebConfigModifications();
webApplication.Update();

GOOD CODE (will apply all mods):

webApplication.Update();
SPFarm.Local.Services.GetValue().ApplyWebConfigModifications();

So the punchline is that the sequence of the method calling does matter!

It seems to be that some companies do not have an Microsoft Exchange server and rely on other mail systems (like Lotus Domino server) for their corporate email. Recently I was asked at such a company if it is possible to have incoming email enabled on SharePoint without an Exchange server. After a day of research I had to conclude: YES, it's possible! It's not that hard either too!

What do you need to do:

1. Point a MX (mail relay) DNS record to the SharePoint server. For example wss.company.com. This is because all email will have to be delivered to the SharePoint server.
2. Enable SMTP on your server http://www.itsolutionskb.com/2008/11/installing-and-configuring-windows-server-2008-smtp-server/
   
   
3. Configure incoming email on the SharePoint server with the following settings:
   

This should make it work. However when I tried it my drop folder kept getting cleaned (by the timer job) but the mail never appeared in the list. I played around with some settings and found these working:

While doing some development on SharePoint solution deployment I encountered a strange behaviour. The following code gave me the "FormatException:Guid should contain 32 digits with 4 dashes" error:

SPFarm.Local.Solution["demo.wsp"].DeployedWebApplications;

Strange as I'm not even using a GUID in my code here. So a little breaking down led me to the conclusion that if you call the DeployedWebApplications property on a solution that is globally deployed you get this error.

A few months ago I figured out how to build STSDEV projects with Team Foundation Server. So here is the result step-by-step (only the steps that differ from the default project steps):

A few months ago I figured out how to build STSDEV projects with Team Foundation Server. So here is the result step-by-step (only the steps that differ from the default project steps):

Adjust the target of the solution to DebugBuild. If you are only building STSDEV projects you can do this at once by changing following lines in TFSBuild.proj file:

<configurationtobuild include="Debug|Any CPU"></configurationtobuild>

to:

<configurationtobuild include="DebugBuild|Any CPU"></configurationtobuild>

or per solution:

<solutiontobuild include="$(BuildProjectFolderPath)/../../ExampleSolution.sln"></solutiontobuild><targets></targets><properties>Configuration=DebugBuild;Platform=Any CPU</properties></solutiontobuild>

Change the DebugBuild in the Microsoft.SharePoint.targets file and make it like this:

<pre name="code" class="xml"><target name="DebugBuild">

<copy condition="'$(IsDesktopBuild)'=='false'" destinationfolder="$(SolutionDir)bin\debug" sourcefiles="$(OutDir)$(TargetName).dll"></copy>

...

<copy condition="'$(IsDesktopBuild)'=='false'" destinationfolder="$(OutDir)" sourcefiles="$(SolutionDir)DeploymentFiles\$(PackageName)"></copy>

</target>

Override path to STSDEV for the build on the server (TFSBuild.proj):

<custompropertiesforbuild>STSDEV="C:\Software\STSDev v1.3\stsdev.exe"</custompropertiesforbuild>

Once this is done you can build your STSDEV projects on the TeamBuild server. Have fun!