How can I investigate non

I'm trying to make the internals of a class library visible to a unit test project. Both the class library and the unit test projects are signed; we've used the project property page in VS-2013, ticked the box for signing, and let VS create a key file.

I used "sn -Tp NUnitTests.dll" on the developer command tool to extract the public key (really anonying MS does not offer a simple "choose a DLL" GUI way to do this tedious stuff - but I digress).

In the class library's AssemblyInfo.cs, I've inserted

[assembly: InternalsVisibleTo("MyProject.NUnitTests, PublicKey=0024000004800000940000000602000000240000525341310004000001000100fbd5b3dfc3247de89f1940718fbecda5fc6f9e19a17515a5af8004555d1f1bc9720dfa522ccf414c2f79c659528053a3ba0083333e5d1ae9d7a674d032386b5180e78cacad2e1f16f2f2cf005452615a5d06c6c6911665e8f66112c568bcd93ae93bd4cce348f3e2c5f8ea9156abd19119773ebe329728ae9558210aa8181be2")]

Both projects build fine as long as I don't test any internals, but if I try to do so, I get the same build errors I'd get if internals were not exposed. Eg if the class library contains

public class Foo 
{
    internal static void Bar() {}
}

and a test does

Foo.Bar();

I get an error claiming Foo does not have the method.

I have checked, double-checked and triple-checked that the name and key is correct. I've emptied the GAC and rebuilt (as I've experienced sometimes that the build appears to use a GAC-ed version of an assembly, even when I rebuild - not sure what this is about). I've looked at the manifest with ildasm and verified the public key there too (only the casing differs, which should not matter much for HEX data; in any case I use lowercase, like sn.exe, in the attribute value). I've tried removing and re-adding the reference from NUnitTests to the class library. I've restarted VS-2013.

Having exhausted all the frustrating "try everything you can think of, even if you have no idea WHY it might work" options, I wonder if there is a better way.

We're targeting fw 3.5 if that matters.

---

Well this is embarrassing!

The assembly name is indeed "NUnitTests" and not "MyProject.NUnitTests" (though how Hans Passant could possibly possess this knowledge is beyond me!).

It's the easy sh*t that gets you...

I still think Microsoft could make this a lot easier for us. Using internal modifiers is useful, and being able to selectively expose them to other components is a huge simplifier for anyone who makes libraries, which is sort of what we all do (even if the consumers are "just" people in the same organization, maybe working on the same system).

链接地址: http://www.djcxy.com/p/73388.html

上一篇: 单元测试依赖关系的角度服务

下一篇: 我如何调查非