Assembly "is not signed correctly." Warning

Question

I have a mobile .NET solution and decided to sign the assemblies. Compilation completes without errors but gives the warning

'CompactUI.Business.PocketPC.asmmeta, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' is not signed correctly.

The application is working fine but I can't open the designer for forms using this assembly anymore. Again the designer says

'CompactUI.Business.PocketPC.asmmeta, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' is not signed correctly.

with the stack information:

at Microsoft.CompactFramework.Build.AsmmetaBindingService.GetAsmmetaAssembly(String sourceAssemblyPath, Boolean verify) at Microsoft.CompactFramework.Build.AsmmetaBindingService.LoadAsmMetaAssembly(Assembly sourceAssembly, String hintPath, IDeviceTypeResolutionService resolver) at Microsoft.CompactFramework.Build.MetadataService.GetAsmmetaType(Type sourceType) at Microsoft.CompactFramework.Build.MetadataService.GetTypeAttributes(Type desktopType) at Microsoft.CompactFramework.Design.DeviceCustomTypeDescriptor.GetAttributes() ...

What is causing this?

Edit: Nicholas suggestion is not solving the problem

I've got a Form that contains common properties which is base for every form in the presentation layer

public class CustomForm : Form
{
    ...
}

This form is in the business layer that causes the warning. Every form that inherits from this base form causes the problem when viewing in the designer.

Answer 1

This should help you out

Answer 2

I'm confused, you say that you signed the assmeblies but yet your public key token is null, if you had signed this assmbley then you should specify the public key that is generated instead of null. Maybe I'm not understanding the issue fully. Try removing the reference to CompactUI.Business.PocketPC.asmmeta and re-add the signed version.

Answer 3

Verify that the assembly wasn't generated with "delay sign" set. This would cause the assembly to advertise that it was signed, when it only has a null placeholder instead. This will cause strong-name verification to fail. For more information you can also check out this page on MSDN: "Assemblies should have valid strong names"

Answer 4

Cause

An assembly is not signed with a strong name, the strong name could not be verified, or the strong name would not be valid without the current registry settings of the computer. Rule Description

This rule retrieves and verifies the strong name of an assembly. A violation occurs if any of the following are true:

* The assembly does not have a strong name.

* The assembly was altered after signing.

* The assembly is delay-signed.

* The assembly was incorrectly signed, or signing failed.

* The assembly requires registry settings to pass verification. For example, the Strong Name tool (Sn.exe) was used to skip verification for the assembly.

The strong name protects clients from unknowingly loading an assembly that has been tampered with. Assemblies without strong names should not be deployed outside of very limited scenarios. If you share or distribute assemblies that are not correctly signed, the assembly can be tampered with, the common language runtime might not load the assembly, or the user might have to disable verification on his or her computer. An assembly without a strong name suffers from the following drawbacks:

* Its origins cannot be verified.

* The common language runtime cannot warn users if the contents of the assembly have been altered.

* It cannot be loaded into the global assembly cache.

Note that to load and analyze a delay-signed assembly, you must disable verification for the assembly.