Are you having trouble keeping track of everything that’s going around in Azure? You’re not alone! In an effort to do so myself, I’m starting a monthly series called “News for developers” which is exactly that: a summary of all of the Azure flavored news specifically for software developers. Now this is based on my personal feeds and my personal opinion, so you might miss things or see things which in your opinion do not matter. Feel free to comment below and I’ll see what I can do for the next edition. And honestly, this is more a personal reference than anything else so having actual readers would already be awesome 🙂 Enjoy!
Are you having trouble keeping track of everything that’s going around in Azure? You’re not alone! In an effort to do so myself, I’m starting a monthly series called “News for developers” which is exactly that: a summary of all of the Azure flavored news specifically for software developers. Now this is based on my personal feeds and my personal opinion, so you might miss things or see things which in your opinion do not matter. Feel free to leave and comment below and I’ll see what I can do for the next edition. And honestly, this is more a personal reference than anything else so having actual readers would already be awesome 🙂 Enjoy!
App Services updates
Here are some important updates from the world of Azure App Services:
- .NET 4.7 is now supported on Azure App Service. For more information about what 4.7 brings for you, check out this post.
- .NET Core 2.0 Preview 2 also rolled out to Azure App Service. For more information about that release, click here.
- Durable Functions are on App Service now. These are built on the Durable Task Framework which allows writing long running workflows using async/await operations. For Functions, this brings us a way to facilitate longer running processes on Functions, which was not possible previously. Check out this post for more information.
- NodeJS versions have been updated to include v4.8.4, v6.11.1, v7.10.1 and v8.1.4 along with the corresponding NPM packages. These updates provide a fix for a known vulnerability.
- Azure App Service Environment (ASE) v2 has been released. Most important changes include scaling based on the App Service Plan (managing worker pools is no longer required). The creation process is now integrated into the Create new App Service Plan experience, increasing the visibility. And the new ASE can scale to bigger, which is of course better 😉 Check out the blog post here.
- A preview of App Service Domains makes it easier to combine Azure DNS hosted domain names with your app service instances. A few of the benefits include: subdomain management, automatic renewals and free cancellation within 5 days. That post is over here.
Visual Studio (Team Services)
From the world of Visual Studio team services:
- There’s a new editor for release definitions and an updated workflow for pull requests. The editor I already used myself and it’s a pretty sweet visual representation of the release flow in your application. Check it out!
- Upon completion of a pull request, you can now automatically mark all linked workitems as Done. Get it done!
- Also in the PR department: a policy now allows an automatic reset of reviewer votes when new code is being pushed.
- Personal favorite: you can now view the original diff of a file once a code update has been pushed. This makes it a lot easier to check out changes to the code which you commented on previously.
- Multiple updates to task groups include: versioning (draft), references and import/export of a task group.
Check out https://www.visualstudio.com/en-us/articles/news/2017/jul-14-team-services for the complete overview.
Here’s all the stuff that didn’t fit into one of the above categories:
- John Papa (yes, the one and only) released Azure Function Tools for Visual Studio Code which allows you to use TypeScript within your Azure Functions. Download it from the marketplace here.
- For all of you Angular folks out there, Angular version 4.2 is now available.
- In the “services that might come in handy one day” department; Microsoft Stream has been made generally available. Stream offers powerful video streaming services combined with intelligent stuff like automatic captioning, face detection and other AI features. Click here for more.
That’s it for this month, see you next month for another round of Azure news!
In my previous post I discussed how to build a bot using a Web Project and deploying it as a DLL to an Azure Function. The Azure Function would then function as the endpoint for your bot which you can make available through channels which include Facebook, Skype (for Business) and many more. Starting at //BUILD this year, Cortana was also included in that list of channels. Cortana of course is a bit of a special channel, since we’ll then be using voice to communicate with our bot. But if you think of it, voice translates to text and text is the input of choice for the bot that we build. So it should be that difficult, right? It’s not!
The Cortana SDK or development framework or whatever you’d like to call it calls this skills. Basically you’re learning Cortana new skills as you would learn a pet or child something new. The set-up on the Cortana side is simpler than you might think. You simply enable the Cortana channel for your bot, fill in some fields and you’re good to go.
One of these fields is the invocation name. That’s how Cortana will understand she needs to route a message to our bot. For my home automation sample, I’ll be using “The House” as invocation name, so a command might be “Hey Cortana, tell The House to turn on the lights in the kitchen”. If you haven’t read it yet, take 5 minutes to read Cortana kills + LUIS pre-built domains on how to effortlessly teach you bot these kinds of intents.
Another cool thing you can configure is which data Cortana will supply your bot with. Since Cortana is the digital assistant of the user you will be communicating with, she knows things about this user. These things you can request for so that you can make use of the data in your bot code.
Be aware though: the user does need to consent to Cortana sending this information to the bot before she actually does so.
Another handy thing is to put Cortana herself into Developer Mode. You can do this by heading over to the Cortana Dashboard (the link is displayed with the Cortana channel itself). Here, under the Debug section there’s the option to enable Developer Mode by simply clicking a checkbox.
After which invoking a command will show you debug info:
Debugging the bot
For testing and debugging your bot, you get all of the options you normally have for bots (and for Azure Functions by the way). Of course you cannot get the online version of Cortana to call a local instance of your bot, but you can simply pass in the text of the intent you want to test via the bot framework emulator. One feature gap at this moment is the fact that the bot emulator does not allow us to pass in the additional channel data that Cortana can supply (context / user info). What you could do is attach your debugger to an Azure hosted instance of your bot and then debug that specific part.
That’s it for now, in my next post I’ll be going in a bit deeper into how this all comes together.
Had a strange thing happen at my client yesterday. We were working on an Office365 set-up and had created some AD security groups in order to have reusable permission groups across a bunch of SharePoint site collections. We missed one person in the org due to which she was not able to access a site she was supposed to have permissions to. So we added here, but still she couldn’t access the site… weird…
TL/DR version: rebooting the machine fixed the problem. If your first response is: “huh?”, read on…
In previous articles I explained how you can build bots using the Microsoft Bot Framework and the Azure Bot Service. The latter is built on top of Azure Functions, one of my favorite components in Azure. Both the Functions and Bot teams are releasing stuff in a fast pace, but sometimes this leads towards the two not being 100% in sync with each other. This post addresses one of these issues, namely the Bot Service having old-style templates for new instances.
When you create a new Bot Service instance and download the code, you get a solution with .CSX files. These are used in Azure Functions and they still work great. The issue though is that when you load these in Visual Studio and want to debug your code locally, there’s no IntelliSense to go with them. Althought this is on the teams backlog, it’s not there yet and if you’re a VS dev like I am, you probably can’t live without it 🙂
.NET Class library as Function App
Two months ago, Donna Malayeri (who’s doing absolutely awesome work on the Functions team) wrote this post detailing how you can build a web project which uses the local functions runtime to host and debug the code. This brings two great worlds together: it allows you to build code in Visual Studio with all the benefits (Intellisense!) whilst utilizing the func.exe CLI runtime as well.
The post does a very good job at explaining how to set this up, but what if you want this for your Bot Service instances?
Converting a Bot Service
To convert your bot service instance to a Web Project, here’s what you need:
- A web project (well duh…).
- The CSX files that you want to convert to ‘regular’ C# classes.
- The function.json file that defines the endpoint for your bot.
- A appsettings file should you have one. This is typically where your Microosft App ID and password are stored.
- The project.json file. You don’t really need this, but it’s handy to look up which packages your instance is using.
And here’s the steps:
- Follow Donna’s post to set-up a new web project.
- When creating the classes, create one for your dialog and one for your entry point. You can combine them as well of course, but I personally like to separate them. In the example these are named Dialog.cs and DialogEntryPoint.cs.
- DialogEntryPoint.cs will contain the contents from the ‘run.csx’ file. This the entry point that’s being called when the user communicates with your bot. It’s referenced in function.json as follows:
Note the scriptFile and entryPoint settings which point to the output DLL and the class/method which handles the incoming message.
- Dialog.cs contains your dialog code.
- Ensure that you set-up the project to load the correct NuGet packages. Normally you will need Microsoft.Bot.Builder.Azure which will include some dependencies. If you include this, ensure the project is set-up to run .NET framework version 4.6 instead of 4.5.
Lastly, you need to configure the start options of the project. This is detailed in Donna’s post as well, but for your reference, below are the settings I used. Note that the location of func.exe might differ based on the installation type you used.
With everything configured, running the project should now start your bot in the func.exe runtime and hook up VS at the same time for local debugging! Awesome!
Sample @ github
If you’re struggling, I took the liberty of adjusting the sample project from the blog post and making a bot specific one from it. You can use it to see how it has been set-up. Be aware that my sample is based on the LUIS bot service, so it does require a settings file with your specific LUIS keys to actually work. Should you have any questions or remarks; feel free to leave them below!
Check out the code: https://github.com/jsiegmund/BotAsWebProject
A while ago I was planning on doing a few posts on bots, but I never really got to that it seems. I did get into the bot building business though, so here’s one about a little bit more advanced use of bots: language understanding. And although I might write “more advanced”, I don’t really mean it. That’s because LUIS makes things so much easier. LUIS? Yeah, that’s short for Language Understanding Intelligence Service. And it’s awesome. Read More
It’s never a bad thing to look at what’s coming. This future peeking seems to be hot in the SharePoint world, with guys like Dan Holme, Benjamin Niaulin and Daniel McPherson giving their take on what’s in store for us. Interesting views which of course always include things like cloud, mobile devices and new ways of working for your end users, whatever generation you want to call them.
In my day-to-day work though, I am still mostly involved with enterprise grade customers who might be thinking about that stuff, considering it, but most definitely they’re not there yet. On the contrary; they have a long way to go. So I wanted to write this post to give an overview of things those companies can do today with their current landscape, in order to prepare for that future. And do not worry: the conclusion will not include you writing apps from now on.
In this n-part blog series, I’ll discuss some of the ‘hot topics’ and my views on what choices enterprise grade companies need to make.
I ran into an error with back-up procedures on SP2013. The error in the log file was:
FaultException: Management called failed with System.InvalidOperationException: 'Job failed: Have tried to perform backup/restore operation twice on all in-sync members in cluster SPe6b9ae739be3.0, but none succeeded. Last failure message: Microsoft.Ceres.SearchCore.Seeding.SnapshotTransferException: Could not send chunk ms\%default\gen.0000000000000309.state: Localpath: [0-700> to target BackupDirectoryTarget[directory=\\backupshare\spbr0001\I.0.0,validateTransfers=False]
at Microsoft.Ceres.SearchCore.Seeding.SnapshotSender.SendChunks(ISnapshot snapshot, ISeedSource source, ISeedTarget target, SeedStatus status, Func
1 checkAborted, Int32 targetFragIndex)1 updateProgress, Func
at Microsoft.Ceres.SearchCore.Seeding.SnapshotSender.FirstPhaseTransfer(ISeedSource source, ISeedTarget target, Action
1 shouldAbort)2 original)
at Microsoft.Ceres.SearchCore.Seeding.BackupWorker.BackupWork.DoFirstPhaseWork()' at at Microsoft.Ceres.SearchCore.IndexController.BackupService.ThrowOnFailure(JobStatus status)
at Microsoft.Ceres.SearchCore.IndexController.BackupService.ProgressFirstPhase(String handle)
Searching for this, I found several explanations. They all have one thing in common: it is search related (pretty obvious) and means that search was unable to write to the back-up location.
I seems that search handles a part of the back-up procedure from within it’s own processes. That is, the search service running on SharePoint servers. This means:
– Your search servers need to be able to access the share which is being used for the back-up.
– The service account running search needs to have permissions to write to that share.
– And there should be enough space left, but that’s a no-brainer I hope.
In my case, the second bullet was where my problem was. I granted the service account for search permissions to the share (Full Control), which solved the error. Same is mentioned in this blogpost by Amol Meshe, but he wasn’t sure on the answer.
Ok. I admit this is a kind of dramatic opening to this blog post and that its contents is probably not as dramatic as you might think. But last week at SharePoint Conference Europe, it finally hit me. The SharePoint developer is no more.
Let me explain. We have all heard Microsofts message about SharePoint apps since SharePoint 2013. It’s all about apps, every developer needs to learn apps. And whether you agree or not, it does sound the bell for a new age in development land. Microsoft is pushing it’s cloud model. And when Microsoft starts pushing, you’d better move in their direction or be prepared to move elsewhere. And to be honest, this push is probably for the best.
So why do I think the SharePoint developer is dead? Well actually, I don’t. Not yet, that is. The “yuk, SharePoint” point of sight still lives on in development land. So it’s going to take a while untill our hip webdevelopment colleagues finally find out SharePoint apps are nothing more than webapplications which use some API’s. Sure, you’re able to deploy XML’s with some lists and stuff, but why would you do that when you can also do the same in provisioning code? Code is easier to create, better to maintain and every developer gets it. So screw those XML’s. Really, apart from a different project type in Visual Studio, a SharePoint app isn’t that much different from any other web application when you take a close look.
When companies start using their normal web development guys to do SharePoint projects, those same companies will find the learning curve to be much less steap than it has been before. It’s far easier to train an existing webdev some API’s and call them “SharePoint developer”. And since there is a big market out there for those same SharePoint developers, why wouldn’t they?
When that happens, we’re done. Our app buddies will create cooler things in lesser time. They will use probably nothing out of SharePoint, maybe store a document or two via the API’s. But companies will still be happy as their apps run “inside SharePoint”, are “fully integrated” and now even look cool, are repsonsive and much more user friendly than before. Uh oh…
This was my biggest take away from last weeks conference. Whether we believe in the app model or not, it will drive change. And if that change is the best for SharePoint, I honestly do not know. What I do know, is that you developer need to start thinking about this and begin to train yourself when you want to keep up. And believe me, I have been skeptic as well, very even. But I now have seen the light and will start doing some Angular in my evening hours. Times are changing!
I ran into a weird problem today, when editing a document set. I created my own content type inheriting from the default Document Set. I added a new content type to the set and wanted to delete the default “Document” reference. I got an error telling me: “Content Type is in use”. Strange, since I hadn’t even deployed this Document Set type to any library.
After some fiddling around I finally found out what the problem was. Under “Default Content”, the drop down box will have “Document” selected. And even when you didn’t specify a file as default content, that still counts as “in use”. So simply change the dropdown selection to your own custom content type and voila: you can now remove the default document from the allowed content types list.