How does ASP.NET find code-behind DLLs

[Chris Durkin]

I've got an ASP.NET website on my local box, set to compile to
bin\Debug and bin\Release in debug and release modes. Both directories
are populated with dlls, as the solution has been compiled in both
modes. When I browse to the local website, it works, but which set of
dlls is it using? What happens when I deploy to Test and there is only
a \bin\ directory, no \Debug or \Release?

I assume .NET has some path-searching rules that govern where it looks
for a website's binaries, but I've been unable to find these on the
web. Does anyone know of a good reference?

Thanks,
Chris

 

[Kevin Spencer]

The Debug and Release directories are used by the Visual Studio IDE, to
place the respective assemblies from different builds in there. In your app,
you only need ONE: bin.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.

 

[Chris Durkin]

Correction - this actually doesn't work. After I deleting the contents
of the "temporary ASP.NET files" directory, the site no longer loads.

ASP.NET appears to be hard-coded to look for the dlls in the temporary
ASP.NET files folder and the approot\bin directory, and nowhere else.
There doesn't seem to be any support for different Debug and Release
dirs.

 

[Chris Durkin]

Right, but when you build from within the IDE, or choose Debug...Start,
it only puts the dlls in Debug or Release, it doesn't copy them to the
website's bin directory. So the site doesn't run, and you get a bunch
of misleading errors. Very buggy behavior on visual studio's part.

steps to reproduce:

Create a blank asp.net web project
Put some code in the default page
Change build locations to bin\Debug and bin\Release
Build the website in both modes
Try to browse to the website

Result - something similar to this:

Parser Error Message: Could not load type 'WebApplication2.Global'.


This happens because vstudio doesn't copy the dlls to \bin, and ASP.NET
doesn't look any deeper than \bin. The correct behavior, in my opinion,
is for vstudio to copy the most recently built dlls to the \bin folder
as part of the build process. Another nice feature would be if ASP.NET
followed some kind of search pattern down through bin to any subfolders
it found.

