Exposing Azure Web Site slot specific variables in a .Net Core ASP 1.1 MVC Web Application

Try saying that five times very fast.

It all started simply enough as I go through my Azure development exams in particular the Developing Microsoft Azure Solutions 70-532.

All I needed was to understand how Azure Deployment Slot Specific App Settings worked.  I had read it up but wanted to see it in action.

How hard could it be?

As it turns out not too bad when you understand it but there were two things I hadn’t appreciated.

1. ASP.NET Core 1.1 uses a different mechanism for application settings.
2. The way that Azure represents deployment slots in the portal.

ASP.NET Core 1.1 Application Settings

In a nutshell web.config is no longer available and you should use an alternative mechanism such as an appsettings.json file.  For a good write up see here

New Configuration and AppSettings for MVC6 – Web.config is Gone

Its all really good news in this is that the new way of doing things frees us from the tyranny of named files and opens up dependency injection, combining multiple files, overrides at runtime, secure secret stores.  It is a good thing but first you must get your head above it.

Azure Deployment Slot Portal Representation

I assumed that the deployment slots would be a child of the web site in the Azure portal but this is not the case.  Instead each slot is its own web site with links between them.  This does make sense as that is what they really are a set of web sites with arbitrary links between them.  Those parts that are hosted on the same VM under the hood share their settings so that updating one will update all of them whilst those that are slot specific do not affect each other.

In the end a solid day of digging got me to the bottom of this and a better understanding of how Azure is put together.

Adding Bootstrap to SPFx web parts

Hi Folks

So we have an SPFx web part that shows how to integrate the React ‘Thinking’ tutorial with the SPFx tutorial but it looks pretty nasty:

Using Themed StyleSheets in your SharePoint Web Parts

Hi Folks

A simple little trick here.  We have developed a nice tabbing web part (which is NOT a jQuery wrapper which shows and hides but a ‘proper’ we only load what you need tabbing system) and as part of it we wanted to use the Search Navigation Web Parts theming.

We did this for consistency so that out of the box the experience with our web part is identical to the only other tabbed interface in SharePoint.

We also wanted to respect any theming that was in place rather than force our own onto the part.

Now its very easy to reference a SharePoint themed style sheet in a web part the trick is simply in OnLoad to use the CssRegistration class as follows:

protected override void OnLoad(EventArgs e)
{
base.OnLoad(e);
CssRegistration.Register(“Themable/searchv15.css”);
}

Now the style sheet will be loaded and you can use its styles.  In addition if you are using theming the themed version will be loaded for you so your colour and font choices are respected and finally if anything else has requested the same style sheet it will only be loaded once.

Cheers

Sebastian

 

Too many numbers

For a long time now I’ve been telling people that there are only three numbers in computing:

• None
• One
• Many (and for our purposes Many will actually be Two)

Thus when testing if we cover these bases then that should be enough.  For example if testing that modifying properties on a record I might have a set of unit tests as follows:

• AddsNoProperties
• AddsOneProperty
• AddsTwoProperties

However even though records are by definition immutable in practice records managers sometimes have to amend them so we also need to test.

• UpdatesNoProperties
• UpdatesOneProperty
• UpdatesTwoProperties

Worse still they sometimes update records by removing information (typically due to a ‘misfile’) so we also need:

• DeletesNoProperties
• DeletesOneProperty
• DeletesTwoProperties

That’s nine tests not too bad.  Hold on what if in a single transaction we add some properties, update some properties and delete some properties?

• AddsNoPropertiesUpdatesNoPropertiesDeletesNoProperties
• AddsOnePropertyUpdatesNoPropertiesDeletesNoProperties
• AddsTwoPropertiesUpdatesNoPropertiesDeletesNoProperties
• AddsNoPropertiesUpdatesOnePropertyDeletesNoProperties
• AddsOnePropertyUpdatesOnePropertyDeletesNoProperties
• AddsTwoPropertiesUpdatesOnePropertyDeletesNoProperties
• AddsNoPropertiesUpdatesTwoPropertiesDeletesNoProperties
• AddsOnePropertyUpdatesTwoPropertiesDeletesNoProperties
• AddsTwoPropertiesUpdatesTwoPropertiesDeletesNoProperties
• …

If you work it out that’s 54 tests.  That’s too many.  We use xUnit so as well as Facts (xUnit tests) we have Theories (xUnit ‘data-driven’ tests) so maybe we really have one ‘theory’.

