Every once in a while when I'm doing some WebServices I get to the point where I need to use the same class on both the server and a client. There are voices that say that you should not do it and that is against the idea of web services. In my opinion though it is not so! What I want to get is to use the same Data Transfer Object on both ends of the line. The reason for this is that I already have it defined in one place and there is no reason to define it once again IF I can reuse the implementation. Other clients - those that do not have the access to my classes may still use the definition from the WSDL language to generate their own classes - nothing is lost here.
The really good article explaining how and what you can do to make your life easier can be found here. A nice read and good to know stuff - really.
Now I wanted to give it a try. Unfortunatelly I was unable to deploy the solution to the PrivateAssemblies folder of the devenv.exe. I got an error when I tried add a web reference. Installing assemblies in the GAC helped.
Next step was to try to debug this stuff. This is actually pretty easy once you know the trick which is to use 2 instances of Visual Studio. One VS with the sources of the SchemaImporterExtension code and the other one which you will use to add web references. In the first one go to Debug->Attach To Process... menu item. Select Devenv.exe from the list (there should be one if you have only 2 visual studios) and attach to it. Now in the second Visual Studio you can add a web reference and... if you have a breakpoint somewhere in the first VS it should break the execution there. In the example file from the above mentioned site put a breakpoint on the line where you have: "public override string ImportSchemaType" and it should work .
You can debug almost anything in such a way - by attaching to the projects. What is not so obvious is that you can also attach to the Visual Studio itself. All you need is a second instance . This was pointed to me by some of the readers of my blog, when there was an issue of debugging ASP.NET BuildProviders.