Problem with Strong-Named Assemblies

Developer
Feb 5, 2011 at 6:53 PM

The current DotSpatial assemblies are strong-named assemblies. This is causing problems in our DotSpatial-based application (HydroDesktop). Our application is shipped with many third-party plugins. Every time we replace the DotSpatial dlls by a new version, all third party plugins must be rebuilt, otherwise they are not detected by the DotSpatial AppManager due to assembly version mismatch. I've posted a related DotSpatial issue: http://dotspatial.codeplex.com/workitem/237

The current setup with strong-named assemblies also makes it very difficult to share a plugin across different DotSpatial based applications. In general, using strong-named assemblies is only recommended for shared assemblies in the GAC (Global Assembly Cache):

http://stackoverflow.com/questions/2310246/when-should-we-not-create-assemblys-strong-name-what-are-the-disadvantages-of

What is the reason for having the DotSpatial assemblies strong-named? Can I remove the signing and strong-name from all DotSpatial assemblies?

Any other suggestions how to solve the strong-named assembly version mismatch issue?

Developer
Feb 5, 2011 at 9:36 PM
Strong named assemblies are about versioning, and performance.

See if you can enable the a bypass.

or use partial references,
http://msdn.microsoft.com/en-us/library/0a7zy9z5(v=VS.100).aspx

On Sat, Feb 5, 2011 at 10:53 AM, jirikadlec2 <notifications@codeplex.com> wrote:

From: jirikadlec2

The current DotSpatial assemblies are strong-named assemblies. This is causing problems in our DotSpatial-based application (HydroDesktop). Our application is shipped with many third-party plugins. Every time we replace the DotSpatial dlls by a new version, all third party plugins must be rebuilt, otherwise they are not detected by the DotSpatial AppManager due to assembly version mismatch. I've posted a related DotSpatial issue: http://dotspatial.codeplex.com/workitem/237

The current setup with strong-named assemblies also makes it very difficult to share a plugin across different DotSpatial based applications. In general, using strong-named assemblies is only recommended for shared assemblies in the GAC (Global Assembly Cache):

http://stackoverflow.com/questions/2310246/when-should-we-not-create-assemblys-strong-name-what-are-the-disadvantages-of

What is the reason for having the DotSpatial assemblies strong-named? Can I remove the signing and strong-name from all DotSpatial assemblies?

Any other suggestions how to solve the strong-named assembly version mismatch issue?

Read the full discussion online.

To add a post to this discussion, reply to this email (DotSpatial@discussions.codeplex.com)

To start a new discussion for this project, email DotSpatial@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Developer
Feb 7, 2011 at 7:42 PM

The application suite I'm working on requires any referenced assembly to be signed.  I'm not sure what the original motivation was, so it may not be a hard requirement.  But, I thought it was considered good programming practice.

The automatic version bumping that Dot Spatial does on each build is a real pain, though.  When I make a simple change in one of the Dot Spatial assemblies, I usually end up having to rebuild all my assemblies that may have a Dot Spatial dependency, which means a several minute wait to test my change.  I would prefer the version get bumped with each release, or something along those lines, but I'm no expert in the matter.

Kyle

Developer
Feb 7, 2011 at 10:06 PM
Edited Feb 7, 2011 at 10:08 PM

I think that for most people the kinds of trouble that they encounter from automatic version changes would not be significantly different from changes that occur during each release.  So in other words if version number changes affect them, then it will affect them in both cases and we should look at making anything in our code that is still sensitive to version changes less so.  Without the automatic versioning I guarantee no one is going to bother to go through manually and update the version unless it were a big change, like maybe once a year or something.  However, having version numbers that auto-increment is more about helping people track what variant they have, and whether or not they should get an update.  It does cause problems, but I'm on the side of solving the underlying problems caused by versioning than the alternative, which is to never version anything ever.

Strong names are much more critical than automatic versioning.  They are needed for everything from Click-Once deployment to GAC registration (presuming you wanted to do that) to allowing your library to be referenced by a library that has a strong name.  Remember, it is acceptable for a library without a strong name to reference a library regardless of its name strength, but in order to build with a strong name I think every library you depend on must also have a strong name. So if you make a library dll and expect other people to reference it, you really should have a strong name, even if in the open source world the whole signing and security aspect is more or less a wash.

 

Ted

 

Developer
Feb 7, 2011 at 10:14 PM

Sounds like the best solution is to set

[assemblyAssemblyVersion("1.0.0.0")]
[assemblyAssemblyFileVersion("1.0.0.*")]

This will allow individuals to track file versions without affecting the strong name.

The buildmaster can occasionally update AssemblyVersion when he feels appropriate.