SharePoint 4 Developers

Additional reference guide in .NET / SharePoint Development

Continuous Integration of ASP.NET 5 (ASP.NET Core) on Azure with Visual Studio Team Services

ASPNET Core Continuous Integration on Azure with Visual Studio Team Services. Alternative solution to Build and Deploy your ASP.NET 5 Application to an Azure Web App where error message The specified path, file name, or both are too long occurs.

Not sure if you know, but the official approach provided by Microsoft to compile ASPNET 5 solutions and deploy to Azure via script doesn’t work. So far this is the current state.

The prebuild.ps1 script fails on Get-ChildItem commandlet, due to the long path of NPM packages, that need to be restored. You probably should be getting errors like this:

“The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.”

This is so annoying! I spent some time trying to circumvent this issue, with no luck. This is a OS limitation.

Luckily I was able to touch base with the Microsoft Corp guys about that. The alternative to the issue is provided on this solution:

https://github.com/Microsoft/PartsUnlimited

Core Scripts

Check-out the scripts for automation:

  • Call-Dnu.ps1
  • Call-Dnx.ps1
  • Install-Dnvm.ps1
  • PublishWebsite.ps1

Available on https://github.com/Microsoft/PartsUnlimited/tree/master/scripts

CI Build

On my CI build I was able to get them running smoothly, as per Figure 1:

Build
Figure 1 – CI build

Considering that my solution is created with the following projects:

Solution
-- Project.Deployment
-- Project.Models
-- Project.Web

 

The details for each task of Figure 1 are displayed here:

  1. Install dnvm
    Type: File Path
    Script filename: $/Project/Main/Project.Deployment/Install-Dnvm.ps1
  2. Dnu restore
    Type: File Path
    Script filename: $/Project/Main/Project.Deployment/Call-Dnu.ps1
    Arguments: restore $(Build.SourcesDirectory)
  3. Dnu build Web project
    Type: File Path
    Script filename: $/Project/Main/Project.Deployment/Call-Dnu.ps1
    Arguments: build $(Build.SourcesDirectory)/Project.Web --configuration $(BuildConfiguration)
  4. Dnu build db model
    Type: File Path
    Script filename: $/Project/Main/Project.Deployment/Call-Dnu.ps1
    Arguments: build $(Build.SourcesDirectory)/Project.Models --configuration $(BuildConfiguration)
  5. Dnx sql script
    Type: File Path
    Script filename: $/Project/Main/Project.Deployment/Call-Dnx.ps1
    Arguments: –p Project.Models ef migrations script > $(Build.ArtifactStagingDirectory)\sql_script.sql
  6. Npm install
    Command: install
    Working Directory: $/Project/Main/Project.Web
  7. Gulp files
    Gulp File Path: $/Project/Main/Project.Web/gulpfile.js
    gulp.js location: Project.Web/node_modules/gulp/bin/gulp.js
  8. Dnu publishing solution
    Type: File Path
    Script filename: $/Project/Main/Project.Deployment/Call-Dnu.ps1
    Arguments: publish $(Build.SourcesDirectory)/Project.Web --runtime active --configuration $(BuildConfiguration) --out $(Build.ArtifactStagingDirectory)\web
  9. Copy files to: $(Build.ArtifactStagingDirectory)\Scripts
    Source Folder: $/Project/Main/Project.Deployment
    Contents: **\*.ps1
    Target Folder: $(Build.ArtifactStagingDirectory)\Scripts
    Overwrite: true
  10. Publish Artifact: drop
    Path to Publish: $(Build.ArtifactStagingDirectory)
    Artifact Name: drop
    Artifact Type: Server

Note: You could add Npm packages to the source code, so you wouldn’t need to have Npm installation as a task. I haven’t even mentioned about Bower packaging as a task, which you might be using. In my case I decided to add bower to the source code, just because it is so damn slow to restore packages during the build.

 

Keep an eye on this post for more updates, as I’ll keep updating it when MS releases new stuff.

Cheers,

Marcel

Office 365 Development Training

Cloud solutions are becoming connected, multi-platform focused, so studying the SharePoint App Model itself is not enough to master, you need to know Office 365 Development APIs.

Hey guys,

Looking at the future, besides SharePoint having its own App Model, solutions are evolving, they are not limited anymore to what we can do within the platform.

Cloud solutions are becoming interconnected, multi-platform focused, so studying only the SharePoint App Model itself is not enough to master, you need to know Office 365 Development APIs. Hands-on training is available here: https://github.com/OfficeDev/TrainingContent

