Wednesday, 6 June 2012

Plan variations

Plan variations (SharePoint Server 2010)

1 out of 3 rated this helpful - Rate this topic

Updated: April 16, 2012
The variations feature in Microsoft SharePoint Server 2010 makes content available to specific audiences on different sites by copying content from a source variation site to each target variation site. If necessary, the content can then be customized in the target variation site. For example, content on a target variation site can be translated into other languages before it is published. Variations can be used only on SharePoint Server 2010 sites that are created with one of the Publishing site templates, or on a site for which the SharePoint Server Publishing Infrastructure feature has been enabled.

Note:
Although variations can be used for multilingual solutions, the variations feature does not translate pages. To use variations for creating multilingual content, you can use workflows to route content for translation by another team or third-party vendor after the content is copied to target sites. For more information about workflows, see Plan workflows (SharePoint Server 2010).

This article contains information about important items that you should consider when you are using variations in a publishing site collection, and it describes the tasks that are involved in planning a solution that uses variations in SharePoint Server 2010. This article does not provide an overview of variations, describe how to use variations, or explain how to create variation labels and hierarchies.
For more information about variations, see Variations overview (SharePoint Server 2010).
In this article:

About planning variations

The planning process that is described in this article starts with describing important items that you should consider when you plan to use variations with your SharePoint Server 2010 solution. The remainder of the article describes the steps that are required to plan for using variations with SharePoint Server 2010. These steps include the following:

Determine the type of variations that are needed and select the variations root site.
Specify the source variation site and plan the target variation sites.
Decide how sites and pages will be created on the target source sites.
Plan how variations timer jobs will be scheduled.

You can record this information in the Variations planning worksheet.

Important items to consider when planning to use variations

Before you plan to use variations with your SharePoint Server 2010 solution, you should be aware of the interaction between variations and other SharePoint Server 2010 features. This section contains information about important items to consider when you are planning to use variations with your SharePoint Server 2010 solution.

Content approval

Content approval is the method by which site members with approver permissions control the publication of content. In content approval, content is considered published when a new major version is approved, because major versions are viewable by users who have read permissions. Content approval in variation sites requires major and minor versioning in the Pages libraries on the source and target variation sites. For more information about content approval, see Plan content approval and scheduling (SharePoint Server 2010).
Content approval has unique factors that you should consider when you are planning variations:

On the source variation site, when a page is submitted for approval, an e-mail is generated and sent to the contact of the page by using the values stored in the following columns, in the following order:

Contact
Contact E-Mail Address
Modified By

Note:
Starting with the Contact field, each field is checked for contact information to which the notification can be sent. If the first field is empty, the next field is tried until contact information is found.

After the page is approved for publication, it is enabled for copying to the target sites. You can configure the variations settings so that content is either manually or automatically copied to the variation sites.

On target variation sites, a page that is copied from the source variation site is always assigned a minor version number. If the page is new to the target site, it is assigned version 0.1. If the page already exists on the target variation site, the copied page is assigned the next available minor version number. For example, if a target variation site has version 2.1 of a page and a new variation of that page is copied to the target site, the page becomes version 2.2.
If a page is published on the source variation site, when the page is copied to target variation sites, the Approval status is set to Draft. If Content Approval and Document Versioning are enabled in the Pages library on target variation sites, the page must be approved on each target variation site before the page is available to readers.

Note:
Changes made to content that originates on the source variation site can supersede changes made to the content in the target variation site. For example, in language variations, if the source variation site is in one language and the target variation site is in another, the following situation might occur: An editor changes a localized page on the target variation site, assigning it a new minor version, 1.1. Then, a writer on the source variation site makes different changes to the same page, which is copied to the target variation site as version 1.2. This supersedes the version 1.1 changes to the page. In this example, an editor for the target variation site would have to restore the previous version of the topic from the Version History, accept the new version, or use the View Changes button to view differences between the current version and previous versions of the page, and manually merge the new and previous versions into a new version. For more information about versioning, see Versioning, content approval, and check-out planning (SharePoint Server 2010).

