c# - Error: A strongly-named assembly is required

Question

I have a Windows forms project (VS 2005, .net 2.0). The solution has references to 9 projects. Everything works and compiles fine on one of my computers. When I move it to a second computer, 8 out of the 9 project compile with no problem. When I try to compile the 9th project (the main project for the application - produces the .exe file to execute the application), I get the following error:

'Error 3: A strongly-named assembly is required. (Exception from HRESULT: 0x80131044)'

The file location for the error is is listed as "C:PATH-TO-APPLC".

I have checked in the project properties and all of the projects are set to build in Debug mode, none of them are supposed to be signed. In the project that is failing, the only assembly that it references that is not in any of the other projects is Microsoft.VisualBasic (a .net 2.0 assembly). So I am at a loss to find what ids causing this error (the file referenced above in the error message - "LC" - does not exist.

Anyone know how I can force the project to accept all unsigned assemblies, or to determine which assembly is the culprit?

The only meaningful difference between the dev environments between the dev environment where this worked and the current one is that the first was XP and this is Vista64. However, a colleague of mine who is using XP is getting the same error.

Third-party assemblies being used:

• ComponentFactory.Krypton.Toolkit
• ComponentFactory.Krypton.Navigator
• VistaDB.NET20

All of these are referenced in other projects in the solution which build with no problems, so it doesn't look like these are the problem.

So far I have tried deleting the suo file, Rebuild All, unloading and reloading projects from the solution, removing and readding referenced assemblies. Nothing has worked.

Answer 1

I just got it to build by doing the following:

There had been a licenses file in the Properties of the project in question. After deleting the file (it was no longer needed) the project was able to build successfully. So it looks like that was the culprit.