views:

617

answers:

6

We've implemented some SOAP client code on our ASP.NET site that calls up a remote service. Implementation was basically done by using Visual Studio "Add Web Reference" wizard, adding proper 'using remote.service.namespace' to the code and calling the service.

Code works perfect locally(from Visual Studio), but fails on production web server with missing assembly reference error:

CS0246: The type or namespace name 'remote.service' could not be found (are you missing a using directive or an assembly reference?)

I have a sneaky suspicion that I am not deploying everything properly, maybe some one can point out what is that I am missing there?

Thanks!

Additional info:

Project is a Website.

ASP.NET version 2.0 installed and used as a target on both dev box and production server.

Proxy file generated by WSDL.exe is deployed into the root folder of the website, same folder where the page resides. Global namespace(default) was used for proxy class generation.

A: 

Did you copy the App_WebReferences folder and all its contents to the server?

John Sheehan
yep... it has folders(remote/service/..) and 2 files something.discomap and something.wsdl
xelurg
In the IIS properties of the site on the remote server, is the ASP.NET version set to 2.0?
John Sheehan
Yes, it is set to ASP.NET 2.0
xelurg
A: 

Does other parts of your ASP.NET site work?

Does your site target 3.5 and possibly 3.5 is not installed on the production server?

Nathan Palmer
A: 

Is this a Web Site, or a Web Application Project? I bet it's a Web Site.

John Saunders
+1  A: 

You mentioned the proxy dll is placed on "the root folder of the web site, where the page resides".

You should place the dll inside the "bin" folder. If the folder is not there create it.

Saravana Kumar
+2  A: 

If this is a WebSite project, then the proxy file should reside inside the App_Code folder

Ramesh
+1  A: 

The Web Service client stack in .NET does runtime generation of the proxy client (from the annotations in the class generated by wsdl.exe/svcutil.exe). this generated file typically ends up in one of your servers temp directories (there's one under the main windows tree somewhere). The problem is that the ASP.NET user account doesn't have rights to write to this particular temp directory, but doesn't notice at the time it writes the file, so you end up with an error with it trying to load the generated file back. You can end up in the situation depending on the exact installation order on your server. Once you find the right directory you can simply fix the NTFS perms on the directory to solve the problem.

superfell