Feeds:
Posts
Comments

The following list summarizes the major differences between an application page and a site page:

  • An application page is deployed to the file system and a SitePage is deployed to the content database.
  • An application page requires a farm solution and a SitePage can be deployed using a sandbox solution.
  • An application page is shared all across the web front end, but a SitePage is unique to its location.
  • A SitePage can be easily customized through SharePoint Designer, but an application page usually requires Visual Studio.
  • Custom application pages should be secured and PageParserPaths for site pages should be avoided.
  • Feature Receivers are necessary to clean up after a site page feature is deactivated. Application page artifacts are removed from the file system when the solution is retracted.

Application pages generally are great for administrative-like functions. For example, all the layouts pages (those that appear at _layouts URLs) are application pages that Microsoft wrote. You should never edit out of the box Microsoft pages or any other out of the box files for that matter. But if you wish to deploy custom application pages, your own folder in the layouts directory is the right place to deploy your custom application pages.

On the other hand, site pages are great for presenting content and functionality to the end user. They also easily adapt the look and feel using the default.master of your SharePoint web site. WebPart pages are special example of SitePages. These are simply SitePages with WebPartZones in them. The WebPart manager itself lives on the master page. Therefore, putting WebPartZones on a site page, allows you to create a page in which during feature activation, or at a later date you can put WebParts.

Recently , I tried to create a sand boxed solution for SharePoint 2010 using Visual Studio 2010. I have created a “Hello World” web part. When I pressed F5 in Visual Studio 2010, I got the following warning message even I have already got Microsoft SharePoint Foundation User Code Service started.

---------------------------
Microsoft Visual Studio
---------------------------
Unable to attach. Process 'SPUCWORKERPROCESS.exe' is not running on 'COMPUTER-NAME'.

Do you want to continue anyway?
---------------------------
Yes No
---------------------------

After using google.bing.com, I have found out the Sand boxed solution does not work on DC(Domain controller).If you are using SharePoint on DC, the following Windows PowerShell command would need to be run to enable Sandboxed Solutions.

Reference: http://ybbest.wordpress.com/2010/03/13/process-spucworkerprocess-exe-is-not-running/

The Feature is a container of various defined extensions for SharePoint. It’s a set of XML files which are deployed to web front ends that can be bundled in site definitions or individually turned on in SharePoint sites. Put simply, a feature is something you activate on either the farm, web application, site collection, or a site. By activating a feature on any of these four scopes, you add new things into SharePoint that are logically bundled together by you. What can those things be? Things such as new WebParts, list definitions and instances, event receivers, or content types.

Package is where you specify what gets packaged into the final .wsp your Visual Studio solution will produce. This may contain features and other assets that are not directly a part of your features. By double-clicking the package node, you can view the package designer which lets you decide what gets deployed as a part of your .wsp.

 

When you’re writing code for SharePoint, and your custom code runs into an error, by default SharePoint will log that error and it will present the user with a generic error through the browser. In order to view the actual error message through the browser, you will need to make three changes to your web.config:

1. Change the SharePoint\SafeMode\@CallStack attribute to true.
2. Change System.Web\CustomErrors\@Mode attribute to Off.
3. Change System.Web\Compilation\Debug mode to true.

Making these changes will allow you to both attach to W3WP.exe and run your code in debug mode, and to view actual error messages through the browser. Whenever I run into an error in SharePoint programming, I usually look at the  following four places in sequence:

1. The browser window, assuming I have made the above-mentioned web.config changes.
2. The ULS logs available at 14\Logs. You may need to tweak the logging level in central administration to view your actual error message. Also, you should try out this fantastic tool at ULS Viewer.
3. The event log, especially for WCF-related errors.
4. The IIS log and tracing facilities.

If all these steps fail, I use the techniques described in this article SharePoint Applied: SharePoint 2007 Ninja Debugging

Here’s a very useful link where you’ll find test credit/debit cards for testing purpose whenever you’re implementing a payment module. Cheers!

http://blog.rac.me.uk/2009/02/12/techy-test-credit-and-debit-card-numbers/

The tip I am going to share today is an old one but many developers do not know about it. Assume you are creating an application and need to test a module that sends out bulk mails, like a newsletter. Your first thought would be to configure an SMTP server to test the email module. However there is a trick that you can make use of while testing your code. Use the following setting in your web.config

<system.net>
  <mailSettings>
      <smtp deliveryMethod="SpecifiedPickupDirectory">
          <specifiedPickupDirectory pickupDirectoryLocation="C:\Mails\"/>
      </smtp>
  </mailSettings>
</system.net>

The specifiedPickupDirectory element configures the local directory for a Simple Mail Transport Protocol (SMTP) server. The pickupDirectoryLocation is a directory where the application saves e-mail for later processing by the SMTP server. Make sure the directory exists before using it.

That’s it. Test this setting using the following code:

protected void btnMail_Click(object sender, EventArgs e)
{
    MailMessage message = new MailMessage("abc@somedomain.com",
        "abc@abcdefgh.com",
        "Newsletter", "This is a test mail");

    SmtpClient client = new SmtpClient("localhost");
    client.Send(message);
}

Run the application and click on the Send button. Now open the Mails folder in your C Drive and you should see your mail there. Similarly you can test your entire newsletter module without sending out mails to real email addresses.

ASP.NET SMTP Email

Cool ain’t it! Just make sure that if you are using IIS, it should have read-write permissions to this folder.

Reference Here: http://www.devcurry.com/2011/03/test-emails-in-aspnet-without-mail.html

Hi All. This is my first post on this blog and I am feeling very happy while publishing it. This post is on javascript.

This post will show how you can DISABLE right click on your web page. It can be used for security purpose or controlling the right click context menus.

Here goes the java script code for it.

<script>

var isNS = (navigator.appName == “Netscape”) ? 1 : 0;
if(navigator.appName == “Netscape”) document.captureEvents(Event.MOUSEDOWN||Event.MOUSEUP);
function mischandler(){
return false;
}
function mousehandler(e){
var myevent = (isNS) ? e : event;
var eventbutton = (isNS) ? myevent.which : myevent.button;
if((eventbutton==2)||(eventbutton==3)) return false;
}
document.oncontextmenu = mischandler;
document.onmousedown = mousehandler;
document.onmouseup = mousehandler;

</script>

Thanks & Regards,

Gaurav Rana