And which log? Log4net? Which namespace then?

Yes, this is logged via log4net. The error message you are looking for would look something like the following:

2013-08-13 12:59:25,819 [35] ERROR EPiServer.Packaging.SitePackageManager: Aborting operation. The following add-on assemblies exist in the main 'bin' directory: C:\EPiServer\ExampleEPiServerSite\wwwroot\bin\EPiServer.Cms.Shell.UI.dll

I hope that helps to resolve your immediate problem.

Hi Johan.

If you have concrete scenarios that you think we can support better or have any suggestions on how we can improve the way that dll:s are handled we're listening. In 7.5 we're making improvements in terms of making each site responsible for its dll:s (for example making ftp deploy much easier). We will also look into improving error messages like the above.

Ok, I found the assemblies now. But I don't see the point with the Add-on Store if we need to do manual work to make it work. Now we have to remove assemblies before updating and then re-add them.

Peter: One concrete scenario would be to have a global repository with all assemblies and application files which all projects could share.

And what I think most developers are missing is clear instructions what to version control. Ideally you just want to check out the project and hit F5 and it would run.

Another hassle is deployment and updating all environments.

You shouldn't have to re-add them. It refused to proceed with the installation because the assembly is not expected to be there and having it there could easily create a conflict after deploying a new version.

Well, I beg to differ :) The website won't run without them. Now we're missing:

• \bin\HtmlAgilityPack.dll
• \bin\ImageVault.Client.dll
• \bin\ImageVault.Common.dll
• \bin\ImageVault.EPiServer.Common.dll
• \bin\ImageVault.EPiServer7.dll
• \bin\sv\ImageVault.Client.resources.dll
• \bin\sv\ImageVault.Common.resources.dll

What exactly is an add-on assembly? And when we're building the project the above assemblies will be re-added to bin, and need to be deleted again before next update.

Hi!

The cause of the problem is probably that you have referred to the ImageVault dll:s in your project and then they are copied to the bin folder. The ImageVault add-on uses the same dll:s and these are placed in the modulesbin folder. So you have the same dll:s in both bin and modulesbin folders. This is no problem when it comes to running the application since the assemblies in the bin folder will be loaded first.

When the add-on system tries to update I guess that they have some kind of sanity check that identifies duplicate dll:s and throws an error when those are detected. This check must have been introduced in some add-on update since this was not an issue for the first version.

To work around the issue, copy the culprit dll:s from the bin folder, and do the add-on operation, then copy them back after the add-on operation has completed.

We are working on a separation of the ImageVault add-on to not reuse the assemblies in both the add-on and client nuget package (files you need to refer to in order to compile your solution).

/Dan

I don't understand how to solve this problem. I have checked the logs for the .dll's causing the issue, which are 4 ImageVault dll's and Newtonsoft.Json. But if I remove them from the bin folder, the site crashes and I can't go through with the update.

I can't uninstall the addon either because of the same reason. I am trying to upgrade the site from 7.0 to 7.5.

Any ideas?

EDIT: Removing the files from modulesbin instead of bin worked for me

Old thread, but just experienced the same thing. The solution was as Daniel says, to delete all files from modulesbin