There’s guidance on system requirements, deployment scenarios & prerequisites.  A new MinRole feature is also explained (with a short, to-the-point video).  He also throws light on health rules & compliance and Upgrade & Migration options.

Read his blog here.

So today I wanted to debug a process that was running on Windows Server 2012 R2 server.  I launched the remote debugger on the server from C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\Remote Debugger\x64 by double-clicking msvsmon.exe.

Got back to my Windows 8.1 box where I have Visual Studio 2013 and tried to connect to the remote computer.  Connection was successful.  But when I tried attaching to a process on the remote server, I hit the below clear error.

This is despite the fact that I have set UAC to “Never notify” (Not recommended) setting.

To fix this problem, I simply launched msvsmon.exe as administrator and that fixed my problem.

Just thought of sharing this out as this really was not something I expected with UAC turned OFF.  And this never happens on my other boxes that are running Windows Server 2008 R2 (with UAC turned OFF).  And to also propagate this message “Trust the error message displayed, no matter whatever our human minds tell us based on our logical derivations from facts.” (not always true I understand, but this time it certainly was!).

Happy debugging!!!

I “boxed” the more information link intentionally as I feel that’s not highly discoverable.  It can be easily reached if we use keywords like “custom script sharepoint online” in our favorite search engines, but not when we search using keywords based on the symptoms we see as a result of this custom script feature.

Here’s the same link, you might want to bookmark it: Turn scripting capabilities on and off.

From the above screen shot we can see that in my SharePoint online tenant, custom script feature is turned ON on personal sites (i.e., Prevent users from running custom script on personal sites) that will not allow users to write scripts using the embed code option for example.  Also notice that custom script feature is turned OFF on self-service created sites (i.e., Allow users to run custom script on self-service created sites).  This means if I create a private site collection, users with appropriate rights should be able to use embed code option and write client-side scripts.  For most of us the options might be obvious, but just wanted to share this out.

The following are the symptoms we would encounter if custom script feature is turned ON (which is BTW the default).

NOTE: Below sections are duplicated from the original link above for quick read.

The following site settings will no longer be available after scripting has been disabled (i.e., the prevent radio button is selected for both personal/self-service created sites).

The following web parts and features are unavailable to site collection owners and site owners after scripting has been disabled.

Custom properties of app parts missing/does not display

Other than the above list, we’ve also observed that custom properties in app parts would be missing when custom script feature is turned ON (i.e., prevent scripts from running).  The resolution is to turn custom script feature OFF thus allowing scripts to run.  This brings back the missing custom properties in app parts.

Unable to upload ASPX files

When custom script feature is turned ON, we might also run into a problem where we are unable to upload ASPX files (JS/HTML files upload just fine).

Enabling script

To allow scripts, all that we have to do is to ensure we choose allow radio button on the appropriate site collection type we need (personal, self-service created sites).  It takes 24 hours for the change to take effect as pointed out in the above link.

If you run into some other problems that you think should normally work in SharePoint, I’d first give custom script feature a shot!

Hoping the information in this post was helpful.

The create workflow dialog.

The downloading data dialog.

Then the cache building dialog comes up.

Then… nothing happens!

Now we know that SharePoint Designer 2013 issues web calls to the server it’s connecting to pull all the information it needs.  With this knowledge, I pulled up our good friend Fiddler and looked at what’s happening behind the scenes.  There was this following request:

<Request AddExpandoFieldTypeSuffix="true" SchemaVersion="15.0.0.0" LibraryVersion="15.0.0.0" ApplicationName=".NET Library" xmlns="https://schemas.microsoft.com/sharepoint/clientquery/2009"><Actions><Method Name="GetActivitySignatures" Id="934" ObjectPathId="916"><Parameters><Parameter Type="DateTime">0001-01-01T00:00:00.0000000</Parameter></Parameters></Method></Actions><ObjectPaths><Method Id="916" ParentId="912" Name="GetWorkflowDeploymentService" /><Constructor Id="912" TypeId="{4ccc7f0e-bf7e-4477-999c-6458a73d0039}"><Parameters><Parameter ObjectPathId="3" /></Parameters></Constructor><Identity Id="3" Name="740c6a0b-85e2-48a0-a494-e0f1759d4aa7:site:12ea7af2-a10f-4eb8-a0bd-b600a085a2b8:web:0feddf5a-d707-4811-b1b1-3e46ba3eb9cd" /></ObjectPaths></Request>

Which resulted in the following response:

[
{
"SchemaVersion":"15.0.0.0","LibraryVersion":"15.0.4667.1000","ErrorInfo":{
"ErrorMessage":"File Not Found.","ErrorValue":null,"TraceCorrelationId":"1871ef9c-f2ff-e017-728a-ae7eecfba3fc","ErrorCode":-2147024893,"ErrorTypeName":"System.IO.DirectoryNotFoundException"
},"TraceCorrelationId":"1871ef9c-f2ff-e017-728a-ae7eecfba3fc"
}
]

