Using an updated or newer assembly?

microsoft.public.dotnet.security

13 Jun 2005 9:17 PM

Jeff

We have a C# Winform application that depends on three or four assemblies.
In one of the assemblies, we changed one line of 'hard coded' data to some
other data. Nothing else was changed just something like:

string temp = "fred";
to:
string temp = "george";

We re-compiled the assembly/dll and copied it over the old dll of the same
name.

The exe will not use the newly compiled dll. The error is something to do
with the access level on classes within the dll. But nothing was changed
other than data. We tried to use the "binding redirections" to allow
substitution of our version for the one the original .exe was looking for.

Is this the new "dll hell"?

Regards,

Jeff

13 Jun 2005 10:27 PM

Claus Konrad

If you are using strongnamed assemblies, you can not use a new assembly with
your winform app. without recompiling this winapp.

Alternatively you should use a policyfile to indicate to the winapp that it
should be using a newer version of the dll in question.

/CK

Show quoteHide quote

"Jeff" <J***@discussions.microsoft.com> wrote in message
news:D12D84E0-A796-4048-9EA9-58369B40B4B4@microsoft.com...
> We have a C# Winform application that depends on three or four assemblies.
> In one of the assemblies, we changed one line of 'hard coded' data to some
> other data. Nothing else was changed just something like:
>
> string temp = "fred";
> to:
> string temp = "george";
>
> We re-compiled the assembly/dll and copied it over the old dll of the same
> name.
>
> The exe will not use the newly compiled dll. The error is something to do
> with the access level on classes within the dll. But nothing was changed
> other than data. We tried to use the "binding redirections" to allow
> substitution of our version for the one the original .exe was looking for.
>
> Is this the new "dll hell"?
>
> Regards,
>
> Jeff

13 Jun 2005 11:08 PM

Jeff

Strong names are not used. This is what is on MSDN:
Redirecting Assembly Versions
When you build a .NET Framework application against a specific version of a
strong-named assembly, the application uses that version of the assembly at
run time. However, sometimes you might want the application to run against a
newer version of an assembly. An application configuration file, machine
configuration file, or a publisher policy file can redirect one version of an
assembly to another. For details on how the common language runtime uses
these files to determine which assembly version to use, see How the Runtime
Locates Assemblies. You can use the .NET Framework Configuration tool
(Mscorcfg.msc) to redirect assembly versions at both the application level
and the machine level, or you can directly edit the configuration file.

Note You cannot redirect versions for assemblies that are not
strong-named. The common language runtime ignores the version for assemblies
that are not strong-named.

The "Note" seems to imply if it is not strong named, you cannot do any of
the techniques, ie: it can't be done!?

Regards,

Jeff

Show quoteHide quote

"Claus Konrad" wrote:

> If you are using strongnamed assemblies, you can not use a new assembly with
> your winform app. without recompiling this winapp.
>
> Alternatively you should use a policyfile to indicate to the winapp that it
> should be using a newer version of the dll in question.
>
> /CK
>
>
>
> "Jeff" <J***@discussions.microsoft.com> wrote in message
> news:D12D84E0-A796-4048-9EA9-58369B40B4B4@microsoft.com...
> > We have a C# Winform application that depends on three or four assemblies.
> > In one of the assemblies, we changed one line of 'hard coded' data to some
> > other data. Nothing else was changed just something like:
> >
> > string temp = "fred";
> > to:
> > string temp = "george";
> >
> > We re-compiled the assembly/dll and copied it over the old dll of the same
> > name.
> >
> > The exe will not use the newly compiled dll. The error is something to do
> > with the access level on classes within the dll. But nothing was changed
> > other than data. We tried to use the "binding redirections" to allow
> > substitution of our version for the one the original .exe was looking for.
> >
> > Is this the new "dll hell"?
> >
> > Regards,
> >
> > Jeff
>
>
>

13 Jun 2005 11:24 PM

Claus Konrad

if you are NOT using strongnamed assemblies, the this is not your problem.
You winapp will use any assembly as it is only referencing a partly
quialified name. Use Ildasm.exe to investigate your manifest of your winapp
to see what it actually expects of evidence from the 4 assemblies...

/CK

Show quoteHide quote

