Office 365 Public Website Branding

Office 365 provides by default a public website which is usually located at an URL similar to this:
og-bit.com

http://mydomain.com/pages/default.aspx

The pages folder is already set up with public permissions. This allows the site to be visited by non-authenticated users. The pages on this site are created with the root.master page. This master page can’t be modified to brand our site. The main reason is because there is a WYSIWYG editor available for these pages that allow you customize the site with predefined styles and themes. Any attempts to modify the root.master files would cause the website to break.

How do I brand my Office 365 website?

Depending on your expertise on web design and SharePoint Online (This is on what Office 365 is built on); you can brand an Office 365 with the following options:

Option 1 – Default Public website with WYSIWYG editor

Use the default public website with the default themes and styles right from the browser. This is the easiest approach, and it will deliver a basic website design with a basic layout and theme. You will be able to add a header, footer and navigation menus. We can also change the layout structure by adding different zones to the page. We can also add page title, description and keyword Meta tags to aid on SEO. Most people are really not happy with the results they get from this option.

Option 2- Public website with CSS and JavaScript.

This option allows you to use option 1 as the baseline with further customization with the use of CSS and JavaScript. Office 365 allows us to apply a custom style sheet to the website. With this style sheet, we can control many of the design elements of the website. For example, we can customize the header, footer and menu with background images and different layout effects. If we need to add other HTML elements to the web pages, we can include JavaScript with the use of a PayPal gadget (hack to avoid using the HTML gadget which uses iframes). This lets us add HTML into the page with the use of a XSL template. This option requires experience in website design and development, but it provides a lot more flexibility on the design. The main problem here is that we are still bound to using the root.master page.

Option 3 – Public Website with SharePoint Designer

When the first two options are not providing all the flexibility you need, you can now start using SharePoint Designer. This is a developer tool that allows us to open an Office 365 site and have more control over the design of the site. We can open the website pages with this editor and fully customize the HTML (within the Container tags that are required by the master page). Once we start doing customization at this level, the WYSIWYG editor on the browser will no longer work. This approach makes designer and developers happy because there is more control on the design and folder structure of the website without the need to know SharePoint specifics.

Option 4 – Create pages with a different master page and SharePoint Designer

If you are ready to move away from the root.master file, this is the approach for you. With SharePoint Designer, we can attach pages to a different master file. This master file can be customized to meet all of our design needs. For example, we can create a HTML5 master template with all the branding requirements and attach the new pages to this new master template.  This however increases the complexity level because your master page needs to meet a few requirements to be a valid SharePoint master page. At this level, SharePoint knowledge starts to become a dependency. There are however a few basic templates that can be used as a starting point.

Option 5 – Create a new sub site and make this your public website with SharePoint Designer

Office 365 allows us to create sub-sites which are created private by default. We can however change the access setting and make it public. Once we make a sub-site public, we can set any page in the sub-site as the site home page (this is a global site setting).  This tells SharePoint that when a person navigates to your domain http://mydomain.com that the browser should be redirected to the home page which now resides at the new sub-site. This is how it works for the default public website. SharePoint basically redirects users to http://mydomain.com/pages/default.aspx. For a sub-site, SharePoint redirects the users to something like: http://mydomain.com/sitepages/home.aspx.

With this approach, you now need to know more about SharePoint administration and development. The benefits are that we can now integrate SharePoint features to the public website. For example, we can display a document library, calendar, lists, custom web-parts and custom business solutions. For public users to create new records in a list, you will need to explicitly provide public write access to that list.

Main Difference between SharePoint on premises VS SharePoint online

The main difference between SharePoint on Premises and online is that you can only deployed Sandboxed solutions on the online edition.  A Sandboxed solution is isolated, and SharePoint will block it if the solution starts to become unstable. The reason behind this is because this is a Multi-tenant environment, and it is not convenient to have one tenant’s solutions affect other tenant’s sites.  This also implies that certain resources are not available for a Sandboxed solution compare to a Farm Solution which limits what you can do for your custom solutions.

Summary

SharePoint branding is not as easy as a normal HTML website, and depending on your skill set, you may choose any of the listed options above. If you are not familiar with SharePoint, you may want to partner with a company that has this expertise. I hear from many designers and a developer how frustrating is to work with this product, but like anything, certain level of expertise is required to know how to work with a particular technology.

 I hope I was able to show you a few approaches on how to brand your SharePoint public website.

Office 365 provides by default a public website which is usually located at an URL similar to this: og-bit.com http://mydomain.com/page...

Read Article →

The type was not expected. Use the XmlInclude or SoapInclude attribute to specify types that are not known statically

When trying to serialize a complex object using the XmlSerializer, we can encountered a Type was not expected exception. This exception is generated as a result of a property declared as a base type, but the actual reference is done with a child class instance. For example:

og-bit.com

Class Declaration:

public class Account

{

int number { get; set; }

}

public class Client

