Category: Web development

  • Dynamics CRM 2016 – Custom plugin development using CRM Development Tool Kit

    Dynamics CRM 2016 – Custom plugin development – This time we are going through a process of building a custom plug-in for Microsoft Dynamics CRM and its deployment on development server.  I assume that you already downloaded and setup Development Tool Kit. And make sure CRM templates are imported in Visual Studio.

    Start with creating a solution using Dynamics CRM. Navigate to Settings >> Customization >> Solution. Create a new Solution “AccountPlugin” and choose any name based on project and company requirement. In case, you are going to develop plugin for any existing solution skip this steps.

    PluginSolution

    Save CRM solution and publish.

    PublishSolution_2

    In Visual Studio, Create new project using Dynamics CRM 2013 Package template. If templates are not available, make sure that you already imported development tool kit templates in Visual Studio.

    Dynamics CRM package is selected instead of Dynamics CRM 2013 plugin because it will make our process easy for plugin registration and deployment using tool kit.

    ConnectionTOCRM_3

    You will be asked to connect CRM live before Visual Studio setup package solution. CRM connection screen pops up. You can also open it from Tool >> CRM connection.

    Connection To CRM

    Fill out required details and connect development Dynamics CRM server.

    URL: CRM URL.

    User Name: Domain Administrator

    Password:   Domain Administrator Password

    Browse all organizations and select appropriate organization and solution to hook plugin.

    ConnectionTOCRM_3

    After a successful connection with CRM server, CRM package solution will be created in Visual Studio. Next step is to add a CRM plugin library project in solution. More plug-in projects can be added in one solution.

    add plugin solution

    Now Visual Studio solution is set up and ready for plugin development. Some important file and DLLs are added in projects which are required. Let me elaborate important of these files.

    RegisterFile.crmregistration is xml file contains details of all added plugins and workflows and register those in Dynamics CRM when package is deployed. Its auto created file using CRM Development Tool Kit.

    Microsoft.Crm.Sdk.Proxy and Microsoft.Xrm.Sdk are two very important DLLs referenced in plugin project. These DLLs contain core classes of Microsoft dynamics CRM which are used for plugin operations.

    Next step is to create strong name key for plugin project. Right click on project and select properties and create new Strong Name key (SNK). SNK is system oriented and when you move this development code on another machine, SNK needs to create again.

    SNLKey_11

    Open CRM explorer from View>>CRM explorer and expend entities. Right click on Account entity and select create plugin. It’s popping up Create Plug-in window.

    Let’s go through Create Plug-in form attributes. First one “Project” is default set to “AccountPlugin” as it’s related to a single plugin project, in case we have more than one plugin projects. It will be enabled for selection.

    Next is “Primary entity” is about to entity for which plugin is being created and it “Account” entity.

    Next one is “Message” is about to CRM action, it’s associated with.

    AccountActionMessage_7

    Next important attribute is “Pipeline Stage” and it’s specifying execution time of plugin. In this example, we created “PostAccountcreate” plugin. So Pipeline Stage is to determine on which stage of “PostAccountCreate”, this plug-in will fire.

    PluginPipelineStage_8

    Next one is “Class” to specify class name for plug-in. Next important attribute is “Execution order” to specify order of plugin execution. In case of many plugins are associated with an action stage, it will be used to determine the execution order of this plug-in. Click Ok and plugin will be created.

    After successful creation of “AccountPlugin”. Open “RegisterFile.crmregister” file and a new code line is added in xml for created “AccountPlugin” plugin.

    Account Plugin Registration_9

    “PostAccountCreate” class is added in plug-in project, where custom code will be written for operations required under this plugin. “ExecutePostAccountCreate” method is responsible for plugin operations.

    Sample code lines for update Account entity Name attribute:

    protected void ExecutePostAccountCreate(LocalPluginContext localContext)

    {

    if (localContext == null)

    {

    throw new ArgumentNullException(“localContext”);

    }

    // TODO: Implement your custom Plug-in business logic.

    IPluginExecutionContext Context = localContext.PluginExecutionContext;

    IOrganizationService service = localContext.OrganizationService;

    ITracingService trace = localContext.TracingService;

    Entity entity = null;

    EntityReference parentCustomerIdAttribRef = null;

    // If we have a target

    if (Context.InputParameters.Contains(“Target”) && Context.InputParameters[“Target”] is Entity)

    {

    // Obtain the target entity

    entity = (Entity)Context.InputParameters[“Target”];

    // Only perform this code if this is a create

    if (Context.MessageName != “Update”) { return; }

    // Only perform this code for a certain entity

    if (Context.PrimaryEntityName != “account”) { return; }

    // Only perform this code if this column is included in the collection of attributes

    else { return; }

    }

    else { return; }

    try

    {

    // update entity attribute with attribute value

    entity.Attributes[“name”] = “John”;

    //Update account entity

    service.Update(entity);

    }

    }

    catch (FaultException<OrganizationServiceFault> e)

    { trace.Trace(string.Format(“Exception: {0}”, e.ToString())); }

    catch (Exception ex)

    { trace.Trace(string.Format(“Exception: {0}”, ex.ToString())); }

    }

    }

    Sample code lines use to update Account attribute name value as John. So after an account is created in CRM, account name attribute is updated as “john”.

    At the end build project and right click on package and select deploy.

    Deploy_10
  • DotNetNuke CSS Precedence

    DotNetNuke CSS Precedence – DotNetNuke skinning isn’t easy exactly how CSS files from the framework get loaded at runtime. You need to spend time for fine tuning the details such as typography, padding, margin, and so on. There is secret of understanding DotNetNuke CSS precedence.

    There are many CSS files being loaded on a page when a user lands on your site. Depending on how your site is configured (how many modules you have on a page, etc), there can be several CSS files the user must download and it can definitely affect performance. In HTML development it’s a good practice to separate content and design. The CSS styles that make up the actual design are defined in separate files called stylesheets.DotNetNuke loads several style sheets for a page. For every level of DotNetNuke there is a style sheets that could be loaded / used.

    Hierarchy of CSS in DotNetNuke:

    • Module.css
    • Default.css
    • Skin.css
    • NewSkin.css
    • Container.css
    • NewContainer.css
    • Portal.css

    FRAMEWORK STYLESHEET:

    This file that contains basic framework CSS, gets loaded for every portal (Site) in your installation of DotNetNuke.This is the only stylesheet that always gets loaded.

    File Location:

    /Portals/Default/Default.css

    PORTAL / SITE STYLESHEET:

    This file is specific to a portal.
    By default it does not contain any CSS, but it can be edited by a site admin from within DNN to overrule CSS in the skins. (Mostly used for small tweaks).

    File Location: /Portals/”PortalFolder/Portal.css

    Points to Ponder:

    If you remove this file from the portal folder it does not get loaded through the file manager. This is the file you edit if you use the stylesheet editor on the Site Settings page. It is there to allow an admin to overwrite CSS defined in one of the other stylesheets.Currently there is no possibility to edit the other stylesheets from the admin interface.

    SKIN PACKAGE RELATED STYLESHEETS:

    These style sheets only get loaded if they exist in the skin package.
    (if you don’t add them to the skin package, there won’t be a link in the head of the page)
    STYLESHEETS FOR ALL SKINS:

    Style sheet that contains CSS for all the skins in a package. If a Skin.css file exists in the package it will load for every skin in the package.
    Location:
    /Portals/~Default/Skins/”NewSkin”/Skin.css
    or
    /Portals/”PortalFolder”/Skins/”NewSkin”/Skin.css
    STYLESHEET FOR A SPECIFIC SKIN:

    Style sheet with the same name as a skin file (.ascx).It is used to overwrite styles from Skin.css for that specific skin variation.

    Location:
    /Portals/~Default/Skins/”NewSkin”/”SkinName”.css
    or
    /Portals/”PortalFolder”/Skins/”NewSkin”/”SkinName”.css
    STYLESHEET FOR ALL CONTAINERS:

    Style sheet that contains CSS for all the Containers in a package. If a Container.css file exists in the package it will load for every container used from the package.
    Location:
    /Portals/~Default/Containers/NewContainer/Container.css
    or
    /Portals/”PortalFolder”/Containers/NewContainer/Container.css

    STYLESHEET FOR A SPECIFIC CONTAINER:

    Style sheet with the same name as a container file (.ascx).It is used to overwrite styles from Container.css for that specific container variation.
    Location:
    /Portals/~Default/Containers/ NewContainer /”ContainerName”.css
    or
    /Portals/”PortalFolder”/Containers/ NewContainer /”ContainerName”.css
    STYLESHEETS FOR MODULES:

    Some modules come with a style sheet with some basic CSS to make sure the module renders ok.
    If a module on the page has a Module.css file it will get loaded.
    Obviously only the Style sheets of modules on the page are loaded.

    Location:
    /DestopModules/”ModuleName”/Module.css

  • What’s the Difference between Zen Cart & Magento?

    What’s the Difference between Zen Cart & Magento?- Zen Cart & Magento are both open source products but each comes with features that make it preferable over the other. It is only by looking at the features of each that you can make a decision on the best for your e-commerce platform.

    Magento

    This is a perfect platform for companies in search of a professional online appearance. It accommodates standard add-ons to enhance the experience of your users. Here are some of the features to expect.

    • Incredible flexibility when dealing with pricing and coupons
    • An impressively advanced filter function that allows you to achieve numerous categories
    • An admin function that allows you to add, remove and edit orders
    • An incredible number of modules
    • Does not require advanced coding skills
    • An impressive template system

    Zen Cart

    This is the perfect option for beginners because of the coding aspect. It is preferred by shop owners who wish to handle coding on their own. The features to expect include

    • A comprehensive package of features to enable online sales
    • Perfect for beginner coding
    • Its footprints are light which increases accessibility on a shared environment
    • Very user friendly
    • An active development teams means that you get new and exciting products on regular basis