Amrox’s BlogWorld

To deploy visual studio addin you have to place the AddIn file in this directory:

My Documents\Visual Studio 2005\Addins\

Open the AddIn file. You will see XML seems the following:

<?xml version=”1.0″ encoding=”UTF-16″ standalone=”no”?>
<Extensibility xmlns=”http://schemas.microsoft.com/AutomationExtensibility”>
<HostApplication>
<Name>Microsoft Visual Studio</Name>
<Version>8.0</Version>
</HostApplication>
<Addin>
<FriendlyName>Sample Addin</FriendlyName>
<Description>Sample Addin Description</Description>
<Assembly>D:\mysampleaddin\bin\SampleAddin.dll</Assembly>
<FullClassName>SampleAddin.Connect</FullClassName>
<LoadBehavior>1</LoadBehavior>
<CommandPreload>1</CommandPreload>
<CommandLineSafe>0</CommandLineSafe>
</Addin>
</Extensibility>

Change the Assembly value to be the path of your addin DLL.

Change the full class name to be (<YourClassName>.Connect)

Then you will be ready to see your addin in the visual studio

To add a text from a resource file into your SharePoint ASPX page you have to place this code where ever you want this text to places.

<%$Resources:MyResource, MyName%>

where:

- MyResource: is the resource file name.

-MyName: is the resource entry key.

Your resource files must be placed in this directory:

..\12\CONFIG\Resources\

all resource files in this directory are copied to the global resources for every web application when it’s creating.

if the webapplication already exists place the resources files in this directory:

C:\Inetpub\wwwroot\wss\VirtualDirectories\<port>\App_GlobalResources\

where <port> is the the web application port

• Using deployment and migration APIs contents may sync between different sites using deployment packages these packages may be translated before they uploaded to the target site.
• Its move all of the list related data (permissions, pages, web Parts,…).
• It’s Very strong if we talk about the way it gets the relative data for very item.
• Reserve ID or create new one.
• Supports incremental deployment. So, it can deploy new changes only.
• Limitations:
  
  • Incremental export/import is supported only in the site scope.
  • In the lists the old items will not be overwritten they will duplicated. But in case of document libraries: the old items overwritten.
  • Unexpected behavior when using to transfer list from a variation site to another variation site have the same list.
  • Can’t export items from different site collections in the same operation.

• References:
  

  Deep Dive into the SharePoint Content Deployment and Migration API - Part 1 to 5
  

• Features:
  
  • Building multilingual sites by building a site (called Label) for every language and transferring the changes from source language site to all other sites.
  • Redirecting the user to the site matching the browser language.
  • Placing a control to change the language in the top navigation bar.
  • A service is running every 20 min to propagate changes from the source language site to all other sites.
• Limitations:
  
  • Transferring changes from the source language to others. So changes in any language other than the source are not reflected in other sites.
  • Pushing a new version from a page to all sites even if there is a minor change like spelling mistake.
  • One to one relationship with site collection (one variation per site collection).
  • Lists changes are transfer only when it’s contained in a new site created.
  • When creating sites using features the target sites created without localization.
  • The localization is working only when creating new sub site and the label sites.
  • List view web part references the source site list in every site it is propagated to(because it use the list ID).
  • Variation fails when trying to push a page when there is a page with the same name but with different content type in the destination site.
  • Permissions are not propagated.
  • Works only on publishing pages.
  • Can’t change default page layout.
  • Don’t support site restore.
  • Variation sites must be in the same level and their parent site must be the root of the variation.
• Risks (from blogs):
  
  • Sometimes variations cause performance issues.
  • May cause an expected behavior with heavy look and feel customizations.
• Variations in other Blogs:
  
  • Dumping MOSS 2007 Variations - Part 1 <http://blogs.msdn.com/jjameson/archive/2007/11/02/dumping-moss-2007-variations-part-1.aspx>
  • Dumping MOSS 2007 Variations - Part 2<http://blogs.msdn.com/jjameson/archive/2007/11/02/dumping-moss-2007-variations-part-2.aspx>
  • Some comments on common Variation problems
    <http://blogs.technet.com/stefan_gossner/archive/2007/11/15/some-comments-on-common-variation-problems.aspx>
  • Site Variations Musings <http://www.thesug.org/blogs/lsuslinky/Lists/Posts/Post.aspx?List=ee6ea231%2D5770%2D4c2d%2Da99c%2Dc7c6e5fec1a7&ID=3>

In this post, I will discuss the logic contained in the data layer. The data layer logic is all in stored procedures and functions.

First, Let us discuss the logic for the Languages table. The following stored procedures may be defined on the languages table:

• AddLanguage: Add new language to the system. You must take care that this stored procedure not only adds a record in the languages table but it also adds a record for that language into all child tables.
• DeleteLanguage: Delete language from the system. You need to remove all the records related to that language from child tables. You have to check also if it’s the default language for any user then he/she has to change it.
• UpdateLanguage: Update the details for a language.
• GetLanguageDetailsById: Retrieves all the language data using language ID.
• GetAllLanguages: Retrieves all the languages supported by the system.

Then we can define a group of stored procedures on every multilingual parent-child tables:

• AddRecord: This stored procedure is defined on the parent child records. It first adds a record in the parent table then adds its child record for a specific language and adds empty child record for each other languages. This stored procedure may use two other stored procedures or functions:
  • AddParentRecord.
  • AddChildRecord.
• UpdateRecord: Updates a parent record and one of its related child so it needs to take a language parameter. Also, it needs another two stored procedures:
  • UpdateParentRecord.
  • UpdateChildRecord.
• DeleteRecord: Deletes a record from parent table and all of its related child records. Again, it needs the two stored procedures:
  • DeleteParentRecord.
  • DeleteChildRecord.
• GetRecoredByLang: Retrieves the parent record and one of its children defined using the language paramenter.
• GetAllRecoreds: Retrieves the parent record and all of its children.

After developing these procedures for all tables, you need to move to the data access layer. In this layer, you have to make functions that allows you to connect to the database and access your tables and stored procedures. It’s so basic and straight forward so I will skip it.

Next time, I will talk about the business logic.