• AddsSomePropertiesUpdatesSomePropertiesDeletesSomeProperties

It will have fifty four examples, so while its better its still long to run and set up.  It smells of hidden complexity.

Hold on do we really have three numbers?  I don’t think so in fact we may have only one number:

• Some, and for our purposes this can be defined as any number greater than the minimum value and less than the maximum value.

In addition we probably have two edge cases:

• Minimum value, which we can assume as zero.
• Maximum value, which if we assume is two we can easily handle.

For this to be useful we need to be working with a collection of separate things, that is they must all be homogeneous and independent.  If they are not homogeneous then we need to treat each separately and if they have dependency on each other then which one we change becomes important.  However when using collections, e.g. lists, arrays, dictionaries, this is nearly always the case.

So this means I can now have a single test so long as I have enough things in my collection to allow for each action. I choose to split my actions and end up with three tests based on an object with two properties.

• AddsSomeProperties, using one existing property and adding one new property.
• UpdatesSomeProperties, using two properties and updating one and not the other.
• DeletesSomeProperties, using two properties and deleting one and not the other.

This is quick and easy and covers all the bases, except for those pesky edge cases.  However if these are important, e.g. deleting all properties, then we can convert our facts into theories and test for them.

So in this case we don’t have three numbers, in this case we only have one number:

• Some

Happy testing

Sebastian

Enum support in ASP.NET MVC

Hi Folks

So what happened to enum support in ASP.NET?

It was working and then, it stopped.

Well enum support is in MVC 5.1 and by default the Visual Studio templates are still using MVC 5.0 for generating new projects.

The solution is simple enough.

1. Upgrade MVC in the project.
2. Find all references to enum types and replace EditorFor with EnumDropDownListFor.

E.g. replace

@Html.EditorFor(model => model.Colour)

with

@Html.EnumDropDownListFor(model => model.Colour)

So how do we get our solutions to use 5.1 by default, and going forward 5.2, 6.0, etc?

Good question and one that doesn’t seem to have that easy an answer as if you chase down the project template, held in “C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\ProjectTemplates\CSharp\Web\1033\WebTemplate45”, you’ll find.

    <WizardExtension>
<Assembly>Microsoft.VisualStudio.Web.Project, Version=2.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a</Assembly>
<FullClassName>Microsoft.VisualStudio.Web.Project.OneASPNetProjectTemplateWizard</FullClassName>
</WizardExtension>

So its code that does it not configuration.

Thus the best thing seems to be a ‘checklist’ for new projects.

1. Create Project.
   1. Explicitly select ASP.NET 4.5.1
2. Update NuGet Packages
   1. MVC ASP.NET 5.1.2

Cheers

Sebastian

Avoiding SharePoint Magic Numbers in Unit Testing

Unit testing really is good. No surprise to those who do it but recently we had a test go red when changing how we configure Enhanced Records Manager, see
Appropriate use of AppInstalled for a Provider Hosted SharePoint App for more details.

Not a problem we have broken something lets fix it.

It turns out that every properties metadata was being added twice to our configuration database.  Simple.  We had inadvertently called the ImportProperties method twice.  So all we have to do is remove the wrong call and we are away.  Hold on isn’t import properties supposed to update if the same property is imported twice not add.  Lets dig further.

So when we unit test we don’t use SharePoint, its too ‘heavy’, but we have abstracted it in the design to an Interface called the RecordRepository Interface which has ‘generic’ methods, such as GetProperties which returns all the properties the Records Management system.  This gives us two great benefits:

1. We can replace it for unit testing by a lightweight RecordsRepository currently a pure in memory one.
2. We can use Records Repositories other than SharePoint by ‘merely’ replacing the Records Repository as it only deals with access, not logic.

The ImportProperties unit tests weren’t failing so the actual logic was okay, well we all know GIGO (Garbage In, Garbage Out) so if the output is wrong but the logic is right it must be the input.  And Lo and behold so it was.  Our Unit test Records Repository generates a defined set of properties using Guids as their unique identifiers.  Good.  Problem was they were generated each time the GetProperties method was called so if you called it twice you get two sets of properties identical in all but identifier.

A long preamble but it got me thinking.  Why hadn’t we just used the known identifiers for the SharePoint built in fields?  Title is always {fa564e0f-0c70-4ab9-b863-0177e6ddd247}.  We didn’t so why?  Ah yes go back to point 2 the design of ERM is that it is repository agnostic.  If we had just used the ‘magic’ value when we changed the actual Records Repository we could have been in the position where our unit tests passed fine but it failed in practice because we had been lazy and also used the magic value somewhere in the business logic.

