This page describes how you can set up your development and hosting environment to support multiple developers working on the same project and deliver continues updates to a live website.
Before we go into the details, it is important you understand the difference between the two main types of web projects in Visual Studio, namely "Websites" and "Web Applications" . There are pros and cons to each, and the type of project you choose has consequences for how you work with staging and source control.
Website project type
In a website project, code and template files are compiled automatically as requests are made to the templates. ASP.NET automatically keep track of changes to a code file and compiles temporary assemblies as needed. This type of project requires that the published website contains all the source files, and the published website is basically a file copy of your local development website. This simplifies the publication process, and makes it possible to make smaller changes to a live website without compiling the site locally first, in fact there is nothing stopping you from making direct changes to the code on a live server by simply changing the content of the .cs files with a notepad or the built in code file editor in Webnodes. There are in principle to types of automatic compilation in ASP.NET, one that is done at start up, and one that is done for each .aspx file. The one done at start up includes all code files within App_Code and a few other special folders and files like the web.config. It is important to be aware that making changes to any of these files will therefore trigger a restart of the entire website and typically cause the website to be offline for about 20-40 seconds. Making changes to files that are compiled individually, like templates files, only cause a website restart after a threshold value of 15 changes. This threshold value can be set in the web.config; "numRecompilesBeforeAppRestart". Making changes to html, css, js and images does not trigger any compilation.
- You can make code changes directly on webserver
- Changes to templates files like (*.aspx.cs) will rarely trigger a site restart.
- Easy deployment.
- Webnodes ontology rebuilds and changes can be performed directly on server
- Webnodes online Update can be run on live server
- MVC type projects are not supported
- Testdriven development is difficult
- Tempting for developers to make risky changes directly on live servers.
Web Application Project
Web application projects must be manually compiled in Visual Studio before you can run or publish them. They use a project .proj file to define what files should be included in this compilation, unlike web applications, where any file located within the website folder is compiled. In Web Application projects, the live server will not contain the source files for code, and any change you want to make must be done in your development version of the site. Once changes have been done here you recompile the project and publish the new assemblies to your webserver. Making changes to html, css, js and images does not require recompilation.
- Better control of the source code due to the .proj file. (Easy to exclude files etc)
- Easier to split complicated source code in separate assemblies.
- The entire website is part of the same compilation. It is therefore it is possible to reference classes defined in code behind files in other templates. (not rec. though...)
- Faster startup time of the website. (Once started, the performance is identical)
- Live webserver does not contain source code.
- Support for MVC type projects
- Test driven development is easier
- Clearer separation of development server and live server, making it less likely developers will make risky changes diretcly on live server.
- Smaller changes are more timeconsuming (and expensive for client.)
- Urgent or "Emergency" fixes are more complicated
- Webnodes online updates cannot be performed on live server
- Webnodes ontology Rebuilds and cannot be performed directly on server
Types of data
For staging and source control you need a strategy for dealing with each of the following types of data:
The Ontology (or datamodel) is stored internally in a xml files at (WAF/Files/Definitions/). The database must always reflect the latest changes in the datamodel. When you are editing the datamodel, Webndoes store the changes in a temporary file called: "ContentDefinitionsTemp.xml", when you rebuild it updates the code files and database to reflect the changes and overwrites the current ontology to the file called "ContentDefinitionsTemp.xml". Internally, and within these files classes and properties are given integer ID number. If two developers are making changes to the same website but in separate installation, you must not do a text merge of these files as you will likely get conflicts in the ID numbers. To merge and move Ontologies to a new installation, you must therefor use the built in Ontology Merge Tool. (see below for more info)
2. Code Files
With code files we refer to all the files you have added to the website manually or with Visual Studio, so basically all files, except: the once uploaded via the edit interface . Typically this means all files within App_Code, all aspx, html, cs, js, css, and all jpg, png, gif for the templates files. For source control on these files we recommend you use standarized third party tools like TSF (Microsoft), Mercurial, Source Safe etc. (Our personal preference is Mercurial).
3. Edited content
Edited content is all content created and edited via the "/edit" interface. This data is stored in two places, the database and the file system. (The files are located at WAF/Files/Content/). Do not make the mistake of synchronizing the files within "WAF/Files/Content/" with a source control software. The files here are references to by the database, and you quickly break these references unless you also include the database in the source control software (which is very uncommon and not recommended). To syncronize and move content between websites we recommend you use the webnodes synchronization tool. Se below for more information.
Merging ontologies is done by importing an external ontology from another website. To sync both ways, you must import in both. During the sync operation you will be able to review all changes and select the parts to sync. To access this function see the Ontology module:
Merging content is done by selection the Syncronization option in the System module: