Fixing errors when publishing different projects to a .NET backend

Quick post today. A few people in our team (and one in the forums) have hit an issue for which the current error logging doesn’t help too much, so write about this issue here. The problem is that when you try to publish a project to a mobile service where another project had been published before – even if it was the same project with a different name. I’ll walk through a scenario where this can happen, and show how to avoid it. If you are already with this problem and only want to fix it, jump to the “Fixing the issue” section on this post.

Setting up the issue

For this scenario I’ll create a new mobile service, and download the starter project. To make it simpler, I’m downloading the server-side project only, not the client app.

We’ll also need to download the publish profile to publish the project later.

After unzipping the downloaded project, open it in Visual Studio, right-click the project and select “Publish”

You’ll need to import the publish profile file which you downloaded a couple of steps back.

Once that is done, click “Publish” and the service will be running on Azure. The publish wizard will open up the service page to say that is running.

Causing problems

After developing my service I decided that I didn’t like the name which the downloaded project had – blog20140429Service didn’t really reflect what my project did. So I decided to rename it. First rename the project itself in VS:

And then change the default namespace and assembly names in the project properties.

Now if we publish the project again, we’ll see an error page where before we had the nice landing page for the mobile service.

The cause

If we look at the logs in the portal, we’ll see an error entry. Clicking on the details button, we’ll see the entry below. It tells us that there are two WebApiConfig classes – but our project only has one of those classes. However, when we published the new (renamed) project, by default it will just copy the files from the local computer to the mobile service in Azure. That means that in our service we have two assemblies, the old one (blog20140429Service.dll) and the new one (MyTodoItemService.dll), and both of them have the bootstrapper class WebApiConfig. Faced with multiple options, the mobile service bootstrapper code makes the “safe” choice and doesn’t start anything (if it were to choose one over the other it could end up choosing the wrong one, and that would be harder to debug).

Fixing the issue

Fortunately, there is a fairly simple way to get rid of this issue. In the Publish wizard there is an option which we can select that will fix this problem. Right-click the project and select publish again, but instead of clicking “Publish”, select the “Previous” button:

In the configuration, expand the “File Publish Options” group, and once that is expanded select the “Remove additional files at destination” checkbox. That will clean up stale files on Azure during the publishing process. Once that is checked, click “Publish”.

And that should do it. By removing the old DLL, the mobile service bootstrapper will only find one entry point and the service can start successfully.

Wrapping up

As we use the .NET runtime and run into those issues we’ll have quick posts so that if you run into them you’ll see how to overcome them. I also hit this scenario once when I tried to use one single “test” service for different pet projects. And as usual, feel free to submit questions or comments to this post, the MSDN forums or contact us via Twitter @AzureMobile.