C# – CorfFlags warning CF011 about strong name signed even after /force

ccorflagsnetpartcover

Im trying to use Corflags to get PartCover running under x64. When I use:

CorFlags.exe PartCover.exe /32BIT+ /Force

i get:
corflags : warning CF011 : The specified file is strong name signed. Using /Force will invalidate the signature of this image and will require the assembly tobe resigned.

without /force i get:

corflags : error CF012 : The specified file is strong name signed. Use /Force to force the update.

On web there appears that others are runnig partcover throught corflags with no problems…

Best Answer

I don't see the problem. When you use /Force corflags is updating the PE header so that the assembly is x86 (32 bit), however this does invalidate the strong naming and thus you must resign the altered assembly. That is why you are seeing the warning, but I would bet that corflags is altering the assembly.

By not using /Force then corflags is telling you it won't do something that will invalidate the assembly without you explicitly giving it permission to with the /Force arguement.

Related Solutions

R – NCover on 64 bit – CorFlags fix – corflags : error CF008 : The specified file does not have a valid managed header

I actually solved this by upgrading to a newer version of NUnit, and changing my NCover task to point to the X86 version:

    <exec program="tools\ncover\NCover.Console.exe" workingdir="${build.dir}\Debug\UnitTests">
        <arg value="//w &quot;.&quot;" />
        <arg value="//x &quot;..\..\test-reports\Coverage.xml&quot;" />
        <arg value="&quot;..\..\..\lib\NUnit-2.4.8-net-2.0\bin\nunit-console-x86.exe&quot;" />
        <arg value="&quot;UnitTests.dll&quot; &quot;/xml:..\..\test-reports\UnitTests.xml&quot; &quot;/nologo&quot;" />
    </exec>

.net – Why exactly does regasm warn me about signing with a strong name

It is a clumsy warning. There are two aspects to COM DLL Hell. The really bad one is modifying the public interfaces and not assigning new GUIDs. A client app that wasn't recompiled tends to crash and burn when it calls an entirely wrong method or bombs with a nasty AccessViolationException that gives no clue at all what the cause might be.

The second one is doing everything right (assigning new GUIDs) but then overwriting the existing DLL with the new version. You'll still crash that stale client app but more mildly with an E_NOINTERFACE hresult that generates a pretty specific exception that helps you diagnose the cause. The user isn't any happier though.

That scenario has a ready solution in .NET, the GAC supports side-by-side deployment of assemblies with different version numbers so that both the old and the new version can co-exist and the stale client app continues to be happy with the old version. Which requires a strong name. Yes, that warning could certainly have been suppressed when you use /codebase since that makes it quite clear you are not going to use the GAC. Although it doesn't hurt to tweak your nose a bit at using /codebase. Also, you never use the GAC on your dev machine while testing but certainly should consider it when deploying.

Best Answer

Related Solutions

R – NCover on 64 bit – CorFlags fix – corflags : error CF008 : The specified file does not have a valid managed header

.net – Why exactly does regasm warn me about signing with a strong name

Related Topic