Note:

Changes made to content that originates on the source variation site can supersede changes made to the content in the target variation site. For example, in language variations, if the source variation site is in one language and the target variation site is in another, the following situation might occur: An editor changes a localized page on the target variation site, assigning it a new minor version, 1.1. Then, a writer on the source variation site makes different changes to the same page, which is copied to the target variation site as version 1.2. This supersedes the version 1.1 changes to the page. In this example, an editor for the target variation site would have to restore the previous version of the topic from the Version History, accept the new version, or use the View Changes button to view differences between the current version and previous versions of the page, and manually merge the new and previous versions into a new version. For more information about versioning, see Versioning, content approval, and check-out planning (SharePoint Server 2010).

Site navigation

If you are using site variations, you must plan your site navigation experience carefully. In SharePoint Server 2010, site navigation links to the current site's peer sites are automatically generated and displayed in the Global Navigation and Current Navigation menus of a Web page. In variation sites, where the current site's peers are variations of the same site, you might not want to give site users the ability to browse to other sites in this manner. You can use the Navigation Settings page to change the settings of the Global Navigation and Current Navigation menus so that peer sites are not displayed.

Note:
Changes to site navigation on the source variation site are not copied to the target variation sites. If you want the site navigation on target variation sites to match the site navigation on the source variation site, you must manually make changes to the site navigation settings on the target variation sites.

For more information about site navigation planning, see Plan site navigation (SharePoint Server 2010).

Content deployment

Content deployment copies content from a source site collection to a destination site collection.
We recommend that you disable any content deployment jobs that include the source variations site while Variations Create Hierarchies Job Definition runs. If content deployment runs while the Variations Create Hierarchies Job Definition timer job is also running, a target variation site that is only partially created may be copied to the target variation site on the destination server.
For more information about content deployment planning, see Plan content deployment (SharePoint Server 2010).

Web Parts

A Web Part is one of the building blocks of pages based on SharePoint Server 2010. Most Web Parts are designed to display a specific type of data, such as text, HTML, or images. SharePoint Server 2010 includes a set of Web Parts, and you can also develop or import custom Web Parts.
Web Parts are copied with pages of variation sites. If Update Target Web Parts is enabled, Web Parts are updated only on the target variations site if a page containing that Web Part has been copied to the target variation site. If the Web Part appears on multiple target pages on different target variation sites, all instances of the Web Part are updated when the page from the source variation site is copied to the target variation sites. For example, if a page contains a Media Web Part, and the Web Part is configured to point to video A that is stored on a site outside of the variations hierarchy, when the page is published on the source variation site, the page is copied to all target variation sites. The pages on the target variation sites display video A in the Media Web Part. If the page on the source variation site is updated and the Media Web Part is changed to point to Video B, the pages on the target variation sites continue to point to video A until the page on the source variation site is published and copied to the target variation sites. Also, if readers on the target variation sites do not have permission to view the video file that is stored outside the variations hierarchy, they cannot view the video. To prevent unintended Web Parts behavior such as this, you can configure the variations settings so that Web Part updates are not copied to target variation sites.

Multilingual sites

SharePoint Server 2010 has several features that enable you to support users in different regions or users who speak different languages. You can use these features to create Web sites in different languages and to enable users to view the user interface of a site in a language other than the one in which a site was created. If you plan to use variations with multilingual sites, there are additional steps that you must follow to enable multilingual support for the variation sites. For more information about how to plan multilingual sites, see Plan for multilingual sites (SharePoint Server 2010).

Determine the types of variations needed

Although variations are most commonly used to create multilingual sites, you can also use variations to create sites based on other criteria, such as regional differences, mobile devices, corporate or product branding, or company subsidiaries. Determine what types of variations are needed for your solution, and make a list of the sites that will belong to the variations hierarchy.

