Troubleshooting Package Validation Warnings and Errors
When you create a package or publish your Windows Azure application, warnings or errors might occur. These warnings and errors can help you fix issues that would prevent the application from being deployed or published. By receiving a warning or error at the packaging stage, you can save time by fixing these issues before you deploy your Windows Azure application. You do not have to wait for the deployment to complete and then have the deployment fail.
By default, package validation issues are treated as warnings and will not prevent deployment of your role. To change the default value and prevent deployment, treat these warnings as build errors. To do this, set the property Treat warnings as errors to true for your Windows Azure project. For more information, see How to: Configure a Windows Azure Project with Visual Studio.
The following table shows the key warning messages for package validation for a Windows Azure application and a link to more details for each message.
The project ‘<project name>’ is dependent on the following assembly: ‘<assembly name>’. This assembly is not in the package. To make sure that the role starts, add this assembly as a reference to the project and set the Copy Local property to true.
The project ‘<project name>’ is dependent on the following assembly: ‘<assembly name>’. This assembly is not in the package and should be installed in the GAC. To make sure that the role starts, add this assembly as a reference in the project and set the Copy Local property to true. Then use a startup task for the role to add the assembly to the GAC.
The project ‘<project name>’ is dependent on the following assembly: ‘<assembly name>’. This assembly is installed in the GAC by an MSI. To make sure that the role starts, you must either install this MSI by using a startup task for your role or add this assembly as a reference in the project and set the Copy Local property to true.
The web project ‘<project name>’ is dependent on the following MVC assembly: <assembly name>. These assemblies must be added to the package or installed on the virtual machine for your role. For more details about this, see the following help page: http://go.microsoft.com/fwlink/?LinkId=218227.
The project ‘<project name>’ contains the following assembly: ‘<assembly name>’. This assembly is not compatible with the 64-bit processor architecture used by IIS on Windows Azure. To make sure that the role starts, you must replace this assembly with one that is compatible with this architecture.
If you have a startup task to configure IIS to run 32 bit applications, you can ignore this warning message. For more information about how to do this, see Enable 32 bit application mode in the IIS application pool using a startup task.
Otherwise, remove the assembly from your project and add an assembly that is compatible with the 64-bit processor architecture. Then repackage or publish the application.
The configuration setting '<setting name>' is set up to use the local storage emulator for role '<role name>' in configuration file '<file name>'. To access Windows Azure storage services, you must provide a valid Windows Azure storage connection string.
For more information about how to add a valid Windows Azure storage connection string, see Setting Up Services Required to Publish a Cloud Service from Visual Studio.
Package creation failed because there are validation errors. You must either fix the errors, or you can set the property "Treat warnings as errors" to false for this Windows Azure project.
For more information about how to set the property Treat warnings as errors, see How to: Configure a Windows Azure Project with Visual Studio.
The project '<project name>' targets ’<version of .Net Framework>’. To make sure that the role starts, this version of the .NET Framework must be installed on the virtual machine for this role. You can use a startup task to install the required version, if it is not already installed as part of the Windows Azure guest OS.
The connection string 'DefaultConnection' is using a local database '.\SQLEXPRESS' in project '<project name>'. This connection string will not work when you run this application in Windows Azure. To access a different database, you should update the connection string in the web.config file. For more details about this, see the following help page: http://go.microsoft.com/fwlink/?LinkId=224877
If a role fails to start, you should check the package build/deployment output window to verify that there were no validation warnings or errors. You can also set up a remote desktop connection when you publish your application to enable you to access the virtual machine and diagnose any issues. For more information about how to use remote desktop for Windows Azure, see Using Remote Desktop with Windows Azure Roles.
Another approach to determine why a role fails to start is to enable IntelliTrace for your deployment. For more information about how to enable IntelliTrace for a Windows Azure application, see Debugging a Published Cloud Service with IntelliTrace and Visual Studio.
For help with troubleshooting other role failure issues, see Troubleshooting Roles that Fail to Start.
When a role is created on a virtual machine, you may want to add a startup task that is run after the virtual machine is created and before the role is started. This task makes sure that the role can start successfully. For example, you might want to do one of the following tasks:
Install an .MSI.
Add an assembly to the GAC.
Install a specific version of the .NET framework that is required for the role.
The startup tasks that you add for a role are run from the command line. You can either create a batch file to run a set of commands or add the specific commands that you want to run. You add the files for the startup task to your project so that they are installed when the service package is deployed. The startup task is then run using these files after the virtual machine for that role is created.
If your files for your startup task are in a subdirectory, your startup task may need to access the directory of the batch file when the commands are run on the virtual machine. You can use the following variable to access the directory of the batch file: %~dp0. Note that this variable contains the drive and path for the batch file and adds a backslash at the end of the path. For example, you might use the following command to run a .exe file (StartUp.exe) that is located in the same folder as the batch file: %~dp0StartUp.exe.
To create a startup task for a role
(Optional) You can create a batch file if you want to run a set of commands together for your startup task. The file that you create to run a startup task must not include a byte order mark. To avoid this issue, you can either create your file to run your startup task using notepad, or make sure that you save a file that you create in Visual Studio with encoding. To save a file in Visual Studio with encoding, use the following steps:
To save a file in Visual Studio with encoding, make sure that the file is displayed in the Visual Studio editor window. On the menu bar choose File, Save <Filename> As.
The Save File As dialog is displayed.
To save the file with encoding, choose the drop-down arrow on the Save button and choose Save with Encoding.
The Advanced Save Options dialog box is displayed.
In the Encoding list choose Unicode (UTF-8 with signature) – Codepage 65001 and then choose the OK button.
To add a folder for your startup task, create a folder in the project for the role that needs a startup task. For example, if it is a web role project called WebRole1 that requires that you install an .MSI add a folder called Startup in this web role project.
To add the files to this folder, open the shortcut menu for the folder and choose Add, Existing Item. Choose the files that are required for the startup task including any batch files and then choose the Add button.
The files are displayed in Solution Explorer below the folder that you created.
To include these files in your service package but not attempt to build these files, open the shortcut menu for each file and choose Properties. In the Properties view, in the Build Action dropdown list choose None and in the Copy to Output Directory dropdown list choose Copy if newer.
To add the startup task to your role, open the shortcut menu for the service definition file ServiceDefinition.csdef and choose Open. Add the following XML statements to the role element that requires this startup task. This command assumes that you created a folder for your startup tasks called Startup and that this batch file or command requires elevated privileges. The command can be a .exe file, a batch file, a .msi file or any valid command line statement.
<Startup> <Task commandLine="startup\<command>" executionContext="elevated" taskType="simple" /> </Startup>
Here is an example of the webrole element in a service definition file with a startup task added:
<WebRole name="WebRole1"> <Sites> <Site name="Web"> <Bindings> <Binding name="Endpoint1" endpointName="Endpoint1" /> </Bindings> </Site> </Sites> <Endpoints> <InputEndpoint name="Endpoint1" protocol="http" port="80" /> </Endpoints> <Imports> <Import moduleName="Diagnostics" /> <Import moduleName="RemoteAccess" /> <Import moduleName="RemoteForwarder" /> </Imports> <Startup> <Task commandLine="startup\StartUpTask.cmd" executionContext="elevated" /> </Startup> </WebRole>
To verify that the startup task runs, publish your Windows Azure application. If necessary, you can create a remote desktop connection for the virtual machine for your role when you publish your application. Then you can connect to the virtual machine and verify that the startup tasks ran correctly. For more information about how to use remote desktop with Windows Azure roles, see Using Remote Desktop with Windows Azure Roles.
For detailed steps about how to create a startup task for a role, see How to Define Startup Tasks for a Role. If you need to use environment variables with your startup task, you can define environment variables for a role in your service definition file. For more information about this, see How to Define Environment Variables Before a Role Starts.
For links to further information about startup tasks for a role, see Starting Tasks Before Role Instances Start in Windows Azure.
If you want to publish an MVC project as a web role to Windows Azure, you need to make sure that all the necessary MVC assemblies are available when the web role runs in Windows Azure. If you create an MVC project as a web role using the templates provided by the latest Windows Azure tools for Visual Studio, the assemblies that you require are automatically added to the service package. In this situation, you should not see a warning message about missing MVC assemblies when the service package is created.
To fix a warning message that you are missing MVC assemblies, you must follow the steps in the procedure that applies to your MVC project:
To add assemblies for an existing MVC3 project
If you are using Visual Studio Service Pack 1 to publish your Windows Azure application, use the following steps to add references to the assemblies and include them in the service package:
Open the shortcut menu for the MVC project and choose Add Deployable Dependencies.
The Add Deployable Dependencies dialog box is displayed.
Select the ASP.NET MVC check box and choose the OK button.
The assemblies will now be added when you create a service package. Then the assemblies will be installed on the virtual machine for this web role when the service package is deployed.
If you are not using Visual Studio Service Pack 1 to publish your Windows Azure application, you can perform one of the following tasks to make sure that your Windows Azure application runs correctly when it is deployed in Windows Azure:
Add references to the following assemblies to your web role project, and then set the Copy Local property to True:
For more information about how to add a reference for an assembly to a web role project, see Include Files in the Service Package.
Add a startup task to your web role to install the MVC3 assemblies. Create a folder in your project called startup. Then add the file AspNetMVC3Setup.exe to this folder. Finally add this XML to the service definition file within the web role element:
<Startup> <Task commandLine="startup\AspNetMVC3Setup.exe /q /log mvc3_install.htm" executionContext="elevated" /> </Startup>
Read a blog entry about adding a startup task for MVC3 assemblies. For more information about startup tasks, see the previous section: Create a startup task for a role.
To add assemblies for an existing MVC2 project
If you receive this warning message for an MVC2 project, the reference for the System.Web.Mvc assembly should already be added to the web role project. To include this assembly in the service package, open the shortcut menu for this assembly and choose Properties.
The Properties window is displayed.
In the Copy Local list choose True.
When you create an MVC 3 web role with the Windows Azure tools for Visual Studio, the web role is set up to use the Universal ASP.Net providers. By default, these providers are configured to use a local SQL Express database for the DefaultConnection connection string. When you publish your Windows Azure application, you must change the connection string to use a SQL Database instance hosted by Windows Azure.
You must have a subscription that enables you to use SQL Database hosted by Windows Azure. If you access your subscription from the Windows Azure Management Portal, you can determine what services your subscription provides. For information on how to change your connection string, see How to: Migrate and Publish a Web Application to Windows Azure from Visual Studio.