Visual Studio Tools and Anything Else I Can Think Of

MissingManifestResourceException when using Portable Class Libraries within WinRT

Phil Hoff - MSFT — Wed, 19 Nov 2014 12:12:00 GMT

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. Recently, we refactored our codebase into several Portable Class Libraries (PCLs) in order to better share code between the application and background tasks. Since then, however, we've started seeing MissingManifestResourceExceptions thrown from the background tasks from the ResourceManager.GetString(String, CultureInfo) method. The odd thing was that this occurred only in the background tasks, only when running on a real phone, and only in the application's Release configuration. The exceptions were not seen in the Silverlight application, or in the Windows Phone emulator, or when using the application's Debug configuration.

We originally thought the issue must be due to some overlooked error in our build or packaging processes, but all of our analysis indicated that the there were no significant differences in the built assemblies nor in the packages generated for Debug and Release configurations; the issue must be in the runtime. After a lot of digging around, we finally found an active Microsoft Connect report for the issue:

https://connect.microsoft.com/VisualStudio/feedback/details/991028/issue-using-resx-files-on-winrt-apps-windows-phone-and-windows

That others were running into the same problem, under the same circumstances, seemed to confirm our conclusion. However, we still needed a workaround. Our options were (1) to avoid using PCLs (that use their own resources) from our background task or (2) redirect use of the ResourceManager within the PCL to the WinRT ResourceLoader. Option #1 would mean undoing much of our refactoring work and obviously was a non-starter.

Option #2 works on the assumption that, in a WinRT library, all of the resources of the referenced PCLs are extracted and placed in the package's resources.pri file in addition to being embedded within the PCL assembly itself. That means you can get to the duplicate resources using the WinRT ResourceLoader even if you cannot using the .NET ResourceManager. Because we need to dynamically switch between using the ResourceManager and ResourceLoader when in Silverlight and WinRT, respectively, we need some sort of dependency injection (DI) scheme.

In a typical .NET library, resources are added to a Resources file (.resx). The file is then used to embed the resources into the built assembly. The file is also used to generate a class that exposes each resource as a strongly-typed property, making it easy to consume resources within the library. This generated class uses a ResourceManager instance to retrieve the resource mapped to each property. Redirection means either (1) not using the generated class at all and using DI scheme directly, (2) alter the generation of the class to use the DI scheme, or (3) try to alter the behavior of the class to conform to the DI scheme.

Option #1 was least desirable as it meant a lot of churn within the PCLs. Option #2 was not particularly desirable either as it was a significant amount of work to write and test a generator that matched the built-in one except for this one minor change. The question was how to implement option #3.

Looking at the generated class for a Resources file, each contains a static ResourceManager field named resourceMan. This field (if null) is set on the first retrieval of a resource via one of the generated properties. The ResourceManager.GetString(String, CultureInfo) also happens to be a virtual method, which means we cancreate a derived ResourceManager that retrieves resources from, say, a ResourceLoader. The trick then, is to initialize that static ResourceManager field to an instance of our derived ResourceManager. That turns out to be a simple act of reflection as shown in the following sample:

public class WindowsRuntimeResourceManager : ResourceManager

{

private readonly ResourceLoader resourceLoader;

private WindowsRuntimeResourceManager(string baseName, Assembly assembly) : base(baseName, assembly)
{
this.resourceLoader = ResourceLoader.GetForViewIndependentUse(baseName);
}

public static void InjectIntoResxGeneratedApplicationResourcesClass(Type resxGeneratedApplicationResourcesClass)
{
resxGeneratedApplicationResourcesClass.GetRuntimeFields()
.First(m => m.Name == "resourceMan")
.SetValue(null, new WindowsRuntimeResourceManager(resxGeneratedApplicationResourcesClass.FullName, resxGeneratedApplicationResourcesClass.GetTypeInfo().Assembly));
}

public override string GetString(string name, CultureInfo culture)
{
return this.resourceLoader.GetString(name);
}
}

In the WinRT component, we then call the static injection method for each generated Resources class within the PCL:

WindowsRuntimeResourceManager.InjectIntoResxGeneratedApplicationResourcesClass(typeof(PortableLibrary.Resources.AppResources));

With that, our WinRT background tasks and referenced PCLs were able to access all of their resources without issue and we did not have to significantly refactor any code.

Caveats:

Using reflection to set private fields for types you do not own completely (e.g. are generated) is highly fragile and could break with the next version of the Resources class generator. Do this only if you have no other choice and ensure you have checks in place to detect such breaks.
In our case we owned all of the PCLs referenced by our WinRT component. I cannot say whether this workaround will work for all (e.g. third-party) PCLs, and may not work for PCLs which have internal resource types that cannot be as easily injected.

Dynamically Add Content to Windows Azure Application Roles

Phil Hoff - MSFT — Thu, 05 Jul 2012 19:41:00 GMT

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 components, etc.) to the virtual machine for a Windows Azure application role. That post was written from the perspective of a developer working within Visual Studio and works great when the content is relatively static and specific to a single project. However, this feature works less well in cases where the content is more dynamic (i.e. where the additional content is not known until package-time) or when the content is used across several roles or applications. Fortunately, the packaging of Role Content Folders within Visual Studio is built upon more general MSBuild infrastructure which we can extend to package additional, arbitrary content.

