Using IIS virtual directories in Visual Studio Web Application projects

I have an ASP.NET project that has the following directories

\ads

\photos

both these folde开发者_如何学Crs have thousands of files in them that get updated frequently. I currently have my IIS set up like

\inetpub\wwwroot\foo

\inetpub\wwwroot\foo\ads

\inetpub\wwwroot\foo\photos

\inetpub\wwwroot\foo.staging

\inetpub\wwwroot\foo.staging\ads

\inetpub\wwwroot\foo.staging\photos

I am considering turning this into

\inetpub\wwwroot\foo

\inetpub\wwwroot\foo\ads

\inetpub\wwwroot\foo\photos

\inetpub\wwwroot\foo.staging

\inetpub\wwwroot\foo.staging\ads

\inetpub\wwwroot\foo.staging\photos

\inetpub\wwwroot\foo.resources\ads

\inetpub\wwwroot\foo.resources\photos

and turning the subdirectories in foo and foo.staging into virtual directories that point to the foo.resources subdirectories. This way while I'm testing in staging, I don't have to copy all the files in ads and photos every time I deploy and worry about things being out of sync. is this a bad idea? I'm developing in Visual Studio 2008 - Is there a way to get VS to treat my web application project subdirectories as virtual directories?

A virtual directory contained within a web application in IIS simply looks like a package in Visual Studio.

By opening the root app and clicking on the package, it should ask you if you want to add the child app / vdir to the solution. Then open it as a second project, you can then refer to it or consume it as needed.

The idea behind test and live deployments is that you should have separate data in case your testing breaks something. Essentially, by using the live data for testing, you have to be sure that you wont delete / alter something you shouldn't or you will break your live copy of the data.

Having said that, if all you plan to build is something that reads the data, this is a great idea as it will save you a lot of disc space and time on deployments.

Get it looking the way you want it in IIS first then open things up in VS.

Visual Studio treats all Virtual applications defined on the server as a sub application. If the resources are not setup in the child directories as an application in IIS it should appear as a normal folder.

For example ...

If you setup 2 websites on IIS and map the physical folder to your images on both as virtual directories, you should have access to them as normal folders when you open either in Visual Studio.

However if you make the virtual directories into applications in IIS and then open the website in VS it should just show a package. Clicking on that adds it as a second project in VS.

I'm not the best at explaining things but hopefully that made sense.

Hope it helps :)

I think the way to go about this is to set it up the way you want it in IIS first with your vdirs, then open the website from IIS in Visual Studio. See my answer to this question.

You could, use linked folders in Visual Studio = this creates a virtual link to a folder in another project (or somewhere else on disc), but doesn't physically copy them on disk.

Another option...If you're using SVN and if you're happy to have the images physically twice on disk, but still have them in sync, is to use SVN Externals

Since these are resources, is there any particular reason you need them to be in Visual Studio at all? VS, IMO, is for managing code in a solution, not necessarily directory structure.

In IIS, you can set your directory structure up exactly like you have it (or even have the virtual directory point to a network drive), and Visual Studio can completely ignore it, since it's likely just a bunch of static files.

I see a similar problem with my application with regarding to having loads of resources to copy up on deployment.
I'm considering building a file handler that serves up image resources to the browser. I.e. When linking to images you'd having something like /filehandler.ashx?image=/ads/101/o3904838402384.jpg then you can have just have a config setting that points to different or the same filestorage folders for both Test and Live environments.

Here is a link to the fundamentals of how it works.

http://dotnetperls.com/ashx-handler