Problem using strong named EntLib assemblies

Topics: Development Team Discussion
May 17, 2007 at 8:35 PM
I'm working on finishing the unit tests for my contribution; I am basing them on the tests for the SQL Server and SQLCe providers. As such, they are inheriting from the tests in the source EntLib assemblies Common.Tests and Data.Tests.

I am trying to rebuild the two test assemblies against the signed libraries, but I get an error that Friend access is granted to a signed version of the library, and I am building unsigned (my translation, long error message available).

My question: are copies of Microsoft.Practices.EnterpriseLibrary.Common.Tests.dll and Microsoft.Practices.EnterpriseLibrary.Data.Tests.dll that have been compiled against the signed libraries available to us?

If not, suggestions on how to go about using the base tests in EntLib. I'd rather not copy all the base test stuff into the EntLibContrib project, but it would probably be a solution.

Ken Scott
May 18, 2007 at 2:46 PM
if I understand the problem correctly, you would like to provide "friend" access to the unittesting assemblies, which are strong-named (and therefore your unittesting library should be strong-named as well).

If this is the issue, I do not think it is a problem to strongname your unittesting project as well.

If your problem is different (and needs more investigation) you can check-in the code and we'll have a look at it together.

May 18, 2007 at 5:13 PM
The problem I am having is from the EntLib project.

I need to recompile the two assemblies listed above (Microsoft.Practices.EnterpriseLibrary.Common.Tests.dll and Microsoft.Practices.EnterpriseLibrary.Data.Tests.dll) against the strong-named EntLib libraries. Microsoft.Practices.EnterpriseLibrary.Common provides "friend" access to a strong-named version of the two test assemblies, and won't give that access to an unsigned assembly of the same name.

The Microsoft strong-name key is not in the EntLib project (naturally), so I don't have a way to create the two test assemblies named above as strong-named assemblies.

I either need to reference unsigned EntLib assemblies in the Test project, or be able to add signed test assemblies.

May 19, 2007 at 1:33 PM
ok, i see.

We are not able to sign the contrib assemblies with the private key we used to sign EL with.
Referencing both unsigned and signed assemblies from within the contrib project might not be ideal either.
Duplicating some unittesting code into the contrib project would be my favorite, though this depends on the amount of code that we potentially need to copy. From your post i gather this is quite a lot?

Could you check in the code you currently have, with the unittests that do not compile commented out?
That way we can have a look at which classes are affected and whether there would be other ways around this problem.

May 19, 2007 at 8:13 PM
I added about a half-dozen unit test base fixtures from the EntLib project, and everything is building and running successfully. I checked in my code changes.

I had to clean up a little bit because of the changes the MySQL provider author made to the project structures.

Question: should the SQLite provider be in a separate solution, like MySQL is now?
May 20, 2007 at 3:35 PM
cool kenneth, looks really good!

If we would have a price for the best test-coverage, you'd be running for #1! :-)

The reason we have put the MySql provider in its own solution and project it, because we cannot distribute the library it depends on.
This means that if we would include the project in the main solution, people wouldnt be able to compile the lot (unless theve installed the library).

This solution is placed in the root, because of visibility (we wouldnt want to put it in a place 6 folders down, somewhere).

As for your question, yes I think it makes sense to either include the library you depend on if licenses permit.
Otherwise we'd be best of having your additions live in a solution of their own.

Having said that, I also noticed you needed a reference to nunit.framework. Which would also count as an external reference.
In fact, I realize that we might actually need different projects for testing (since it wouldnt be fair to assume that everyone would have an edition of VisualStudio that would allow for unittesting.

know what? if you could find the time to place the SqlLite provider in its own project/solution, i'll have a look at splitsing the main solution in: