views:

195

answers:

3

I have an ASMX Web Service that has its code entirely in a code-behind file, so that the entire contents of the .asmx file is:

<%@ WebService Language="C#" CodeBehind="~/App_Code/AddressValidation.cs" Class="AddressValidation" %>

On my test machine (Windows XP with IIS 5), I set up a virtual directory just for this ASP.NET 2.0 solution and everything works great. All my code is separated nicely and it just works.

However, when we deployed this solution to our Windows Server 2003 development environment, we noticed that the code only compiled when all of the code was dropped directly into the .asmx file, meaning that the solution didn't work with code-behind. We can't figure out why this is happening.

One thing that's different about our setup in our development environment is that instead of creating a separate virual directory just for this solution, we dropped it into an existing directory that runs a classic ASP application. So here we have a folder with an ASP.NET 2.0 application within a directory that contains a classic ASP application. Granted, everything in the ASP.NET 2.0 application works if all of the code is within the .asmx file and not in code-behind, but we'd really like to know why it's not recognizing the code-behind files and compiling it correctly.

A: 

You may have a difference between a Web Site "project" and a Web Application project. In a web site project, all of the files are compiled dynamically. In a web application project, you have to build the code first.

You should be using Web Application Projects for web services. Use File->New Project and choose the appropriate project type. Then build your project and finally use the Publish command to deploy to IIS.

John Saunders
@John I created the asmx project originally by first creating a virtual directory under IIS 5 on Windows XP. Then I went to VS 2005 and selected "Add New Website." From there I selected "AJAX Enabled Website". I then dropped the files from my box onto our development server. What could be different between the two to cause the issue?
Ben McCormack
@Ben: the two are totally different. Web sites are not projects. They do not actually build, for instance. They should not be used for web services - they cause much too much trouble. The issue you're having is that you never built your code, because web sites do not build.
John Saunders
@John: Web sites do build they just build on the destination server in a highly fragmented on demand manner.
AnthonyWJones
@Anthony: sorry, but the term "build" is better defined by what "build" means for every other project type - compile and link to an assembly. Web Site "projects" are so much an exception that I do not believe the same terms should be used to describe them. It corrupts the meaning of the term "build" to say that web sites "build". It corrupts the meaning of the word "project" to call them projects.
John Saunders
@John: I don't think its "better" its just narrow. Ultimately ASMX, ASPX etc do compile and link to an assembly on the destination server. We might like to pidgeon hole everything in to small highly specific terms but real life just isn't like that. Context is important. In this context "Website projects build on the destination server" makes perfect sense to me. What would you substitute into that phrase to make it "better"?
AnthonyWJones
@Anthony: I'd say, "Components of Web Site "projects" (individual pages, controls, handlers and ASMX web service files) are compiled at runtime, on the destination server. Therefore, each server in a server farm will be running different executables. There may be other unexpected affects stemming from the fact that, unlike all actual projects in Visual Studio, these "projects" are deployed in an uncompiled state".
John Saunders
@Anthony: I them might go on to remind the reader that Web Site "projects" were a stupid mistake on the part of Microsoft, and that they largely corrected the mistake in Visual Studio 2005 SP1, which came hard on the heels of the RTM, largely as a result of the outrage in the developer community over their idiocy. These "projects" were thought by certain people at Microsoft to be the way we all wanted to do web development, and they got that flat wrong.
John Saunders
A: 

I'm not sure I can explain why its not working however placing Code behind files in the App_Code folder seems like a dodgy thing to do. App_Code files will get compiled into a single assembly. Hence the code in your code behind will end up in this assembly even though its not intended to.

I would first create a AddressValidation.asmx.cs file in the same folder as the .asmx folder and tweak the CodeBehind attribute of the asmx file. Remove the file from the App_Code folder and place its contents in the new .asmx.cs file.

Check this works in the XP environment then move it the destination server.

AnthonyWJones
A: 

As others have mentioned, it's probably a better practice to build the solution as a "Web Application Project." This way your code will be precompiled to run on the server.

The following solution worked for us: In IIS, navigate to the folder in your website that contains your solution. Right click on the folder and choose Properties. In the Directory tab, under Application Settings, click Create to make the folder into an application (I believe this can also be accomplished simply by making the folder a Virtual Directory). Then, make sure your ASP.NET configuration is set to use ASP.NET Version 2.0. The problem we had was that the larger directory was running under ASP.NET 1.0, so we had to go through this step to have this directory use ASP.NET 2.0.

Ben McCormack