Subversion and using IIS for ASP.NET development

Question

Hi,

I'm a total newbie to SVN and haven't been able to find an answer for the following situation.

I have an ASP .NET 2.0 web app that I am developing. I am using my local IIS as the development web server (i.e. not the Visual Studio web development server). My development environment is VS2005, Vista, IIS7, TortoiseSVN / AnkhSVN. VisualSVN is installed on the server.

My .sln files and class libraries, etc. are located in the *C:\Localsource\Projects\ProjectName* folder, and my .aspx files are in my *C:\inetpub\wwwroot\ProjectName* folder.

I can set up the repository for *C:\Localsource\Projects\ProjectName* fine, but can't think of a way to set it up for the IIS folder as well in the same repository.

What's the best way for dealing with this development environment in SVN?

Many thanks,

Ant

Answer 1

Can you not just point IIS to C:\Localsource\Projects\ProjectName and set the permissions?

Answer 2

Hmmm - Good point. It was set up like this when I got here, and Visual Studio always creates websites in the wwwroot folder, so I assumed wwwroot was just where they had to go.

Maybe I'll have to think about doing a little rearranging...

Thanks!

Answer 3

OK, I may be being stupid here but.. Why do you need to add the IIS folder (i.e. the output of the code base) to your repository?

Update

I think I should clarify this a bit more.. What I mean to say is I am not sure why the ASPX is seperate from the project anyway? What is wrong with an Web Project and n Class Library Projects in a Solution, added to your repository.. You then publish on each new release..

If it is simply a case of "it might be easier to roll back the published output" then so be it, I was just curious as I have not seen many people actually work that way.

Deployment of solutions in this structure would be a lot easier as well..

Answer 4

The IIS folder is not the output of the code base it is part of the application. It's not CGI output or anything but actually the scripts to run the app!

This is the .aspx pages that will have user controls and HTML to actually run the application. Its part of the applciation but split away from VS Studio solution.

The easiest way is to have a solution and then C:\Localsource\Projects\ProjectName\WEBSITE.

Point IIS at that folder as well.

Answer 5

In a solution in Visual Studio you can have a class library project which is usually in a directory underneath the .sln file.

In this case he also has a web project within the solution but NOT underneath the .sln file in the file directory structure.

He will be attaching to this project via HTTP not via local file path.

IIS will manage this as http://localhost/webapp and by default will place it in c:\inetpub\wwwroot\webapp. The files in webapp folder will not be in the repo as they arent in the hierachy of the solution and the class library. This is his question how to sort it out.

My answer is to move http://localhost/webapp to point to a folder that is underneath the .sln file and adjacent to the class library directory then it can all go in the repo.

Seperating the class library and the the webapp is best practice to aide code re-use and decoupling the logic from the web site.

Answer 6

I think you might want to separate this into two problems, following this recommendation from Dillorscroft.

First, with regard to the material on your development server that is published to the production site, I think you need version control for that. First so you can roll back any page, and you can also decide when you have a stable level of the development site that you want to extract to production. (I would get that from the source control system into a site image and then synchronize that image with the production site.)

So, for the first part, we are talking about versioning the web pages and all of the custom server-side material that supports the web site.

Secondly, With regard to the development of components that are used on the site, they need their own development projects, since it is the result that goes to the development site, not all of the source, libraries, etc. that the component is built with. So these will have their own project development tree (think of it as if you were building a library that is to be used by other development projects, although in this case the other projects are web pages). So the only thing that should show up in IIS is the "deployed" component to the development site.

There seem to be three critical questions for you:

1. How development of tests that need to go against the web site is handled and where that is version controlled (assuming they do not belong on the web site itself)

2. How easily you can arrange to make sure that all content on the development web site is kept under version control and checked-in and -out appropriately. (This has to do with the tools you use to edit web pages and other server-side gunk other than components developed off to the side.)

3. Easily taking developed components from the projects that produce them to the development site and have them be checked-in there.

My solution to (2) and to version control of the development web site is to use Visual Source Safe integration with IIS and FrontPage extensions that places the site under version control. Components produced from other development projects are mapped to the server project by VSS sharing.

For SVN, I speculate that (1) you want to see if there is an SVN adapter that IIS will recognize as an external source-control system and, either way, (2) have a discipline that takes delivery of components from their construction projects into the overall web site project.

Answer 7

Rob,

Why do you consider an .aspx file an output of the code base?

It is part of the code base. It's not an output after compilation for instance.

Just wondered?