When you think you have mastered something, you realize you are only on the top of the iceberg. :)

Happy studying.

Cheers,

Marcel Medina

Click here to read the same content in Portuguese.

SharePoint 2013 Workflows - Suspended state HTTP 401 Error

Investigation and Fix on SharePoint Workflow 2013 Suspended state, where HTTP 401 is displayed.

Hi guys,

It is really annoying when you get stuck on something that you cannot identify the real source of the problem. The suspended state with SharePoint 2013 workflows is one of them, really difficult to troubleshoot.

Problem

I was getting this error from the UI, after starting the workflow:

(RequestorId: 0cd909bf-f85a-1da7-0000-000000000000. Details: RequestorId: 0cd909bf-f85a-1da7-0000-000000000000. Details: An unhandled exception occurred during the execution of the workflow instance. Exception details: System.ApplicationException: HTTP 401 {"error":{"code":"-2147024891, System.UnauthorizedAccessException","message":{"lang":"en-US","value":"Access denied. You do not have permission to perform this action or access this resource."}}} {"Transfer-Encoding":["chunked"],"X-SharePointHealthScore":["0"],"SPRequestGuid":["0cd909bf-f85a-1da7-b6a7-48f3d5618b90"],"request-id":["0cd909bf-f85a-1da7-b6a7-48f3d5618b90"],"X-FRAME-OPTIONS":["SAMEORIGIN"],"Cache-Control":["max-age=0, private"],"Server":["Microsoft-IIS\/8.0"],"WWW-Authenticate":["Negotiate","NTLM"],"X-AspNet-Version":["4.0.30319"],"X-Powered-By":["ASP.NET"],"MicrosoftSharePointTeamServices":["15.0.0.4481"],"X-Content-Type-Options":["nosniff"],"X-MS-InvokeApp":["1; RequireReadOnly"],"Date":["Tue, 25 Nov 2014 01:13:50 GMT"]} at Microsoft.Activities.Hosting.Runtime.Subroutine.SubroutineChild.Execute(CodeActivityContextSystem.Activities.CodeActivity.InternalExecute(ActivityInstance instance, ActivityExecutor executor, BookmarkManager bookmarkManager) at System.Activities.Runtime.ActivityExecutor.ExecuteActivityWorkItem.ExecuteBody(ActivityExecutor executor, BookmarkManager bookmarkManager, Location resultLocation))

Behind the scenes from SharePoint ULS logs:

Original error: System.UnauthorizedAccessException: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))    

Troubleshooting

In my case only few users were able to trigger workflows, as Contributors, but others couldn't. They were getting to this "Suspended" state. By checking the user permissions on the Library, of a user that could execute the workflow and one that couln't, permissions were exactly the same as Contributors.

Permissions were not broken, they had access to Workflow History and Tasks Lists, as indicated here:
http://zasharepoint.blogspot.co.nz/2014/05/sharepoint-2013-workflow-gets-suspended.html

By checking the User Profile Services, the synchronization of users were in-place, as suggested here:
http://sharepoint.stackexchange.com/questions/58772/sharepoint-2013-workflow-authentication-error-401

I had also explored these URLs, with no success:
https://social.technet.microsoft.com/Forums/sharepoint/en-US/8671e31e-fde2-454c-aba4-0fc6484dd873/sharepoint-2013-workflow-suspend-with-401-error?forum=sharepointcustomization
https://social.technet.microsoft.com/Forums/sharepoint/en-US/653dcf25-131e-402a-9fd1-f0b3e60e7750/suspended-workflow-in-sharepoint-2013-with-http-401-error?forum=sharepointadmin

This was getting tricky.

Solution

By doing a thorough investigation in this site, OOTB SharePoint groups were mapping both AD Users and AD Groups. There was a good evidence there that I had overlooked, users that were getting to a suspended state were mapped by an AD Group.

When the user was manually added to the SharePoint group, the workflow worked. :)

Going a little bit further, the AD Group was from a different OU that wasn't mapped in the User Profile Synchronization. When the OU path was mapped and the sync was run again...BANG! All the users that couldn't run the workflow, now could.

So it is not only the OU where the users are that need to be mapped with User Profile Sync, but the AD groups OU as well.

Lesson learned! Hope it helps with your troubleshooting!

Cheers,

Marcel Medina

Click here to read the same content in Portuguese.