Note:
If you will be using variations for creating multilingual sites, and if you want the site administration pages of the target variation sites to be displayed in another language, you must install the language pack for each language that corresponds to a variations site. For information about how to install language packs, see Deploy language packs (SharePoint Server 2010).

Select the variation root site

The variation root site provides the URL for all variations sites and contains the landing page that redirects users to the correct variations site. The root site can be a site at any level in a site collection, including the top-level site. However, after you specify the root site, you cannot change it after you click Create Hierarchies, and you cannot use variations anywhere else in the site collection.

Note:
If the root site contains a site hierarchy or content in the Pages library that you want to be in the source variation site, you must manually copy them to the source variations site after it has been created.

Decide what site you want to use as the root site, and record the URL in the variations planning worksheet.

Specify the source variation site

The source variations site is the site where content to be shared by all sites is authored and published, and it is the site that is used to copy changes to the target variation sites. A source variation site is specified by selecting the Source Variation setting for a variation label on the Create Variation Label page in the Site Collection Administration Web site. There can be only one source variation site for a variations hierarchy. After a variation label has been specified for use as the source variations site, it cannot be changed.
Review the list of sites for your variations solution, and decide which site will be the source variation site. Record the source variations site for your solution in the top row of the Sites data sheet tab in the variations planning worksheet. Type the label as you want it to appear in the site URL, the label display name, and the name of the site owner who will be responsible for the site.

Plan target variation sites

Your planning goals for target variation sites will vary depending on the type of variation sites that you are implementing. For example, if the variation sites are based on languages, you might want the pages in the target variation sites to look the same as the pages in the source variation site. If the variations are based on devices, you will probably want the pages in the target variation sites to look different from the pages in the source variation site so that they fit the devices intended to display them.
Review the list of sites for your variations solution, and record each target variation site in the variations planning worksheet. For each site, enter the label as you want it to display in the site URL, the label display name, and the name of the site owner who will be responsible for the site.

Note:
SharePoint Server 2010 supports up to 50 variation labels.

Plan custom master pages, layout pages or style sheets

You can decide to use custom master pages, page layouts, or style sheets for variation sites. For example, in site variations based on devices, you could define simpler page layouts for those variations that are displayed on devices with limited screen sizes. Master pages, page layouts, and style sheets are managed only in the top-level site of a site collection, so you must make all changes to these resources in one of the following locations in the top-level site:

Resource	Location
Master Page	Master Page Gallery
Layout Page	Master Page Gallery
XSL styles and cascading style sheets	Style Library

You can also specify that each target variation uses its own custom page layout.

Plan custom content types

You must use the same content type (either the Page content type, or a content type based on the Page content type) for all pages that are stored in the Page library of the source variation site. The easiest way to do this is to use a content type that is defined in the Site Content Type Gallery in the top-level site of the site collection.
If you must have custom columns for one or more variation sites' pages, add them to the content type that you are using in your Page libraries. For example, if the variation sites are based on language differences, you can add a column that indicates whether the page has been localized. For more information about planning content types and columns, see Content type and workflow planning (SharePoint Server 2010).
In some site variations solutions, you do not have to edit or change the content on the target variation sites. For example, if your variation sites are device-dependent, you might want identical content displayed on all devices but with different layouts and master pages for each type of device. When this is the case, you can simplify the administration of your target variation sites by disabling required check-outs.

Decide how sites and pages will be created on target variation sites

If the source variation site will have other sites below it in a site hierarchy, you must plan for how those sites will be created on the target variation sites. There are two ways in which sites can be created on target variation sites: automatically and manually. By default, any new sites that are added below the source variation site will automatically be created on all target variation sites. However, if you disable automatic site and page creation for variations, for each new site that you create below the source variation site, you must manually specify the target variation sites on which the site should be created. Although enabling new sites to be created automatically on the target variation sites has the advantage of reducing tasks for the site administrator, the advantage to manual site creation is that you can specify which sites should be created on which target variation sites. This can be useful if you want a site to be included only on some, but not all target variation sites.
Publishing pages can also be created on target variation sites in two ways: automatically and manually. By default, any new pages that are published in the Pages library of the source variation site will automatically be created on all target variation sites. However, if you disable automatic site and page creation for variations, for each new page that you create on the source variation site, you must manually specify the target variation site on which the page should be created, and you can only specify a single target variation site. Disabling automatic site and page creation can be useful if you want certain pages to be included only on some, but not all target variation sites. However, requiring manual creation of pages on target variation sites can be a disadvantage if the source variation site will contain many pages. If you want to create variation pages on a subset of the target variation sites, we recommend that you use automatic creation to create the pages on all target variation sites, and then either delete the pages from the target variation sites where you do not want copies of the pages, or use a workflow to approve only the pages that you want to have copied to the target variation sites.
By default, automatic site and page creation is enabled. You should carefully consider the potential increase in administrative tasks if you decide to disable automatic site and page creation for your variations solution. Automatic site and page creation is configured on the Variations settings page in Site Collection Administration. For information about specifying variations settings, see Turn on variations settings so you can create versions of your site.

Plan variations timer job scheduling

The variations feature uses timer jobs to perform tasks such as creating and propagating sites and pages. A timer job runs inside OWSTIMER, a Windows service for SharePoint Server 2010. Each timer job has its own default schedule for when the job runs. You can change the frequency with which each job runs on the Job Definitions page on the Central Administration Web site.
The following table lists the variations timer jobs and the default schedule for each job:

Job name	Default schedule
Variations Create Hierarchies Job Definition	Once a day
Variations Create Page Job Definition	Hourly
Variations Create Site Job Definition	Every 5 minutes
Variations Propagate Page Job Definition	Hourly.
Variations Propagate Site Job Definition	Every 5 minutes

You can specify when each job will run by setting a recurring schedule in minutes, hourly, daily, weekly, or monthly intervals. If you select daily, weekly, or monthly, you can specify a window of time for when the job should run, and the server will randomly select a time within the specified range in which to begin running the job. This option is most appropriate for high-load jobs that run on multiple servers in a farm. Be aware that running this type of job on all servers in the farm simultaneously might increase the server load and affect performance. To avoid this possibility, you can specify an exact starting time for a job.
You should carefully plan when the variations timer jobs should run on your servers, and set the recurring schedule accordingly. For example, to determine how often the Variations Create Page Job Definition or the Variations Propagate Page Job Definition should run and copy pages to target variation sites, consider how many pages will be created on the source variation site, and how often those pages will be updated.

Tuesday, 5 June 2012

Configure multilingual sites in SharePoint 2010

Here are quick guidelines for creating and configuring sites in multiple languages and use variations.

First Create Publishing site or activate publishing infrastructure features in the site and go to Site Actionsà

Site Settings

Then click on “Language settings” under “Site Administration” section as shown below

Next screen will show all available language packs on the server, select appropriate ones and click on “OK”.

Note: here if “Overwrite Translations” mark as “Yes” that means any changes that are made to the user interface in the primary language overwrite any changes that have been made to those same user interface elements in secondary languages

Now your site can be used in multiple languages, you can change the display languages by clicking on welcome control at top right corner of the page and select display language as shown below

Now site will be shown in selected language (currently French is selected).

Note: Here only default labels will be translated in other language but other contents like web parts, list items, and page content will not be shown in other language.

Multilingual user interface

When language packs installed on the server in SharePoint Server 2010 and you created a site collection or site, you could also select the language in which to display the site user interface. However, after the language for the user interface of a site was set, it could not be changed. This feature is used to display the site user interface in a secondary language that the user prefers rather than the default, primary language that was selected when the site was created.

Benefits of the multilingual user interface

Ø Same site can be available in one primary and number of secondary languages

Ø Logged on user can select site in different language and change the user interface like site title, description etc by using site settings, however those things in primary site will not be changed, it will be changed for secondary sites only

