MissingManifestResourceException when using Portable Class Libraries within WinRT
Our team recently ran into a strange issue. Our Windows Phone application targets Silverlight 8.1 but we have several WinRT 8.1 based background tasks. Recen...
When a package fails to deploy to Windows Azure (or deploys but its roles fail to start properly) it can be difficult to determine what went wrong. In many cases, these failures often happen before the diagnostics agent has had a chance to startup and help identify the issue. A lot of these failures are due to simple but easily forgotten tasks, such as not adding a referenced assembly to the package or not updating your connection strings to point to Windows Azure storage instead of the storage emulator. The Windows Azure Tools for Visual Studio tries to help developers catch many of these issues before they spend time waiting for their package to deploy and the application to start (and then fail). When such issues are encountered during packaging the build process generates validation warnings or errors. The developer then has immediate, specific feedback on what needs to be done before deploying again to Windows Azure.
Validation performed by the Tools include:
In some cases, however, these warnings may not apply. For example, suppose you are generating a package as part of a continuous build that will then be deployed to the development fabric and undergo a series of automated tests. If you were to generate a package (e.g. by calling the Publish target), you may see the following warnings:
WebRole1(0,0): warning WAT170: The configuration setting 'Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString' is set up to use the local storage emulator for role 'WebRole1' in configuration file 'ServiceConfiguration.Cloud.cscfg'. To access Windows Azure storage services, you must provide a valid Windows Azure storage connection string.
WebRole1(0,0): warning WAT230: The connection string 'DefaultConnection' is using a local database '(LocalDb)\v11.0' in project 'WebRole1'. 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.
The warnings indicate that there are connection strings pointing to the storage emulator as well as a local database and these will likely cause a deployment to Windows Azure to fail. In this case, however, we know that the package is being deployed to the development fabric so those connection strings are, in fact, perfectly valid. In the interests of producing “clean” builds, it would be nice to ignore these warnings in this particular case.
To ignore validation warnings when packaging a Windows Azure application, set the IgnoreValidationIssueCodes
MSBuild property in your application’s project file. For example, to ignore the two warnings encountered above set the property after the import of the WindowsAzure targets file:
.
.
.
<Import Project="$(CloudExtensionsDir)Microsoft.WindowsAzure.targets" />
<PropertyGroup>
<IgnoreValidationIssueCodes>WAT170;WAT230</IgnoreValidationIssueCodes>
</PropertyGroup>
.
.
.
Now these warnings will not be generated when packaging.
This post was migrated from my MSDN blog, Visual Studio Tools and Anything Else I Can Think Of, and written as a Microsoft employee.
Our team recently ran into a strange issue. Our Windows Phone application targets Silverlight 8.1 but we have several WinRT 8.1 based background tasks. Recen...
In a previous post I introduced the concept of Role Content Folders and how they can be used to deploy additional content (e.g. configuration files, runtime ...
The latest versions of the Windows Azure Tools for Visual Studio have the ability to maintain multiple versions of the Service Configuration (.cscfg) file.&n...
When a package fails to deploy to Windows Azure (or deploys but its roles fail to start properly) it can be difficult to determine what went wrong. In many c...
Windows Azure applications often need to package and deploy additional content. This could be advanced configuration files such as the diagnostics.wadcfg for...
The LINQ-to-DASL provider of the Office Interop API Extensions provides a very limited set of mappings between its query types and their associated DASL prop...
When your LINQ-to-DASL queries do not return the results you expect, how do you determine where the problem is? The issue could be that the query simpl...
I received an email over the weekend asking why the following LINQ to DASL query threw an exception: Outlook.Folder folder = (Outlook.Folder)Application.Se...
Now that the Office Interop API Extensions have been released, I thought I would post a complete walkthrough of a simple LINQ to DASL application. Let's star...
One of the disadvantages of C# compared with VB is its lack of support for parameterized properties. Instead, parameterized properties in C# are exposed as ...
As announced in Andrew Whitechapel’s post, version 1.0 of the VSTO Power Tools have been released! One of those tools is the Office Interop API Extensions, a...
In an earlier post I discussed LINQ to DASL, part of the Office Interop API Extensions, which is one of the forthcoming VSTO Power Tools. LINQ to DASL ...
In my last post I talked about LINQ to DASL, a LINQ provider that converts query expressions into their DASL equivalent in order to efficiently filter item c...
Quick, tell me what the following code does:
I like VSTO. I like C#. What I don’t like is having to write VSTO code in C# like:
Yesterday I gave a presentation on VSTO at the third annual Portland Code Camp. I demonstrated an Outlook 2007 add-in that used Outlook Form Regions, WCF, an...