none
ADVANCED: Custom Behavior type loaded in PowerShell but still throws Can't load type when client is used RRS feed

  • Question

  • I have spent a bit of time and have successfully gotten a WCF client app written in powershell using .NET assemblies borrowed from my larger .NET enterprise app. All the data is ready to go. I understand loading of .NET assemblies, Reflection.Assembly.LoadFrom contexts, etc. My types are all loaded, including my extensions that I have listed in my configuration.

    I load the extension dll like this:

    add-type -path "$binDir\WCFExtensions.MessageCompressor.dll"

    I can even new-object the behavior extension:

    $compressor = new-object WCFExtensions.MessageCompressor.MessageCompressionElement;

    But when I call the service itself, I get this exception:

    Error while submitting claimset to service:
    Exception calling ".ctor" with "0" argument(s): "The type 'WCFExtensions.MessageCompressor.MessageCompressionElement, WCFExtensions.MessageCompressor' registered for extension 'CompressBehaviorExtension' could not be loaded. (C:\WINDOWS\system32\WindowsPowerShell\v1.0\powershell.exe.Config line 122)"

    My configuration is in the right powershell.exe.config, and it works when run in a regular .NET context:

       <extensions>
          <behaviorExtensions>
    		<add name="CompressBehaviorExtension" type="WCFExtensions.MessageCompressor.MessageCompressionElement, WCFExtensions.MessageCompressor" />
          </behaviorExtensions>
        </extensions>
    

    The type matches what I have in the DLL code, the DLL Name matches precisely what's listed in the second type param. I also doublechecked all the dependencies (per RedGate Reflector) and all of these are loaded too.

    Why did WCF change context? How did powershell suddenly lose access to this type?

    I thought powershell would be quicker and more deliverable for a one-off utility than a .NET console app, but I'm about ready to fold and go .NET.  I'm SO CLOSE to getting this working, any ideas would be much appreciated.

    Sunday, March 16, 2014 10:48 PM

All replies

  • Hi,

    Please change your type definition. First is full type name (interface+class name). After coma you place name of dll holding your type. And than the rest. Like this:

    <behaviorExtensions>
        <add name="customHeaders" type="InMotionGIT_NT.Address.Service.CustomHeaders, <DLLName> , Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
    </behaviorExtensions>

    Best Regards,
    Amy Peng


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Monday, March 17, 2014 7:30 AM
    Moderator
  • Thanks for your quick response, Amy!

    The the exception of the version/culture/publicKeyToken portion, I have it set up as you note.  I also tried it with the full identifier earlier and it still did not work.

    But just to leave no stone unturned, I copied and pasted the last part of your specification into my config file and still, the same exception is raised.

    Here's the full stack trace for your enjoyment:

    System.Configuration.ConfigurationErrorsException: The type 'WCFExtensions.MessageCompressor.MessageCompressionElement,

    WCFExtensions.MessageCompressor, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' registered for

    extension 'CompressBehaviorExtension' could not be loaded. (C:\WINDOWS\system32\WindowsPowerShell\v1.0\powershell.exe.Config line 122) at System.Configuration.BaseConfigurationRecord.EvaluateOne(String[] keys, SectionInput input, Boolean isTrusted, Fac toryRecord factoryRecord, SectionRecord sectionRecord, Object parentResult) at System.Configuration.BaseConfigurationRecord.Evaluate(FactoryRecord factoryRecord, SectionRecord sectionRecord, Ob ject parentResult, Boolean getLkg, Boolean getRuntimeObject, Object& result, Object& resultRuntimeObject) at System.Configuration.BaseConfigurationRecord.GetSectionRecursive(String configKey, Boolean getLkg, Boolean checkPe rmission, Boolean getRuntimeObject, Boolean requestIsHere, Object& result, Object& resultRuntimeObject) at System.Configuration.BaseConfigurationRecord.GetSectionRecursive(String configKey, Boolean getLkg, Boolean checkPe rmission, Boolean getRuntimeObject, Boolean requestIsHere, Object& result, Object& resultRuntimeObject) at System.Configuration.BaseConfigurationRecord.GetSectionRecursive(String configKey, Boolean getLkg, Boolean checkPe rmission, Boolean getRuntimeObject, Boolean requestIsHere, Object& result, Object& resultRuntimeObject) at System.Configuration.BaseConfigurationRecord.GetSection(String configKey) at System.Configuration.ConfigurationManager.GetSection(String sectionName) at System.ServiceModel.Activation.AspNetEnvironment.UnsafeGetSectionFromConfigurationManager(String sectionPath) at System.ServiceModel.Configuration.ConfigurationHelpers.UnsafeGetAssociatedSection(ContextInformation evalContext, String sectionPath) at System.ServiceModel.Description.ConfigLoader.LookupChannel(ContextInformation configurationContext, String configu rationName, ContractDescription contract, EndpointAddress address, Boolean wildcard, Boolean useChannelElementKind, Serv iceEndpoint& serviceEndpoint) at System.ServiceModel.ChannelFactory.InitializeEndpoint(String configurationName, EndpointAddress address) at System.ServiceModel.ChannelFactory`1..ctor(String endpointConfigurationName, EndpointAddress remoteAddress) at System.ServiceModel.EndpointTrait`1.CreateSimplexFactory() at System.ServiceModel.ClientBase`1.CreateChannelFactoryRef(EndpointTrait`1 endpointTrait) at System.ServiceModel.ClientBase`1.InitializeChannelFactoryRef()


    I'd also note that the line number in the configuration makes no sense to me.  Even if I walk back 122 lines from the actual extension declaration (noted in first post), it lands on a line that is not the start of a major section, or anywhere near it.


    • Edited by jesse1008 Saturday, April 19, 2014 8:03 PM
    Monday, March 17, 2014 6:00 PM
  • So I take it this is one of those defects that probably won't ever get addressed because hardly anyone tries to use PowerShell to talk to a service?  it's taking a good deal longer to do this in C#. :(
    Thursday, March 27, 2014 1:24 AM