P. Long time no Post.

I’m working on a prototype that involves .net micro controllers, RFID readers, XBee PAN network with a PC which connects to a WCF service that populates and queries data stored in an Azure data base. This was all developed first. The overall architecture is shown

Then I built an MVC 4 web site on local host and with a local copy of the DB and ASP membership which of course was deployed to .\SQLEXPRESS 2012 but need to be integrated into the production database. In the middle of the development process is TFS. This Post is about the steps I took to deploy the MVC 4 based web site via TFS to Azure having taken a DB first approach to development and incorporating ASP membership along the way.

Here are the steps.

1. Setup a Project in TFS.

2. Scripted DB from Azure and created local copy on SQLEXPRESS

a. Created EDMX (EF 5) link to the SQLEXPRESS database.

b. SQLEXPRESS also handles the ASP membership

3. Merge the ASP authentication model with the data model in SQLEXPRESS. This gives rise to two connection strings for 2(a) and 2(b) as EDMX is compiled/scripted and has metadata references in the connection string and ASP Auth does not.

4. Export a script of the newly updated DB from SQL Express as it now has the ASP membership and user Profile tables in there.

5. Drop the Azure SQL database and recreated it with an admin login and took note of the connection string on Azure Portal.

6. Login to the Azure SQL manager (Silverlight based) on the Azure Portal. You’ll need the admin account setup previously for this. The DB being empty and imported the local script and populated the Azure SQL Data.

7. Change the local Web.config to point at the new Azure Database and tested it worked.

8. Upload a copy of the latest code to TFS

9. Create a web site (new Azure feature in Review at the moment)

10. Connect the website to TFS (you should ensure that the same live ID is used for TFS and Azure Portal for clean connection between the two services)

11. Go to TFS

a. Choose your Project

b. Choose the Build Option

c. You should see name-CD that is created

12. Selecting name-CD click on Queue Build…

13. Fill in the Build popup screen and click ok

14. It will deployed to the linked Azure Web site.

Go for a cup of tea and then test the site.

P.

So you want to deploy your beautiful localhost ASP.NET MVC project to Azure. Well, pack a lunch…

Typically your ingredients will be:

• Visual Studio ASP.NET MVC Project (tested with VS2012 Update 2)
• SQL Server local database (tested with SQL Express 2012)
• Azure subscription
• Team Foundation Service source control

There are several ways to go about deploying and this is part of the confusion. The database deployment in particular can be difficult once you leave the same confines of SQL Server Management Studio (SSMS). Shifting the project itself can be accomplished in a few ways (link to TFS, download publish profile etc.). Here’s how to go about it:

1. Sign into Azure and create a SQL Server. You don’t need a database at this point as we’ll create that later. Do note the administrator username and password as you’ll need this later.
2. I found it best to deploy the database first as you can then attempt to connect to it from your localhost web app to ensure that the connection string is correct before you deploy the web app itself to the cloud. SSMS 2012 now has an easy way to deploy the database to Azure.
   
   
   You’ll have to connect to the SQL Server on Azure so ensure you took careful note of the Administrator username and password. The rest of the form will be filled by SSMS.
3. You now have the database on Azure and can modify your connection string in your localhost project if you like to see if you can access it. You only have the administrator username/password for now so we’ll need to create a separate Login/User combination later (best practice). You’ll find the full connection string by visiting Azure and viewing the newly uploaded database.
   Test your localhost web app against the Azure-hosted SQL database. If using Code Migrations ensure you have updated your database with Package Console before doing these steps. While it’s possible later to have code migrations run by Azure, I haven’t tested this.

Next we need to set up specific a Login and User for your deployed database. This is distinct from the admin username & password we use to connect to the Azure SQL Server. Ordinarily, SSMS would be useful here but Azure isn’t compliant with these kinds of operations from SSMS so we need some T-SQL. However, one problem that needs addressing is that you cannot use the T-SQL ‘USE’ command to switch between databases on the Azure SQL Server. This is important as we need to set up both a Login (for the master database) as well as a corresponding User (for the deployed database).
The easiest way to do this is via SSMS but as the Login must be established on the master database, you need to make a connection to the Azure SQL Server ‘master’ database first. Remember to use the admin username here. Then create another connection to the Azure SQL Server but this time to your deployed SQL database. Have these two connections side by side in SSMS for convenience.
Now create a Login on the master database. Ensure you have the ‘master’ db connection active on the left panel and press CTRL-N to create a new SQL Query window. Now create a Login with an associated password: CREATE LOGIN readonlylogin WITH password=’1231!#ASDF!a’;
Next create a User on the deployed database by switching to the other database connection:  CREATE USER readonlyuser FROM LOGIN readonlylogin;
Lastly, you need to assign permissions to that Login so that it can play with the database: EXEC sp_addrolemember ‘db_datareader’, ‘readonlyuser’;

