Problem after renaming .NET library

views:

204

answers:

+1 Q:

Problem after renaming .NET library

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?

+2 A:

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?

Jon Skeet 2009-07-27 09:48:27

Nope, it doesn't compile. I have an spanish error message but I'll try to translate it:Error 1 The assembly [project.dll] couldn't convert itself to a type library. The type library exporter detected an error when processing [project.class] Error: The type library exporter couldn't load type [project.class] (error: FileNotFoundException: File or assembly could not be loaded 'fooLib, ...'or one of its dependencies. The system could not find the specified file. Then it said something about the linker logging. I realize now that it must have something to do with COM Interop.

Jaime Pardos 2009-07-27 09:54:44

BTW, project.class (name ommitted for brevity) is a class which inherits from a fooLib class.

Jaime Pardos 2009-07-27 09:58:08

Ah, I didn't realise it was a COM API. That probably changes things. Have you rebuild the derived class?

Jon Skeet 2009-07-27 10:19:23

What do you mean with 'rebuild the derived class'? I have rebuilt the whole project and AFAIK I can't build a single class.

Jaime Pardos 2009-07-27 10:39:37

Which project does "project.class" live in? The one you're trying to rebuild, or a different one? You need to rebuild *that* first, as it declares a dependency to the old library.

Jon Skeet 2009-07-27 11:00:34

It lives in the same project I'm trying to rebuild (I'm referring to it as 'project', therefore 'project.class'. I'm aware it's not very clear, sorry). It derives directly from a class in the renamed library (fooLib, which now is barLib, and it has been rebuild like a zillion times). So it shouldn't be a problem, but it's searching it in the fooLib assembly instead. The fooLib Namespace hasn't changed, only the assembly name and its metadata, and the derived class doesn't have COM visibility, in case it matters.

Jaime Pardos 2009-07-27 11:13:07

Still unsolved, or perhaps I should say sorta solved with my own response (changing target to 'x86'), but I feel you deserve it.Thank you a lot.

Jaime Pardos 2009-07-29 20:27:19

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.

Jaime Pardos 2009-07-27 10:05:39

ansaurus

tags:

views:

answers:

Problem after renaming .NET library

related questions