In v1.7, the targets file for Windows Azure projects contains a new packaging phase (i.e. high-level target) called AddRoleContent. In this phase, various sub-targets identify the Role Content Folders defined by the project file, prepare the files within those folders for packaging, and then inject appropriate elements into the Service Definition (.csdef) file such that those files will be packaged when the process invokes CSPack. The AzureRoleContent MSBuild item group ultimately determines what folders will be packaged and for which roles. An AzureRoleContent item contains the following metadata:

Identity (i.e. Include): This metadata specifies the source folder of the content to package
RoleName: This metadata specifies the name of the role to which the content should be deployed; the content will be deployed to all instances of that role.
Destination: (Optional) This metadata specifies the location to which the content should be deployed (relative to APPROOT). If omitted, the content is deployed directly to APPROOT.

To inject additional content into the package, one must add new AzureRoleContent items prior to the last step of this packaging phase. A convenient place to do this is within an override of the BeforeAddRoleContent target. An alternative is to add a custom target to the beginning of the target list CoreAddRoleContentDependsOn MSBuild property. This latter approach can be useful for cases where you customize many Windows Azure projects in the same way, as it ensures that individual Azure projects do not interfere with the customization if a project were to independently override the BeforeAddRoleContent target.

Let’s suppose we have the following:

A Visual Studio solution with a Windows Azure project, DynamicRoleContentFolderTest, containing two roles:

A web role named MyWebRole
A worker role named MyWorkerRole

An additional folder of content, AdditionalContent, to be deployed only to the web role:

Located within the DynamicRoleContentFolderTest project
Contains a single file, AdditionalContent.xml

The first step is to edit the Windows Azure project file and override the BeforeAddRoleContent target. Next, the target will create a new item group, AzureRoleContent, that includes the AdditionalContent folder. We’ll then add metadata to the item group to specify that it be deployed with the web role, MyWebRole, as well as deployed to the APPROOT\AdditionalContent folder. In the end, we will have a project file that looks something like:

.
.
.


      MyWebRole
      AdditionalContent


.
.
.

When a package is built and/or deployed you will then see the AdditionalContent folder, with its AdditionalContent.xml file, in the package layout and/or on the virtual machine.

Now what would happen if we omitted the Destination metadata from the item group, as in the following example?

.
.
.

MyWebRole

.
.
.

In this example, the content in the AdditionalContent folder will deployed directly to APPROOT, with no corresponding subfolder. This can be very useful when you need to deploy a configuration file to APPROOT. However, note that this can result in name collisions between files deployed by the role project and files deployed through this Role Content Folder mechanism. You will not get any warnings or errors from CSPack (or the Tools) when this happens, so beware!

Role Content Folders can be a great option when you have additional content to deploy to a role of a Windows Azure application, whether used to deploy static content within Visual Studio or used in conjunction with the underlying infrastructure to deploy more dynamic content.

Transform Windows Azure Service Model Files During Packaging

Phil Hoff - MSFT — Mon, 02 Jul 2012 17:47:00 GMT

The latest versions of the Windows Azure Tools for Visual Studio have the ability to maintain multiple versions of the Service Configuration (.cscfg) file. The developer is then prompted to select the version to accompany a deployment, whether it’s going to Windows Azure or the development fabric (i.e. the emulator). However, sometimes a developer needs to do something a little more dynamic, where elements of the Service Configuration file must be generated on-the-fly before deployment.

The Tools generate a Windows Azure package via a process driven by MSBuild. The process already performs certain transformations of the Service Configuration file from the original hosted by the project. These transformations include:

Adding configuration setting values when IntelliTrace or Profiling are enabled during publishing
Adding configuration setting values when Remote Desktop is enabled during publishing
Adding endpoints when WebDeploy is enabled

This transformation process is easily extensible (for certain definitions of “easy”). To do this, some of the MSBuild concepts you will need are:

TargetProfile: This MSBuild property corresponds to the configuration selected for packaging or deployment, e.g. “Local” or “Cloud”.
SourceServiceConfiguration: This MSBuild item group* corresponds to the Service Configuration file hosted by the project that was selected for deployment (based on the value of the TargetProfile property), e.g. ServiceConfiguration.Cloud.cscfg.
TargetServiceConfiguration: This MSBuild item group* corresponds to the actual Service Configuration file that will be deployed. This file begins as a copy of SourceServiceConfiguration but may then be transformed based on the selected publish settings.
TransformServiceModel: This target represents the part of the build and package process that controls transformation of the Service Configuration file. It can be extended by overriding the BeforeTransformServiceModel or AfterTransformServiceModel targets, or by adding new targets to the CoreTransformServiceModelDependsOn MSBuild property.

*Despite being an item group, it only ever contains a single file.

To add a new transformation step, start by updating the project file (.ccproj). Add a new property group that redefines CoreTransformServiceModelDependsOn, adding a new target to the end of the original value. Next, define the new target; it will now get called during the transformation phase of the package process. In the target, open the file represented by the @(TargetServiceConfiguration)item group, modify it as desired, and then save it.

.
.
.



      $(CoreTransformServiceModelDependsOn);
      NewServiceConfigurationTransform;