locked
Plugin error: The remote name could not be resolved: 'http' RRS feed

  • Question

  • I’m working on the result of a 3.0 upgrade to 4.0.

    We’ve registered a very simple plugin on pre-create. The crmService object is retrieved from the plugin context. But on Execute we get an error "The remote name could not be resolved: 'http'"

    The block of code causing issue below:

    // Use the Account Entity in the SDK Type Proxy
    // No custom entities/attributes are used here
    account account = new account();
    account.accountid = new Key(accountId);
    account.accountnumber = accountnumber;
    TargetUpdateAccount target = new TargetUpdateAccount();
    target.Account = account;
    UpdateRequest request = new UpdateRequest();
    request.Target = target;
    // Create an ICrmService from the Context
    ICrmService service = context.CreateCrmService(true);
    // Execute the Update Request
    service.Execute(request);

    On calling “service.Execute(request)” an error invokes:

    System.Net.WebException was caught
      Message="The remote name could not be resolved: 'http'"
      Source="Microsoft.Crm.ObjectModel"
      StackTrace:
           at Microsoft.Crm.Extensibility.SdkTypeProxyCrmServiceWrapper.InternalInvoke(MethodInfo methodInfo, Object[] parameters)
           at Microsoft.Crm.Extensibility.SdkTypeProxyCrmServiceWrapper.Execute(Object request)
           at Diisr.Crm.Tardis.Plugins.AccountNumber.Plugin.Execute(IPluginExecutionContext context) in C:\WorkSpace\AccountNumber\AccountNumber\Plugin.cs:line 74
      InnerException:

    I’ve already checked the registry settings for the SDK and the configuration settings table in the config database are correct. It may also be worth noting that this network is highly secure with many restrictions and cross AD authentication and we can only access the server by its fully qualified name.

    Any ideas?

    Thanks.

     

    Monday, June 28, 2010 12:19 AM

Answers

  • This looks a little odd, it might be the problem of the upgrade or something that you inherited from previous version. 

    One thing I would do is to inspect HKLM\Software\Microsoft\MSCRM registry, you might want to pay extra attention to the entry of ServerUrl, it should be something in the following format. 

    http://crmservername/MSCRMServices


    Daniel Cai | http://danielcai.blogspot.com
    • Proposed as answer by DavidBerryMVP, Moderator Tuesday, June 29, 2010 5:12 PM
    • Unproposed as answer by SiN_1 Wednesday, June 30, 2010 5:06 AM
    • Marked as answer by SiN_1 Sunday, July 11, 2010 7:58 AM
    Tuesday, June 29, 2010 12:29 PM

All replies

  • This looks a little odd, it might be the problem of the upgrade or something that you inherited from previous version. 

    One thing I would do is to inspect HKLM\Software\Microsoft\MSCRM registry, you might want to pay extra attention to the entry of ServerUrl, it should be something in the following format. 

    http://crmservername/MSCRMServices


    Daniel Cai | http://danielcai.blogspot.com
    • Proposed as answer by DavidBerryMVP, Moderator Tuesday, June 29, 2010 5:12 PM
    • Unproposed as answer by SiN_1 Wednesday, June 30, 2010 5:06 AM
    • Marked as answer by SiN_1 Sunday, July 11, 2010 7:58 AM
    Tuesday, June 29, 2010 12:29 PM
  • Thanks Daniel,

    I've checked this and the setting is correct. Infact to get arount the issue I'm constructing the service address using this very registry setting.

    I've also used the CRM Configuration Tool to set the SDK addresses and double checked the database. All these values are fine.

    I feel that the address its self may not be the issue, but some security restriction in retrieving or passing the value. Any other ideas?

     

    Thanks,

    Kiavash

    Wednesday, June 30, 2010 1:16 AM
  • It may not be an actual solution, but I would try to import the database to a fresh CRM installation, and then see if the problem persists after you have registered your plug-in. 


    Daniel Cai | http://danielcai.blogspot.com
    Wednesday, June 30, 2010 1:57 AM
  • Thanks for the tip. I did try that and it turns out to be an issue with the environment. The imported DB on our Dev server works fine with this code.
    Tuesday, July 6, 2010 11:48 PM
  • That's what I sensed in the first place. Glad to know it worked. 

    Cheers,


    Daniel Cai | http://danielcai.blogspot.com
    Wednesday, July 7, 2010 12:32 AM
  • But its still not solved. We've assertained that the issue is with the environment and not the Org database. But still cant get if working on our target server.
    Wednesday, July 7, 2010 5:33 AM
  • Cheers Daniel,

    Turns out the ServerUrl registry setting was the issue. Though the problem was quire subtle.

    The value on our server contained "http://". So rather than storing "crmserver.com", it was http://crmserver.com. I still have no idea why this was wrong, but all is fine now.

    Thanks for you help.

    Sunday, July 11, 2010 8:06 AM