Mobile Views in SharePoint 2010

About Mobile Views:
Mobile views is the out-of-the-box feature of SharePoint 2010 which helps render pages on various mobile devices. Basically mobile view is a standard SharePoint list view.
Hence, in mobile view all the pages, appear as sequence of links.
The supported mobile devices are defined in compat.browser file.

How does it work?

When a SharePoint site is accessed from a mobile device, the mobile device browser submits the HTTP GET request to the SharePoint server. In this request a User Agent parameter is set which denotes the browser of the client machine. SharePoint parses this User Agent string and determines if the client is a mobile device. If it is mobile device then it redirects the requests automatically to mobile view.
SharePoint uses compat.browser file as a metadata for supported browsers.

Problem:
Although, the default mobile view works well for intranet sites, it lacks the UI customizations for Internet facing sites.
Mobile view often consist of sequence of links listed one below another without any custom styles.

Solution:
There are ways to customize SharePoint mobile view. But a quick fix for this is to set isMobileDevice flag to false. This basically disables the default mobile view redirection and simply renders default view.

To implement this, go to
C:\inetpub\wwwroot\wss\VirtualDirectories\80\App_Browsers\compat.browser

Locate the mobile browser you wish to disable.
e.g. If you want to disable mobile view for iPad,
then locate the element <browser id="iPadSafari" parentID="AppleSafari">

And set isMobileDevice to false in capability element under browser element as follows:
<capability name="isMobileDevice" value="false" />

Thats it. This will stop requests from iPad being redirected to default mobile view.
There are however better ways to fix this problem. I will blog on it later.

Fiddle the web with Fiddler

About Fiddler:
Fiddler is a very handy and powerful tool in web debugging, analyzing and troubleshooting. I was able to resolve many of the MOSS issues within minutes which otherwise would have taken lot of effort and time. Thanks to my friend in Microsoft who recommended me to use Fiddler.

Although, I used Fiddler heavily for MOSS, Fiddler can used with any web page regardless of the web technology used. So you can use it with ASP.NET or JSP site the same way.


Fiddler is available at:

http://www.fiddler2.com/fiddler2/version.asp
 
Once you install fiddler, it is very easy to start your debugging. Videos and demos can be found at above site.

Uses of Fiddler:
1. To measure performance of the web page on client browser:

Fiddler trace gives you analysis of every single element downloaded and loaded on the web page. So it is very easy to Pin Point the heavy-weights on your page. Fiddler gives a nice graph for this. You can easily figure out which image or script is taking a lot of time.

2. To debug:

Fiddler gives facilities to view the HTTP form and script parameter. With this you can easily debug errors on the web page. For example, you can trace down a wrong value sent during HTTP Postback, view and resolve missing images at client end, common 404-Page Not Found errors, hard-to-trace wrong redirect from MOSS web part etc.

CAS Trusted MOSS Web Parts

.NET provides a CAS (Code Access Security) as an addition to role based security. CAS restricts external activities of code and controls the way code can be reused or invoked. In this blog post we will look at web part deployment options and where CAS can be used to implement a secure web part deployment pattern.

Introduction to CAS:

A good introduction to CAS can be found at:
http://msdn.microsoft.com/en-us/library/aa302424.aspx#c08618429_002

CAS infrastructure in MOSS/WSS:
MOSS being an ASP.NET based application has its own extended implementation of CAS. In fact, MOSS/WSS minimum trust policy is an extended version of ASP.NET CAS minimum trust policy with additions to allow web part connections. CAS can configured in MOSS just like a .NET application.
 
There are two options to deploy web part:

1. Bin Directory of the Virtual Server - This is more restrictive
2. GAC of the web server – This is less restrictive

Following is a comparison matrix for both the deployment options:

	Bin Directory	GAC
Execution Mode	More restrictive execution. Access to most resources denied	More trusted execution with access to many resources granted by default
Configuration Required	Create a CAS policy and set the trust level of web part in order to make it work	Need to set configuration of web part entry in web.config

Choosing one of the two options:
Bin directory should be used when:

• Web Part code is not trusted. E.g. Third party web parts 
• To ensure that the web part works regardless of server settings and deployment method. E.g. a web part vendor may opt for this

GAC should be used when:

• Web part code is trusted
• Intranet sites where risk of an attack is less

Recommended Method for web part deployment:
Microsoft recommends to deploy web part to Bin directory of the virtual server and set the appropriate CAS policy.

