[Gtk-sharp-list] Gtk# 0.10 installer for Windows (aka. Gtk# Runtimeand Development Environment for Windows)

Mathias Hasselmann mathias.hasselmann@gmx.de
Thu, 26 Jun 2003 23:51:07 +0200

Timothy Parez wrote:
> Hi,
> I've also been thinking about this problem
>>Gtk# assemblies are now strongly named, compiled with ngen and copied to
>>the assembly cache during installation. This solves the first part of
>>the long known ".NET-Framework-cannot-find-Gtk#" problem. Second part of
>>the well known problem is gtksharpglue.dll not being found. Best
>>solution for this so far: Manually tweaking the PATH environment
>>variable. The Gtk# Runtime and Development Environment introduces a more
>>elegant solution:
> How did you solve that ? Because I tested a few things and I came to the
> following conclusion
> Lets say assembly X is an open-source assembly, your installer installs
> assembly X into the GAC
> Then I recompile assembly X from cvs (which is then unsigned) and compile my
> application Y against assembly X
> In my experience my application Y will never run against the version of
> assembly X which is located in the GAC
> because my application doesn't expect a signed assembly X (strong named)

Signing an assembly alters the assemblies name. Remember in .NET an 
assembly name doesn't only include the name of the file used to store 
the assembly. In .NET an assembly name also includes "minor" details 
like version number, locale (aka. "culture") and a "PublicKeyToken".

So if the names of two assemblies differ, then why should the runtime 
even try to bind a program linked with the assembly "Frosch, 
Version=, Culture=neutral, PublicKeyToken=null" against another 
assembly called "Frosch, Version=, Culture=neutral, 

A solution for the problem _could_ be shipping the keychain used to sign 
the "official" assemblies with the distribution. You could then sign 
your CVS versions of the assemblies with that key. If I understood the 
concept behind strong assembly names correctly your manually built 
assemblies should get the same name as the distributed assemblies then.

Problem with that procedure: We cannot prove anymore that binaries we've 
shipped have not been modified by Fluffy Bunnies and other creatures.