Error occurred while loading attribute 'FaultContractAttribute' on method 'Get' in type 'Resource'.

[Bluecakes]

Hello,

I am getting the following error whenever i try to create an instance of the ResourceManagementClient object:

Link to Error Image

Steps i followed:

1. Create a new console project in Visual Studio
2. Add reference to Microsoft.ResourceManagement
3. Type "Install-Package Lithnet.ResourceManagement.Client" into the Package Management Console (Installed perfectly by the way)
4. Add "var client = new ResourceManagementClient("http://fimtestlab:5725");"
5. Debug project

Additional notes:

• Error occurs even when i provide an invalid FIM hostname
• Error also occurs if i put the FIM hostname in my app.config and call ResourceManagementClient with no arguments

Full app.config (In case i put the line in the wrong spot)

`<?xml version="1.0" encoding="utf-8"?>

`

[ryannewington]

Hi,

The library requires Microsoft.ResourceManagement.dll version 4.1.3451 or higher.

The FIM Service itself can be running an older version, but the library can only bind to that version of the DLL or higher.

[Bluecakes]

Hey Ryan,

Thanks for your reply, i downloaded the MIM 2016 Installer and copied Microsoft.ResourceManagement.dll from the ISO (Version 4.3.0.0) and replace the DLL in my project with it.

Using the same or a new project i am still not able to instantiate a ResourceManagementClient, by looking at the Exception and expanding Inner Exception it says "Could not load file or assembly 'Microsoft.ResourceManagement, Version=4.1.3653.0, Culture=neutral'".

Link to image with hopefully enough information

Is there a way i can get Visual Studio to use the referenced DLL or do i have to find version 4.1.3653.0 of the DLL?

[ryannewington]

Hi,

You definitely don't need that specific version. VS usually adds a binding redirect to the app.config file, but in this case, it doesn't seem to be there.

<runtime> 
     <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> 
       <dependentAssembly> 
         <assemblyIdentity name="Microsoft.ResourceManagement" publicKeyToken="31bf3856ad364e35" culture="neutral"/> 
         <bindingRedirect oldVersion="0.0.0.0-4.1.3653.0" newVersion="4.1.3653.0"/> 
       </dependentAssembly> 
     </assemblyBinding 
</runtime>

Change the 'newVersion' to the exact version of the DLL you are using. v4.3.0.0 seems a bit odd. It's usually something like 4.3.2195.

[Bluecakes]

The version number when i rightclick -> Properties -> Details in Windows Explorer is 4.3.1935.0 but the version shows as 4.3.0.0 in Visual Studio. Whether i put 4.3.0.0 or 4.3.1935.0 in newVersio ii'm still receiving an error.

I noticed the Getting Started example was for a Console Application so i create a brand new Console Application project in Visual Studio and installed the package, it has the exact same app.config and i was able to query an object in FIM.

It seems strange to me that the only difference between the project that works (Console Application) and the project that doesn't (Class Library) is the type of project.

  <?xml version="1.0" encoding="utf-8"?>
  <configuration>
    <configSections>
      <section name="lithnetResourceManagementClient" type="Lithnet.ResourceManagement.Client.ClientConfigurationSection, Lithnet.ResourceManagement.Client" />
    </configSections>
    <lithnetResourceManagementClient resourceManagementServiceBaseAddress="http://fimtestlab:5725" />
    <runtime>
      <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
        <dependentAssembly>
          <assemblyIdentity name="Microsoft.ResourceManagement" publicKeyToken="31bf3856ad364e35" culture="neutral" />
          <bindingRedirect oldVersion="0.0.0.0-4.3.0.0" newVersion="4.3.0.0" />
        </dependentAssembly>
      </assemblyBinding>
    </runtime>
  </configuration>

[ryannewington]

Re: the version number, definitely use 4.3.1935.0.

Class libraries don't use an app.config file - they inherit their settings from the EXE that hosts them. So the app.config of the process that is hosting your class library needs to have the binding redirects added to it. (note: you can add an app.config to a class library project, but it does nothing)

[Bluecakes]

Hey Ryan,

Thanks so much for your assistance with my troubles.

I did not know that Class Libraries don't use the app.config file, i assumed they did because Visual Studio automatically generated the file for me when i installed the Lithnet package. With the new information i was able to research more specifically and find an answer to my specific situation.

Link to StackOverflow Question that helped me out

I was originally creating PowerShell commands in my Class Library so i can attempt to automate many of the tasks me and my colleagues encounter at my workplace.

I was able to solve my dilemma by creating a powershell.exe.config file containing the following text in C:\Windows\system32\WindowsPowerShell\v1.0\powershell.exe.Config :

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="Microsoft.ResourceManagement" publicKeyToken="31bf3856ad364e35" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.3.0.0" newVersion="4.3.0.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

After creating the powershell.exe.config file, i was able to import my class library into PowerShell and it worked instantly.

My only concern now is that if i successfully create cmdlets that i want to pass to my colleagues, they might have to create this config as well (Small price to pay for awesome cmdlets).

Thanks also for releasing this awesome library, it'll be a big help to my automation and i'm sure i could learn a lot from the source code.

[ryannewington]

Check out https://github.com/Fody/Costura. It allows you to embed the reference into your DLL and have it load dynamically at runtime. No need for binding redirects. It saves having to worry about setting .config files for 32bit, 64bit and as well as the powershell ISE on every PC that its used on.

Alternatively

1. Specify a script in your powershell module definition (psd1) that will load a resolver that will find and load the file. The AssemblyResolve event overrides the version that the framework is looking for
2. Use fody module init. This is similar to the above, but adds a module initializer to your DLL where you can handle the AssemblyResolve event. Module initializers are loaded before any other code in your DLL.

[Bluecakes]

Oh. My. God. That is a seriously cool package and i didn't even need to configure it, i just added the package and built my project. I removed the PowerShell.exe.config and my project is now using the internal 4.3.1935.0 version of the DLL.

Thank you very much for your patience and wisdom, i've got some scripting to do!

[ryannewington]

Glad its working! Happy scripting!