views:

247

answers:

6

We have multiple projects in our system that want to share the same asmx webservice. Does anybody have any advice / best practices on how to do this.

The problem is that the webservices are constantly changing so i can't just add a webreference to production. Also that is dangerous because when doing development I want it pointing to my local machine. Should I just add my web references to localhost?

Also should I have dedicated webservices projects as opposed to asmx files scattered in multiple projects?

Thanks

A: 

Not sure i understand your question. If you publish a web service in a production environment, all you have to do is add a web reference to it in each app that requires it. The whole premise of using a web service is that you make it available - if you're using it only in your development environment, perhaps you want to consider using it as a standard C# dll that you distribute or leave in the GAC?

NoCarrier
+2  A: 

One of the main points of web services is that they are reusable, so you are right to use it wherever you can.

Your question is a bit unclear on exactly what the problem is, but you should be able to consume your web service from any application that has network access to it.

-Edit-

It is generally considered best practice to have dedicated web service projects. You can have multiple web service projects, and how you break these up is up to you and your business/technical requirements.

This should address your main issue. You have a local web service project, as well as local projects that consume it. You deploy either, or both, of these projects to production as needed.

AaronS
Could you point me to something that recommends having separate web service projects
Ryu
This is a standard setup in any N-Tier architecture, where you want to separate your data from your business and presentation layers. If you Google N-tier and web service you will find a lot of examples.
AaronS
A: 

All you would need is to create a good process ownership, and documentation for usage of these web services across multiple teams or divisions. In SOA world, you will have to create service registry which can make it easy to view the services available and reuse them if needed.

CodeToGlory
A: 

When doing development, just point the web reference to your local machine and run the web service locally. I don't really see any problem with that.

ionut bizau
will it still work when i move it to production?
Ryu
In production you have to set the correct URL for it to work. Just read the URL from a configuration file and set it at runtime.
ionut bizau
A: 

If I understand ur quesstion correctly you would like to have a development webservice and a production webserive. The production instance is that last debugged/checked build. The debug instance is the current build that you are working on.

My recommended method to acheive this would be to have a dev subdomain so you can have both webservices available e.g. http://www.myapp.com/Service.asmx and http://dev.myapp.com/Service.asmx. Both subdomains would be a different site in IIS. In you code you would bind the web-references to the dev subdomain as this domain would be the one that you would use to update the web-references (if changing the parameters). You would then use a '#if not debug' to change the web service object url to the www site for production (release) code.

This way you would build against the debug service until you were happy with it. At which point you can update your software (if parameters have changed) and upload the new dll to the release site.

I would keep webservices in a seperate project to keep the deployed assembly simple.

Stevo3000
A: 

You should create a class library project and define your webservice there. Refer that project into your web application, Then in the webservice asmx file you point it to the webservice class.

this. __curious_geek