About the author

Something about the author

Tag cloud

    AG_E_NETWORK_ERROR

    This is a terribly annoying and uninformative error which occurs sometimes while developing Silverlight applications. At its core, the error seems to happen any time the Silverlight client is unable to retrieve content and/or not understand the content which it has retrieved. I guess one could argue that it is a network-related error (not being able to get data off the wire, or getting data which may be corrupted); but the error code to me just seems highly generic and, well, in great need of rework.

    …when searching the internet, you’ll come across many different problems causing this error. In my particular scenario, however, the problem was the result of missing security policy files which SL requires in order to initiate network activity (even in the event the destination host is LOCALHOST).

    In order to resolve the issue, I simply created a clientaccesspolicy.xml file at the root of the website (wwwroot, in my instance) with the following content:

    <?xml version="1.0" encoding="utf-8"?>
    <access-policy>
        <cross-domain-access>
            <policy>
                <allow-from http-request-headers="*">
                    <domain uri="*"/>
                </allow-from>
                <grant-to>
                    <resource path="/" include-subpaths="true"/>
                </grant-to>
            </policy>
        </cross-domain-access>
    </access-policy>

     

    I stumbled across the fact the security file was missing by way of Fiddler2; and then found out what generic content to add to the policy file here.


    Permalink | Comments (55) | Post RSSRSS comment feed

    DLR from the ground up

    Either I’m incapable of finding a nice “from 0 – 60” tutorial on getting up and going with the DLR, or one doesn’t exist. Until now. This short post will run you through getting the DLR, building it, and then using it to automate a static C# .NET application (the application is useless, it’s the act of going through the steps that’s meaningful).

    The DLR is not part of the .NET 4 release, so you’ll need to download it and build it separately; luckily, that’s very easy to do. Simply go to

    http://dlr.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=34834

    And download it. Once downloaded, open it up in VS2010 and build it. The binaries you’ll need will be located in a Bin/40 folder at the root of the solution.

    Now create a new .NET C# application in VS2010, call it whatever you like. Once made, copy the following binaries to your project folder from Bin/40:

    image

    Now reference those from your new solution. To verify everything is bound correctly, add the following code (once you resolve the proper namespace, you shouldn’t get any “red squigglies”):

       1:  private static ScriptRuntime _runtime = ScriptRuntime.CreateFromConfiguration();
     
     

    So far, so good. You now have the DLR and Python runtime libraries loaded in your project; you’re now ready to use them.

    The purpose of the code which you just added is to bootstrap the scripting runtime’s configuration; and it’s doing so by reading from your application configuration settings.  Thus far, however, you haven’t created any configuration settings – so let’s do that now. Add a new App.Config file and add the following:


       1:  <?xml version="1.0" encoding="utf-8" ?>
       2:  <configuration>
       3:    <configSections>
       4:      <section name="microsoft.scripting" type="Microsoft.Scripting.Hosting.Configuration.Section, 
       5:  Microsoft.Scripting, Version=0.9.6.20, Culture=neutral" requirePermission="false" />
       6:    </configSections>
       7:    <microsoft.scripting>
       8:      <languages>
       9:        <language names="IronPython;Python;py"
      10:                  extensions=".py"
      11:                  displayName="IronPython 2.6"
      12:                  type="IronPython.Runtime.PythonContext, IronPython, Version=2.6.10920.0, 
      13:  Culture=neutral" />
      14:      </languages>
      15:      </microsoft.scripting>
      16:  </configuration>

    In order for scripting languages to interact with your application you’ll need to expose a palette of CLR objects with which it may interact; you do this by creating a ScriptScope and adding CLR objects to it – the ScriptScope acting as the bridge between the two worlds. So let’s do that now. Create a private ScriptScope object as a member variable of your Program class and instantiate it like this:

       1:          private static ScriptScope _scope = null; 
       2:          static void Main(string[] args)
       3:          {
       4:              _scope = _runtime.CreateScope(); 
       5:              return; 
       6:          }

    Now would be a good time to F5 and verify everything builds and runs correctly.

    The next thing to do is to create a class which your scripts may interact against, and you do this by simple creating a POCO:

       1:      public class MyTest
       2:      {
       3:          public string A = "Hello World"; 
       4:      }

    …and adding it to the scripting scope using SetVariable:

       1:          static void Main(string[] args)
       2:          {
       3:              _scope = _runtime.CreateScope();
       4:              MyTest test = new MyTest(); 
       5:              _scope.SetVariable("MyTest", test); 
       6:              return; 
       7:          }

    The last thing to do is to invoke the scripting engine with some IronPython against the object (the IronPython is passed as a string to the Execute() method, so you can imagine loading it from file, from an interactive console, etc.):

       1:          static void Main(string[] args)
       2:          {
       3:              _scope = _runtime.CreateScope();
       4:              MyTest test = new MyTest();
       5:              _scope.SetVariable("MyTest", test);
       6:   
       7:              ScriptEngine engine = _runtime.GetEngine("IronPython").Execute(
       8:                  "MyTest.A = \"Hello Scripting World\"", _scope);
       9:   
      10:              Console.WriteLine(test.A);
      11:              Console.ReadLine(); 
      12:              return; 
      13:          }
     

    The result should be “Hello Scripting World”. There you have it – you now interacted with your program from Python.

    Next I’ll go the other way; I’ll execute a method defined in Python from C#.


    Permalink | Comments (241) | Post RSSRSS comment feed

    VS 2010 Referencing .NET 3.5

    Another annoying error this evening:

    “Cannot define a class or member that utilizes 'dynamic' because the compiler required type 'System.Runtime.CompilerServices.DynamicAttribute' cannot be found. Are you missing a reference to System.Core.dll?”

    This happened when trying to use the dynamic keyword from Visual Studio when the target framework was pointed to 3.5. Just change the target framework to 4.0 and everything will work as expected.

    Now – the more important question: why did this happen?

    Well – I had created a project for doing some development against Windows Azure; and Windows Azure only accepts projects targeting the .NET framework version 3.5 (so the project wizards created a project with such a dependency).


    Permalink | Comments (116) | Post RSSRSS comment feed

    Strange error

    I got the following error today: ‘ConfigurationSettingSubscriber needs to be set before FromConfigurationSetting can be used”

    I don’t claim to understand the physics behind this error, but it’s really kind of stupid.

    It seems you may be get this error when developing with the Azure SDK (yes, even the November CTP); more specifically when dealing with the retrieval of configuration settings:

    image

    How do you fix it?

    Go to the ASP.NET application project for the web role, open up the role entry point class (the class file holding the WebRole class for this project), and insert the following into the OnStart() method body:

       1:  CloudStorageAccount.SetConfigurationSettingPublisher((configName, configSetter) => 
       2:  { 
       3:      configSetter(RoleEnvironment.GetConfigurationSettingValue(configName)); 
       4:      RoleEnvironment.Changed += (sender, arg) => 
       5:      { 
       6:          if (arg.Changes.OfType<RoleEnvironmentConfigurationSettingChange>() 
       7:              .Any((change) => (change.ConfigurationSettingName == configName))) 
       8:          { 
       9:              if (!configSetter(RoleEnvironment.GetConfigurationSettingValue(configName))) 
      10:              { 
      11:                  RoleEnvironment.RequestRecycle(); 
      12:              } 
      13:          } 
      14:      }; 
      15:  });

    All should be well with the world. Don’t ask.


    Permalink | Comments (159) | Post RSSRSS comment feed

    Cloud Storage Studio

    Microsoft really should develop a nice user interface for developers to interact with their cloud storage on Azure. I’ve got to believe that something is in the works, somewhere.

    Until then, however, there are a number of nice 3rd party applications which can give a developer a way to go spelunking through their Azure storage. Take Cloud Storage Studio produced by Cerebrata; currently it’s free (though it’s in Beta) but pretty darn good. It even has support for connecting to your local development storage (useful for testing).

    Upon opening the application, you’ll be presented by a splash screen of sorts:

    image 

    Just hit cancel.

    Instead, click on the “Connect to…” listbox on the top-left corner of the application:

    image

    Select “Development Storage”.

    Give the application a while to connect to your local development storage; once there, you should be able to visually inspect what you’re doing as you play with your local development tools for Windows Azure.


    Permalink | Comments (145) | Post RSSRSS comment feed