Ø By using the multilingual user interface, team members can work on documents and projects in a shared, primary language, while they view the site and perform tasks in their preferred language

How the multilingual user interface works

Go to Site Actions of secondary language and click on respective link to change title or description

Enter title and description in secondary language and click on OK

Now you site in secondary language will show changed title and description.

What is supported by the multilingual user interface

The following list includes examples of items that are supported by the multilingual user interface:

Settings pages, such as those in the _layouts and the _admin virtual directories.
Help.
Application content, such as menus, controls, site actions, site title and description, list or library titles and descriptions, top link bar links, Quick Launch links, local breadcrumbs, site and list content types, and site and list columns.
Developer content, such as features, and solutions.

Exporting and importing translated content

Multilingual interface allows import/export of application content for bulk operation. For that you can go to Site Settingsà Export Translations under Site Administration section

In the next screen choose the language you want to export and it will gives you resource file in.resx format, which you can update it and import it back using "Import Translations" link on the same page in target site.

Limitations of the multilingual user interface

Following things are not supported in multilevel feature of SharePoint 2010

v Shared components

ü Web Parts

ü Lists

v Permissions

ü Permission group names

ü Permission level names and descriptions

ü User information

v Site templates

ü My Site

ü Blogs

ü Meeting sites

ü Search

ü Web databases

I hope this article helps you to understand multilingual feature of SharePoint 2010 and create sites in multiple language and impress your boss.

Sunday, 3 June 2012

Anonymous Access for SharePoint Sites

When we build an internet-facing website using SharePoint, the first question that arises is the accessibility of this site to anonymous users. SharePoint takes care of this feature too, the only thing we need to do is enable the anonymous access to our site.

How do we enable anonymous access?
Enabling anonymous access has two stages. First, this has to be enabled in Central Administration for the respective Web-Application. Then it has to be set for the respective Site (site collection).
Navigate to the central administration page.
Click on Application Management ->Manage Web Applications. Select the web application and click on ‘Authentication providers’

A pop-up window opens, from which you need to select your authentication provider as shown in the image below. Click on ‘Default’

This opens up the edit window of the selected authentication provider. In this window CHECK the “Enable Anonymous Access” field and click on ‘Save’

The above process sets anonymous access at CA level. We still have to set the anonymous access for a single site-collection or for a root site.

Enabling Anonymous Access for a Site
Go to the respective site, for which anonymous access has to be enabled.
Navigate to Sites->Site Permissions. You will notice a new option ‘Anonymous Access’ in the ribbon.

Click on Anonymous Access and select the required option. Selecting ‘Entire Web site’ gives read-only permissions to all users who visit the site.

The process described above is how we enable Read-Only access to anonymous users. But there are also few scenarios where we need to give limited Write/Edit permissions to anonymous users.

For example, when we create a blog site in SharePoint we need to give permissions for all users to add comments to the (published) posts.

(**Note: A SharePoint blog site has three lists – Categories, Posts and Comments—which are created by default. Categories and Posts can be ‘Read only’ lists. But when Comments are taken into consideration, we need to allow anonymous users to write/enter their comments.)

Enabling Anonymous Users to Add Comments to Blog Posts
Navigate to your blog site. Click on, Sites->Site Settings. There in the left menu bar find all the available lists in the blog site. Select ‘Comments’

Now all the available comments will be shown.
In the ribbon select, List Tools->List->List Permissions

Here, we can set permissions for anonymous users to add comments by stopping ‘Inherit permissions’ and giving permissions exclusively for this list. Click on ‘Stop Inheriting Permissions’, this stops inheriting permission from parent site.

When we stop inheriting permissions from parent site, ‘Anonymous Access’ appears in the ribbon menu. Click on this and select ‘Add Items- Add items to lists’

You are done and any user can add comments to your blog posts!!!
But wait, this may not work in cases where BLOG is set as a sub site under a publishing site.
This is because site collection is based on publishing portal and have a ‘ViewFromPagesLockdown’ feature. This feature prevents anonymous users from gaining access to certain areas of site. So, first check if ‘ViewFromPagesLockdown’ feature is enabled for the site.

