I searched the wiki, but didn’t turn up anything. I happened to bump into the case where two assemblies needed by my project both had the same class with the same namespace. How does one resolve that? I get errors like:
C:\Program Files (x86)\MSBuild\RemObjects Software\Oxygene\RemObjects.Oxygene.targets(167,5): error CE73: Type “Guardian.EditObservation.DataContracts.Category” used is defined in multiple assemblies (ClientSettingsServiceInterface, ViewModels)
I don’t believe you can work around that — the .NET runtime won’t allow it, even if you make one version private. The only fix is to change the namespace sir the type names, as far as i can see.
I think I have the same thing again. I have an assembly, GuardianAppSettings. It contains an enumeration: DuplicatePersonKeyType. GuardianAppSettings assembly is used by two services, EOService and SettingsService.
When I generate the proxy client for those services, they both then generate code for the enumeration.
Now I have an application that uses both services. So it includes assemblies that were compiled with the generated proxies. Now the compiler for this application is complaining about multiple definitions.
In one service, the generated code is:
type
[System.CodeDom.Compiler.GeneratedCodeAttribute('System.Runtime.Serialization', '4.0.0.0')]
[System.Runtime.Serialization.DataContractAttribute(Name := 'DuplicatePersonKeyType', &Namespace := 'http://schemas.datacontract.org/2004/07/Guardian.Settings.Enums')]
Guardian.Settings.Enums.DuplicatePersonKeyType = public enum ([System.Runtime.Serialization.EnumMemberAttribute]
FirstnameAndLastname = 0, [System.Runtime.Serialization.EnumMemberAttribute]
Username = 1);
The other contains this:
type
[System.CodeDom.Compiler.GeneratedCodeAttribute('System.Runtime.Serialization', '4.0.0.0')]
[System.Runtime.Serialization.DataContractAttribute(Name := 'DuplicatePersonKeyType', &Namespace := 'http://schemas.datacontract.org/2004/07/Guardian.Settings.Enums')]
Guardian.Settings.Enums.DuplicatePersonKeyType = public enum ([System.Runtime.Serialization.EnumMemberAttribute]
FirstnameAndLastname = 0, [System.Runtime.Serialization.EnumMemberAttribute]
Username = 1);
They actually are from the same source code in the same namespace. Is there a way to get around this multiple definition problem?
IMHO the proper fix would be to move the common code into a shared assembly that both of the other assemues use. That, or of course to put the same code into different namespaces.
Not sure how I would do your first suggestion. The conflict is coming because of the generated classes. So there will always be two of them. If I make yet another client assembly to be used as the “common” one, it would have to include the two service references. And that again would cause the conflict.
I’m trying to go down the path of putting the same conflicting enum code in two namespaces. I’m afraid when I do that to resolve the one that is reported in conflict, the compiler will just reveal the NEXT one that is in conflict.
This is becoming a huge problem for me. I’m working on a LARGE project that already had an extremely tight schedule (not set by us). Everything has to be done by Sept 17th. I THOUGHT I only had a couple of things left to do and now I’m stuck with a complicated refactoring IF that works.
Create a third library project, LibraryGen. Put the generated classes into that project, instead of into LibraryA and LibraryB. Make LibrayA and LibraryB both reference LibraryGen. Now they can all use the same version of those classes, rather than each having their own copy.
That’s the 'proper" way to do this in .NET.
I don’t think that will work, but I’ll go try now…
Nope, that doesn’t work. Remember, I have two services. So there are two generated files.
I have Services:
EOServiceLibrary
EOSettingsServiceLibrary
They both use a common assembly:
GuardianDatabaseHelper
So both service libraries contain the enum from GuardianDatabaseHelper.
The generated classes are for the client. I use slSvcUtil to generate them from the services.
So if I generate the two generated files together into one client library project as you suggested, both generated files contain the same enum in the same namespace.
And the compiler doesn’t like it.
It looks like your second suggestion (same code in two namespaces) MIGHT work. I had to do a little tricky typecasting in one routine in one of the services, that was using the same enum from both namespaces, but I think I made the compiler happy. A little more to test to be sure.
One part that surprises me: I only had that ONE duplicate. The enum. I’m not sure what else I expected to be common to both services. I think it has something to do with the fact that that enum had to be output into the generated files in order to serialize it. Probably the other types that will be serialized are just string and Boolean and int and the basic types. I think that enum may be the only enumerated type that was used by both services. I’ll have to check that.
Still with all the code in both services, I’m surprised there was only ONE duplicate for it to complain about.
time passes…
Okay, THAT enum was the only enum declared in common GuardianDatabaseHelper that was used by both services in the datacontracts. So it was the only one that was generated into both client files. I guess that makes sense now and I am lucky that the two services had so little overlap of the enumerated types.
Sorry, i don’t understand what the problem is.
Yeah, I thought about trying to make a test solution to demonstrate, but I’m REALLY pressed for time.
So the enum is in GuardianDatabaseHelper.
GuardianDatabaseHelper is used by EOServiceLibrary AND EOSettingsServiceLibrary.
All that is on the server side of the project.
Both service libraries contain classes that have DataContracts that include a variable of the enum type.
When the services are used to generate the code to use from the client for the WCF calls, both generated files contain the enum.
The compiler says both files contain the same enum in the same namespace that came from the single GuardianDatabaseHelper and so the compile fails.
So if you put both the generated files into a client project, it won’t compile.
So your suggestion of putting both of the generated files into a single library won’t work. That is the SOURCE of the compiler error.
Hope that made things clearer. I’m just saying your first suggestion can’t be done (or else I didn’t understand what you meant)
Right. Hence my suggestion to add (one copy, not both, of course) of the shared code into a shared library. That way you have one copy of that code, build into LibraryGen, and both LibraryA and LibraryB can then use it from there. I’m not sure if i am missing something here?
If the two enervated files have the same code, of course you’d only put them into the shared project once. Don’t put both copies in.
Yeah, you’re not getting it. I’ll try to stop back here again to make sure there is no other solution than to hack the same code twice in two namespaces so that they don’t conflict. But for now, I can move on with this time critical project.
Thanks for trying to understand.
Apparently, sorry.