"Sharing my headache moments"


The located assembly’s manifest definition does not match the assembly reference

Recently I ran into a strange problem which took me a while to solve. In the end I was able to solve the problem and because of the limited information for my situation, I decided to write a blogpost about it.

Problem: DLL not removed from temp folder

The problem occurred with a on-premise SharePoint 2010 environment, but also occurs in higher versions. A new version of the code had to be installed on the production environment for a customer. The installation was trivial, but the first attempt resulted in a solution deployment job that hangs on “Deploying scheduled” status due to a stopped SharePoint Administration service on one of the front-end servers. Started the SharePoint Administration service, restarted the deployment and the installation successfully deploys in the farm.

A quick smoke test shows that one of the web parts was giving an error. In the ULS logs the following error occurred: “The located assembly’s manifest definition does not match the assembly reference”. A search on the internet shows several causes for this errormessage. Except the cause for my situation: the DLL ‘hangs’ in the assembly temp folder. As you can read in this blogpost from Junfeng Zhang’s Musing the GAC contains a temp and a tmp folder. The tmp folder is used for installation and the temp folder is used for uninstallation of a DLL. Due to the stopped SharePoint Administration service, the installation couldn’t be completed and the old DLL remains in the temp folder. After the second try the DLL was successfully installed in the GAC but the old DLL was still in the temp folder, which causes the assembly manifest error in the SharePoint logs.

Solution: delete the contents of the temp folder in the GAC

The issue occurred on a Windows Server 2008 R2 machine, but the solution should work as well on a Windows Server 2012 (R2) machine. To solve the issue, the DLL must be deleted from the temp folder. Do this by:

  1. Stopping the IIS service
  2. Remove the DLL from the temp folder
  3. Start IIS again

Tip: view the temp folder in the GAC

It’s not straightforward to navigate to these temp folders. To view the GAC temp folder you must open the assembly folder through the Run tool Win flag + R and open C:\Windows\Assembly\temp.

Gac Temp Folder

If you navigate via windows explorer to c:\windows\assembly you’ll only see the DLL’s and not the temp and tmp folder.

Gac Folder

Hope to help someone with my solution and feel free to comment.


Share Visual Studio Workspace settings with your teammates

You often see the NuGet packages checked into TFS. This is an unnecessary waste of space, because you can ‘tell’ the build server to download the NuGet packages at build time. You can do this by enabling NuGet package restore at solution level.

Enable package restore
(Click on the image to enlarge)

Now we know how to enable package restore, but you still see all installed packages in your pending changes. You could hide the packages from the pending changes by selecting the ‘Show Solution Changes’ option in the pending changes window. But there is a better way. Visual Studio has so called workspaces. In these workspaces you define mappings. These mappings represent the location of your client-side folders on your local disk and the corresponding Repository Folders. In these mappings you have to cloak the packages folder to hide the installed NuGet packages.

Show solution changes
(Click on the image to enlarge)


The Visual Studio Workspace

If you open the source control explorer, you see your workspace. In this workspace you can configure which directories and files will be added to source control. To get rid of your NuGet package folder add the Packages folder as a cloaked mapping in your workspace. Please note, it is important to explicit include the repositories.config in your mappings, else the build server doesn’t know which packages it has to download to successfully compile your project. After you’ve cloaked your packages folder, you add a map to /packages/repositories.config. This way only the repositories.config is included and not the binaries in the package folder. When you add a new NuGet package to your solution you’ll see the repositories.config has a pending change, but the binaries of the package aren’t included in your changes and will be downloaded by the the build server.

Your workspace settings
(Click on the image to enlarge)


Share the mappings with your teammates

So that’s cool stuff, but what if you work in a team of developers. Does every developer have to setup his own workspaces? Fortunately not. You have two options to share you mappings.

  1. Copy your mappings to a text file and share this text file with your teammates
  2. Copy your workspace settings to a build workspace (Copy Existing Workspace). Your teammates can copy the mappings from the build workspace and past into theirs. They should only correct the mapping according to their existing mappings.
Copy your workspace settings
(Click on the image to enlarge)

Thank you for reading, please feel free to comment.


Oops, provisioned my web parts twice.

A while ago I was working on a SharePoint 2010 solution for one of our customers were I had to change a content type and a page layout. I modified the content type and page layout and deployed the solution on the test environment.

To provision the changes, I reactivated the feature containing the content type and page layout. To ensure my changes were successfully deployed I created a new page based on the page layout and added some content.

Surprisingly there were duplicate web parts on the page I just created. What happened here? After some digging I found the problem.The feature I reactivated contained an element manifest with a web part declaration in the AllUserWebPart element.

elements.xml contains the webparts
(Click on the image to enlarge)

When you reactivate a feature that contains an element manifest with one or more web part declarations SharePoint inserts this into the content database. In SharePoint 2013 you have the option to replace the contents instead of insert, so the problem won’t occur anymore (more on this below). However SharePoint 2010 doesn’t have the option and you’ll end up with duplicate web parts on your page.

double webparts on the page

(Click on the image to enlarge)

Steps to reproduce

Follow the steps below to reproduce the issue.

  1. Add web part declarations in the element manifest
  2. Update your solution
  3. Reactivate the feature containing the page layouts
  4. All the new pages you create with the page layout have duplicate web parts on the page


The fix for this issue is relatively simple. You have to open the page layout in web part maintenance mode. To do this navigate a page that uses the page layout and click on the page layout link and  append ?contents=1 to the url.

Pagelibrary view
(Click on the image to enlarge)

In the web part maintenance page you’ll see all the web parts on the page layout. Now, check out the page and delete one of the duplicate webparts. Check in and publish the page layout and the issue is solved.

Webpart maintenance page
(Click on the image to enlarge)

This action shouldn’t customize the page layout, but I always say: better safe than sorry. So my advice is to always check the CustomizedPageStatus of the page, because as long as your page is ghosted you can update the page layout with an solution update.

Check the CustomizedPageStatus with PowerShell.

$web = Get-SPWeb http://intranet.contoso.com
$file = $web.GetFile("/_catalogs/masterpage/Mypagelayout.aspx")

Check the customized page status
(Click on the image to enlarge)

Your page can have three statuses:

  • None – The page is never cached.
  • Uncustomized – The page is cached and has not been customized.
  • Customized – The page was cached and has been customized.

Source: MSDN


To prevent this issue you have three options:

Check out all page layouts before reactivating the feature containing the page layouts

SharePoint will not change checked out page layouts and thus the new element manifest will not be applied.

Separate your page layouts, masterpages and content types in different features

If you separate these, the chance that you have to reactivate the feature is minimal.

In SharePoint 2013 you can use the new property ReplaceContent on the file element

When you use the ReplaceContent=”true” in your File module, SharePoint overwrites the previously installed version of the file with a new version when the element manifest is being applied. Thanks to my colleague Jordy van Paassen who gave me this tip.