Although use of CAS is a recommended practice, it comes at a price of tedious configurations. Following are the advantages and disadvantages of using CAS to set the trust level:

 Advantages of using CAS to set trust level for MOSS/WSS Web Part:

• Setting correct CAS policy ensures that the web parts are run in correct level of trust. This allows web part to be run successfully regardless of the trust level of the application provided correct CAS policies are implemented. This is the biggest advantage of using CAS.
• CAS limits access to policy specifications. Hence, there are fewer loopholes for an attacker to gain access to critical system resources

One should also consider following drawbacks in deployment to Bin with CAS configs:

• CAS requires tedious configurations. If something goes wrong, entire site will be affected by wrong configs.
• CAS is not a replacement to role based security. CAS is rather a defense mechanism to control and regulate access to resources
• CAS configurations require significant amount of knowledge and developer skill

 Conclusion:

Application Bin directory is best suited when web part code cannot be trusted. It requires CAS policy implementation to set the trust level. It will require configuration. Web part can be deployed to GAC, if the web part is trusted. This option is easy to implement but is less secure.

Using configurations in MOSS Web Parts/ InfoPath browser forms

There are times when we want some values to be configurable. For example, a hyperlink in MOSS web part or an InfoPath browser form must be configurable so that when the artifacts are moved across environments, the link points to correct target.

This can be achieved in simple web.config changes of MOSS web application as follows:
Step 1:
Define a sectiongroup tag under

<sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
</sectionGroup>

Step 2:
Add a corresponding .Settings tag under applicationSettings group we defined

<section name="SampleConfig.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />


Step 3:

Now that we have defined a placeholder, we can define actual configuration settings under it.
<applicationSettings>
<SampleConfig.Properties.Settings>
<setting name="AHyperLink" serializeAs="String">
<value>http://abc</value>
</setting>
</SampleConfig.Properties.Settings>
</applicationSettings>

Why this works?
Thanks to the ASP.NET infrastructure upon which MOSS is built. The MOSS web application undergoes the same ASP.NET request processing pipeline. Hence, the configurations defined above work. Please note that the highlighted tag names must match for this to work.

Remote Debugging in Visual Studio

Overview:
Remote debugger is a tool provided by Visual Studio to debug an application hosted on a different machine.
In local debugging, it is required to have application hosted on the development machine. We attach a debugger to the local process (e.g. W3WP.exe) which hosts the application. The symbol files (.PDB files) location is present on the same machine.
In remote debugging, the application can be hosted on a different machine (or server). Yet, we can debug it as if it is on the local machine.


Key Scenarios where remote debugging is must:
1. Debugging of ASP.NET web applications/Web services right on the server
2. Debugging InfoPath browser forms
3. Debugging of Web Parts deployed on MOSS


