I need two things out of an assembly I'm developing, and they seem to be at odds:

Bake the compile time into the version number

Offer a web part that won't go stale every time I deploy

I'm using [assembly: AssemblyVersion("1.0.*")] to bake the compile time into the assembly (so that I can format it and display it later). That changes the last two numbers in the assembly version every time I compile.

When I add to my page a Web Part that's in this assembly, it seems to become invalid after future deployments, b/c the version number of the assembly is always changing automatically. The error message is similar to (italic text is simulated):

Web Part Error: A Web Part or Web Form Control on this Page cannot be
displayed or imported. The type
Namespace1.Namespace2.AssemblyName.AssemblyName, Namespace1.Namespace2,
Version=1.0.4454.15790, Culture=neutral,
PublicKeyToken=2d5b72b5e35faf73 could not be found or it is not
registered as safe.

How can I use this feature of AssemblyVersion w/o having to re-add to my page all of this assembly's Web Parts each time the version number automatically changes?

3 Answers
3

SharePoint uses the strong name of a library anywhere it needs to reference it and is thus highly dependent on the specific version numbers remaining reasonably constant. Using the '1.0.*' feature is not a viable option for SharePoint development.

Lance's suggestion to use the approximate Build Date rather than the version is probably the best workaround, though I have not personally used that approach.

It is strongly discouraged to use assembly versioning in SharePoint unless you are prepared to manage all old SafeControl entries. Using versioning will only cause the errors you're seeing. Just don't use it.

A better approach is to use the AssemblyFileVersion attribute. This is what I, and most of the community uses today to manage version numbers on assemvlies.

Suppose you are building a framework assembly for your project which
is used by lot of developers while building the application
assemblies. If you release new version of assembly very frequently ...
and if assemblies are strong named, Developers will have to change the
reference every time you release new assembly ... A better option in
such closed group and volatile scenarios would be to fix the 'Assembly
Version' and change only the 'Assembly File Version'.