Virtual Directory, Paths, Local and Deployed Problem

[nick]

I have a problem and I've been using a cheezy work around and was
wondering if anyone else out there has a better solution.

The problem:

Let's say I have a web application appA. Locally, I set it up as
C:\domains\appA. Locally, my IIS root points to C:\domains. I don't
point it to C:\domains\appA since if I have an appB under C:\domains I
wouldn't be able to get to it. So to access it via my browser I go to
localhost/appA.

When deployed, the IIS website's root points not to domains, but one
directory deeper to appA. This is because I don't want to type
www.appA.com/appA, but just www.appA.com.

So, the above is the typical way of setting up web projects with
ASP.NET when you've got a local version and a final version on a
server somewhere.

The problem is with virual paths in the browser. If I want to point to
an image locally which is in C:\domains\appA\images\myImage.gif in the
client side code I write "/appA/images/myImage.gif". Obviously this
doesn't work when deployed since the path from the root is different.
Rather, the correct path is "/images/myImage.gif".

The work around I've used is locally to switch the root of my website
everytime I want to work on a different project so that the structure
of the site mirrors that of the site when deployed. This is obviously
a big pain in the butt.

The problem would go away if M$ allowed more than one website in IIS
in non-server versions of their OS, but, well, they don't. That's one
of the joys I've had doing PHP development on Apache - no screwing
around with in IIS every time I want to work on a different site
locally.

So, does anyone have better solutions that the one I've been using?

I realize I could dynamically generate the paths server side, but,
well, that's a pretty cheezy solution.

Oh yeah, and please remember I'm talking about _client_ side paths. I
know already about ~/directoryName on the server.

 

[Curt_C [MVP]]

Look at the "~/"
The ~ translates to "root of this site" so it doesn't matter.
The other thing is use relative pathing. Lots of "../dir/page.ext"

 

[Ken Dopierala Jr.]

Hi,

What kind of project are you making that you are pointing the browser to
local resources in a specific directory? Do you actually go to each one of
your client machines and create this directory structure? If that is the
case, you might want to just add to that workload. Create a text file that
you give to the client and copy it to their machine while you are creating
all these directories. Have that text file hold the correct paths for each
client and then use those. Good luck! Ken.

 

[nick]

Like I said,

"please remember I'm talking about _client_ side paths. I
know already about ~/directoryName on the server."

I'm not talking server side. I'm talking client side. I want to set my
image paths _on the client_ to "/images/mygif.gif". The ~ doesn't work
on the client. The fact that the root of the site is in different
places on the dev machine compared to the production machine makes
this problem.

Moreover, IMHO ../ is a crappy solution. If I have images in user
controls which can be included on pages in directories of different
depths the ../ won't work since the path will be different depending
on the page the control is included in.

Nick

 

[nick]

I think you misunderstood.

I'm not pointing the browser to folders on the client machines, but on
the server. Just normal referencing of an "image" dir, for example.
The problem is that on my development machine on which IIS limits you
to one website all my sites have the url

localhost/site1
localhost/site2
localhost/site3

on the production machine they are

www.site1.com
www.site2.com
www.site3.com

As you can see from this, the root of the site is at a different depth
on each of the machines. So, in order to reference an image in an
images directory in the root the path would be:

Locally: /site1/images/mygif.gif
In production: /images/mygif.gif

So, if I code for one, it'll break on the other.

I've searched the groups and found a few people mentioning this
problem, but I'm surprised that it's not a bigger deal.

Of course, if M$ would let us have more than one site on IIS on XP or
W2K things would be peachy. As it is, developers are forced to develop
their sites locally with a different structure than that in
production, something which is a severe drawback IMHO.

 

[Ken Dopierala Jr.]

Hi,

I think you are looking at the situation totally wrong:

Locally: /site1/images/mygif.gif
In production: /images/mygif.gif

If you are looking to get to the /images folder from the root. Let's say
localhost/site, you would use the exact same path that you have for your In
production entry. Because your web app is running from the site1 virtual
directory that is your root. /site1 really has nothing to do with anything,
it is your root directory and should never be referenced. Basically it
comes down to this. In the example you gave that I quoted above you are
comparing apples to oranges. They do not match and don't equal each other.
There are two ways you can write the quoted lines above to be equal:

Way 1 (not a good way of doing it):
Locally: /site1/images/mygif.gif
In production: http://www.site1.com/images/mygif.gif

Way 2 (this is the correct way)
Locally: /images/mygif.gif
In production: /images/mygif.gif

As you can see they are identical, there is no need to reference /site1 at
all. To test this out put a test image in your Default.aspx file and place
the image in your /images folder. Reference the image with an image tag and
set the source to "/images/mygif.gif". Run it locally from your /site1,
your /bin folder should be in your /site1 folder. When you run it the image
will display. Now deploy it to production. Once again your image will
display. I run over a dozen web sites locally that I have created and
deploy to different URLs. I'm not sure where you get the limitation that
W2K or XP only lets you run one website. You could run as many as you have
disk space for.

You may be setting up your solutions wrong. When you create an ASP.Net
solution this is the recommended way of doing so:

Create a MyProjects folder, make this a virtual folder in IIS.
Create a WebAppNameSystem folder, this will contain everything for that
particular site.
Create a new blank solution and name it WebAppNameSolution and have VS.Net
create it in the WebAppNameSystem folder.
In the solution create a project for your web app. I always name this
project the domain name of the site I am creating.
Once you do this IIS will automatically create this virtual folder for you
in IIS and the physical folder will reside inside the WebAppNameSolution
folder.
Now, in the project create your Images folder and all the other folders you
want. When you run your app it will be as if you are running it from the
root of the production site. No paths will ever need to be changed, if they
work locally they will work in production. That is all there is to it. By
the way, nothing we have talked about has anything to do with Client-Side.
Even though you are running it locally, it just means that your server is
local. Client-side means that the browser itself is executing code that
runs on the client. Good luck! Ken.

 

[Greg Burns]

I'm not sure where you get the limitation that W2K or XP only lets you
run one website. You could run as many as you have
disk space for.

There IS a technical limit that the server editions don't have. You can
have many virtual directories on non server editions, but only one "site".
Server allows multiple sites.

Greg

 

[Ken Dopierala Jr.]

Hi Greg,

Your right. There is a 1 site limit and 10 connection limit. With properly
setup solutions that shouldn't mean additional coding for all paths to have
the app run correctly both locally and in production. If you want someone
from inside your intranet to run your app locally you can give them
"http://yourcomputername/appname" and it will work just fine. I've just
never even felt restricted by it. By "site" does that mean people setup
their local computer to accept a ww w.theirsitename.com and when they type
it in the browser it runs their local app? I've never looked into this.
Thanks. Ken.

 

[nick]

Hmmm, one of us is missing something. I hope it's me since my problem
would then be solved.

What OS are you developing on?

When you access your sites on your development machine, what do you
type as the URL or what pops up when you hit F5? For me, it has to be:

localhost/site1
localhost/site2

The fact that IIS limits me to setting up only one site means that I
have to do this. I can't set up:

mylocalsite1
mylocalsite2

As far as I know, the browser doesn't care if there's a virtual
directory set up or not. Server side, ASP.NET knows the application
root and that's why you can use ~. The browser, AFAIK, doesn't know a
thing about virtual directories. It only knows the website root. So,
all paths from the root, i.e. from "/" start at, for me, /site1/...
/site2/....

Regardless, I tried setting it up exactly as you suggested, and it
didn't work. When however I put the full path in there
(/WebAppNameSolution/domainName/Images/myImage.gif) it did work.

On thing, when you enter the project location when you first set up
the project, what do you type? It defaults to http://localhost for me
and then I can append to that to create the project where I'd like to.

It seems there would be two sources to the confusion. Either you're
developing on a server edition OS and can set up multiple websites or
you talking about paths on the server and I'm talking about paths in
the browser.

As I said, I hope I'm wrong about all this. Do you have a link to any
docs which told you how to set up a web solution in the recommended
way?