You may find this post useful to elaborate on this aspect. Test your settings by taking the Login and changing your connection string (in your localhost app) to reflect the new Login and its password.

4. Assuming your modified connection string worked, the next step is deploy the web application. Begin by signing into Azure and creating a Web Site. Don’t bother with a database for this as we’ll indicate the linked database later. Next step is to upload your localhost application. But before doing this, make a connection on Azure between your Web Site (not yet uploaded) and the database created in the previous steps.
5. One new way to do this is particularly convenient (if it works) is to integrate your nascent web site on Azure with TFS (Team Foundation Service). Ensure that the Azure Live ID is the same you use to manage your TFS project (or at least, I’m guessing, is a member of the project team on TFS). Once connected in Azure, head back to VS2012 and do a trivial change and check in to Source Control. This will trigger the Build that Azure set up and begin the deployment. You can monitor the progress of this Build from within VS by calling up Team Explorer and viewing the Builds dropdown.
   
6. Another method which I’ve had better success with is to download from Azure a ‘Publish Profile’, available from the main web site dashboard. Save this small file locally and re-enter VS. Right click on the web application Project in Solution Explorer.
   Most of the information needed by this dialog will be pre-populated. However, on the Settings tab, ensure that only the necessary connection string is active – uncheck those that don’t apply. The final ‘Preview’ screen will warn of any errors and click ‘Start Preview’ to see your files scanned in readiness for uploading to Azure. Click ‘Publish’ to deploy and try to browse to your newly published web site.
7. If you get errors (YSOD) that are not descriptive, then turn on ‘CustomErrors’ in your web.config file. Read more on this here. This will result in better descriptions of your problems – likely to be database connection issues.
8. Also, you need to ensure that your IP address is set as an ‘allowed IP address’ on Azure. For public deployment you’ll likely need a range of addresses that are permitted.

So, piece of cake really though I guess once you’ve ironed out all the pitfalls, it would be automatic. Also, republishing is simple and it will only upload those files that have changed. If using TFS integration, the a simple re-build is all that is needed – be sure to turn on continuous integration for the Build in question though.

Often, we use wire-framing or mock-up tools (like the good guys at Balsamiq) to help communicate design ideas between developers as well as to clients. However, there is a need for something more efficient to aid communication of possible user interface flows through our emerging application. This communication is for internal use typically and doesn’t need to approximate the appearance of the final product in any way – it’s just a means to explore the pathways through the program without getting side-tracked by the scenery along the way.

Ryan at 37Signals posted a very interesting way of addressing this issue. As you can see it seeks to communicate the movement between states more effectively. It also avoids getting bogged down with the detail of each representation of state, focusing instead on the salient aspects to each (probably, well-known) state.

The horizontal line separates what the user sees on the screen (topside) from what action he (can) take (bottom-side). Here’s a more detailed example Ryan provides:

As you can see it very succinctly captures the pathway that the user takes through the process of adding an item to a ‘To-Do List’. Building on this Ryan offers equally compact means to capture multiple choices of action by the user:

The dashed lines separate alternative actions that the user can choose from, each naturally leading to alternative views from where further actions can be selected. I like Ryan’s reminder at the end that all these drawings are ‘destined for the garbage’ – like all prototyping and similar tooling, they are part of the process, not the product. The longer they linger the less use they serve.

One of the challenges of working in the Mac environment while developing in Microsoft technologies is getting the VM machine working as you want. Being a fan of keyboard shortcuts, it’s a major PITA if the key mappings aren’t set as you’d expect, especially as I move routinely between Mac and Windows PC.

So, with my Parallels 7 and Windows 8 setup, do the following to get it just right:

1. In Parallels, choose Preferences…Keyboard and ensure Virtual Machine Shortcuts are off.
2. At the bottom of that box, I leave ‘Enable Mac OSX system shortcuts’ enabled to give me the Fn controls across the top of my keyboard. This means I have to press Fn with, say, F6 to compile in VS2012 but that’s how I prefer it.
3. That’s all she wrote.

There’s an issue when you try to attach a local MDF SQL database file to the local instance of SQL Express. VS typically will insert a USER INSTANCE = true into the connection string that it generates when you add the LINQ-to-SQL or ADO.NET Entity modelling to your project.

The connection to the database as attached to SQL EXPRESS will fail on open. Fix this by removing the User Instance clause from the connection string.

Other solutions advise deleting the SQL Express folder from the AppData folder for the user but I found the first options works for me and doesn’t require any privileges on the host machine.