Visual Studio GenerateResource Error Building on Windows 10

Visual Studio GenerateResource Error Building on Windows 10

A couple of weeks ago when I installed Windows 10 on my primary machine I ran into an issue where Windows Phone/Windows/Universal applications stopped building due to a rather cryptic error relating to trusted network resources…. which was bizarre since the projects were all local on my machine. This is the same error reported on the Windows Dev Center – https://social.msdn.microsoft.com/Forums/windowsapps/en-US/82fea1c9-ae5a-4595-a2c1-46efb853303b/error-2-generateresource?forum=wpdevelop.

The good news is that there’s a relatively simple fix as indicated in the error message ”please enable the loadFromRemoteSources switch. Of course this shouldn’t need to be applied but that’s the danger of running on the edge with a pre-release product. What’s not obvious is where the switch should be applied – if you follow the link to MSDN it seems to indicate that the switch needs to be added to Devenv.exe.config, which does nothing to fix the issue. Turns out you need to add it to the MSBuild configuration file (eg C:Program Files (x86)MSBuild12.0Bin MSBuild.exe.config).

<?xml version =”1.0″?>
<configuration>
    <configSections>
        <section name=”msbuildToolsets” type=”Microsoft.Build.BuildEngine.ToolsetConfigurationSection, Microsoft.Build.Engine, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a” />
    </configSections>
    <startup useLegacyV2RuntimeActivationPolicy=”true”>
        <supportedRuntime version=”v4.0″ sku=”.NETFramework,Version=v4.5.1″/>
    </startup>
    <runtime>
    <loadFromRemoteSources enabled=”true”/>
    ….

Demo rule #1 practice again and again and again, particularly the night before….

Demo rule #1 practice again and again and again, particularly the night before….

Tomorrow is round 2 of TechEd Australia and after my demos all seemed to go well in Melbourne I figured I was all set. However as I usually do I wanted to double check that everything was going to work (particularly since I’m running the Windows 10 preview build). Anyhow, it’s a good thing I did because the wonderful Azure team have changed the syntax of one of the manifest files I have to manually edit mid-way through my first session. The step I walk through is actually taken from a post over on Azure Mobile Services site (http://azure.microsoft.com/en-us/documentation/articles/mobile-services-windows-store-dotnet-adal-sso-authentication/) and includes this change:

image

Well, no more – if you try to do this you’ll find that the appPermissions node doesn’t exist in the manifest file. Luckily I have a working mobile service with this change already applied, so I figured if I download the manifest file I should be able to see what’s changed. It turns out that the syntax has changed and that instead of replacing the appPermissions node, you now have to replace the oauth2Permissions node ie change:

“oauth2Permissions”: [],

to

“oauth2Permissions”: [
    {
      “adminConsentDescription”: “Allow the application access to the mobile service”,
      “adminConsentDisplayName”: “Have full access to the mobile service”,
      “id”: “b69ee3c9-c40d-4f2a-ac80-961cd1534e40”,
      “isEnabled”: true,
      “origin”: “Application”,
      “type”: “User”,
      “userConsentDescription”: “Allow the application full access to the mobile service on your behalf”,
      “userConsentDisplayName”: “Have full access to the mobile service”,
      “value”: “user_impersonation”
    }
  ],

The upshot of this is that had I just assumed that my demos would all just work tomorrow I would have been fighting this fire on stage (argh). Moral of the story is practice, practice and practice some more – you never know when the demo gods will strike, and it’s best to be prepared when they do.