Question

I'm maintaining a c#.Net (vs2005) library, let's call it fooLib, developed by a coworker. Now management has decided that we should change it's name to, say, barLib.

So I have renamed it, changed some of the metadata (copyright info, etc), registered it in gac, removed the reference and added it again in each project which uses it, and voila!

So far, so good, but there's a project which uses it, that gives me some weird error when linking the Debug version, while the Release works like a charm, without a warning. It gave me a way long error message telling me that it cannot found fooLib.dll (when it should be searching barLib.dll) and told me that linking log was deactivated, and the way to activate it. So I did, but the only new information returned is the list of paths in which it's searching for the wrong file. Any idea how can I fix this without having to rebuild the solution from scratch?

Was it helpful?

Solution

Take a look in the project file - make sure nothing odd is going on there for different configurations.

Build the solution from "ultra-clean" - manually get rid of all the bin/obj directories.

When you say there's a problem "linking" the Debug version, do you mean it fails at execution time rather than compile-time?

OTHER TIPS

It seems that changing the build target from 'Any CPU' to 'x86' or 'x64', it works. Changing the Release Build (which was set to x86) to 'Any CPU' it fails with same error

But it was working as it was before the library's name change. Seems quite frightening...

Edit: Now it's getting really funny. If I set the project config to "Release|Any CPU" with register for COM interop unchecked, it compiles fine. Then I can go to debug, mark the COM checkbox, and it still works fine. Then I return to release, with the interop option checked, and it fails. I return to debug, and it fails, too.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top