Subversion and Using IIS for ASP.NET Development
I am new to SVN and could not find an answer for the following situation.
I have an ASP.NET 2.0 web application that I am developing. I am using my local IIS as a development web server (i.e. 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 in the ** C: \ Localsource \ Projects \ ProjectName ** folder, and my .aspx files are in my ** C: \ inetpub \ wwwroot \ ProjectName * * folder.
I can set up a repository for ** C: \ Localsource \ Projects \ ProjectName ** fine, but can't think of a way to set it up for the IIS folder as well as in the same repository.
What's the best way to work with this development environment in SVN?
Many thanks,
Ant
source to share
In a Visual Studio solution, you can create a class library project, which is usually located in a directory below the .sln file.
In this case, it also has a web project within the solution, but NOT under the .sln file in the file directory structure.
It will attach to this project via HTTP not via a local file path.
IIS will manage this as http: // localhost / webapp and will by default place it in the c: \ inetpub \ wwwroot \ webapp directory. The files in the webapp folder will not be in the repo as they will not be present in the solution and class library hierarchy. This is his question, how to figure it out.
My answer is to move http: // localhost / webapp to point to the folder that is under the .sln file and next to the class library directory then this can all go into the repo.
Separating class library and webapp is the best practice for reusing aide code and decoupling logic from the website.
source to share
OK, I might be silly here, but .. Why would you need to add the IIS folder (i.e. the codebase output) to your repository?
Update
I think I should clarify this a little more. I mean, I'm not sure why ASPX is separate from the project? What's wrong with the Web Project and n Library Library Projects in the solution added to your repository. Then you publish in each new version.
If this is just a case of "it might be easier to rollback the published output" then it would be, I was just curious as I haven't seen many people work that way.
Deploying solutions in this framework would be much easier.
source to share
The IIS folder is not the output of the codebase that is part of the application. This is not CGI output or anything other than the actual scripts to run the application!
These are .aspx pages that will have custom controls and HTML to actually launch the application. Its part of the application, but separated from the VS Studio solution.
The easiest way is to have a solution and then C: \ Localsource \ Projects \ ProjectName \ WEBSITE.
point IIS in this folder.
source to share
I think you can split this into two issues by following this recommendation from Dillorscroft.
First, as far as stuff on your development server gets published to the production site, I think you need version control for that. You can rollback any page first, and you can also decide when you have a stable development site level that you want to checkout for production. (I would get this from the original management system into a site image and then sync this image to the production site.)
So for the first part, we are talking about versioning web pages and all the server side custom content that the website maintains.
Second, with regard to the development of the components that are used on the site, they need their own development projects, since that is the output that goes to the development site, not all the sources, libraries, etc. that the component is built from. This way they will have their own project development tree (think of it as if you are building a library that will be used by other development projects, although in this case the other projects are web pages). Thus, the only thing that should appear in IIS is a "deployed" component on the development site.
You seem to have three important questions:
-
How are the tests to be passed against the website developed and where is version controlled (unless they belong to the website itself)
-
How easy can you ensure that all content on a development website is kept under version control and checkout and -out. (This has to do with the tools you use to edit webpages and other server side server side, apart from components developed in the side.)
-
It's easy to take developed components from projects that produce them on a development site and test them there.
My solution (2) and version control of the development website is to use the Visual Source Safe integration with the IIS and FrontPage extensions that host the site under version control. Components created from other development projects are mapped to a VSS server project.
For SVN, my guess is that (1) you want to see if there is an SVN adapter that IIS will recognize as an external source control system and, in any case, (2) have a discipline that takes delivery of components from their construction projects to a generic website project.
source to share