Friday, October 11, 2019

Problem with creating new content database for web application in Sharepoint and Full recovery mode

If you want to create new content database for web application using New-SPContentDatabase cmdlet you should be aware of one side effect related with this action: new content database will be created with Full recovery mode by default even if your basic content database has Simple recovery mode:

With Full recovery mode transaction log will grow quite fast until you will do full backup. It may be significant consideration for large content databases. So before to start using it you may want to change recovery mode of additional content database to Simple. If you moved existing site collection there using Move-SPSite – transaction log already may be quite big. So after changing recovery mode you may also need to shrink log file.

Friday, October 4, 2019

How to test and debug Timer triggered Azure functions running locally on localhost

With Azure function project type we may create many types of Azure functions. One of them is Timer triggered Azure function which is triggered by scheduler (CRON expression is specified during function creation and may be modified later in Azure function attribute):

When you will run this function locally (on locahost) you will notice thatt it won’t be listed under

http://localhost:7071/api/*

address together with Http triggered Azure function. Runtime will call your function automatically when schedule time will come. But this is not very convenient since during development you would probably like to have possibility to call it synchronously on demand.

In order to call Timer triggered Azure function you may use Postman tool. You have to construct URL little bit different from Http triggered functions: instead of /api you should send POST request to http://localhost:7071/admin/functions/* base url and send the following request body:

{
    "input": ""
}

Using this technique you may debug your Timer triggered Azure functions synchronously.

Wednesday, October 2, 2019

Different nuget packages of Camlex.Client library for different Sharepoint versions

There is excited news for those Sharepoint developers which use Camlex in their work: now Camlex.Client library (Camlex version for CSOM) is available for each Sharepoint version as separate nuget package:

Sharepoint versionNuget package
2013 on-prem Camlex.Client.2013
2016 on-prem Camlex.Client.2016
2019 on-prem Camlex.Client.2019
SPO Camlex.Client.dll

Before it was only Sharepoint Online version Camlex.Client.dll (see here). May be it is more logical to call it package for SPO version Camlex.Client.Online but since this package exists quite a long time I left it to keep backward compatibility.

So now for targeting correct Sharepoint version you may just add appropriate nuget package to your project and work with it. Each package contains Camlex.Client.dll assembly which is compiled using appropriate versions of CSOM (Microsoft.SharePoint.Client.dll and Microsoft.SharePoint.Client.Runtime.dll). This approach is similar to those which is used e.g. in OfficeDevPnP which uses different nuget packages for each Sharepoint version.

This feature is well wished feature and was requested many times so probably many developers will find it useful. The only reason which prevented me to do it earlier is that it will increase maintenance time and as I’m the only developer who maintains the project it is quite significant. But now time has come and now with each new release all 4 nuget packages for Camlex.Client will be updated.

Friday, September 20, 2019

Fix The EntityContainer name must be unique EF error in Sharepoint

If you use Entity Framework in Sharepoint (I described one useful technique which simplifies usage of EF in Sharepoint in this article: Build connection string for Entity Framework programmatically via code or use Entity Framework in Sharepoint Timer jobs) you may face with the following error:

The EntityContainer name must be unique. An EntityContainer with the name '…' is already defined

Although in your project (class library which you install to GAC for using it in Sharepoint) there is single entity container with specified name.

The problem is that entity container name appears to be unique within project boundaries. I.e. if you have another project which is compiled and installed to the GAC and loaded to the same app domain and which uses the same metadata for Entity Framework data model like:

res://*/DataModel.csdl|res://*/DataModel.ssdl|res://*/DataModel.msl

and then install another assembly to the GAC with the same EF data model metadata – you will get the above error when second project will be loaded to Sharepoint site’s app domain. This is not that obvious that you have to use unique name for EF entity containers across all assemblies used in Sharepoint. Solution for this problem is to rename EF data model in second project so it will have unique name:

res://*/Project2DataModel.csdl|res://*/Project2DataModel.ssdl|res://*/Project2DataModel.msl

After that your code will start working in Shrepoint.

Thursday, September 12, 2019

Use Office 365 connected groups in Yammer