{

public object[] Accounts { get; set; }

}

The client class has an array of Accounts, but the declaration of the property uses object instead of the Account class. When we try to serialize an instance of Client with the code below, the exception is generated:

Client client = new Client();

client.Accounts = new Account[]{new Account(), new Account()};

StringBuilder stringBuilder = new StringBuilder();

           

 using (XmlWriter xmlWriter = XmlWriter.Create(stringBuilder))

 {

          XmlSerializer serializer = new XmlSerializer(typeof(Client));

          serializer.Serialize(xmlWriter, objRef); 

           xmlWriter.Flush();

  }

InnerException      {"The type Account was not expected. Use the XmlInclude or SoapInclude attribute to specify types that are not known statically."} System.Exception {System.InvalidOperationException}

Solution:

The serializer expects a type of object, but it finds a type of Account instead. The easy fix would be to refactor the property and use Account instead of object. This is not as easy when we do not have access to the source code as in the case when using a third party API. When this is the case, we can tell the serializer to expect unknown types by including an array of types when instantiating the XmlSerializer which provides the following constructor:

public XmlSerializer(

                   Type type,

                   Type[] extraTypes

)

We can now change the previous code with the following:

Client client = new Client();

client.Accounts = new Account[]{new Account(), new Account()};

Type[] types = new Type[] { typeof(Account)};

StringBuilder stringBuilder = new StringBuilder();

           

  using (XmlWriter xmlWriter = XmlWriter.Create(stringBuilder))

  {

                 XmlSerializer serializer = new XmlSerializer(typeof(Client),types);

                 serializer.Serialize(xmlWriter, objRef); 

                 xmlWriter.Flush();

 }

We are now creating an array of Type[] and passing that information to the serializer in its constructor. If you run this code, you can now notice that the exception is no longer raised.  We should also notice that there may be other properties with this problem. When this is the case, we need to include all those types in the array as follows:

Type[] types = new Type[] { typeof(Account), typeof(Address)};

In this case, we added the Address type as another possible type which should be included during the serialization.

I hope I was able to help you understand why this exception is raised when serializing complex objects and show you a way to handle the problem.

When trying to serialize a complex object using the XmlSerializer, we can encountered a Type was not expected exception. This exception is...

Read Article →

There was no endpoint listening - WCF Certificate Policy

When using WCF with transport security, you may encounter this error:

og-bit.com

“There was no endpoint listening at https://servername/Service1.svc that could accept the message. This is often caused by an incorrect address or SOAP action”

This is often caused because we tend to use a dev or expired certificate which is actually not valid and causes an invalid certificate exception that drops the communication with the server. To address this on the dev environment, we need to add a certificate policy that can handle the invalid certificate.

This can be done by first adding a policy class:

public sealed class CertificatePolicy

{

        /// <summary>

        /// certificate policy handler

        /// </summary>

        public static void SetPolicy()

        {

System.Net.ServicePointManager.ServerCertificateValidationCallback += RemoteCertValidate;

        }

        /// <summary>

        /// remote certificate validation.

        /// </summary>

 private static bool RemoteCertValidate(object sender,       System.Security.Cryptography.X509Certificates.X509Certificate cert,

System.Security.Cryptography.X509Certificates.X509Chain chain, System.Net.Security.SslPolicyErrors error)

        {

            //ignore invalid certificates by returning true

            return true;

        }

  }

With the policy now in place, we need to add it to the client code before calling the web service as follows:

CertificatePolicy.SetPolicy();

//TODO ADD CALL TO WEB SERVICE HERE

With the SetPolicy call, we added a policy to validate the remote certificate. In the case of an invalid certificate and with no policy, this usually creates an un-handled exception which terminates the communication. With this policy, we handle the validation of the certificate and return true to ignore any invalid certificate exception. This policy should only be used on dev environment. In production, the certificates should be valid for the most part.

I hope I was able to show how to handle this exception and manage invalid certificates on your WCF service.

When using WCF with transport security, you may encounter this error: og-bit.com “There was no endpoint listening at https://serverna...

Read Article →

WCF Service Configuration Visualized

I created this diagram that attempts to help us visualize how a WCF service configuration is constructed. The diagram does not display every single attribute that can be added to a configuration, but the goal is to show the main settings and their associations.  The diagram is divided into two main layers:

Custom Assembly and WCF Service configuration

Custom Assembly:

This is the layer that contains the custom assemblies with the implementation of the service contract, security policies and custom user validators.

WCF Service Configuration:

This is the XML that resides in the app/web.config file. It contains all the elements that are needed to configure a WCF service with its endpoint, binding and behavior configuration. Each one of these elements can also contain other elements to further define the communication details, security and behaviors for the service. 

This diagram provides a simple visualization of the main elements and their association.

og-bit.com

I created this diagram that attempts to help us visualize how a WCF service configuration is constructed. The diagram does not display every...

Read Article →