So we generated Guids just for our Unit test Records Repository as fixed Guids and that sorted that.

Cheers

Sebastian

Appropriate use of AppInstalled for a Provider Hosted SharePoint App

Sometimes the clue’s not in the name.

As part of ERM (enhanced Records Management) we are trying to create a minimum configuration solution.  Why?  Well most implementations in the Records Management sphere take three to six, or months, to implement.  Scratch that most ‘enterprise’ software takes about a year to get installed.  That’s a major block to implementation.  What causes this?  You install on a ‘prototype’ and configure; then on a test system and configure; then on production and configure as a minimum.  In fact many enterprises will also have a performance, penetration and pre-production environment as well.  Configuration always takes time and its tricky as you set up servers, services, databases and modify configuration files for all of them.  Get it wrong and you then spend ages wondering is it your configuration or a bug?

Now contrast that with your mobile phone.  You select the app, download it and start.  Configuration, if there is any, tends to be entering some log on details and maybe flipping a couple of options, no more.  Time to implement?  Minutes.

So how do we get the same effect in the enterprise?

Simple we avoid configuration like the plague, we let the application discover and configure itself, much like your ‘plug and play’ hardware has been doing for over a decade now.

Right so when the software installs it should do it shouldn’t it?

There’s a remote event receiver for SharePoint Apps called AppInstalled that’s what we should use, shouldn’t we?

After some experience I think the answer, at least for Provider Hosted Apps, is no to both.

The AppInstalled event has some real shortcomings.

1. It only ever runs once, when the App is installed, if something goes wrong then it will never run again.  Also if something in the host site changes it will never reconfigure to match.
2. Its error reporting facility is poor, it is an asynchronous event handler after all, it effectively swallows errors, or rather seems to automatically retry a couple of times, and has no in built display method.
3. It interferes with the planned running of the App, for example the App Icon does not show.
4. It has no mechanism for showing progress on what could be a long running event.

In retrospect it seems like AppInstalled was designed for short, sharp actions to be taken that have little chance of failure.  Used like this it works nicely.

So what should we do instead?  The key is that if it fails then it won’t be run again.  We could use the AppUpgraded event but that has all the same limitations.

Hmmm.

We do have something that is guaranteed to run every time someone accesses the event and that’s the Home Controller’s Index action.  We could use that.  The last version did just that and it works nicely.  It checks if the App is configured and if not starts configuring it.  However it turns out that at least two mechanisms do not invoke this action.

1. Remote Event Receivers, e.g. Item Added or Field Updated.
2. Unit Tests.

Even one of these is enough to remove the responsibility from the Controller, where it did, in retrospect seem a bit out of place.

So we moved it again.  ERM uses a ‘service’ layer to talk to its twin repositories, the ‘native’ Records Repository and its own Management Repository.  So now it is its job when instantiated to check if the App is appropriately configured and if not do something about it.

This means that:

1. It runs as often as is needed therefore it picks up configuration changes as needed.
2. It will always be invoked by something else so it off loads the error handling to that all it now needs to do is handle its own errors if it can and if not throw them up the stack.  Perfect error handling is now being done in the correct place.
3. The App will just install with less chance of anything going wrong, installation has been simplified further.
4. Handling progress, if its a long running event, can be delegated to the view that is invoking the service creation, again perfect.

Now all we need to do is move the code to the appropriate place and rejig the unit tests.

Cheers

Sebastian

TFS goes Virtual

Hello Once More

As we prepare for doing SharePoint 2013 Apps we decided to look at some of our infrastructure, in many ways the start of a project is the only time you can make these changes.  The middle is too fraught and the end is too risky.

Our TFS server is an aging physical box running TFS and SQL and its done Stirling service.  I have justified this on how ‘important’ it is and how we don’t want to trust this unproven virtualization technology.

However we use virtual boxes here day in day out and they never go wrong, they are easier to manage and we can snapshot them and back them up easily.  Our clients run their production systems on them.  We can easily increase their disk, memory and processors to scale the box as well.  What’s not to like?

We stopped short of buying a virtual machine in the cloud because I wasn’t happy with our source being on someone else’s hardware and because cost wise its still cheaper for us to use our own hardware over three years than rent a VM.

