Short reminder, SharePoint autohosted apps are only available for Office 365. Technically Office 365 will create an Azure website on demand when app is deployed. The potential cost overhead will be billed directly to the tenant owner.

Once the project is created and the Office 365 developer tenant provisioned (you can have 30 free trial days or one free year if you have an MSDN subscription), the first thing we try is F5 right?

The only thing is when we do that, we have this error message (it’s in French but it says file not found)

Two reasons for this. First we lied to you, cloud isn’t always fast. In order to deploy your app, office 365 needs to do two things.

- Create a Web which will be a bridge between office 365 and azure

- Create an azure web site and deploy binaires

And in some situations it can take time.

The other reason is that the project is wrongly configured by visual studio

By default the manifest contains this starting url.

Which corresponds to this XML.

The issue is this URL does not exist in you rasp.net mvc project, you then have to solutions: edit the manifest or add a URL-rewriting rule in your MVC project.

Keep it simple and smart, I edited the manifest. Here is what you need.

Which will lead to this XML.

Don’t try to get rid of the web project name in the URL (at first I thought it was a relative directory). Visual Studio needs it to replace it by the token equivalent to “url relative to app’s web”. If this token is not in the manifest you’ll have an error message saying that your app package is not valid during deployment (without any other detail).

When using the entity framework with a data context we often have this problematic:

What’s the best between performance and simplicity of usage or scalability?

(no? you do not ask yourself that kind of existential question?)

Here is a little explanation :

Static instance

In this first case you wrote a static reference to the context. Sometimes you also add some lazy loading and/or disposal management in global.asax (application end event)

It is efficient (understand fast) because the context is instantiated at the same time as the application domain (when app pool starts) or during the first call.

The instance will be destroyed during application end/stop (iis reset, pool reset, etc)

The advantage resides in the fact that, for each page request the model is already in memory. Entity Framework does not have to re scheme the model in memory and to check model and database integrity.

Another advantage is that you are working with a unique instance of the context all along page generation. Your objects are related to the context (no context rebinding, navigation properties available…)

The problem is this instance is shared across the application domain. Shared across all requests. This can be source of troubles when using transactions but the most important, it can be a bottleneck. Indeed, the Entity Framework is a APU (Applicative Persistence Unit) which does not (or does a very little of) pool database connections.

One instance = limited connection = thread waiting.

Instance by call

In that case, context is instantiated every time we need it and disposed as soon as possible. If we have a business layer, the context is instantiated in each service method. Most of a time a using (){} block is used.

The advantage is the application uses multiple context instances, so the application easily scales up.

The inconvenient is we are working with disconnected entities, we have to attach entities to the context. We also have to explicitly ask navigation properties loading (via .Include() method). Things are more complicated.

Instance by Request

The solution Brian Knoepfel (coworker) and I found is the following one: instantiate one context for the request duration. So we benefit of the best of the two other solutions: simplicity, performances and scalability.

During Init we register an event which will be raised every time request handling ends.

Every time a new request is submitted, we instantiate a new entity framework context and store it into http context (unique to each request and in memory stored).

When we need the context we can access it via a simple helper.

During the end request event, we dispose the context avoiding potential memory leaks.

I hope this solution will help you building your applications. Do not hesitate to comment if you have a better one.