To determine if a site has ‘ViewFromPagesLockdown’ enabled run the following in Powershell:
get-spfeature -site http://sitecollectionURL
If ViewFormPagesLockDown is listed, it’s enabled.
To toggle lockdown mode to off:
$lockdown = get-spfeature viewformpageslockdown
disable-spfeature $lockdown -url

Now re-set the anonymous access and try to add comments to a blog post without signing in. You can add comments!!!!

Friday, 4 May 2012

check password strength in c#

enum PasswordScore
        {
            Blank = 0,
            VeryWeak = 1,
            Weak = 2,
            Medium = 3,
            Strong = 4,
            VeryStrong = 5
        }

        private PasswordScore CheckingPasswordStrength(string password)
        {
            int score = 1;
            if (password.Length < 1)
                return PasswordScore.Blank;
            if (password.Length < 4)
                return PasswordScore.VeryWeak;

            if (password.Length >= 8)
                score++;
            if (password.Length >= 12)
                score++;
            if (Regex.IsMatch(password, @"[0-9]+(\.[0-9][0-9]?)?", RegexOptions.ECMAScript))   //number only //"^\d+$" if you need to match more than one digit.
                score++;
            if (Regex.IsMatch(password, @"^(?=.*[a-z])(?=.*[A-Z]).+$", RegexOptions.ECMAScript)) //both, lower and upper case
                score++;
            if (Regex.IsMatch(password, @"[!,@,#,$,%,^,&,*,?,_,~,-,£,(,)]", RegexOptions.ECMAScript)) //^[A-Z]+$
                score++;
            return (PasswordScore)score;
        }

Creating a Custom ASP.NET MVC Project Template

When you create a new ASP.NET MVC 3 project, the new project wizard dialog contains several options for different MVC project templates:

Empty
Internet Application
Intranet Application (new in the April 2011 Tools update)

There’s a lot of white space in that dialog. To many of you, all that unsullied territory smells like opportunity. When I talk about this dialog, I go to great pains to tell folks that, yes!, you too can extend that dialog and add your own project templates in there.

If you wanted to, you could have your own ASP.NET MVC 3 project template configured exactly the way you want. Hate the default template? Make your own!

The only problem is, I keep telling you that you can extend it, but sadly I never told you how. But that’s about to change!

I don’t expect that a large number of people will want to do this, which is one reason we haven’t spent a large amount of time making it easy (though that may change in the future). But for the few of you impatient masochists who want to add your own custom templates now, this blog post will walk you through the hacking around it takes to make it happen.

Imitation is the sincerest form of productivity

The easiest way to get started is to simply copy and modify an existing project template. For example, I looked in the following directory:

C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\ProjectTemplates\CSharp\Web\1033

on my machine and ~~stole~~ *ahem* borrowed the project template named MvcWebApplicationProjectTemplatev3.01.cshtml.zip. Note that the 1033 folder is for English (en-US) templates. For other languages, you may need to look in a different folder.

I then renamed it to MyProjectTemplate.cshtml.zip and extracted the contents into a folder so I could make some modifications to its contents.

When you extract the contents, you’ll want to rename the .vstemplate file to match the name of the template you chose. In my case, I renamed MvcWebApplicationProjectTemplatev3.01.cshtml.vstemplate to MyProjectTemplate.cshtml.vstemplate.

Open up the .vstemplate file in NotePad and make sure to change the TemplateID element value to something unique.

You can change any of the contents of the template folder now, but be very careful to make sure that any additions or deletions of content are reflected in the .vstemplate file. That file is a manifest of all the files within the VSIX package that makes up the project template. Also make sure that the .csproj file reflects those changes as well, to ensure any new files you add to the template are properly referenced in the project.

Pre-installed NuGet packages

