Issue with dependent assemblies when rebuilding a WAP and the Workarounds

In Visual Studio 2010, the dependent assembly of a custom control assembly will be deleted from the project’s Bin folder on project clean or rebuild if the project does not contain a reference to that dependent assembly. The result will be a WAP that successfully builds but fails at runtime.

When adding a control from such a custom control assembly, both the custom control assembly and the dependent assembly will be added to the bin folder of the WAP. However, only the reference to the primary assembly will be added automatically to the references node of the project, but the reference to the dependent assembly will not. If the dependent assembly is not required at the compile time, then usually, users would not add it to the references node themselves. Things will work fine as long as users don’t rebuild the project in this scenario. Examples of custom controls with dependent assemblies include Ajax Control Toolkit Beta and Coolite.

However, if the user rebuild the project, then first, the bin directory’s content will be deleted as part of the Clean action. Then only the assemblies that are in the references list will be copied back to the bin directory. That means only the primary assembly will be copied, but the dependent assembly will not. It will still compile successfully, but users will get an error at runtime, saying it does not know how to load the dependent assembly. For example, with the Ajax Control Toolkit Beta, the error message would be “Could not load file or assembly ‘System.Web.Ajax, Version=3.0.31106.0, Culture=neutral, PublickKeyToken=28f01b0e84b6d53e’ or one of its dependencies. The system cannot find the file specified” . If the user adds the dependent assembly back to the bin directory themselves, then the project will run correctly. However, the user will encounter the issue every time they rebuild the project since adding the dependent assembly to bin is only a one time solution.

A fix for this will be included in a service pack for VS 2010 in the future. In the meantime, there are two easy workarounds for it. The first workaround is the user needs to explicitly add the dependency references to the project.

A second workaround would be adding an AssemblyFolderEx entry in the registry hive that points to the location of the assemblies. For example, for the AjaxControlToolkit Library Beta release for 3.5 framework, we would add an entry named AjaxControlToolkit under “HKEY_LOCAL_MACHINESOFTWAREMicrosoft.NETFrameworkv2.0.50727AssemblyFoldersEx”, and give it a path pointing to the Release directory “AspNetAjaxLibraryBeta0911WebFormsRelease” as illustrated below.