Yammer platform allows you to integrate your Yammer groups to Office 365. Technically it means that each time when new Yammer group will be created it will be also created in Azure AD of the tenant of this Yammer network. More information about Yammer and O365 groups can be found in this article: Yammer and Office 365 Groups. This article also contains information how to enable Office 365 connected groups in Yammer and which conditions should be met before you will be able to enable it:

  • You must enforce Office 365 identity for Yammer users. When you first enforce Office 365 identity there is a seven-day trial period, after which the Status of your Office 365 Identity Enforcement changes to Committed.
  • Your Yammer network must be in a 1:1 network configuration. This means you have one Yammer network that is associated with one Office 365 tenant.

Note that currently it is possible to enforce Office 365 identity for Yammer users without 7 days trial i.e. right away.

In order to enable Office 365 connected groups in Yammer it you need to login to your Yammer network with administrator account and go to Network settings (gear icon in top left) > Network Admin > Security setting. On this page at first we need to enforce Office 365 identity for Yammer users:

Once it’s status will be changed to Committed after some time “Office 365 Connected Yammer Groups” setting will be changed to Enabled:

Documentation above says that it takes up to 24h to change status to Enabled. But in my case it was changed quite fast: almost immediately after enforcing of Office 365 identity for Yammer users.

Let’s see what happens when “Office 365 Connected Yammer Groups” setting is disabled for your Yammer network. When you create new Yammer group:

this group won’t be found in Azure AD of the Yammer network’s tenant:

After Office 365 Connected Yammer Groups have been enabled Yammer groups will appear in Yammer:

So you will be able to use all advantages of O365 connected groups. Note that for those Yammer groups which already exist when O365 connected groups had been enabled also appropriate O365 groups will be created after some time. Documentation says that it may take up to 1 week:

After about 1 week, existing eligible groups will be converted to Office 365 groups.

but for me it also happened quite fast within 1 hour or so.

Wednesday, September 11, 2019

Camlex 5.1.1 and Camlex.Client 3.2.1 are released

Today I’ve released new versions of Camlex library: Camlex 5.1.1 and Camlex.Client 3.2.1 (for Sharepoint client object model). In these versions reverse engineering support has been added for Includes/NotIncludes operations (support for Includes/NotIncludes operations was added in Camlex 5.1 and Camlex.Client 3.2). This is common practice currently that at first basic feature is released and then reverse engineering support is added into next minor release. Also http://camlex-online.org service was updated with new version.

Primary goal of reverse engineering is to power Camlex Online web site where developers may convert plain CAML query to C# code with Camlex. I.e. it simplifies usage of Camlex for developer who doesn’t familiar with its syntax yet (also there should not be those nowadays Smile ). I.e. you may enter CAML query like:

<Query>
  <Where>
      <Includes>
        <FieldRef Name="Title" />
        <Value Type="Text">Hello</Value>
      </Includes>
  </Where>
</Query>

and it will convert to to the following C# code:

Camlex.Query().Where(x => ((object)(string)x["Title"]).Includes((object)"Hello")) 

Tuesday, September 3, 2019

Problem with not unique web ids for Sharepoint Online web sites created with Fast Site Collection creation

When you create modern Team or Communication sites which use Fast Site Collection creation (not only from UI but also e.g. using New-PnPUnifiedGroup cmdlet) you may face with unexpected surprise: web id of the root sites (SPWeb.ID) of different site collections created this way may be equal!

Connect-PnPOnline https://{mytenant}.sharepoint.com/sites/site1
Get-PnPWeb
Title             ServerRelativeUrl        Id

-----             -----------------        --

site1             /sites/site1             {guid1}


Connect-PnPOnline https://{mytenant}.sharepoint.com/sites/site2
Get-PnPWeb
Title             ServerRelativeUrl        Id

-----             -----------------        --

site2             /sites/site2             {guid1}

This may be crucial if you have custom features which depend on web id. At the same time site collection ids appears to be different (SPSite.ID). Which means that if you have custom feature which identifies sites by SPWeb.ID only it will be safer to modify it so it will use pair (SPSite.ID, SPWeb.ID) to identify sites.