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.)?

Edited:

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.

.NET Framework 4.5.1 Broke .NET 4.0 Application

Recently we installed the latest Windows Updates; one of the updates installed .NET Framework 4.5.1!

After installing the updates, .NET 4.0 Web API project stopped working. Following three errors were reported in the logs generated by the application; this is the same code that was running fine before the updates were installed! Please note that each of the following was a separately reported exception which occurred when the code was trying to open a connection to the database.

• System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
• System.InvalidOperationException: Timeout expired.  The timeout period elapsed prior to obtaining a connection from the pool.  This may have occurred because all pooled connections were in use and max pool size was reached.
• System.Data.SqlClient.SqlException (0x80131904): A connection was successfully established with the server, but then an error occurred during the login process. (provider: SSL Provider, error: 0 – The message received was unexpected or badly formatted.) —> System.ComponentModel.Win32Exception (0x80004005): The message received was unexpected or badly formatted

The following errors were found in the Applications event log.

Faulting application name: w3wp.exe, version: 7.5.7601.17514, time stamp: 0x4ce7afa2
Faulting module name: System.Data.dll, version: 4.0.30319.18408, time stamp: 0x52310bef
Exception code: 0xc0000005
Fault offset: 0x000000000002ca0c
Faulting process id: 0x1c44
Faulting application start time: 0x01cf160933711ff2
Faulting application path: c:\windows\system32\inetsrv\w3wp.exe
Faulting module path: C:\Windows\Microsoft.Net\assembly\GAC_64\System.Data\v4.0_4.0.0.0__b77a5c561934e089\System.Data.dll
Report Id: b43e16a4-81fd-11e3-9401-d4ae5267f94a

Fault bucket , type 0
Event Name: APPCRASH
Response: Not available
Cab Id: 0

Problem signature:
P1: w3wp.exe
P2: 7.5.7601.17514
P3: 4ce7afa2
P4: System.Data.dll
P5: 4.0.30319.18408
P6: 52310bef
P7: c0000005
P8: 000000000002ca0c
P9:
P10:

Attached files:

These files may be available here:
C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_w3wp.exe_1dabd81cc049f8988c7cfa9798cf58f89514c50_0970896a

Analysis symbol:
Rechecking for solution: 0
Report Id: b43e16a4-81fd-11e3-9401-d4ae5267f94a
Report Status: 4

Research on Google didn’t help much because different people received these errors in different contexts and the solutions/tips varied from restarting the computer to changing the way we access the database! We didn’t want to touch the code because this application was working moments ago! There has to be something in the Windows Updates that broke the application.

Painstaking review of the Windows Updates which were installed that day couldn’t result in anything important that would help narrow down to a particular update.

Then all of a sudden, the light bulb moment! I remember seeing .NET Framework 4.5.1 in the list of updates Windows wanted to install but it wasn’t in the above list! So where did it go? It was found in the “Add/Remove Programs” area. Before we could uninstall it, we wanted to check whether that is the culprit. Little research on .NET Framework 4.5.1 lead us to the KB2915689 which talks about one of the errors we were getting!

We tried the first workaround by disabling the Sophos Antivirus which had several BSP/LSP installed on the server but no use; the application still threw the same errors.

The second workaround was to uninstall .NET Framework 4.5.1 and we did just that! Please make a note of the following gotchas (originally listed here) before you install or uninstall .NET Framework 4.5.1

• The .NET Framework 4.5.1 is an in-place update to the .NET Framework 4.5.
• The .NET Framework 4.5 and .NET Framework 4.5.1 replace the .NET Framework 4. When you install these versions on a system that has the .NET Framework 4 installed, the assemblies are replaced.
• Uninstalling the .NET Framework 4.5 also removes pre-existing .NET Framework 4 files. If you want to go back to the .NET Framework 4, you must reinstall it and any updates to it. (See Installing the .NET Framework 4.)

In a nutshell, we were able to run the application again by following these steps:

1. Uninstall the .NET Framework 4.5.1
2. Install the .NET Framework 4.0
3. Update the Application Pool for the particular application to use .NET 4.0 (apparently uninstalling 4.5.1 changed it to .NET 2.0)

Which .NET Frameworks and Updates are Installed?

Recently we had to deal with an issue where a .NET Framework update caused a .NET 4.0 application to stop working. In fact the IIS worker process was crashing! Long story short, we had to figure out which versions of .NET and the respective updates were installed on the server in order to take corrective actions. The following links helped determine the information needed.

How to: Determine Which .NET Framework Versions Are Installed

How to: Determine Which .NET Framework Updates Are Installed

AzureTools–Diagnostic Utility

On the Windows Azure Advisors group, one of the Azure team members shared this utility which MS Azure teams use internally for diagnostic the problems! You can find more information about it here.

nuget “Access is denied” “Command existed with code 5”

I just setup a new Windows Server 2008 R2 development VM in order to work on a project. Downloaded the source code from Git and hit “Rebuild Solution”. Few projects failed to build with the following error (taken from the Output window after enabling MSBuild verbosity to Detailed:

Task “Exec” “C:\Work\Github\………….\.nuget\nuget.exe” install “C:\Work\Github\…………\packages.config” -source “”  -RequireConsent -solutionDir “C:\Work\Github\…………….\ “

C:\Work\Github\…….\.nuget\NuGet.targets(87,9): error : Access is denied.

C:\Work\Github\…..\.nuget\NuGet.targets(87,9): error MSB3075: The command “”C:\Work\Github\…..\.nuget\nuget.exe” install “C:\Work\Github\…..\packages.config” -source “”  -RequireConsent -solutionDir “C:\Work\Github\…..\ “” exited with code 5. Please verify that you have sufficient rights to run this command.
Done executing task “Exec” — FAILED.

The NuGet executable could not be executed during the build process! I had never faced this problem before. Came across few posts on the Internet where others were facing similar problems and had recommended to change certain NuGet settings or to delete and reinstall NuGet altogether. I did all that but no use.

I manually ran the nuget.exe in a command prompt and got the same “Access is denied” error. All of a sudden, light-bulb moment I looked at the properties of the nuget.exe and that is where the answer was! See below the screen shot.

Perhaps this is Windows Server 2008 security feature but the Everyone was allowed only “Read” permission on the nuget.exe; in order for it to get executed, the caller should have the “Read & Execute” permission as well.

Granting the “Everyone” group “Read & Execute” seems to solve the problem.

I would love to hear if you know of a better way to solve this issue. Drop me a line. Thanks.