[RESOLVED] Referencing DLLS in the GAC And Policy files

[FishGuy]

I have a project/app released which references a dll from the GAC folder. The project is looking for version 1.0 of the referenced dll.

I want to release version 2 of the dll without having to re-release the app and have all users re-install.

I had thought if i deployed a policy with the new dll which redirected calls for the dll to the new version this would be ok. However I think I am missing something. IT seems the redirect is not working as when I test on a users machine, give them the version 2 dll and the policy dll but take away the version 1.0 the app fails. It seem calls to the missing dll are not redirected by the policy dll to version 2.

Any advice on what I am missing please?

Policy config which is used to create the policy.1.1.CorpReportsClassLibrary.dll
is as below.

<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="CorpReportsClassLibrary"
                          publicKeyToken="c375aa43badaeae6"
                          />
        <!-- Redirecting to version x of the assembly. -->
        <bindingRedirect oldVersion="1.0.0.0-1.2.0.0"
                         newVersion="1.2.0.0"/>
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

Object reference not set to an instance of an object.

This is the message I get when version 1.0 is missing, at the bottom it appears it does load version 1.2 rather than 1.0 but the app doesnt like using it?

************** Exception Text **************
System.NullReferenceException: Object reference not set to an instance of an object.
at CRSUsageReport.ThisWorkbook.ThisWorkbook_Startup(Object sender, EventArgs e)
at Microsoft.Office.Tools.Excel.Workbook.OnStartup()
at CRSUsageReport.ThisWorkbook.FinishInitialization()
at Microsoft.VisualStudio.Tools.Office.EntryPointComponentBase.Microsoft.VisualStudio.Tools.Application s.Runtime.IEntryPoint.FinishInitialization()
at Microsoft.VisualStudio.Tools.Applications.AddInAdapter.ExecutePhase(ExecutionPhases executionPhases)
at Microsoft.VisualStudio.Tools.Applications.AddInAdapter.CompleteInitialization()
at Microsoft.VisualStudio.Tools.Office.Internal.OfficeAddInAdapter.ExecuteEntryPointsHelper()


************** Loaded Assemblies **************
mscorlib
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000)
CodeBase: file:///C:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll
----------------------------------------
Microsoft.VisualStudio.Tools.Office.Runtime.v9.0
Assembly Version: 9.0.0.0
Win32 Version: 9.0.30729.1
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/Microsoft.VisualStudio.Tools.Office.Runtime.v9.0/9.0.0.0__b03f5f7f11d50a3a/Microsoft.VisualStudio.Tools.Office.Runtime.v9.0.dll
----------------------------------------
CorpReportsClassLibrary
Assembly Version: 1.2.0.0
Win32 Version: 1.2.0.0
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/CorpReportsClassLibrary/1.2.0.0__c375aa43badaeae6/CorpReportsClassLibrary.dll
----------------------------------------

[FishGuy]

The referenced assmbley ships with a policy assembly which is meant to handle the re-direct.

The main app which is looking for the assembly doesnt like the version it returned by the policy it seems.

I am going to alter the app.config of the main app by inserting the code below to see if it makes a difference.

<runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">

      <publisherPolicy apply="yes"/>
      </assemblyBinding>

I have seen a similar example where the redirection is as above but the redirection is applied in the app config, this is no good to me though as i need to update the reference without altering the app.config.

[FishGuy]

OK that seemed to work now on test machine one.

I now have a problem when trying to inststall the assemblies via msi on test machine 2.

Error writing to file publisherpolicy.config verify that you have access to that directory.

[FishGuy]

that was just a permissions error on the local pc.

problem now fixed.