Converting an ASP.NET site into a SharePoint site

Introduction

There are a lot of ASP.NET web developers who are moving to SharePoint site creation. This article will explain in detail how an ASP.NET webpage developed in Visual Studio can be converted into a SharePoint site. If there is a requirement for a website created in Visual Studio, just the old fashioned way with the code-behind logic and other layers like Data Access and Business Logic, to be converted into a SharePoint site, and still make it work the same way with the same code-behind, you are in the right place. This article deals with right that.

Scenario

There is an ASP.NET website solution that contains three layers viz. Code-Behind Layer, Business-Logic Layer, and the Data-Access Layer. The website has functionality implemented in all these layers. The Business-Logic and the Data-Access layers are in a different Class Library project. We have to convert this website into a SharePoint site. Also, we want to use the same look and feel of the SharePoint site. So, we have to use the SharePoint master page instead of the one that we are having (we can also use our own master page; just that you have to add some default Place Holders that are required for the SharePoint functionalities). In this article, we are dealing with a website with the same look and feel as a SharePoint site.

Steps Overview

There are three steps that are explained in the article which will help you to transform your ASP.NET Web Application into a SharePoint site.
Step1: Add a Web Deployment Project to your website solution that will create a single DLL for the website. This step will give us the code-behind DLL and other dependency DLLs for the website.
Step2: Copy the bin folder items (DLLs) into the SharePoint site, and tweak the web configuration file of the SharePoint site to use the copied DLLs.
Step3: Open your created SharePoint site in SharePoint Designer and import the web pages from our web application and link it to the appropriate DLLs.

Step 1: Adding a web deployment project to your website solution that will create a single DLL for the website

1. The first step is to make sure you have added the proper namespaces and avoided class name duplications within a namespace before going to step 2.
2. Add a web deployment project into your website solution. This can be done by right clicking on the website project and choosing 'Add Web Deployment Project' option.
Note: This option will be available once you have installed the Web Deployment Setup.

3. Add a strong name key to the solution which we will be using to sign all the DLLs.
4. Now, we have to set the deployment project properties. Right-click on the deployment project and click 'Property Pages'.
5. Go to the 'Output Assemblies' tab, and choose the 'Merge all assemblies to single assembly' option (this is the default option), and give the assembly name.


6. Next, go to the Signing tab and choose the 'Enable strong naming' option, and choose the strong name key that you have created in step 3.


7. Also check the option 'Mark the assemblies with AllowPartiallyTrustedCallersAttribute (APTCA)'. This will make the DLL partially trusted, and thus the SharePoint site can use them. Click on OK.
8. The Data Access, Business Logic, or any other assemblies that are a dependency to the web application must be strong named with a strong name key.


9. Also, we have to allow partially trusted callers for the dependency DLLs. This can be done by opening the Assembly.info file of the Class Library project and putting the following line of code as shown above:
Collapse | Copy Code

[assembly: System.Security.AllowPartiallyTrustedCallers]

10. Build the deployment project under Release mode (any mode).
11. Go to the path where the deployment project has put the output. Here, in the bin directory, you will find the web deployment DLL file. If there are any dependency projects such as the Business Layer and the Data-Access Layer, those DLLs also will be copied to this bin folder.

Now, we have the DLLs that can be used in our SharePoint site for using the same functionality as in our ASP.NET site.

Step 2: Copy the bin folder items (DLLs) into the SharePoint site and tweak the web configuration file of the SharePoint site to use the copied DLLs

The next step in our SharePoint site creation is linking the DLLs that we have created in the procedure above into our already existing blank SharePoint site. There are also some changes that are required in our SharePoint site's web.config file (By default found in C:\Inetpub\wwwroot\wss\VirtualDirectories\<PortNo>). Following are the steps that has to be done:

1. Copy the bin folder contents from your ASP.NET deployment folder into the bin folder of your SharePoint site (usually in C:\Inetpub\wwwroot\wss\VirtualDirectories\<PortNo>\bin).
2. Open the web.config file of your SharePoint site.
3. Add the following line in under the <PageParserPath> section:
Collapse | Copy Code

