Andrew Hoefling

Azure Blob Storage is a great tool for storing any type of file for easy access in your app. The APIs allow you to easily upload and download files of any type which integrates with many popular languages and frameworks. If the SDK isn't supported you can always fall back right to the RESTful endpoints (which I wouldn't recommend, unless you absolutely have to).

DNN has powerful User Management controls, but sometimes you need to use your companies Azure Active Directory configuration or Office 365 credentials (those are really the same). This provides a robust integration with your organization and whatever content you are trying to serve with DNN

When integrating with Azure Services regardless of what the service is, you are commonly required to provide a Tenant ID which is sometimes refered to as a Directory ID. This is a GUID that is used commonly for API access. Some tools skip the Tenant ID and request a Tennant Name? What is that?

Deploying a .NET Framework WebJob to Azure is easy enough, but as of writing this blog the tooling is lacking for .NET Core. Many organizations are making it an initiative to migrate their .NET Framework projects to .NET Core which is a good idea. The tooling limitation for .NET Core WebJobs should not be a barrier, following this guide you will be able to deploy your .NET Core WebJobs to Azure

Hosting apps in the cloud is common practice due to it's ease of use and performance that smaller organizations may not have on their own. Why not host DNN in the cloud? If you follow our guide here you can be up and running in Microsoft's Azure Web App in a matter of minutes.

DNN (DotNetNuke) is a Dot Net based Content Management System (CMS). Building DNN Modules allows you to easily extend the functionality of the DNN Website with complex apps that you can bolt on to any page in your CMS.

The single biggest problem I have seen while developing any type of mobile app is how do we handle offline sync? On most projects I have worked on this has been punted as a problem that isn’t worth the devs time until we are close to release. While this is a bad idea in my opinion, the team does not need to freak out about handling offline sync. It is easier than we make it for ourselves, today’s take away is “Don’t freak out, mobile sync is easy”

Azure Mobile App Services sets you up with a nice template builds all of your boiler plate code. When I went through the setup on the Azure Portal and downloaded the template locally I ran into all sorts of issues with iOS not working in my Xamarin.Forms project. Everything appears to work without issue on Android but I couldn’t get the MobileServiceClient to load, the app would just crash. After lots of digging and playing with the tools provided I figured out what was wrong. It appears the template was missing some platform specific code for iOS.