2

I have one VS solution in which there are 20 custom web part is there and it is working fine in production environment as well.

Now because of some business requirement I have changed DLL version of that Visual Studio solution and deployed updated WSP file to SharePoint server.

Now all the web part get stopped working with following error:

Part Error: A Web Part or Web Form Control on this Page cannot be displayed or imported. The type [Namespace], Version=1.0.0.0, Culture=neutral, PublicKeyToken=6b79829b0b76e944 could not be found or it is not registered as safe. Correlation ID: ca46d29d-7206-a0a6-8e9d-63e88de320b1.

I checked root cause and found that all the page's web part is still pointing to old dll version of my solution but it should point to new version.

Now I can solve issue by adding safe control entry of old dll version to web config but which I don't want because If I will do that then my all web part will point to old code.

I have approx. 200 pages in SharePoint.

Please suggest me how can I fix that issue?

Improve this question

1 Answer 1

Reset to default
1

Changing the Assembly version of a DLL containing Web parts/Jobs/Workflows/Event receivers is not a good practice. All these artefacts point to the assembly, including its version number.
And you cannot easily update these references, since they're stored at different locations in the DB.

Don't change the AssemblyVersion, use the AssemblyFileVersion instead

So, the first recommendation would be to not update the Assembly version (i.e. roll-back to the previous version); you may update the File version if you want to track the version of the DLL. See https://andrewwburns.com/2011/05/18/assembly-versioning-in-sharepoint/ or http://www.sharepointsecurity.com/sharepoint/sharepoint-webpart-versioning/ for more info.
I'd definitely go with that first option to avoid future problem.

Use bindingRedirect

Second option is to add redirection in the web.config. You would direct all requests for version 1.0 to version 2.0. However, note that it won't solve the problem for workflows, jobs or Event receivers loaded in another process than w3wp.
See here for the bindingRedirect documentation, and here if you want to automate the process at deployment.

Improve this answer
1
  • Thanks for your prompt response. The reason is changing DLL was that there is one visual studio workflow in this solution and There was one change in workflow functionality and in this case If I change the workflow code without changing assembly version then old workflow stops get working. Do you have any other solution for that?
    – Kalpesh Vaghela
    Feb 6, 2017 at 9:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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