<PageParserPath VirtualPath="/*" CompilationMode="Always" 
   AllowServerSideScript="true" IncludeSubFolders="true" />

4. Register the assemblies that will be used in the SharePoint site (web deployment DLL which has the code-behind code, the Business Layer and Data Access DLLs) as a SafeControl. For this, add the following under the <SafeControls> section:
Collapse | Copy Code

<SafeControl Assembly="SampleWebSiteAssembly" 
   Namespace="SampleSiteNamespace" TypeName="*" Safe="True" />

5. Also add all the other dependency DLLs that your site will be using. Note that all these DLLs must be strong named and marked AllowPartiallyTrusted.
6. Change the trust level from Minimal to Medium by changing the level attribute of the <trust> section from 'WSS_Minimal' to 'WSS_Medium'.
Note: You can also do the following to enable the original errors being shown in the SharePoint site screen for easy error identification. You have to change the mode attribute of the <customErrors> section to Off. Also, change the CallStack attribute of the <SafeMode> section to True.

Step 3: Open your created SharePoint site in SharePoint Designer and import the web pages from our web application

Let us say we have a link in our SharePoint site in the left navigation panel, on the click of which you want to display one of your ASP.NET pages in the content place holder of the SharePoint site. This is what we do:

1. Open your SharePoint site in the SharePoint Designer (in this article, we are using SharePoint Designer 2007).
2. Click on File-->Import-->File. This will open the Import dialog box.
3. Click on 'Add File' and choose the ASPX page that you have created from your local folder. Please note that you have to take the ASPX file from the deployment folder and not the ASPX page that is there in the project. Click OK. This will import the page into your SharePoint site.
4. Now, double-click on the newly imported page. Click on the Split option in the Design/Split/Code option in the centre pane (bottom left of the pane).
5. As soon as you do this, you will see in the designer window an error that says: The Master Page file cannot be loaded. This is because the master file that we have used in the project is different from the master page that the SharePoint site uses. You can either import the master page or use SharePoint's default master page. In this article, we are going to use SharePoint's default master page.
6. Change the 'MasterPageFile' attribute in the Page directive of the web page to a value same as the default.aspx in the SharePoint site, which is ~masterurl/default.master.
7. Delete the 'CodeFile' attribute from the Page directive as this is only for Visual Studio purposes.
8. Now, change the ContentPlaceHolderID of the place holders in the ASP.NET page to a relevant SharePoint site place holder. For example, the ContenPlaceHolderID of the main content place holder of the ASP.NET page must be changed to 'PlaceHolderMain'.
9. After mapping the place holders of the ASP.NET page to that of the SharePoint master page, the page will render in the design view with the default master page.
10. Now, we have to change the Inherits attribute to add the assembly name. For example, if the namespace is 'SampleSiteNamespace' and the assembly name that the page uses for code-behind is SampleWebSiteAssembly, then we set Inherits="SampleSiteNamespace.SampleWebSiteAssembly", and this assembly must be in the bin of the SharePoint site as added in Step 2 above.

Now, we have our ASP.NET site as a SharePoint site, ready to run with the same look and feel of the SharePoint site.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Conver Asp.net to SharePoint 2010

Migrating Asp.Net Application to SharePoint 2010

Migrating Asp.Net Application to SharePoint 2010
Or
Converting asp.net 3.5 Web Application to SharePoint 2010

Hi Friends,

                     This blog is about converting or migrating custom asp.net 3.5 or 4.0 web application to SharePoint 2010.

Scenario: I have an application which was developed in asp.net 3.5 with sql server database. I have a SharePoint Portal where I need to deploy my Asp.net Web application. The main aim is to integrate all the asp.net application that were developed in Asp.net so that all the application can be access using single-sign-on and all application will have single access point in SharePoint.

Solution:  To accomplish this scenario I have first created a SharePoint site collection in a web application then in this web application I have created no of sub sites for each asp.net Web Application so that each application can be separated.

So Steps will as below:

Note: This solution is targeted to SharePoint 2010.

Step 1: Create a Web Application (if you don’t have existing one) from SharePoint Central administrator.

Step 2: Create a Site collection which will be the main entry point for SharePoint Portal.

Step 3: Create sub sites for each web application which you are planning to deploy in SharePoint so that you can link each application from main site.

 -  Now first check your existing asp.net Web application setting and configuration

Step 1:  Go to your Asp.net Web application and check if all the application are using .NET framework 3.5

Step 2: Go to all the application’s (if you have n-tier application) and check that every solution is using .net 3.5 framework.

Step 3: First Create strong key name for all the application dlls which you will copy to SharePoint so every solution in an application require strong key.

  ->  To generate strong key go to Start-> Visual studio 2010(2008)-> Tools ->Visual studio command Prompt. It will open visual studio command prompt.

  -> Type :  sn –k yourdllName.dll  <path of your snk file where you will like to store>

  ->  eg: sn –k mydll.dll C:\mysnk1.snk

Step 4: Now go to your asp.net application select solution one by one ->Project Properties. You will get signing tab click on it. Check sign the assembly checkbox and upload strong key and save.

Step 5: Follow same steps 3 to 4 for all your application to sign with strong key name.

Step 6: Add following line in all the assembly.cs of all layers ( if n-tier): at the top of [assembly attribute]. It allows SharePoint to call these dlls and also allows communication among dlls.

[assembly: System.Security.AllowPartiallyTrustedCallers]

Step 6: Now compile all of your dlls layer by layer and the complete solution.

Step 7: Next you need to copy all the dlls from you asp.net solutions’ bin directory to SharePoint. So you have created a SharePoint Site go to It’s virtual directory.

    -:  If your IIS is installed in C:\ drive then your path may look like below:

    -:  C:\inetpub\wss\VirtualDirectories\8888\bin where 8888 is the port number of my sharepoint site.

    -:  Copy all the dlls to Bin directory

Step 8: Next Open the web.config of your SharePoint portal which will be at your port no 8888 (your port no may differ).

   ->  Add following Tag to web.config file:

