"phcmi" <phcmi@nospam.nospam> wrote in message
news:%235crd8$EIHA.4772@TK2MSFTNGP02.phx.gbl...
> I've recently inherited a nightmare of a project. My predecessor created
> 18 assemblies where only 2 were necessary. These assemblies provide common
> implementations for our 7 and growing applications, so he decided that the
> deployment strategy is that each application will place all 18 into the
> GAC. Since we do not deploy our applications as a suite, it is possible
> for each application to prompt new features in these 18 common assemblies
> and it may be months between application RTMs, this deployment strategy is
> severely flawed. I've taken care of almost all of the deployment
> nightmare, automated builds and other issues where these 18 assemblies are
> concerned but there's one major pain that I haven't been able to solve
> yet.
>
> Each application contains an app.config file where a <configuration>
> section is defined for all 16 of the 18 assemblies ( because of
> dependencies between 2 of the assemblies). Each entry in the section
> outlines the assemblyname, version, key, etc.
>
> Here's the nightmare, when an AssemblyVersion increment in any of these
> assemblies occurs, each application's app.config file must also be updated
> with the correct version information.
>
> Is there some way to load an assembly from the GAC in a
> version-independent way as is possible in COM? My strategy to solve the
> versioning issue is to remove any versioning data in the applications'
> app.config file, then load the latest or highest version of each of these
> assemblies at application runtime. Is this possible? If so, can you
> outline or provide a sample that outlines how to accomplish this?
>
>
>
>

"Phil Wilson" <pdjwilson@nospam.cox.net> wrote in message
news:OzBy55nFIHA.280@TK2MSFTNGP03.phx.gbl...
> Is this a case where each app should just install its own copy of a shared
> assembly into each application's folder instead of the GAC? I'm wondering
> if this is one of those cases where the GAC is a dumping ground for every
> shared assembly in a similar way that the System folder used to be for
> Win32 shared Dlls.
> --
> Phil Wilson
> [Microsoft MVP-Windows Installer]
>
> "phcmi" <phcmi@nospam.nospam> wrote in message
> news:%235crd8$EIHA.4772@TK2MSFTNGP02.phx.gbl...
>> I've recently inherited a nightmare of a project. My predecessor created
>> 18 assemblies where only 2 were necessary. These assemblies provide
>> common implementations for our 7 and growing applications, so he decided
>> that the deployment strategy is that each application will place all 18
>> into the GAC. Since we do not deploy our applications as a suite, it is
>> possible for each application to prompt new features in these 18 common
>> assemblies and it may be months between application RTMs, this deployment
>> strategy is severely flawed. I've taken care of almost all of the
>> deployment nightmare, automated builds and other issues where these 18
>> assemblies are concerned but there's one major pain that I haven't been
>> able to solve yet.
>>
>> Each application contains an app.config file where a <configuration>
>> section is defined for all 16 of the 18 assemblies ( because of
>> dependencies between 2 of the assemblies). Each entry in the section
>> outlines the assemblyname, version, key, etc.
>>
>> Here's the nightmare, when an AssemblyVersion increment in any of these
>> assemblies occurs, each application's app.config file must also be
>> updated with the correct version information.
>>
>> Is there some way to load an assembly from the GAC in a
>> version-independent way as is possible in COM? My strategy to solve the
>> versioning issue is to remove any versioning data in the applications'
>> app.config file, then load the latest or highest version of each of these
>> assemblies at application runtime. Is this possible? If so, can you
>> outline or provide a sample that outlines how to accomplish this?
>>
>>
>>
>>
>
>