5

This question is related to a previous, unanswered question of mine, as I'm still solving the same problem; this is about a different approach though.

I'm currently consuming a third-party SOAP web service in a C# .NET project. Unfortunately, the generated client proxy classes and class members have names that are inconsistent with my current conventions.

Until advised otherwise, I'm left to presume that Svcutil doesn't support aliasing (though, it certainly seem it would be most easily accomplished at that level)

I'm now considering wrapping the web service consumption into it's own project, thus assembly, and simply referencing that from other projects. I'm considering this given that it's possible to add some (presumably, assembly-level) declarations to expose the public types with different names than those defined within the assembly.

My question is; is it possible to expose different type/member names than those defined in the assembly, essentially aliasing them?

For example, given a magical assembly attribute:

[assembly: AssemblyTypeAlias(
    Type = typeof(Foo.Bar.qux),
    Name = "Qux"
)]

Thus, projects referencing this assembly would access Foo.Bar.qux as Foo.Bar.Qux.

Of course, a similar class-level attribute would be great too, seeing as the generated proxies are partial:

namespace Foo.Bar
{
    [Alias("Qux")]
    public partial class qux 
    {
    }
}

Yielding the same effect.

While I've only covered type names with my theoretical examples, a solution that allows the aliasing of member names would be spectacular.

Edit: I've said "alias", where the more applicable term would be "rename", in order to hide the original name; preferably the latter, but the former will work.

Community
  • 1
  • 1
Dan Lugg
  • 20,192
  • 19
  • 110
  • 174
  • 1
    You're asking if such a thing already exists? Or are you asking how one might go about creating such an attribute? Also, is using an attribute a critical part of the solution you are looking for, because, for example, you could always create a Qux class that inherits from qux, and then reflect the members by using properties with new names that pass values called from the old names. – Mark Bailey Mar 14 '14 at 14:48
  • @MarkBailey I'm asking if such a thing already exists. An attribute is not at all critical, per se, I was just hoping for something with the least LOC impact. Inheritance *would* work, however the original (poorly named) type is still exposed publicly, along with the members. Otherwise, yes, I'd just extend types and forward method calls. – Dan Lugg Mar 14 '14 at 14:54
  • I fear I might be venturing toward an X/Y problem situation; the linked question provides an initial proposal for how I'd have liked to solve the problem. Aliasing the names *somewhere*, without borking up the inheritance hierarchy would be excellent; whether that happens at the service consumption level, the assembly level, or elsewhere. Have a look at the original question @MarkBailey, if you have any insight. – Dan Lugg Mar 14 '14 at 14:57
  • I see, and I read the other post now too. I would expect, however, that even if such an Aliasing attribute or function does exist, it would probably still leave visible the old names that you don't want, so that you have your original and your alias. I suppose I do have some comments and an idea that I will post to the other question, since it addresses that more general inquery. – Mark Bailey Mar 14 '14 at 15:01
  • @MarkBailey Great! I look forward to your input. Attacking it at the service consumption level would be far better; I would assume there must be a way to perform a transformation on the WSDL, yielding different class names which map back to the appropriate service types/operations. *This* approach, assembly-level aliasing, is far more "extreme", and I'd rather not venture down this path for this problem (*though, knowing it's possible or not never hurts*) – Dan Lugg Mar 14 '14 at 15:04
  • After looking into this, the answer I posted below is significantly simpler and easier than what I had been considering. I have tested it now too, and it works the way I had hoped. I hope it works for your situation too. – Mark Bailey Mar 14 '14 at 17:34
  • let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/49772/discussion-between-dan-lugg-and-mark-bailey) – Dan Lugg Mar 14 '14 at 17:34

1 Answers1

1

I've moved this answer suggesting use of the XmlType Attribute in the Reference to the Service to your other question, since this one is really asking about aliasing assemblies, whether they come from a service or not.

Community
  • 1
  • 1
Mark Bailey
  • 1,091
  • 10
  • 25