File Locking Issues when using WPF and Silverlight Designer

When creating and testing a registered assembly (e.g. an assembly registered via TCI), it is possible to run into a file locking issue that causes compilation to fail.  While there are a few different manifestations of this particular issue, the root cause is the same.  Visual Studio 2010 treats any assembly found in the GAC, Private Assemblies folder, or Registry as a framework assembly and thus locks these files.  Once these assemblies are loaded by the designer, any attempt to copy over them will fail with the following error message:

Unable to copy file "obj\Debug\<Assembly Name>" to "..\..\<Assembly Name>". The process cannot access the file '..\..\<Assembly Name>' because it is being used by another process.

It does not matter if this copy is happening as the result of a compilation; build action, or manual copy.  Once these assemblies are loaded by Visual Studio, they will be locked and attempts to overwrite these files will fail.

Recommended Rules to Avoid Locking Issue

To avoid this scenario, you should follow these rules for development and deployment testing of your registered assemblies: 

• If at all possible, assembly deployment testing (e.g. assembly registration) should not be done on the same machine as development of the assembly.  This is the definitive way to avoid this issue.   Also, if the assembly you're building is using a public key and has already been registered on your development box, you have no choice but to follow this rule.  There is no other reliable way around this issue. Two popular examples of projects that use a public key are the WPF toolkit and the Silverlight toolkit.  If you download and install these toolkits, you will see this locking issue (regardless of what the project output path is set to) if you attempt to also build these toolkits on the same machine.
• If, however, your assembly does not use a public key, and you must do development and deployment testing on the same box, you will need to follow these rules instead:
  • Make sure your project output does not write directly to a path which has been registered in any way.  For example, your output path should never be to any path that's registered in AssemblyFoldersEx.
  • Any Visual Studio instance which has already loaded your assembly must be closed before you can either rebuild the assembly, or copy a new version of the assembly to the registered path.  For example, if you're using a different Visual Studio instance for testing, you will need to close this test instance of VS before you can rebuild or replace the assemblies that have been loaded by this instance.

Recommended Pattern for Testing Controls During Development

First, it's important to point out that TCI registration is not required to develop/test/debug design-time features.   It is recommended that you separate out the functional testing of control libraries from the testing of deployment scenarios.  One easy way to accomplish this is to create a test project directly in your working solution.  This will allow you to take full advantage of the Toolbox Auto-pop and will make it easy to create controls from the toolbox, all without the need for TCI registration.  You do need to ensure that the controls that you are building have not been placed in the GAC, Private Assemblies Folder, or in the registry (such as under the AssembyFoldersEx node). 

Please contact us if you need additional help with this issue.

WPF & Silverlight Designer Team