<!–Page parser added–>
< PageParserPaths>
< PageParserPath VirtualPath=”/*” CompilationMode=”Always” AllowServerSideScript=”true” IncludeSubFolders=”true” />
< /PageParserPaths>

  ->  Mostly  <PageParserpaths> tag will be there in your web.config file search for it and place above tag in side it.

  ->  Next  you need to register your dlls within safe control section of web.config file go to <SafeControl> section and just press enter , then register your dll one by one here eg below

  <SafeControl Assembly="SPMigration, Version=1.0.0.0, Culture=neutral, PublicKeyToken= 512e23e28e25b338 " Namespace="SPMigration" TypeName="*" Safe="True" SafeAgainstScript="True"/>

      <SafeControl Assembly="BusinessLayer, Version=1.0.0.0, Culture=neutral, PublicKeyToken= f371028fb11feba8 " Namespace=" BusinessLayer " TypeName="*" Safe="True" SafeAgainstScript="True"/>

     - Assembly: Name of your assembly which you have copied in bin directory of SharePoint.

     -  Version: It will mostly 1.0.0.0 but you can check version of your assembly and replace it with correct version.

     - PublicKeyToken: You need to get public key token of your assembly, you can get it by using sn –T <your dll name>. It will display public key token copy it here.

     - NameSpace: It should contain name space which is written in side assembly some time assembly name and namespace is different. So check name space from your asp.net Web application and copy here.

   - Other attribute will remain same as I have written above.

Step 9: If your application contains database connection or any other dll registration which may be there in asp.net’s web.config file needs to be register here also in web.config file of SharePoint Portal. So copy connection string from your web.config to SharePoint portal config in Connection section of web.config same way register all dlls also in this config file.

Eg:

 <connectionStrings>
< add name=”MyCompanyConnectionString” connectionString=”Data Source=PRAVEEN;Initial Catalog=MyCompany;User ID=sa;Password=@System”
providerName=”System.Data.SqlClient” />
< /connectionStrings>

Step 10: Now everything is in place, we need to copy our aspx pages in SharePoint site. For this go to your asp.net Application copy only aspx pages not .cs page in a separate folder on your computer.

   - Open your SharePoint site by using SharePoint designer and click on site pages. On top of ribbon bar click on import files and point to your local folder of where you have copied  aspx page. Click on ok button it will import all the aspx pages to SharePoint site page gallery.

 -  Now you need to change Master Page: Attach v4.Master page to these pages by going to Style tab on Ribbon, Click on Attach and select the v4.master as shown here. Select aspx page one by one and apply master page to them.

  -  Now go to source code of all your aspx pages one by one and remove codebehind tag.  

  -  Inheritance tag at tope of page is very important. It may struggle you to get data from your database. So don’t change it because we have registered our dll in web.config just make sure Inheritance=”DllName.CodebehindfileName”

   - If you want to use your master page of asp.net then you need not to use master page of SharePoint just keep the things as it is and put your master page in a web part which is used to display page content and it will work fine.

  -  Now  go to your SharePoint portal (or even you can check your pages in SharePoint designer by browsing page in browser), go to Site pages and click on any page which belongs to your application. You can see it has same look and feel as SharePoint.

That’s It your application is migrated now you can use Authentication of SharePoint and you can also use default permission of SharePoint with your aspx pages.

Note: If you get any issue regarding migration of your asp.net application write your comments or you can mail me at: girish.eng@gmail.com

Related link: 

Migrating asp.net web Application to ShaerPoint 2010

Converting asp.net Web Application to ShaerPoint 2010

Converting Custom asp.net Web Application to SharePoint 2010

Thanks& Regards

Gireesh Painuly

Happy Coding…

Configuring Forms Based Authentication in SharePoint 2013

Configuring forms based authentication (FBA) in SharePoint 2013 is very similar to SharePoint 2010, but there are some differences due to SharePoint 2013 using .Net 4.0. The web.config entries entries are slightly different. As well, IIS doesn’t support editing .Net 4.0 membership provider configuration through the IIS interface, so all of the configuration has to be done directly in the .config files. I’ll go through all of the steps required to setup FBA for SharePoint 2013, from start to finish.

Section-1 Creating the Membership Database

The first thing you need when configuring FBA for SharePoint is a place to keep all of the usernames and passwords. ASP.Net comes with a tool that we’ll use to create a membership database to store the logon information.

• Navigate to c:\windows\Microsoft.NET\Framework64\v4.0.30319\
• Run “aspnet_regsql.exe”

• 

• A welcome screen will appear. Click Next.

• Select “Configure SQL Server for application services” and click Next.

• Enter the name of your server and your authentication information.  In this case SQL Server is installed on the same server as SharePoint 2013 and I am logged in as an administrator and have full access to SQL Server, so I choose Windows Authentication.For the database name, I just leave it as <default>, which creates a database called “aspnetdb”.
• 
• A Confirm Your Settings screen will appear. Click Next.
• A “database has been created or modified” screen will appear. Click finish and the wizard will close.
• Now that the database has been created, we’ll have to give SharePoint permissions to read and write to it. We’re going to connect to the database with Windows Authentication, so we’re going to have to give those permissions to the service account that is being used to run SharePoint.First, let’s find out the service account that’s being used to run SharePoint. Open IIS, go to “Application Pools”. Take a look at the “Identity” that is being used to run the SharePoint application pools. On my test server, it happens to be my administrator account that is being used, but it will probably be different on your machine. Make note of the identity used.
• Now that we know what account is being used to run SharePoint, we can assign it the appropriate permissions to the membership database we created.  Open up SQL Server Management Studio and log in as an administrator.
• Under Security/Logins find the user that SharePoint runs as.  Assuming this is the same database server that SharePoint was installed on, the user should already exist.Right click on the user and click 
• 
  ‘Properties’.
• 
  
• Go to the “User Mapping” Page. Check the “Map” checkbox for the aspnetdb database. With the aspnetdb database selected, check the “db_owner” role membership and click OK. This user should now have full permissions to read and write to the aspnetdb membership database.

Section-2 – Adding users to the Membership Database 

Now that we’ve created an empty membership database, we need to add some users to it that can be used to login.  You have a couple of options for doing this.  If you’d like to do all of your user management in SharePoint, then you can install the SharePoint 2013 FBA Pack and skip to Section-3.

If you’d like to be able to manage the users outside of SharePoint, and setup some inital users, then continue on to learn how to manage the FBA users with IIS.
To manage users in IIS, we’re going to create a dummy site just for managing users.  In SharePoint 2010 and earlier it was possible to edit the users directly from a SharePoint web application site, as long as the default membership provider was set to the membership provider you were going to edit. This is no longer possible, as previous versions of SharePoint ran against ASP.NET 2.0 (3.5), but SharePoint 2013 runs on ASP.NET 4.0.  IIS does not support editing users and roles for ASP.NET 4.0 applications. To get around this, we’ll create a dummy/blank ASP.NET 2.0 web site just for editing users. The asp.net 2.0 and 4.0 membership databases are exactly the same, which makes this possible.

NOTE: These directions were created on Windows 2008 R2.  On Windows 2012 they have reversed things and the .Net Users and .Net Roles options are only available for .Net 4.0 and are not available for .Net 2.0 – So on Windows 2012 please use .Net 4.0 where 2.0 is mentioned in the directions.

• Open IIS.
• Right click on Sites and select “Add Web Site…”
• A configuration dialog will appear. Just give it a meaningful name, point it to an empty folder and give it a random unused port number and click OK.
• Click on “Application Pools”. An application pool of the same name should have been created. The .Net Framework for that application pool should show as “2.0″.  If it doesn’t, you’ll need to modify it’s settings and change it to “2.0″.
• You’ll also have to set the identity the account runs as to the same as SharePoint, so that it will have permissions to read and write to the membership database. Select the application pool and click “Advanced Settings…” in the right panel. In the dialog that comes up, click on the Identity to change it. Choose “Custom account” and enter the SharePoint service account username and password. Click OK on all of the open dialogs to close them.
• The identity should now match the identity used for the SharePoint application pools.
• We’re now going to create a database connection to the membership database. Select your new site and open the “Connection Strings” page from the Features view.
• From the Connection Strings page, click “Add…” on the right side panel. On the Add Connection String dialog that appears, give it a name (I used “FBADB”), enter your server name and enter “aspnetdb” for your database name. Select “Use Windows Integrated Security” and click OK. We’ve now created the database connection.
• We’re now going to create the membership provider, that will let us edit users in the membership database. From the site Features view, click “Providers”. (If “Providers”, “.Net Users” and “.Net Roles” is missing from the features view, then the associated application pool is configured for .Net 4.0. Go back and configure it for .Net 2.0).
• From the Providers page, select “.Net Users” under Feature. Click “Add…” in the right side panel. In the dialog that appears, chose “SQLMembershipProvider” for type. Give it a name. For this example I used FBAMembershipProvider_2_0.  I added the _2_0 so as not to confuse it with the “FBAMembershipProvider” entry we will be creating when we set it up for SharePoint. Select the different options you want associated with your membership provider.  I have some more detail on the options available in the next section when we setup the membership provider for SharePoint. One thing I must stress though is that the options you pick here MUST match the options you use when you setup the membership provider for SharePoint. If they don’t, the users you create here will not work properly.For options, I chose:
  

  Option	Value
  EnablePasswordReset	True
  EnablePasswordRetrieval	False
  RequiresQuestionAndAnswer	False
  RequiresUniqueEmail	True
  StorePasswordInSecureFormat	True
  ConnectionStringName	FBADB (This must match the database connection we setup earlier)
  ApplicationName	/

  Click OK to close the dialog and create the membership provider.
  
• We’re now going to add users to the membership database. Click “.Net Users” from the Features view.
• The first thing we have to do before we can create users is configure the default membership provider. Click “Set Default Provider…” in the right side panel.  When the dialog appears, choose the membership provider we just created and click OK.
• Now that the default membership provider is selected, we’re presented with an empty .Net Users page, as there are not yet any users in the database. Click “Add…” in the right side panel to add a user.
• From the “Add .Net User” dialog, give the user a name, email and password. In this example i’m creating an admin user that i’m going to use as the SharePoint Site Collection administrator.The password needs to be at least 7 characters long and must contain at least 1 non-alphanumeric character. Since we set RequiresQuestionAndAnswer to false when configuring the membership provider, the Question and Answer fields can be left blank.Click OK to create the user and close the dialog.
• Now the .Net Users page lists the one user you have created. You can use this page to add and edit users in the future.
• If you are going to use Roles in SharePoint, you can create a Role provider from the Providers page, and then use the .Net Roles page to add roles – very similar to how we added the membership provider and added users.

Now that we’ve added a user to our membership database, you can continue on to Section-3 to learn how to configure the membership provider for SharePoint.

Section - 3 – Editing the Web.Config Files

The next thing that has to be done to get forms based authentication working with SharePoint is setting up the membership provider.  A membership provider is an interface from the program to the credential store.  This allows the same program to work against many different methods of storing credentials. For example you could use an LDAPMembershipProvider to authenticate against Active Directory, or a SQLMembershipProvider to authenticate against a SQL Server database. For this example we’re using the SQLMembershipProvider to authenticate against a SQL Server database.
SharePoint is actually divided up into several web applications – Central Administration, the Security Token Service and all of the SharePoint web applications that you create. Each of those web applications needs to know about the membership provider. Most tutorials have you adding the membership provider settings over and over again in each web config (as well as every time you setup a new SharePoint web application).  I prefer to add the membership provider settings directly to the machine.config. By adding it to the machine.config, the configuration is inherited by all of the web.config files on the machine – so you only have to make the changes once, and don’t have to remember to make the changes every time you create a new SharePoint web application.
If you don’t have access to the machine.config, or prefer not to edit it, you will have to make all of these changes to the following web.config files:

• SharePoint Central Administration
• SecurityTokenServiceApplication
• Every SharePoint web application you create that you would like to access via FBA.

• Navigate to “C:\Windows\Microsoft.Net\Framework64\v4.0.30319\Config” and open “machine.config”.
• In the <ConnectionString> section, add the following line:

  <add connectionString="Server=WIN-C6ES927TE58;Database=aspnetdb;Integrated Security=true" name="FBADB" />

  Be sure to replace the value for Server with the name of your SQL Server.
• In the <membership><providers> section add the following:

  <add name="FBAMembershipProvider"
   type="System.Web.Security.SqlMembershipProvider, System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
   connectionStringName="FBADB"
   enablePasswordRetrieval="false"
   enablePasswordReset="true"
   requiresQuestionAndAnswer="false"
   applicationName="/"
   requiresUniqueEmail="true"
   passwordFormat="Hashed"
   maxInvalidPasswordAttempts="5"
   minRequiredPasswordLength="7"
   minRequiredNonalphanumericCharacters="1"
   passwordAttemptWindow="10"
   passwordStrengthRegularExpression="" />

  You can customize the authentication by modifying each of these options. The most important thing to remember though is that if you define a membership provider in multiple locations for the same database, they MUST ALL USE THE SAME OPTIONS. Otherwise you’ll run into all kinds of problems with users created with one set of options, and later being authenticated against with a different set of options.
  Here’s a description of the different options available:
  

  Option	Description
  connectionStringName	The name of the database connection to the aspnetdb database.
  enablePasswordRetrieval	true/false. Whether the user’s password can be retrieved. I suggest setting this to false for security purposes.
  enablePasswordReset	true/false. Whether the user can reset their password. I suggest setting this to true.
  requiresQuestionAndAnswer	true/false. Whether accounts also have a question and answer associated with them. The answer must be provided when resetting the password. I suggest setting this to false, as setting it to true prevents an administrator from resetting the user’s password.
  applicationName	Setting the application name allows you to share a single membership database with multiple different applications, with each having their own distinct set of users. The default applicationName is /.
  requiresUniqueEmail	true/false. Determines if multiple users can share the same email address. I suggest setting this to false, in case you ever want to implement a login by email system.
  passwordFormat	Clear, Hashed or Encrypted. Clear stores the password in the database as plain text, so anybody with access to the database can read the user’s password. Encrypted encrypts the user’s password, so although the password isn’t human readable in the database, it can still be decrypted and the user’s actual password retrieved. Hashed stores a one way hash of the password.  When a user authenticates, the password they enter is hashed as well and matched against the stored hashed value. Using this method, the user’s password can never be retrieved (even if your database is stolen), only reset.  I always recommend using “Hashed” as it is the most secure way of storing the user’s password.
  maxInvalidPasswordAttempts	The number of times in a row that a user can enter an invalid password, within the passwordAttemptWindow, before the user’s account is locked out. Defaults to 5.
  passwordAttemptWindow	The number of minutes before the invalid password counter is reset. Defaults to 10.
  minRequiredPasswordLength	The minimum password length. Defaults to 7.
  minRequiredNonalphanumericCharacters	The minimum number of non-alphanumeric characters required in the password. Defaults to 1.
  passwordStrengthRegularExpression	A regular expression that can be used to validate the complexity of the password.

  
• In the <roleManager><providers> section add the following:

  <add name="FBARoleProvider" connectionStringName="FBADB" applicationName="/"
   type="System.Web.Security.SqlRoleProvider, System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />

  Save and close the machine.config file.
  
• I mentioned that if you modified the machine.config, you’d only have to put the config in a single place.  I wasn’t being completely truthful.  The SharePoint Web Services configuration overrides the machine.config and clears the entries we created. For that reason, the membership and role providers also need to be added to the SecurityTokenService (But only there – you won’t have to add them to the central admin or other SharePoint web app web.configs.First we need to find the web.config for the SecurityTokenService. Open up IIS. Under sites, SharePoint Web Services, right click on SecurityTokenServiceApplication and click on Explore. Edit the web.config in the folder that opens.
• Add the following to the web.config, just before the closing </configuration> tag:

  <system.web>
   <membership>
   <providers>
   <add name="FBAMembershipProvider"
   type="System.Web.Security.SqlMembershipProvider, System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
   connectionStringName="FBADB"
   enablePasswordRetrieval="false"
   enablePasswordReset="true"
   requiresQuestionAndAnswer="false"
   applicationName="/"
   requiresUniqueEmail="true"
   passwordFormat="Hashed"
   maxInvalidPasswordAttempts="5"
   minRequiredPasswordLength="7"
   minRequiredNonalphanumericCharacters="1"
   passwordAttemptWindow="10"
   passwordStrengthRegularExpression="" />
   </providers>
   </membership>
  <roleManager>
   <providers>
   <add name="FBARoleProvider" connectionStringName="FBADB" applicationName="/"
   type="System.Web.Security.SqlRoleProvider, System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
   </providers>
   </roleManager>
   </system.web>

  Remember to match all of the options with what was entered in the machine.config.Save and close the file.
  

The role and membership providers have now been setup for SharePoint. Continue on to Section-4 to configure SharePoint to use the membership provider we just setup.

Section-4 –  Configuring SharePoint

Now that the membership and role provider have been configured, we can configure SharePoint to use them.  For this example i’m going to create a new SharePoint web application.  The same settings can be applied to an existing web application through the Authentication Providers dialog.

• Open SharePoint Central Administration -> Application Management -> Manage Web Applications.
• Click “New” to create a new Web Application.
• Name the web application and adjust any other options to your preferences.
• Check “Enable Forms Based Authentication (FBA)”. Enter the ASP.Net Membership Provider Name and ASP.NET Role Provider Name that you configured in the web.config. For this example we used “FBAMembershipProvider” and “FBARoleProvider” (Without the quotation marks).Also, for this example we left “Enable Windows Authentication” checked. This allows us to login either via Windows Authentication or Forms Based Authentication (SharePoint will prompt you when you login for which method you’d like to use).Click OK.
• An Application Created dialog will appear. Click the “Create Site Collection” link to create the first site collection for this web application.
• From the Create Site Collection dialog, give the site collection a name and URL and select a template.
• For the Primary Site Collection administrator, i’ve left it as my Windows administrator account, so that I can login without FBA. For the Secondary Site Collection Administrator i’ve set it to ‘fbaadmin’ – the FBA account we setup in Section-2  (If you skipped Section 2 because you’re using the SharePoint 2013 FBA Pack, then you can just leave this blank for now and use your domain account to login to SharePoint and create your FBA users). You can set these to whatever is appropriate for your setup. Click OK.
• You’ll get the “Top-Level Site Successfully Created” dialog. You can click on the URL to visit the new site collection you just created.
• When authenticating to the site collection, if you enabled both Windows Authentication and Forms Based Authentication, you’ll be prompted for which method you’d like to use to authenticate. I’m going to choose to authenticate with Forms Authentication.
• You’ll be prompted for a username and password. Enter the username and password that we created in Section-2, and also set as the Secondary Site Collection Administrator.
• You’re now logged into the site as a site collection administrator.

That’s it! Now you can authenticate to the site with Forms Based Authentication. You can also create and edit users using the methods discussed in Section-2. Be sure to check out the SharePoint 2013 FBA Pack, which will allow you to manage your forms based users directly within SharePoint, as well as provide methods for users to register, change their password and recover their password.

Difference between sharepoint 2010 and sharepoint 2013

Difference between SharePoint 2010 and SharePoint 2013. 

SharePoint 2013	SharePoint 2010
What is SharePoint 2013 (Preview) - A new version of Microsoft famous Collaboration portal called SharePoint. The version adds few new exciting features such as Social Feed, SharePoint Apps and cross-site publishing.	What is SharePoint 2010 - It is a previous or I should say current version of SharePoint that was released in year 2010.
Development Changes –   §  In SharePoint 2013 Microsoft introduced a new Cloud App Model for designing Apps for SharePoint. Apps for SharePoint are self-contained pieces of functionality that extend the capabilities of a SharePoint website. You can use HTML, CSS, JavaScript and protocols like the Open Data protocol (OData), and OAuth to communicate with SharePoint using Apps. §  Tools – SharePoint 2013 has introduced new Tools for App development. Visual Studio 2012 now lets you develop apps for SharePoint and apps for Office. In addition a new web-based tools called “Napa” Office 365 Development Tools were introduced for developing apps. §  No more Sandbox solutions. SharePoint 2013 sandboxed solutions are deprecated. So all we got is the New App model and the Old SharePoint Farm solutions. check out SharePoint 2013 – Apps Vs Farm solutions	Development Changes –   §  SharePoint 2010 Introduced Sandbox solutions to help developers deploy code that did not affect the whole farm. §  In SharePoint 2010 you could use Server Object model and Client Object model (.Net Managed, ECMASCRIPT and Silverlight) to extract data from SharePoint. §  In SharePoint 2010 developers were also developing Farm solutions as they did with the previous SharePoint 2007 version.
Social and Collaboration features –  Microsoft in SharePoint 2013 Introduced new Social capabilities for better collaboration in the company. New Features added are -   §  Interactive feed §  Community Site §  Follow people §  Follow Sites	Social and Collaboration features - SharePoint 2010 had very few social capabilities.   §  My sites §  Tags and Tag profile pages §  Notes
Search - SharePoint 2013 includes several enhancements, custom content processing with the Content Enrichment web service, and a new framework for presenting search result types. Some of the features added are –   §  Consolidated Search Results §  Rich Results Framework §  keyword query language (KQL) enhancements	Search – SharePoint 2010 had Introduced Integrated FAST search as an Enterprise search. In addition to this build-in SharePoint search is still widely used in companies.
Enterprise Content Management (ECM) - SharePoint 2013 added some of the best capabilities of an ECM software. The newly added stuff is   §  Design Manager §  Managed Navigation §  Cross-site Publishing §  EDiscovery	Enterprise Content Management (ECM) -SharePoint 2010 on the other hand had Introduced Managed metadata and taxonomy as a part of new ECM benefits for SP 2010. This version did not had Managed Navigation and Cross-site Publishing. SharePoint designer was a primary tool to modify Master pages instead of the new Design Manager.