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

  1. Bake the compile time into the version number
  2. 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.


As others have said, use AssemblyFileVersion and the reasons why :- KB556041 - How to use Assembly Version and Assembly File Version

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'.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.