Installing Remote Debugger on the server:
Remote debugger setup can be found at ”Program Files\Microsoft Visual Studio 8\Common7\IDE\Remote Debugger” in Visual Studio Setup.
If it is not possible to install the setup on the server, copy and paste following directory to the server:
(Program Files\Microsoft Visual Studio 8\Common7\IDE\Remote Debugger\ x86 (or x64if server is 64 bit) to any location.


In this post, I will explain first scenario:
Remote debugging of ASP.NET web applications/Web services


To remote debug ASP.NET application following setup is required on server and development machine:

Setup on the Server:
Start the remote debugger by double clicking msvsmon.exe located in the Remote Debugger folder.
If you are debugging ASP.NET application, in command prompt type IISAPP.VBS. This will list all the worker processes and their PIDs. Note the Process ID of the worker process to be debugged.
Note: If you are debugging InfoPath form or a MOSS web part, please note the PID of the MOSS web application.


Setup on the development machine:
1. Go to debug -> attach to Process
2. Enter the machine name on which msvsmon.exe is running
3. Select the w3wp.exe with correct PID
4. Click attach


Debugging will start and break points will be hit.


Common Problems in Remote Debugging:
1. Debug Symbols not getting loaded
Solution:

Many times source code gets updated after the build was deployed on the server. Rebuild the source code and redeploy the ASP.NET application.
If this does not help, then
Go to debug -> Modules. This lists all modules.
Right click the module for which symbols are not loaded -> Load symbols

Harnessing Post-Build-Events in Visual Studio

In class library development, we need to add an assembly to GAC. One way is to open Visual Studio command prompt. And type the command for gacutil /i "DLL" or gacutil /u "DLL".
The disadvantage of the approach is that after every successful build we have to do it manually uninstall the prev version and install the correct version.

In my todays post, we will harness Visual Studio Post-Buil Events to automate this process.

On every successful build the DLL will be automatically added to the GAC.

To begin with,
1. Open any existing class library project to be deployed to the GAC.
2. Right click on the project, add new item-> Text File. Rename the file as PostBuildActions.bat
3. Paste the following content:

@ECHO OFF
SET DEPLOY=%3
ECHO DEPLOY: %DEPLOY%
:: Extract the deploye variable value from the command line
SET DEPLOYVALUE=DEPLOY
ECHO DEPLOYVALUE: %DEPLOYVALUE%

IF NOT %DEPLOY%==%DEPLOYVALUE% (ECHO Skipping deployment & GOTO QUIT)
SET TARGETDIR=%1
:: Fix the extra slashes the the path
echo %TARGETDIR:~0,-2%
:: Fix the extra slashes the the path
SET TARGETDIR=%TARGETDIR:~1,-2%
ECHO TARGETDIR: %TARGETDIR%
SET TARGETNAME=%2
:: Fix the extra slashes the the path
SET TARGETNAME=%TARGETNAME:~1,-1%
ECHO TARGETNAME: %TARGETNAME%
IF EXIST "%programfiles%\Microsoft Visual Studio 8\SDK\v2.0\Bin\gacutil.exe" (SET GACUTIL="%programfiles%\Microsoft Visual Studio 8\SDK\v2.0\Bin\gacutil.exe" & GOTO DEPLOY)
IF EXIST "%programfiles% (x86)\Microsoft Visual Studio 8\SDK\v2.0\Bin\gacutil.exe" (SET GACUTIL="%programfiles%\Microsoft Visual Studio 8\SDK\v2.0\Bin\gacutil.exe") ELSE (ECHO Gacutil.exe could not be found! & GOTO QUIT)

:DEPLOY
ECHO.
ECHO Adding assemblies to the GAC...
ECHO.
ECHO.
%GACUTIL% -uf %TARGETNAME%
ECHO.
ECHO.
%GACUTIL% -if "%TARGETDIR%\%TARGETNAME%.dll"
ECHO.
:QUIT
ECHO.
ECHO Assembly added to GAC
ECHO.

4. Right click on solution-> Go to properties -> Build Events -> Post-build events command line and
Paste the following
call "$(ProjectDir)\PostBuildActions.bat" "$(TargetDir)" "$(TargetName)" DEPLOY

(Replace DEPLOY with NODEPLOY to skip adding to GAC)

Multi-Tenant Architecture in SharePoint 2007

What is Multi-Tenant Architecture (MTA)?

MTA is similar to database views where same data is given different representations. As an example, consider a company portal. When an employee logs in, he will be interested more in company happening. On the other hand, when HR person logs in he will be keen to see new buddy referral or other relevant content. MTA implementation provides such dynamism with single portal.

MTA implementation options in SharePoint 2007:

Audience:

Audience is group of users for which the content can be target. SharePoint 2007 audience can consist of Active Directory users or other compatible domain users. We can target list, web part, and navigation for audience. Problem with Audience: Although provide customized content on the fly, Audience cannot be used with master pages.
So if the requirement is to provide different master pages depending on users it is not possible. In our example, if we want to provide a different look-and-feel for HR and employee then it would not be possible.

Solution:

Our problem can be reframed as switching master pages at run-time on the fly. SharePoint 2007 is built on top of ASP.NET 2.0 framework. Thus, we can harness the ASP.NETHTTP request pipeline and change the master page on the PreInit event of Page. For this, we need to create HTTP module and change the master page on the fly by reading page path from web.config.

Steps:

1. Define a class that implements IHttpModule

2. In the PreRequestHandlerExecute method provide a handler for page_PreInit

3. Set page.MasterPageFile property. This can be read from config. It could be similar to /_catalogs/masterpage/BlackBand.master

4. Add the Module to GAC

5. Add the entry to safe-controls section of web.config

6. Add entry to the httpModules section of web.config

That’s it. We are done with MTA implementation.

In my next post, I will provide a walkthrough of creating the MTA module with Visual Studio .NET 2005.