pdxfilter-google@yahoo.com wrote:
>Here's a fun one:
>
>Our Windows Forms application uses the Crystal Reports .NET assemblies,
>which we ship and reference privately from our application folder.
>These assemblies have strong names. Works great - most of the time.
>
>Other vendors of Crystal applications will often register these DLLs in
>the GAC, which should be fine. The problem is that Crystal Decisions
>sometimes does not change the assembly version when releasing DLL
>updates. So, what happens is our application loads, binds to a
>particular DLL version, the CLR loader finds this exact version in the
>GAC and loads from the GAC instead of our app folder. This is
>problematic as the "sub-versions" are not compatible with each other
>and our app crashes.
>
>This is new in the 2.0 framework. Under 1.1, our app would always load
>the private assembly.
>
>Our question: How do we force the CLR loader to ignore the GAC and
>always load these assemblies from the app folder? I've experimented
>with many config file combinations - to no avail. Also ran
>FUSLOGVW.exe, which happily announced that the assembly was found in
>the GAC - no need to look further.
>
>Crystal Decisions was no help.
>
>Ideas on this? Something I might be missing? Thanks!
>
>Jon

pdxfilter-google@yahoo.com wrote:
>SMC,
>
>Thanks for the reply. We've tried Assembly.Load(). Here's what
>happens:
>
>1. Runtime finds the DLL in our private folder.
>2. Runtime extracts strong name info from said DLL
>3. Runtime binds to DLL in the GAC with the same strong name, ignoring
>the private DLL.
>
>This is great if the private DLL and the GAC DLL are the same. In the
>case of Crystal Reports, they're not, even though they have the same
>assembly version.
>
>We're still looking for a workaround, hack or not...
>
>Thanks again!
>
>Jon

<pdxfilter-google@yahoo.com> wrote in message
news:1147136026.467687.135450@j33g2000cwa.googlegroups.com...
> Here's a fun one:
>
> Our Windows Forms application uses the Crystal Reports .NET assemblies,
> which we ship and reference privately from our application folder.
> These assemblies have strong names. Works great - most of the time.
>
> Other vendors of Crystal applications will often register these DLLs in
> the GAC, which should be fine. The problem is that Crystal Decisions
> sometimes does not change the assembly version when releasing DLL
> updates. So, what happens is our application loads, binds to a
> particular DLL version, the CLR loader finds this exact version in the
> GAC and loads from the GAC instead of our app folder. This is
> problematic as the "sub-versions" are not compatible with each other
> and our app crashes.
>
> This is new in the 2.0 framework. Under 1.1, our app would always load
> the private assembly.
>
> Our question: How do we force the CLR loader to ignore the GAC and
> always load these assemblies from the app folder? I've experimented
> with many config file combinations - to no avail. Also ran
> FUSLOGVW.exe, which happily announced that the assembly was found in
> the GAC - no need to look further.
>
> Crystal Decisions was no help.
>
> Ideas on this? Something I might be missing? Thanks!
>
> Jon
>