Now the System.IO.DirectoryNotFoundException was familiar to me from the previous post, so it was a quick guess.  But the point is that when workflow deployment service is called (specifically the call GetActivitySignatures) ends up in Microsoft.SharePoint.WorkflowServices.Activities.dll.  Now this was a new environment I provisioned and I was careful to first get workflow manager registered with SharePoint Server 2013 and then install Office Developer Tools for VS 2013.  However, I did not recall to create the WorkflowActivities folder and drop Microsoft.SharePoint.WorkflowServices.Activities.dll into it as explained in my previous post linked.  Apparently, SharePoint Designer 2013 wasn’t able to communicate with the workflow manager because of the above error.

After implementing the fix in my previous post, SharePoint Designer 2013 was good and I was able to create workflows using 2013-platform.

As an aside, if we implement the fix and then delete the WorkflowActivities folder, we can still create 2013 workflows without problems.  This is because once the activities are cached, SharePoint Designer 2013 picks it up from cached location.  However, I think we should not do that (i.e., deleting WorkflowActivities folder) because when WFM/SharePoint is upgraded and if there’s a newer version of Microsoft.SharePoint.WorkflowServices.Activities.dll, we’ll run into the same problem.

Hope this post was informative and useful…!

<script type="text/javascript">

    ExecuteOrDelayUntilScriptLoaded(spCallOut, 'SP.js');    

    var web;

    function spCallOut() {

        var clientContext = new SP.ClientContext.get_current();

        this.web = clientContext.get_web();

        clientContext.load(this.web, 'Title');

        clientContext.executeQueryAsync(Function.createDelegate(this, this.onQuerySucceeded), Function.createDelegate(this, this.onQueryFailed));

    }

    function onQuerySucceeded(sender, args) {

        alert(this.web.get_title());

    }

    function onQueryFailed(sender, args) {

        alert('Request failed. ' + args.get_message() + '\n' + args.get_stackTrace());

    }

</script>

According to the logic in the above code, we expect to see a message box with the current web’s title.  However, the message box pop-up never appears when the option to “Hide Ribbon” is enabled on publishing sites.

We found this to be because the client-side libraries (SP.js etc.,) was not loaded yet.  To circumvent this problem we replaced the call to ExecuteOrDelayUntilScriptLoaded(spCallOut, ‘SP.js’) to EnsureScriptFunc("SP.js", "SP.ClientContext", function() { spCallOut() }) (EnsureScriptFunc is definite in init.js).  And that fixed this problem.

Apparently ExecuteOrDelayUntilScriptLoaded function is not the correct one to be used in this case, but EnsureScriptFunc is, which also loads the dependent libraries on-demand.

Hope this post was useful in your client-side development efforts!

Here’s the sequence of my installation.

1. Installed SharePoint 2013 RTM + SP1 and then SharePoint 2013 November CU 2014.  Ran PSConfigUI.exe – successful.

2. Installed Workflow Manager 1.0 Refresh by downloading it through Web Platform Installer.  Provisioned Workflow Manager farm – successful.

3. Installed Microsoft Office Developer Tools for Visual Studio 2013 – November 2014 Update through Web Platform Installer. <<< This steps appears to be the culprit as this deletes the 15\TEMPLATE\WorkflowActivities folder and the DLL within it >>>

4. Then issued the Register-SPWorkflowService command to register the WFM farm with SharePoint 2013 and hit the below error.

Before installing Office Developer Tools November 2014 Update, the WorkflowActivities folder had Microsoft.SharePoint.WorkflowServices.Activities.dll in it.

After installing Office Developer Tools, the WorkflowActivities folder was deleted.

After hitting this error, I just had to pick this assembly from the .NET 4.0 GAC and copy it into 15\TEMPLATE\WorkflowActivities folder after creating WorkflowActivities folder under \15\TEMPLATE path.

The path I copied this assembly from is: C:\Windows\Microsoft.NET\assembly\GAC_MSIL\Microsoft.SharePoint.WorkflowServices.Activities.  [NOTE: If you have latest CU of SharePoint 2013 installed (like SharePoint 2013 November CU 2014) then you’ll see 2 versions of this assembly (15 and 16) in the GAC.  You need to pick the 15 version of this assembly].

I then copied over this assembly to \15\TEMPLATE\WorkflowActivities folder after manually creating this folder.

Post this, I issued the Register-SPWorkflowService command with the –Force switch.

That fixed this issue for me and I was able to develop 2013-platform workflows and run it.

HTH!

I don’t wish to cover the well documented and easily searchable part of how to create a custom login page for SharePoint 2013 in this post (I know that link is for SharePoint 2010, but it’s pretty much the same for SharePoint 2013 as well).  Instead I’ll delve into the problem in hand and the solution.

Assume that we have our custom login page created and deployed to C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\TEMPLATE\LAYOUTS\CustFormsLogin as shown in the below picture.

The way we tell the SharePoint web application that it needs to use our custom login page instead of the default, is by setting the Custom Sign In Page of the appropriate zone of the web application to point to the relative path of the custom login page.

Below are the quick steps along with screenshots for quicker understanding.

1. Click Manage web applications.

2. Click Authentication Providers after selecting the web application.

3. Select the zone where FBA is configured.  In my case, I’ve configured FBA in my Default zone.

4. Scroll to the bottom of the dialog to find Sign In Page URL and set the relative path to where our custom login page is deployed to on the server.

After this, if all is well, we should see our custom login page once we browse to a site collection on the web application and should be able to login without issues.

But once we click on a SharePoint Hosted App that’s installed in this site collection.

We’ll get to see this error.  Had we used the default login page, we wouldn’t have hit this issue in the first place.

Oh yes, the above (IMO, more descriptive) error is because I had the option Show friendly HTTP error messages turned off (shown below) in IE browser.

If we have this option turned on, we’ll see a 403: Forbidden error instead.

A fiddler trace will pretty much show the same 403 error code and if we probe the ULS, we’ll see entries talking about access denied (notably, EventIDs: ftd0 and ai1wu the stack is provided below).

ftd0:

Access Denied. Exception: Attempted to perform an unauthorized operation., StackTrace:  

 at Microsoft.SharePoint.Utilities.SPUtility.HandleAccessDenied(Exception ex)    

 at Microsoft.SharePoint.SPWeb.GetWebPartPageContent(Uri pageUrl, Int32 pageVersion, PageView requestedView, HttpContext context, Boolean forRender, Boolean includeHidden, Boolean mainFileRequest, Boolean fetchDependencyInformation, Boolean& ghostedPage, String& siteRoot, Guid& siteId, Int64& bytes, Guid& docId, UInt32& docVersion, String& timeLastModified, Byte& level, Object& buildDependencySetData, UInt32& dependencyCount, Object& buildDependencies, SPWebPartCollectionInitialState& initialState, Object& oMultipleMeetingDoclibRootFolders, String& redirectUrl, Boolean& ObjectIsList, Guid& listId)    

 at Microsoft.SharePoint.ApplicationRuntime.SPRequestModuleData.FetchWebPartPageInformationForInit(HttpContext context, SPWeb spweb, Boolean mainFileRequest, String path, Boolean impersonate, Boolean& isAppWeb, Boolean& fGhostedPage, Guid& docId, UInt32& docVersion, String& timeLastModified, SPFileLevel& spLevel, String& masterPageUrl, String& customMasterPageUrl, String& webUrl, String& siteUrl, Guid& siteId, Object& buildDependencySetData, SPWebPartCollectionInitialState& initialState, String& siteRoot, String& redirectUrl, Object& oMultipleMeetingDoclibRootFolders, Boolean& objectIsList, Guid& listId, Int64& bytes)    

 at Microsoft.SharePoint.ApplicationRuntime.SPRequestModuleData.GetFileForRequest(HttpContext context, SPWeb web, Boolean exclusion, String virtualPath)    

 at Microsoft.SharePoint.ApplicationRuntime.SPRequestModule.InitContextWeb(HttpContext context, SPWeb web)    

 at Microsoft.SharePoint.WebControls.SPControl.SPWebEnsureSPControl(HttpContext context)    

 at Microsoft.SharePoint.ApplicationRuntime.SPRequestModule.GetContextWeb(HttpContext context)    

 at Microsoft.SharePoint.ApplicationRuntime.SPRequestModule.PostResolveRequestCacheHandler(Object oSender, EventArgs ea)    

 at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()    

 at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)    

 at System.Web.HttpApplication.PipelineStepManager.ResumeSteps(Exception error)    

 at System.Web.HttpApplication.BeginProcessRequestNotification(HttpContext context, AsyncCallback cb)    

 at System.Web.HttpRuntime.ProcessRequestNotificationPrivate(IIS7WorkerRequest wr, HttpContext context)    

 at System.Web.Hosting.PipelineRuntime.ProcessRequestNotificationHelper(IntPtr rootedObjectsPointer, IntPtr nativeRequestContext, IntPtr moduleData, Int32 flags)    

 at System.Web.Hosting.PipelineRuntime.ProcessRequestNotification(IntPtr rootedObjectsPointer, IntPtr nativeRequestContext, IntPtr moduleData, Int32 flags)    

 at System.Web.Hosting.UnsafeIISMethods.MgdIndicateCompletion(IntPtr pHandler, RequestNotificationStatus& notificationStatus)    

 at System.Web.Hosting.UnsafeIISMethods.MgdIndicateCompletion(IntPtr pHandler, RequestNotificationStatus& notificationStatus)    

 at System.Web.Hosting.PipelineRuntime.ProcessRequestNotificationHelper(IntPtr rootedObjectsPointer, IntPtr nativeRequestContext, IntPtr moduleData, Int32 flags)    

 at System.Web.Hosting.PipelineRuntime.ProcessRequestNotification(IntPtr rootedObjectsPointer, IntPtr nativeRequestContext, IntPtr moduleData, Int32 flags)  .

ai1wu:

System.UnauthorizedAccessException: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)), StackTrace:   

 at Microsoft.SharePoint.SPWeb.InitWeb()    

 at Microsoft.SharePoint.SPWeb.get_EnableMinimalDownload()    

 at Microsoft.SharePoint.Utilities.SPUtility.Redirect(String url, SPRedirectFlags flags, HttpContext context, String queryString)    

 at Microsoft.SharePoint.Utilities.SPUtility.HandleAccessDenied(HttpContext context)    

 at Microsoft.SharePoint.Utilities.SPUtility.HandleAccessDenied(Exception ex)    

 at Microsoft.SharePoint.SPWeb.GetWebPartPageContent(Uri pageUrl, Int32 pageVersion, PageView requestedView, HttpContext context, Boolean forRender, Boolean includeHidden, Boolean mainFileRequest, Boolean fetchDependencyInformation, Boolean& ghostedPage, String& siteRoot, Guid& siteId, Int64& bytes, Guid& docId, UInt32& docVersion, String& timeLastModified, Byte& level, Object& buildDependencySetData, UInt32& dependencyCount, Object& buildDependencies, SPWebPartCollectionInitialState& initialState, Object& oMultipleMeetingDoclibRootFolders, String& redirectUrl, Boolean& ObjectIsList, Guid& listId)    

 at Microsoft.SharePoint.ApplicationRuntime.SPRequestModuleData.FetchWebPartPageInformationForInit(HttpContext context, SPWeb spweb, Boolean mainFileRequest, String path, Boolean impersonate, Boolean& isAppWeb, Boolean& fGhostedPage, Guid& docId, UInt32& docVersion, String& timeLastModified, SPFileLevel& spLevel, String& masterPageUrl, String& customMasterPageUrl, String& webUrl, String& siteUrl, Guid& siteId, Object& buildDependencySetData, SPWebPartCollectionInitialState& initialState, String& siteRoot, String& redirectUrl, Object& oMultipleMeetingDoclibRootFolders, Boolean& objectIsList, Guid& listId, Int64& bytes)    

 at Microsoft.SharePoint.ApplicationRuntime.SPRequestModuleData.GetFileForRequest(HttpContext context, SPWeb web, Boolean exclusion, String virtualPath)    

 at Microsoft.SharePoint.ApplicationRuntime.SPRequestModule.InitContextWeb(HttpContext context, SPWeb web)    

 at Microsoft.SharePoint.WebControls.SPControl.SPWebEnsureSPControl(HttpContext context)    

 at Microsoft.SharePoint.ApplicationRuntime.SPRequestModule.GetContextWeb(HttpContext context)    

 at Microsoft.SharePoint.ApplicationRuntime.SPRequestModule.PostResolveRequestCacheHandler(Object oSender, EventArgs ea)    

 at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()    

 at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)    

 at System.Web.HttpApplication.PipelineStepManager.ResumeSteps(Exception error)    

 at System.Web.HttpApplication.BeginProcessRequestNotification(HttpContext context, AsyncCallback cb)    

 at System.Web.HttpRuntime.ProcessRequestNotificationPrivate(IIS7WorkerRequest wr, HttpContext context)    

 at System.Web.Hosting.PipelineRuntime.ProcessRequestNotificationHelper(IntPtr rootedObjectsPointer, IntPtr nativeRequestContext, IntPtr moduleData, Int32 flags)    

 at System.Web.Hosting.PipelineRuntime.ProcessRequestNotification(IntPtr rootedObjectsPointer, IntPtr nativeRequestContext, IntPtr moduleData, Int32 flags)    

 at System.Web.Hosting.UnsafeIISMethods.MgdIndicateCompletion(IntPtr pHandler, RequestNotificationStatus& notificationStatus)    

 at System.Web.Hosting.UnsafeIISMethods.MgdIndicateCompletion(IntPtr pHandler, RequestNotificationStatus& notificationStatus)    

 at System.Web.Hosting.PipelineRuntime.ProcessRequestNotificationHelper(IntPtr rootedObjectsPointer, IntPtr nativeRequestContext, IntPtr moduleData, Int32 flags)    

 at System.Web.Hosting.PipelineRuntime.ProcessRequestNotification(IntPtr rootedObjectsPointer, IntPtr nativeRequestContext, IntPtr moduleData, Int32 flags)

Looking at the stack we can guess that the app redirection process is not able to get hold of a valid SPWeb object to move on with its operation and hence failed.  We have successfully reproduced the problem now!

Solution:

The solution to this (at least the path I took) was to figure out how out of the box forms login page works.  Switching the web application in question to use the default login page, I realized that the default forms login page was served from a different location other than the 15 hive (which happens to be the default location most developers deploy their custom login page to).  The default forms login page was indeed served from a folder (configured as a virtual directory) right under the root of the IIS web site that’s running SharePoint.

The default forms login page default.aspx is served from a virtual directory named _forms.

Looking this virtual directory up from IIS Manager, I was able to determine the above fact.

Having learnt this, the solution appeared to be very simple.  I copied over my CustFormsLogin folder I had deployed under the 15 hive directly under the root of my SharePoint’s IIS web site and configured it as a virtual directory.

I then configured the Custom Sign In Page to point to the default.aspx located in the newly created virtual directory.

Now, when I browse to the site collection, I get to see the custom login page deployed to the root of the SharePoint IIS web site.

And once I login and click on the SharePoint hosted app’s hyperlink, I am correctly redirected to my custom login page again.

And needless to say, I can login and see the sample app too.

Reasoning for this solution:

Sounds like this has to do with the way app redirection is performed that it constructs the relative path to custom login page based off of the root IIS web site path that SharePoint is running on.  So, while it could figure out how to get to https://servername/custformslogin/default.aspx after the change, it couldn’t figure out how to get to https://servername/_layouts/15/custformslogin/default.aspx because the _layouts\15\custformslogin folder structure isn’t present directly under the root IIS web site that SharePoint is running on.

Hope this is helpful if you happen to hit this error at some point in time!

We were able to manually attach VS debugger to the SharePoint process (w3wp.exe) and debug it, however, if we press F5 (or DEBUG –> Start Debugging from VS), we see the following message box in VS.

Here’s some information on the environment where we were facing this issue.

Visual Studio Professional 2012 version 11.0.50727.1 with Microsoft Office Developer Tools for Visual Studio 2012 ENU version 11.0.60226.0.

Microsoft Team Foundation Server 2013 Update 2 version 12.0.30324.0.

Team Explorer for Microsoft Visual Studio 2013 version 12.0.21005.13.

On debugging this I found that the VS debugger process (msvsmon.exe) couldn’t attach to the w3wp.exe process (I was testing with a Visual WebPart project that runs on w3wp.exe) because it couldn’t load the following debugger component:

Microsoft.Workflow.DebugController, Version=12.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35

Checking the GAC, I saw an earlier version of this DLL installed.

I don’t know the exact reason why this problem happens with SharePoint project types (and only with SharePoint project/item templates, because F5 debugging works fine for other VS project/items templates).  But my best guess is that Office Developer Tools is not looking at the right place to determine which version of Microsoft.Workflow.DebugController it should use at run time.

The fix turned out to be simple.  VS debugger process C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\Remote Debugger\x64\msvsmon.exe was trying to load the incorrect version of debug controller (of course, as dictated by Office Developer Tools).  I found there’s configuration file MSVSMON.EXE uses also located in the same path pointed out above C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\Remote Debugger\x64\msvsmon.exe.config.  The default entries in this config file is shown below.

<?xml version ="1.0"?>

<configuration>

    <startup useLegacyV2RuntimeActivationPolicy="true">

        <supportedRuntime version="v4.0.30319" />

        <supportedRuntime version="v2.0.50727" />

        <supportedRuntime version="v1.1.4322" />

    </startup>

    <runtime>

        <loadFromRemoteSources enabled="true"/>

    </runtime>

</configuration>

I just added an <assemblyBinding/> element and redirected calls to 12.0.0.0 version of Microsoft.Workflow.DebugController to 11.0.0.0 version as shown below.

<?xml version ="1.0"?>

<configuration>

    <startup useLegacyV2RuntimeActivationPolicy="true">

        <supportedRuntime version="v4.0.30319" />

        <supportedRuntime version="v2.0.50727" />

        <supportedRuntime version="v1.1.4322" />

    </startup>

    <runtime>

        <loadFromRemoteSources enabled="true"/>

      <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">

        <dependentAssembly>

          <assemblyIdentity name="Microsoft.Workflow.DebugController" publicKeyToken="31bf3856ad364e35" culture="neutral" />

          <bindingRedirect oldVersion="12.0.0.0" newVersion="11.0.0.0" />

        </dependentAssembly>

      </assemblyBinding>

    </runtime>

</configuration>

Closed all instances of Visual Studio Professional 2012 and opened it.  Now F5 debugging for all projects (including SharePoint) works like charm!

Hope this helps!

The Scenario:

The scenario is the same as what’s provided in FIX: SharePoint 2013 Workflow recursion prevention – Part 2.  Only difference is that these are workflows built using Visual Studio.  We are going to take a look at how to leverage the new REST APIs to trigger off a workflow associated with a given list when item is created/updated in the list.

RECOMMENDATION: If you are using Visual Studio 2012 with Office Developer Tools, consider switching to Visual Studio 2013 with the latest Microsoft Office Developer Tools for Visual Studio 2013 – July 2014 Update (as on 22-August-2014).  There were two problem I ran into using Visual Studio 2012 with Microsoft Office Developer Tools for Visual Studio 2012.

1) When re-deploying a workflow solution through Visual Studio 2012 after performing some changes, the changes won’t be reflected in the workflow instance (when it runs).  This is because there’s perhaps some sort of file handle that’s not completely released when the process vssphost5.exe performs the deployment for us.

The workaround is to kill vssphost5.exe process before performing a re-deployment.

2) Got a weird error when I placed just the “CreateListItem” activity that simply creates an item on a list.  The error is:

System.FormatException: Expected hex 0x in "{0}". 

   at System.Guid.GuidResult.SetFailure(ParseFailureKind failure, String failureMessageID Object failureMessageFormatArgument, String failureArgumentName, Exceptio innerException) 

   at System.Guid.TryParseGuidWithHexPrefix(String guidString, GuidResult& result) 

   at System.Guid.TryParseGuid(String g, GuidStyles flags, GuidResult& result) 

   at System.Guid.Parse(String input) 

   at Microsoft.Activities.Expressions.ParseGuid.Execute(CodeActivityContext context) 

   at System.Activities.CodeActivity`1.InternalExecute(ActivityInstance instance, ActivityExecutor executor, BookmarkManager bookmarkManager) 

   at System.Activities.ActivityInstance.Execute(ActivityExecutor executor, BookmarkManager bookmarkManager) 

   at System.Activities.Runtime.ActivityExecutor.ExecuteActivityWorkItem.ExecuteBody(ActivityExecutor executor, BookmarkManager bookmarkManager, Location resultLocation)

The reason for this error and solution is documented is my good friend Chandrasekar’s blog post (thanks Chandru!).  The context there is list lookup activities.  But the resolution is the same because technically “CreateListItem” is also a sort of a list lookup activity on which we can create items.

Having said that let’s now look at our objective.

VSList1 has the workflow VSWF1 associated with it and it’s designed to create a list item on another list VSList2.

The “CreateListItem” activity is declared like shown below.  It creates an item on VSList2 and it returns ItemId which is the integer value (list item ID – the sequence number).  We create a new variable named NewItemId to store this value.

NOTE: This is one difference between a Visual Studio workflow and SharePoint Designer workflow when we try to create an item.  While the return value we get from “CreateListItem” activity is an integer value, the return value from “Create List Item” is the GUID of the item that got created.

For the actual list item, we simply write some text to the title property as shown below.

On VSList2, we associate another workflow named VSWF2.  This workflow simply writes “VSWF2 triggered successfully on item creation.” to history list as shown below.

NOTE: It’s not required that this workflow should be a Visual Studio workflow, it can be a SharePoint Designer workflow as well.  Just to keep this post simple, I am using another VS workflow.

After deploying these workflows, we go to VSList1, create an item and start off VSWF1 manually on that item.  We should see the following in workflow status page.

And then we visit VSList2 and see that the new item is created successfully.

The problem:

However, the /workflow.aspx page indicates that there were no VSWF2 instance ever run whereas it should have since we have setup VSWF2 workflow to auto-start when it is created/updated.  This is the actual problem.

Fix:

We basically need to do the same things we did for SharePoint Designer Workflow (walk through here).  We open VSWF1 solution and add a “BuildDynamicValue” activity.  Set its Properties to what’s shown below.

We create a variable named “RespContent” of type “DynamicValue”.  We won’t see the “DynamicValue” type in the dropdown immediately so we’ll have to choose “Browse for Types” and search for “DynamicValue” and pick it up as shown in the pictures below.

Assign the “ReqHeader” variable to the Result property of BuildDynamicValue activity.

Next we drop a “LookupWorkflowContextProperty” activity.  We create a new variable named “SiteUrl” of type string.  Click on “LookupWorkflowContextProperty” and in the properties windows of Visual Studio 2013, choose “Current Site URL” for “PropertyName” and set “Result” to the new string variable “SiteUrl” we just created as shown below.

We did this to pick up the current site’s URL that we need to use later for sending the HttpSend requests.

The first thing we need is the GUID of WFList2.  To get that design a HttpSend method and get the GUID.  Drop a HttpSend activity.  Choose GET for the Method in the properties window of HttpSend activity.  Set RequestHeaders property to ReqHeader, the variable we created above.  For the Uri property provide the following value:

Hit OK.  We create a new variable named ResponseContent of type DynamicValue and assign that to ResponseContent property in HttpSend activity.  Now our HttpSend activity should look like the below.

We drop a “GetDynamicValueProperty<T>” activity next.  When we get the small window to select the type for <T> we choose System.Guid (again use Browse for Types… and pick Guid by searching for it).  Click on “GetDynamicValueProperty<T>” and set PropertyName field in the properties window to "d/Id".  For the Source field choose the variable ResponseContent that we used to store the output from the above HttpSend method call.  Create a new variable named WFList2Guid of type System.Guid and set that as the value for Result field in “GetDynamicValueProperty<T>” properties window.  Now we should have the workflow designed as shown below.

Now that we have the GUID of WFList2 stored in the variable List2Guid, we move forward to pick up the workflow subscription Id of the workflow we are interested in by calling /_api/SP.WorkflowServices.WorkflowSubscriptionService.Current/EnumerateSubscriptionsByList(guid'" + List2Guid.ToString() + "')?select=Id.  This again is a HttpSend method so we go ahead and design it.  The only think to note is that this will be a HTTP POST request.  The completed design should look like below.

Next we drop two more “GetDynamicValueProperty<T>”.  We design the first one (the type should be GetDynamicValueProperty<DynamicValue>) as shown below.

NOTE: As to how we decided to use “d/results(0)”, please review the part about using Fiddler to determine this in part 2.  But for this walk through, we use Fiddler, replay the request to get workflow subscriptions on list VSList2 and then we choose the correct one.  Below is the response we get from Fiddler.

The response shows we have 3 workflow subscribed to this list.  But the one we need is the first one whose name is “VSWF2 – Workflow Start” which is at index 0.  So we use “d/result(0)”.  The 2nd and 3rd are the triggers to start this workflow when an item is added or updated.

We create a variable named VSWF2SubscriptionId of type System.Guid.  And we design the second one (the type should be GetDynamicValueProperty<System.Guid>) as shown below.

Now we have both the parameters we need to call StartWorkflowOnListItemBySubscriptionId REST method.  We’ll design our next HttpSend method to do exactly that.  The Uri property of our HttpSend method will be what’s shown below.

The complete design of this final HttpSend method should look like what’s shown below.

We’ve just assigned the ResponseContent field to the ResponseContent variable we created above (we are reusing the same variable).  But it actually does not matter for this REST method call.  And that’s it!!

Re-deploy VSWF2 back to VSList1.  We then browse to VSList1, create another item and start off VSWF1 on that item manually.  Now we browse to VSList2 and we can see the new item that was created by VSWF1 workflow.

And now if we visit the workflow status page we should see the following.

If we click the Completed hyperlink, we should see the text we logged to the workflow history list.

I hope these walkthroughs posted in this series were helpful and gives everyone some basic insights into SharePoint REST APIs.

Tip:

Everyone should already know this, but a very quick way to find out SharePoint REST methods is by appending the $metadata attribute to the _api endpoint (e.g., https://sp/_api/$metadata).  This will get us all REST methods and their input/output parameters, which I think will be quite helpful.

For e.g., I can check the method EnumerateSubscriptionsByList using this technique as shown below.

Happy exploring!

The scenario:

List1 has a workflow Workflow1 associated with it.

Workflow1 can be set to auto-start on item adding/updating or set to manually start or both, it doesn’t matter.

Workflow1 is designed to create a list item on List2.

List2 has a workflow Workflow2 associated with it.

Workflow2 should have manually start workflow option enabled. (Allow this workflow to be manually started)

Workflow2 simply logs the title of the list item in workflow history list.

NOTE: Both Workflow1 and Workflow2 are built on 2013 workflow platform.

Publish both the workflows and create an item on List1.  Manually start Workflow1 on the list item and you should see that it completes successfully.

Now browse to List2 and you will see that a new list item was successfully created by Workflow1.

The problem:

But Workflow2 would never start off.  Refer part 1 of this series, check ULS logs and you’ll see Workflow2 didn’t start because of workflow recursion prevention.

Fix:

The fix is to leverage the new REST APIs exposed to start off Workflow2 from Workflow1.  Let’s open Workflow1 in SharePoint Designer’s workflow editor.

We drop a “Build Dictionary” action just above the create item in list action with the following name/value pairs of type string.

accept: application/json;odata=verbose

content-type: application/json;odata=verbose

Choose the dropdown against “(Output to Variable: dictionary)” and create a variable to type Dictionary named “ReqHeader”.

Choose the dropdown against “(Output to Variable: create)” and create a new variable named “NewItemGuid”.  It will be of type GUID.

Drop a “Call HTTP Web Service” action after the create item in list action.

Click “this”, use the … button against the textbox titled “Enter the HTTP web service URL”.  This will bring up string builder dialog box.

Click “Add or Change Lookup”, change “Data source” dropdown to select “Workflow Context” and for “Field from source” choose “Current Site URL” and hit OK.

Append /_api/web/lists/GetByTitle('List2')/items?$filter=GUID eq ' to the end of the current site URL token (watch out for the single open quote in the end, that is necessary too).

Click “Add or Change Lookup” again, change “Data source” dropdown to select “Workflow Variables and Parameters” and then choose “Variable: NewItemGuid” for “Field from source”.  Hit OK.

The string builder dialog will now have the following string in it.

We are calling the REST method GetByTitle passing it the title of the list we are interested in (for this scenario it’s List2).  We are then asking for all the items filtered on the specific GUID which is the GUID of the item we just created in the create item in list action.

Hit OK on string builder dialog.  The “Call HTTP Web Service” dialog should now look like this.  Ensure you select “HTTP GET” for the HTTP method.  And hit OK.

Choose “Properties” option from the context menu of “Call HTTP Web Service” action.

Set “RequestHeaders” to the request header variable you created and create a new variable of type dictionary named “RespContent” for “ResponseContent” as shown below.  Hit OK.

Drop a “Get an Item from a Dictionary” action after “Call HTTP Web Service” action and click “item by name or path” hyperlink.  In the editor type d/results(0).

Click the dictionary hyperlink and choose “Variable: RespContent” from the dropdown.  Click the item hyperlink and again choose “Variable: RespContent” from the dropdown.  End result will be.

There are plenty of articles out there that talk about how to parse the JSON to get to the actual data we need so I am not going to cover that here.  But remember we can use Fiddler to determine the structure of JSON result and we’ll use that knowledge to decide on how we will get to the result we need (for e.g., d/results(0)).

What we did above is that we want the value at d/results(0) from the RespContent dictionary variable we get back from the web service call.  We are then storing the result again back in RespContent because the result is also of type dictionary.

Drop another “Get an Item from a Dictionary” action.  Click on “item by name or path” hyperlink and type Id.  Click “dictionary” hyperlink and choose “Variable: RespContent”.  Click the item hyperlink in “(Output to item)” and create a new variable named “NewItemId” of type integer as shown below.

We did all these to get the ID (the sequence number) value of the list item we just created.  Phew!!!  This is because we need to know the ItemID of the list item we just created as we need to pass it to the StartWorkflowOnListItemBySubscriptionId REST method later.  But we are just 30% into our design

The other parameter that StartWorkflowOnListItemBySubscriptionId needs is the workflow SubscriptionId.

We drop another “Call HTTP Web Service” action and construct our next REST call.  This time we call /_api/web/lists/GetByTitle('List2').  We set the same “ReqHeader” variable to this call.  And set the same “RespContent” variable as we did before.  The end result you should have in “Call HTTP Web Service” dialog is shown below.

And in designer we should see.

We then add another “Get an Item from a Dictionary” action.  Ask for d/Id from “RespContent” variable and assign the output to a new variable named “List2Guid” of type GUID as shown below.

Now the variable “List2Guid” will have the GUID of List2.  We need this to get the workflow subscriptionId that we can get by calling an already available REST API called /_api/SP.WorkflowServices.WorkflowSubscriptionService.Current/EnumerateSubscriptionsByList.

We now drop another “Call HTTP Web Service” action and set it up get all workflow subscriptions.  Here’s how string builder should look like for this call.

And we set the “HTTP method” option for this “Call HTTP Web Service” action to “HTTP POST” as shown below.

We should now have the workflow design as shown below.

Now we have a tricky situation where we need to get the subscriptionId of the exact workflow that we are interested to start off.  This is where Fiddler is very helpful.  Again I’ll defer to the plethora of articles available online that tells us how to do a GET, POST REST calls using Fiddler.  But I am going to rush on this piece a bit.

Through Fiddler (by submitting a POST request to the same REST method EnumerateSubscriptionsByList, we see the following output.

Workflow2 happens to be the 3rd in the list of workflows associated to List2 so I can get that out using the 2nd index.  So we drop two more “Get an Item from a Dictionary” actions.  In the first action we ask for d/results(2) from “RespContent” and we store the output again in “RespContent”.  In the second action we ask for Id which happens to be the SubscriptionId of Workflow2 on list List2 from “RespContent” again and store the result in a new variable named “SubscriptionId” of type GUID.  Our workflow design should now look like below.

Now we are at the final stage where we will start the workflow.

Drop our last “Call HTTP Web Service” action and call the new /_api/SP.WorkflowServices.WorkflowInstanceService.Current/StartWorkflowOnListItemBySubscriptionId REST method by passing in the SubscriptionId and NewItemId variables.  Our string builder dialog should look like the below.  (Ensure the parameter names of this method is exactly as it is shown below and that the values are enclosed within single quotes).

This will again be a POST request.

After setting the “ReqHeader” correctly using the “Properties” context menu option for the last “Call HTTP Web Service” action, we drop a “Set Workflow Status” action.  The completed Workflow1 should look like below.

That’s it!!

We Save/Publish our workflow, go to List1 and create a new item.  Start off Workflow1 manually on that new item.  It should complete successfully.  Then we go to List2 and we should see that a new item is created and Workflow2 was trigged off too.

If we click on “Stage 1”, we’ll see that Workflow2 logged the message as we designed.

I hope the information in this post was useful.  Please check out the next part SharePoint 2013 Workflow recursion prevention – Part 3 to achieve the above objective from a Visual Studio SharePoint 2013 Workflow.