In the end an easy enough process we created a new VM, installed TFS 2012 on it (a big improvement) and took across the existing TFS data stores, fired it up, failed to connect to it, realised that we had it behind a firewall so opened the right ports and, “That’s a bingo!”.

Now I was just about to create a brand new TFS project to hold the SharePoint 2013 solution in when I realised that this would be a very bad idea.  TFS projects should not be specific to solutions or even technologies but teams, or rather code that wants to be shared.  In our case we are going to have a core that is called from both 2010 and 2013 so it will actually belong in the general EDRMS Project.

 

Cheers

 

Sebastian

SharePoint 2013 App Testing – First Steps

There is a reason why we can’t use a Sandboxed Solution for our Enhanced Records Management as unfortunately they are not supported in SharePoint Records Centers, we have checked in 2010 and 2013 and it appears to be a long standing bug see https://simpleinnovationassociates.wordpress.com/2013/03/28/sandboxed-solutions-and-sharepointrecords-centres/.

So our Office 365 offering will be a SharePoint App but how do we know even that will work in a SharePoint 2013 Records Center?

In this case we need to establish what is the minimum required for success.  We need to remove anything that will cloud the issue, and in this case that’s any functionality.

A site administrator must be able to install a SharePoint 2013 Application into a SharePoint Site built with the Records Center (OFFILE#1) Site Template.

We don’t care what the SharePoint Application does we just need to know that it will install without error.

So what we need is the simplest possible SharePoint Application, in the simplest possible environment.

A good primer for this can be found in http://www.amazon.co.uk/Microsoft%C2%AE-SharePoint%C2%AE-2013-Development-ebook/dp/B00B8D47F2 and using this we can write a simple SharePoint 2013 Application and deploy it internally via our own application store.

This should be a suitable task for someone to undertake tomorrow.

 

Cheers

Sebastian

Writing the Documentation for a Design Up Front

Well this turns out to be far harder than you would think it is.

Once you put yourself in a user’s shoes things look very different.

I started the User Guide 1.1 for the next release of the Enhanced Records Management product and immediately realised that the vocabulary in version 1.0 is hopeless unless you already know both SharePoint and the architecture of the solution.  I started a glossary translating Records Management vocabulary into SharePoint Records Management vocabulary and this I realised was a dead-end in itself.  I used a bit of my misunderstanding of Stanislavski and imagined I was a Records Manager whose main concern was to care for my records.  I don’t know SharePoint and frankly I haven’t got time to learn it.  I do have a SharePoint Records centre though and I have to use it.  In my old friend Ed Texeria’s words:

What’s the least I need to know?

Not much it turns out.

• What policies have been set up to govern retention?
• How do I change the policies?
• What events do those policies depend on?
• Which records are dependent on which policies and hence which events?

Hold on even that’s thinking in a ‘data centric’ sort of manner.  Lets try again but this time thinking of it from arriving in the morning with a steaming mug of coffee.

• What records do I need to deal with today?
• What records do I really need to deal with today because they are overdue?
• Are there any records that I don’t have a policy for?
• How can I set up a policy for records that don’t have one?

Interesting I’d probably change the first two round now I think further.  It seems to me that getting those things right is what my job is all about.

I probably have some other responsibilities that occur on a less frequent basis and I may even have staff who can help me so once we have dealt with the critical matters what would the next most likely things to occur during the day?

• I’ve had a request about a topic how do I satisfy it?
• How do I find out what happened to the record the auditors are asking about?
• Have any of the projects closed or any one left us, as due to this event I need to start the clock running on all the relevant records?

Okay that’s probably enough to get going on for now.  What is interesting is that none of this cares about how I do it I could be using a paper based system and the questions would be the same.   Also looking at the questions it seems that the ‘keywords’ are:

• Record(s)
• Policy
• Overdue
• Find
• Audit
• Event

The Record(s) is interesting because I want to deal with records in groups to reduce the time it takes.  I know that the record management vocabulary for a group of records that will be handled simultaneously is a ‘part’ and that a ‘class’ is a records management term for a branch in a ‘file plan’ whilst a ‘part’ is a leaf and the only thing that can contain a ‘record’.  So adding these to my other keywords gives me a very small vocabulary to start with:

• Record
• Part
• Class
• File plan
• Policy
• Overdue
• Find
• Audit
• Event

I’m sure more will crop up later but that’s enough for now.

So in my introduction I want to define these terms so that as a Records Manager I know that this manual is speaking my language, not some techies.

Onwards!

Sebastian