UPDATE: The upcoming NuGet 1.5 feature will provide support for this feature in a way that doesn’t require the following harsh warning. Marcin Dobosz has a blog post detailing the feature.

Warning: I probably shouldn’t show you this next section and some of my co-workers may chide me on this. But if you promise to be responsible and pay close attention to the information and context for that information I’m about to show you, I’ll do it anyways and trust you not to inundate us with support calls when this blows your hand off.

The ASP.NET MVC 3 Tools Update includes very limited support for project templates that include NuGet packages. We originally wanted it to be very extensible, but ran out of time and imposed some severe limitations on the feature, hence the caution.

If you scroll to the bottom of the .vstemplate file, you’ll notice the following section:

</packages>

</WizardData>

That is the list of NuGet packages that the MVC 3 project template installs when you invoke the project template.

But as I mentioned, there are two major limitations:

The package must exist in the %ProgramFiles%\Microsoft ASP.NET\ASP.NET MVC 3\Packages folder. MVC 3 doesn’t go searching online for them.
The version attribute of the package in the <package> element is required and is an exact match.

If you are fine with these limitations, you can modify this section of your custom project template to install the NuGet packages you care about. Just make sure they exist in the MVC 3 packages folder like I mentioned.

Once you are done making your changes, zip up the contents of the folder with the same file name you had before.

Registering your project template

At this point, all you need to do is copy the project template to the right location and add the appropriate registry entries. For extra credit, you can write an installer (MSI) that does all this for you.

The place to copy your template is the same place I mentioned previously, C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\ProjectTemplates\CSharp\Web\1033

Once the template is there, you’ll need to setup the correct registry settings.

Since I’m lazy, I put these registry settings in a .reg file to make it easy to install. You’ll just need to modify the settings within the .reg file to match your project template.

32-bit

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\10.0\MVC3\

ProjectTemplates\MyProjectTemplate]

"Title"="My Project Template"

"Description"="This is the coolest project template EVAR MADE."

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\10.0\

MVC3\ProjectTemplates\MyProjectTemplate\C#\Razor]

"Path"="CSharp\\Web"

"SupportsHTML5"=dword:00000000

"SupportsUnitTests"=dword:00000000

"Template"="MyProjectTemplate.cshtml.zip"

64-bit

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\10.0\MVC3\

ProjectTemplates\MyProjectTemplate]

"Title"="My Project Template"

"Description"="This is the coolest project template EVAR MADE."

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\10.0\

MVC3\ProjectTemplates\MyProjectTemplate\C#\Razor]

"Path"="CSharp\\Web"

"SupportsHTML5"=dword:00000000

"SupportsUnitTests"=dword:00000000

"Template"="MyProjectTemplate.cshtml.zip"

The important thing to note are the options in the second registry section:

Path – Relative path from the ProjectTemplates folder. For C# projects, enter “CSharp\\Web”. For VB.NET use “VisualBasic\\Web”
SupportsHTML5 – Whether or not the project template supports HTML5. If set to 1, then the HTML 5 checkbox is enabled. That checkbox sets a project template variable, $usehtml5$. You can look at the default /Views/Shared/_Layout.cshtml inside of MvcWebApplicationProjectTemplatev3.01.cshtml.zip for an example of this.
SupportsUnitTests – This allows you to associate a unit test project template with your project template.
Template – the name of your project template file.

The last step is to run the command devenv /installvstemplates to force Visual Studio to recognize the project templates.

I wrote a batch file, install.bat, when combined with the .reg file, that automates these steps.

cd %~dp0

regedit.exe /s project-template.reg

xcopy MyProjectTemplate.cshtml.zip "C:\Program Files (x86)\Microsoft Visual Studio
10.0\Common7\IDE\ProjectTemplates\CSharp\Web\1033" /Y

devenv /installvstemplates

For your convenience, I packaged up the necessary files in a zip file. Unzip the file, and run install.bat and you’ll see a new project template when you create a new ASP.NET MVC 3 project.