by Oren Ellenbogen | .NET, .NET|ASP.NET, WebServices

Changing the Output Path in your Web Applications is a bad idea

<rational thinking>


Let’s assume we have a WebSite(the same issue applied to WebService btw) named WebApplication1. Now, we want to put its(the website’s) output files into some other directory (!= “bin” directory) for development reasons (working as part of a team with some sophisticated Source Safe). What’s the first thing you (and me) do? we use our “rational” programmer nature and Right-Click on the project->Properties->Build Tab->and changing the Output path to whatever we need.


OutputPath.gif


(Instead of “bin\” we can write here “..\..\infrastructure” for example)



We then build the all thing and surprise surprise, the new output path contains all the dlls as expected. Awesome!
Satisfied with the greatness of Visual Studio .Net 2005, we now want to Publish the WebSite so we(or the QA) can play with it. “Think as a developer, think as a developer” I say to myself and Right-Click the WebSite project->Publish… A few really easy “decisions” and ~10 seconds later, VS.NET tells(it speaks to me, I swear) me that my site was published successfully.


Happy as a little girl with a new puppy, I enter my site: http://localhost/webapp1/Default.aspx and Oops!


OutputPathUnableToFindClass.gif


The page can’t find its “code behind”(The class that it inherits from)! What the hack is going on here!?


Well, it turns out that the Publish process is not as smart as you may think it should be. Changing our Output path to another directory (!= “bin”) caused this all mess as the Publish process simply copy all the files from the bin directory into the new(Published) bin directory. No questions asked. The Publish algorithm do not check if you actually compile your dlls into another directory via Output path and taking it into account.


</rational thinking>


<effective thinking>


Fortunately for us, the solution is pretty easy: define your Output path into the original location (“bin\”) and use the Build Events(post-build in this scenario) in order to copy the output files into your “infrastructure”(or whatever) directory like this:


OutputPathUsePostBuild.gif


(The command: xcopy /Y /S ${TargetDir}*.* ..\..\Infrastructure)


</effective thinking>



May it save you the 15 minutes it took me and my teammate Hagay to solve this one.

 

Oren Ellenbogen

 

2 thoughts on “Changing the Output Path in your Web Applications is a bad idea”

  1. If your Build process works fine, and your Publish process doesn’t, I’d think that you’ll fix the Publish, not the Build.

    I do not use the Publish action altogether. Instead, I have scripts that do aspnet_compiler magic (and aspnet_merge) on the web application. You could simply include the ..\..Infra.. directory in the aspnet_compiler’s parameters.

  2. I agree that there should be a fix in the Publish, but I’m not sure that writing my own script is a good idea or cost effective. We are working with Web Application Project which do not use the aspnet_compiler so I would rather use MS tools in order to Build and Publish and my own custom script\MSBuild only for environment deployment.

Comments are closed.