"Jeff" <J***@discussions.microsoft.com> wrote in message
news:950FE55F-3A07-4275-8A29-07B7B43C8E78@microsoft.com...
> Strong names are not used. This is what is on MSDN:
> Redirecting Assembly Versions
> When you build a .NET Framework application against a specific version of
> a
> strong-named assembly, the application uses that version of the assembly
> at
> run time. However, sometimes you might want the application to run against
> a
> newer version of an assembly. An application configuration file, machine
> configuration file, or a publisher policy file can redirect one version of
> an
> assembly to another. For details on how the common language runtime uses
> these files to determine which assembly version to use, see How the
> Runtime
> Locates Assemblies. You can use the .NET Framework Configuration tool
> (Mscorcfg.msc) to redirect assembly versions at both the application level
> and the machine level, or you can directly edit the configuration file.
>
> Note You cannot redirect versions for assemblies that are not
> strong-named. The common language runtime ignores the version for
> assemblies
> that are not strong-named.
>
> The "Note" seems to imply if it is not strong named, you cannot do any of
> the techniques, ie: it can't be done!?
>
> Regards,
>
> Jeff
>
> "Claus Konrad" wrote:
>
>> If you are using strongnamed assemblies, you can not use a new assembly
>> with
>> your winform app. without recompiling this winapp.
>>
>> Alternatively you should use a policyfile to indicate to the winapp that
>> it
>> should be using a newer version of the dll in question.
>>
>> /CK
>>
>>
>>
>> "Jeff" <J***@discussions.microsoft.com> wrote in message
>> news:D12D84E0-A796-4048-9EA9-58369B40B4B4@microsoft.com...
>> > We have a C# Winform application that depends on three or four
>> > assemblies.
>> > In one of the assemblies, we changed one line of 'hard coded' data to
>> > some
>> > other data. Nothing else was changed just something like:
>> >
>> > string temp = "fred";
>> > to:
>> > string temp = "george";
>> >
>> > We re-compiled the assembly/dll and copied it over the old dll of the
>> > same
>> > name.
>> >
>> > The exe will not use the newly compiled dll. The error is something to
>> > do
>> > with the access level on classes within the dll. But nothing was
>> > changed
>> > other than data. We tried to use the "binding redirections" to allow
>> > substitution of our version for the one the original .exe was looking
>> > for.
>> >
>> > Is this the new "dll hell"?
>> >
>> > Regards,
>> >
>> > Jeff
>>
>>
>>

17 Jun 2005 1:58 PM

Jeff

Upon further test, you're right. There does indeed appear to be one or more
"extraneous" factors.

Thanks,

Jeff

Show quoteHide quote

"Claus Konrad" wrote:

> if you are NOT using strongnamed assemblies, the this is not your problem.
> You winapp will use any assembly as it is only referencing a partly
> quialified name. Use Ildasm.exe to investigate your manifest of your winapp
> to see what it actually expects of evidence from the 4 assemblies...
>
> /CK
>
>
> "Jeff" <J***@discussions.microsoft.com> wrote in message
> news:950FE55F-3A07-4275-8A29-07B7B43C8E78@microsoft.com...
> > Strong names are not used. This is what is on MSDN:
> > Redirecting Assembly Versions
> > When you build a .NET Framework application against a specific version of
> > a
> > strong-named assembly, the application uses that version of the assembly
> > at
> > run time. However, sometimes you might want the application to run against
> > a
> > newer version of an assembly. An application configuration file, machine
> > configuration file, or a publisher policy file can redirect one version of
> > an
> > assembly to another. For details on how the common language runtime uses
> > these files to determine which assembly version to use, see How the
> > Runtime
> > Locates Assemblies. You can use the .NET Framework Configuration tool
> > (Mscorcfg.msc) to redirect assembly versions at both the application level
> > and the machine level, or you can directly edit the configuration file.
> >
> > Note You cannot redirect versions for assemblies that are not
> > strong-named. The common language runtime ignores the version for
> > assemblies
> > that are not strong-named.
> >
> > The "Note" seems to imply if it is not strong named, you cannot do any of
> > the techniques, ie: it can't be done!?
> >
> > Regards,
> >
> > Jeff
> >
> > "Claus Konrad" wrote:
> >
> >> If you are using strongnamed assemblies, you can not use a new assembly
> >> with
> >> your winform app. without recompiling this winapp.
> >>
> >> Alternatively you should use a policyfile to indicate to the winapp that
> >> it
> >> should be using a newer version of the dll in question.
> >>
> >> /CK
> >>
> >>
> >>
> >> "Jeff" <J***@discussions.microsoft.com> wrote in message
> >> news:D12D84E0-A796-4048-9EA9-58369B40B4B4@microsoft.com...
> >> > We have a C# Winform application that depends on three or four
> >> > assemblies.
> >> > In one of the assemblies, we changed one line of 'hard coded' data to
> >> > some
> >> > other data. Nothing else was changed just something like:
> >> >
> >> > string temp = "fred";
> >> > to:
> >> > string temp = "george";
> >> >
> >> > We re-compiled the assembly/dll and copied it over the old dll of the
> >> > same
> >> > name.
> >> >
> >> > The exe will not use the newly compiled dll. The error is something to
> >> > do
> >> > with the access level on classes within the dll. But nothing was
> >> > changed
> >> > other than data. We tried to use the "binding redirections" to allow
> >> > substitution of our version for the one the original .exe was looking
> >> > for.
> >> >
> >> > Is this the new "dll hell"?
> >> >
> >> > Regards,
> >> >
> >> > Jeff
> >>
> >>
> >>
>
>
>