Hopefully this is fixed in Whidbey. (I'm using 2003). Can anybody test
2005 and see if this bug exists there?

 

[William F. Robertson, Jr.]

When you build an asp.net application in release mode, it places the release
built assembly into the /bin directory.

When you build an asp.net application in debug mode, it places the debug
built assembly into the /bin directory.

If you assembly is large enough, you will see a size difference in the bin
directly whether you built from debug or release.

bill

 

[Chris Durkin]

You're correct, if the default settings are used. But in the project
properties, you can change the build directory for each "mode". For
example, bin\Debug in Debug mode and bin\Release in release mode. If
you do that, the website won't run, and you get no clear indication of
why. See my reply to Kevin Spencer in this thread for steps to
reproduce.

 

[Kevin Spencer]

I'm not sure which reply you posted in reply to my message, as you didn't
quote it. However, I can assure you that what I told you was true. I don't
use Visual Studio for deployment; it's really too simple to need it. I just
copy over the template files and the DLLs from my development machine to the
deployment server. When I do so, I copy whichever version of the DLLs I want
to deploy to the \bin folder of the app. Works perfectly every time.

Gotta love that XCopy deployment!

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.

 

[William F. Robertson, Jr.]

Kevin,

I was thinking he could just change his private probing path and it would
work. Is there a limitation to this for asp.net applications?

<runtime>
<assemblyBinding>
<probing privatePath="bin/Debug" />
</assemblyBinding>
</runtime>

bill

 

[William F. Robertson, Jr.]

Why would you want to change the default build locations?

I was thinking you could use

<runtime>
<assemblyBinding>
<probing privatePath="bin/Debug" />
</assemblyBinding>
</runtime>

to change the runtime assembly location, but for some reason I can't get it
to work.

I see your steps to reproduce, but it is not a bug. ASP.NET documentation
clearly states the assemblies should be located in the \bin directory under
the Application root. You can't take the wheels of the car and then be
upset at Ford that your car doesn't drive anymore.

It does give you an indication of why. It says it can't load type:
WebApplication2.Global. That means the type loader can't find the assembly
that contains the WebApplication2.Global type. Meaning it can't find the
assembly, because you have taken them from the directory they should be.

Again, what reason do you have for changing the debug/release build
locations?

bill

 

[Kevin Spencer]

Hi William,

Yes, he could, but I don't see how it would help. Why would he want 2 sets
of code (Debug and Release) for 1 app? And if he only needs one, why use a
non-default location?

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.

 

[Chris Durkin]

Looks like a workaround.. I assume these settings are in
machine.config?

 

[William F. Robertson, Jr.]

That is the main question I posed to him, why...

But I tried setting the privatePath on my machine and it never worked. I
renamed "bin" to "bin1" and added the privatePath="bin1". I only received
"could not load type" errors. I tried looking around and never came across
if it was even possible in an asp.net application. I did see plenty of
examples of windows forms applications, and it worked on my machine using
windows forms and console applications.

Thanks,

bill

 

[William F. Robertson, Jr.]

These go in the .config file for your application, but I couldn't get it to
work on my machine for a web application, only a forms application or a
console app. But there really is no good reason for wanting to change this
default behavior of the IDE.

bill

 

[Chris Durkin]

Not deployment, development. I use XCopy for deployment too.

What I'm talking about here is the Debug...Start New Instance command
in visual studio, used during development on the local machine. If you
change the output directories for the binaries, that command crashes
and the error doesn't explain why. The docs don't either.

If changing the output directory for a website breaks the website, why
is it allowed?
Here's a quote from the Help for the Project properties...Configuration
Properties...Output Path setting:

Output path
Specifies the directory in which output generated by the project should
be placed. For client-based projects, this can be any valid file or
Universal Naming Convention (UNC) path. **For Web-based projects, any
relative path within the project folder is allowed**. By default, this
is set to the Bin directory in the current project directory structure.
To access this property programmatically, see OutputPath Property.

Bug, missing feature, bad documentation.. whatever you want to call it,
this should be fixed in the next version of Studio.

 

[Chris Durkin]

Again, what reason do you have for changing the

debug/release build locations?

I'd like to use the Debug versions in dev and test, and the release
versions in preprod and prod. I have an xcopy script that copies
everything out to the staging point. This gets run whenever a version
is ready for test. The server images for test, preprod and prod are all
created at the same time. What I want to be able to do is:

Compile in Debug mode
Compile in Release mode
XCopy everything to staging

This works fine for all the other projects in the solution, which have
Debug and Release folders. It won't work the same way for the web
sites. Based on the problem behavior described in this thread, I have
to pick either Debug or Release for the web sites. Plus, the whole
process becomes more fragile because it depends on which order the code
gets compiled in.. Debug..Release or Release..Debug. Which makes my
deployment instructions for other developers more complicated...

I can work around the problem, but I'm still curious if it's fixed in
2005. If not, maybe I'll submit it to MS.

 

[William F. Robertson, Jr.]

Are they other projects referenced by your web application? If they are,
you can set the reference Copy Local to true. This will copy the assembly
into the bin directory, then all the release builds are in one location, and
the debug builds are in one location.

We deploy here similiarly to you.

Compile in Debug mode
Run debug xcopy script
--repeat until bugs are completely removed.

Compile in Release mode
Run release xcopy script.

By placing all the assemblies in the defaulted "bin" directory, you don't
have to worry about having difference build versions of assemblies floating
around all over your deployment. When you build in release mode, every
single release mode dll will be in one location.

On a side note, do you allow all your developers to push to
release/production?

bill

 

[Scott Allen]

I'd like to use the Debug versions in dev and test, and the release
versions in preprod and prod. I have an xcopy script that copies
everything out to the staging point. This gets run whenever a version
is ready for test. The server images for test, preprod and prod are all
created at the same time. What I want to be able to do is:

What's missing with a release mode build that you can't use release
builds in test?

 

[Chris Durkin]

The debug versions have .PDBs and show line numbers in the stack trace
if an exception occurs.

 

[Chris Durkin]

Are they other projects referenced by your web application?

If they are, you can set the reference Copy Local to true.
This will copy the assembly into the bin directory, then all the
release builds are in one location, and the debug builds are
in one location.

We are using the copy local feature, which helps.. The solution is more
complex than just one web site.. a couple of websites, some windows
services, a Forms EXE, all referencing a bunch of common dlls.
Different "things" get deployed to different servers. What I want is a
Debug and Release copy of each "thing", which would include it and all
the dlls it references.

My workaround for the websites will be something like this:

use \bin\ for Debug mode
use \bin\Release for release mode
document the fact that the websites always use Debug code in dev

That way I can preserve the current methdology of running the deploy
scripts only once for each release candidate.

On a side note, do you allow all your developers to push to
release/production?

Yes, we can all push code up. No buildmaster. I don't allow or
disallow, I'm just a lowly contractor

 

[Scott Allen]

You can have PDBs and stack traces with line numbers in release builds
too:

Project -> Properties -> Configuration Properties -> Build -> Generate
Debugging Information.

http://odetocode.com/Blogs/scott/archive/2005/01/24/963.aspx

HTH,