The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Windows Azure Tools\2.3\Microsoft.WindowsAzure.targets" was not found.

Visual Studio 2013 ultimate began reporting this error while F5-ing the application; surprisingly the application compiles just fine! It just would not debug which I was able to do a day before!

The imported project “C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Windows Azure Tools\2.3\Microsoft.WindowsAzure.targets” was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.

I searched online but could not find helpful information. I made couple of attempts to fix the issue (reinstalled the Azure Tools for VS 2013) but no use! It kept giving me this error. From the error description it is obvious that the VS is unable to find the Microsoft.WindowsAzure.targets file.

After a while I realized that I had installed Red Gate’s .NET Daemon and this error could be related to that. Saw the following setting on the .NET Daemon menu – unchecking it allowed me to F5 the application without running into that error!


At least now I knew which software was causing the issue. Unchecking the setting in the daemon isn’t the solution; I had to address the root cause which is the missing Microsoft.WindowsAzure.targets file.

On my development machines this file existed under the folders for Windows Azure Tools for Visual Studio 2.2 (C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\Windows Azure Tools\2.2) and 2.3 (C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\Windows Azure Tools\2.3).

The .NET Daemon was looking for this file under C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Windows Azure Tools\2.3 folder! All I did to resolve the issue was to mimic the folder structure for v12.0 under v10.0.

Questions for the Red Gate team in case they read this post. I may be wrong but this appears to be an issue or perhaps I didn’t install the Daemon correctly. What is the elegant solution that would NOT require me to copy the folders? Perhaps the Daemon should just look at the project it is dealing with to figure out what version of the Azure Tools it is using and look for the .targets file in the respective folder under correct Visual Studio sub-folder (v10.0, v12.0, etc.)?


I received the following response from the Red Gate support. Hope it helps.

Hi, sorry you had a problem with Demon.

Msbuild paths have changed in Visual Studio 2013 and this may cause some problems for .NET Demon if you have files that still point to older versions of VS or to the old msbuild path. This error happens when a .nuget package restore file points to the wrong MSBuild tools path. In this case, removing your restore files (particularly Nuget.config and Nuget.targets) from your solution and file system, and then re-enabling package restore should resolve it. Similar errors can occur if you have either the PlatformToolset or VisualStudioVersion properties set to an older version, but changing their values to “v12.0” should help.


Windows Azure Symbols and Icon Set

Rob Boucher just posted a link to the recently published “Windows Azure Symbols and Icon Set” containing Visio stencil for creating diagrams for system built for Azure and related PNG files! Already loving it.

This is how the stencil looks in Visio.


Fix for “The Windows Azure computer emulator must be run elevated” error

Debugging a Cloud Service project in Visual Studio 2013 requires you to run VS under elevated account (such as an Admin). You would receive the following message if you try to Debug the project without running the VS under an elevated account.


This happens because by default the Full Emulator is supposed to run which needs the elevated access.


You can avoid running the VS under elevated account if you change the Cloud Service project’s Emulator setting to “Use Emulator Express” which does not require the VS to run under elevated account. See below.


You would miss out on few features but this may not be a deal breaker for many developers. See the following article for more information – Debugging a Cloud Service with Emulator Express

Got enrolled in the Windows Azure Advisors program!

I recently got enrolled in the Windows Azure Advisors program. It is a group of Windows Azure architects, developers and the MS Azure teams to collaborate on ideas, to discuss upcoming features, and really to help out each other by asking and answering questions! Looking forward to more Azure learning and discussions.

Resource Management on Windows Azure SQL Database

Most of you might know that Microsoft’s cloud database engine, SQL Database, implements throttling in order to avoid a rouge or poorly coded application from affecting performance of other applications that might be sharing the same cloud infrastructure.

Throttling is good because it promotes writing optimize code but it also helps to know the thresholds that define the size of the sandbox that the applications must remain in before the throttling kicks-in. I could not find concrete throttling thresholds and solid guidance until recently.

Microsoft just published some material on this topic; it covers not only the concepts (throttling, governance, etc.) involved in the resource management but also concrete throttling thresholds, best practices and code example. Check it out @ Resource Management in Windows Azure SQL Database