DasBlog

/OldFiles/dasBlog-1.9.6229.0-Web-Files.zip

/OldFiles/dasBlog-1.9.6229.0-Web-Files.zip

The DasBlog project on SourceForge has migrated to SubVersion. To browse the project on the web, go to: http://svn.sourceforge.net/viewcvs.cgi/dasblogce/ >> >To retrieve and work with the code, you need a SubVersion ... [More] client. You can use the command-line client: >http://subversion.tigris.org/ > Or you can use the TortoiseSVN Windows shell extension: http://tortoisesvn.tigris.org/ >> In either case, you must enable the ASP.NET "hack". It simply requires you set an environment variable before working with SubVersion: set SVN_ASP_DOT_NET_HACK=1 For more information about the hack, read http://www.codefez.com/Home/tabid/36/ctl/ArticleView/mid/364/articleId/191/Subversion-and-the-ASP-NET-Hack.aspx >> The rest of this document will assume the command-line client. The equivalent actions with TortoiseSVN should be fairly obvious. The first thing you will notice is that the project root folder (dasblogce), has 3 subfolders: [branches] [tags] [trunk] These 3 folders are a common convention in Subversion repositories. You can read about them in the Subversion book http://svnbook.red-bean.com/ >. If you are new to Subversion, I highly recommend you read the first 3 chapters. If you are already familiar with Subversion and how to use these folders, you can skip down to the section labeled *DasBlog Specifics.> *TRUNK All work is done from the trunk folder. All checkins/commits should be to the trunk folder. In fact, when working with the code, you should treat /dasblogce/trunk as the root folder (as opposed to /dasblogce). For example, to checkout a working copy of the entire codebase, you would use the following command: svn checkout https://svn.sourceforge.net:443/svnroot/dasblogce/trunk >> dasblogce This will create a new folder on your filesystem named dasblogce which contains all of the data under the trunk folder. Nothing from branches or tags will be retrieved. *TAGS The tags folder is used to hold milestone snapshots of the repository. Typically, after each release, you will create a new "tag", so that it is easy to retrieve the codebase corresponding to that release. You create a new tag by copying the trunk folder to a new named subfolder of the tags folder. For example, to take a snapshot of the codebase after making the 1.9.6180.1 release, you would run: svn copy https://svn.sourceforge.net:443/svnroot/dasblogce/trunk >> https://svn.sourceforge.net:443/svnroot/dasblogce/tags/1.9.6180.1 >> If you forget to tag after a release, you can always reference the previous state if you know the revision number. For example, I created a tag for the state of the codebase after the CVS migration (revision 410), even though the code had been modified since. svn copy -r 410 https://svn.sourceforge.net:443/svnroot/dasblogce/trunk >> https://svn.sourceforge.net:443/svnroot/dasblogce/tags/FinalCVSVersion >> Note: There is nothing that technically limits you from checking out a working copy from the tags folder, and then committing changes. However, it is a VERY BAD IDEA. The tags folder should just contain snapshots in time. Make all changes to the trunk or a branch. *BRANCHES The branches folder is used to create alternate branches of the source base. The process for creating a branch is the same as creating a new tag. Just copy the trunk folder to a new subfolder of the branches folder. You can then checkout and commit your changes to the branched folder, and then merge it back into the trunk when appropriate.   *DasBlog Specifics The DasBlog trunk folder has the following layout: [docs] [lib] [source] [tools] package.bat The source folder contains only the source code and automated unit tests created by the DasBlog development team. Under CVS, this folder held all files related to the project. The following sections will describe the new location for files that are not considered part of the DasBlog source code, but are still kept with the project. The docs folder contains all documention and reference material (URL links). This includes the readme, license, and release notes. The lib folder contains all compiled 3rd party assemblies referenced by the source code projects. These files used to be in the source\Assemblies folder. The projects under the source folder have been updated to reference the files in the lib folder (which is why it is important to checkout the entire trunk, and not just the source subfolder, when working on code). The tools folder contains all of the executables needed to support the development and packaging of DasBlog (not including the .NET Framework itself). For example, the tools\nunit folder contains all of the nunit executables required to run the DasBlog unit tests. Note that the nunit.framework.dll referenced by the test projects is copied to the lib folder - source code should not reference files in the tools folder directly. Keeping the tools stored with the project helps ensure that all developers on the project always use the same version. (You will want to remove NUnit from your GAC to avoid overriding the project copies.) For more information about this strategy, check out Mike Robert's excellent article "How to setup a .NET Development Tree": http://www.mikebroberts.com/blog/archive/Tech/ArticlesandPapers/Howtosetupa.NETDevelopmentTreeWrapup.html >> The CreateDasBlogVdir.vbs file is also in the tools folder, and has been updated so that it works properly from that location. package.bat is the sole file in the root of the project (arguably, it could have been placed in the tools folder). It is used to create the release files to post on SourceForge. A number of changes have been made to the script, although the resulting release files are equivalent to files created with the previous version. Most importantly, the script will now automatically determine the release version number based on the AssemblyVersion attribute in the source\AssemblyInfo.cs file. While you still have to manually update AssemblyInfo.cs when the time comes, you no longer need to modify package.bat for each release. package.bat now takes an optional command-line argument. You can specify ALL (the default), WEB, or SOURCE. If you specify WEB or SOURCE, it will only create the one zip file. All release files are created in the build subfolder. The build subfolder is considered a temporary folder, so it is wiped out every time package.bat is executed, and Subversion has been set to ignore the folder (via the svn:ignore property). This weblog is sponsored by DasBlog. [Less]

The DasBlog project on SourceForge has migrated to SubVersion. To browse the project on the web, go to: http://svn.sourceforge.net/viewcvs.cgi/dasblogce/ >> >To retrieve and work with the code, you need a SubVersion ... [More] client. You can use the command-line client: >http://subversion.tigris.org/ > Or you can use the TortoiseSVN Windows shell extension: http://tortoisesvn.tigris.org/ >> In either case, you must enable the ASP.NET "hack". It simply requires you set an environment variable before working with SubVersion: set SVN_ASP_DOT_NET_HACK=1 For more information about the hack, read http://www.codefez.com/Home/tabid/36/ctl/ArticleView/mid/364/articleId/191/Subversion-and-the-ASP-NET-Hack.aspx >> The rest of this document will assume the command-line client. The equivalent actions with TortoiseSVN should be fairly obvious. The first thing you will notice is that the project root folder (dasblogce), has 3 subfolders: [branches] [tags] [trunk] These 3 folders are a common convention in Subversion repositories. You can read about them in the Subversion book http://svnbook.red-bean.com/ >. If you are new to Subversion, I highly recommend you read the first 3 chapters. If you are already familiar with Subversion and how to use these folders, you can skip down to the section labeled *DasBlog Specifics.> *TRUNK All work is done from the trunk folder. All checkins/commits should be to the trunk folder. In fact, when working with the code, you should treat /dasblogce/trunk as the root folder (as opposed to /dasblogce). For example, to checkout a working copy of the entire codebase, you would use the following command: svn checkout https://svn.sourceforge.net:443/svnroot/dasblogce/trunk >> dasblogce This will create a new folder on your filesystem named dasblogce which contains all of the data under the trunk folder. Nothing from branches or tags will be retrieved. *TAGS The tags folder is used to hold milestone snapshots of the repository. Typically, after each release, you will create a new "tag", so that it is easy to retrieve the codebase corresponding to that release. You create a new tag by copying the trunk folder to a new named subfolder of the tags folder. For example, to take a snapshot of the codebase after making the 1.9.6180.1 release, you would run: svn copy https://svn.sourceforge.net:443/svnroot/dasblogce/trunk >> https://svn.sourceforge.net:443/svnroot/dasblogce/tags/1.9.6180.1 >> If you forget to tag after a release, you can always reference the previous state if you know the revision number. For example, I created a tag for the state of the codebase after the CVS migration (revision 410), even though the code had been modified since. svn copy -r 410 https://svn.sourceforge.net:443/svnroot/dasblogce/trunk >> https://svn.sourceforge.net:443/svnroot/dasblogce/tags/FinalCVSVersion >> Note: There is nothing that technically limits you from checking out a working copy from the tags folder, and then committing changes. However, it is a VERY BAD IDEA. The tags folder should just contain snapshots in time. Make all changes to the trunk or a branch. *BRANCHES The branches folder is used to create alternate branches of the source base. The process for creating a branch is the same as creating a new tag. Just copy the trunk folder to a new subfolder of the branches folder. You can then checkout and commit your changes to the branched folder, and then merge it back into the trunk when appropriate.   *DasBlog Specifics The DasBlog trunk folder has the following layout: [docs] [lib] [source] [tools] package.bat The source folder contains only the source code and automated unit tests created by the DasBlog development team. Under CVS, this folder held all files related to the project. The following sections will describe the new location for files that are not considered part of the DasBlog source code, but are still kept with the project. The docs folder contains all documention and reference material (URL links). This includes the readme, license, and release notes. The lib folder contains all compiled 3rd party assemblies referenced by the source code projects. These files used to be in the source\Assemblies folder. The projects under the source folder have been updated to reference the files in the lib folder (which is why it is important to checkout the entire trunk, and not just the source subfolder, when working on code). The tools folder contains all of the executables needed to support the development and packaging of DasBlog (not including the .NET Framework itself). For example, the tools\nunit folder contains all of the nunit executables required to run the DasBlog unit tests. Note that the nunit.framework.dll referenced by the test projects is copied to the lib folder - source code should not reference files in the tools folder directly. Keeping the tools stored with the project helps ensure that all developers on the project always use the same version. (You will want to remove NUnit from your GAC to avoid overriding the project copies.) For more information about this strategy, check out Mike Robert's excellent article "How to setup a .NET Development Tree": http://www.mikebroberts.com/blog/archive/Tech/ArticlesandPapers/Howtosetupa.NETDevelopmentTreeWrapup.html >> The CreateDasBlogVdir.vbs file is also in the tools folder, and has been updated so that it works properly from that location. package.bat is the sole file in the root of the project (arguably, it could have been placed in the tools folder). It is used to create the release files to post on SourceForge. A number of changes have been made to the script, although the resulting release files are equivalent to files created with the previous version. Most importantly, the script will now automatically determine the release version number based on the AssemblyVersion attribute in the source\AssemblyInfo.cs file. While you still have to manually update AssemblyInfo.cs when the time comes, you no longer need to modify package.bat for each release. package.bat now takes an optional command-line argument. You can specify ALL (the default), WEB, or SOURCE. If you specify WEB or SOURCE, it will only create the one zip file. All release files are created in the build subfolder. The build subfolder is considered a temporary folder, so it is wiped out every time package.bat is executed, and Subversion has been set to ignore the folder (via the svn:ignore property). This weblog is sponsored by DasBlog. [Less]

A few words on ISP hosting of dasblog:   (You should only use the dasblog “web” files for upload installation to a host, keep the directory layout/structure as provide in the zip file)   ASP.NET 1.1   Hosts who ... [More] offer ASP.NET impersonation:   If your host supports asp.net impersonation there are no permission configuration issues. The only task required of these hosts is to be sure your dasblog install directory is a vdir (Virtual Directory) also know as a (ASP.NET Application directory). If you place your blog in the domain root, this will normally be a vdir by default.   Non ASP.Net impersonation hosts:      IIS5 Sites (IWAM xxx): On IIS 5.0 (Windows 2000), the account used to execute web applications (IWAM xxx) needs read/write permissions to the content, siteconfig, and logs subdirectories. ({machinename}\ASPNET): The ASP.NET worker process identity, usually “{machinename}\ASPNET” on IIS5.0 (Windows 2000 and Windows XP) also need read/write access to the content, siteconfig, and logs subdirectories.       IIS6 Sites    (“NETWORK SERVICE”): on IIS 6.0 (Windows Server 2003), also need read/write access to the content, siteconfig, and logs subdirectories.   Permission gotcha’s: (These can apply to any host situation!) On some hosts the permissions for files in directories does not inherit properly. To insure that you do not have this problem, you should install dasblog using the following process. Create the required directories siteconfig, logs, and content on the host server and insure that they have Read Write permissions on the remote system BEFORE you upload the dasBlog web files.   If there is any concern that permissions were not replicated correctly or you have already uploaded these files and feel you may have a problem, set all the existing files to Read Wrire permissions. ASP.NET 2.0   Hosts running DasBlog on ASP.NET 2.0   If you are running DasBlog on ASP.NET 2.0, all the preceding applies but you will also need to modify your supplied web.config file to customize your installation for ASP.NET 2.0.   See the following web.config sections, make the changes documented:   <!-- ***IMPORTANT*** If you are using ASP.NET 2.0 to host dasBlog             you must uncomment the httpCookies section below,             as dasBlog was written for ASP.NET 1.1 and will             automatically add the HttpOnly flag to cookies automatically -->   <!---        <httpCookies httpOnlyCookies="false"/> --->   Note: (The comments tags are the <!--- and the trailing --->)   <!-- ***IMPORTANT*** If you are using ASP.NET 2.0 to host dasBlog             you must add cookieless="UseCookies" to the <forms>             element below! -->   <forms name=".DASBLOGAUTH" cookieless="UseCookies" protection="All" timeout="60" path="/"/>   Your entry should look something like the above: All IIS Sites:   After you have successfully uploaded all your web files retaining the directory structure that was defined in the download zip file, you the user, or maybe some ISP Hosts who setup dasblog for you will need to accomplish the following:   Go to the siteconfig directory in (likely in c:\inetpub\wwwroot\{sitename}) and open the site.Config file. In that file, change the settings (quite obvious when you look at them). The most important change is to set the <Root> value to the proper URL for your weblog.               Example <Root>http://domain.com/dasblogdirectory</Root>   Open the siteSecurity.config file in the same directory and set up your own account with a proper password.   If all the above have been accomplished correctly, then you should now have a functional dasblog system.   This weblog is sponsored by DasBlog. [Less]

A few words on ISP hosting of dasblog:   (You should only use the dasblog “web” files for upload installation to a host, keep the directory layout/structure as provide in the zip file)   ASP.NET 1.1   Hosts who ... [More] offer ASP.NET impersonation:   If your host supports asp.net impersonation there are no permission configuration issues. The only task required of these hosts is to be sure your dasblog install directory is a vdir (Virtual Directory) also know as a (ASP.NET Application directory). If you place your blog in the domain root, this will normally be a vdir by default.   Non ASP.Net impersonation hosts:      IIS5 Sites (IWAM xxx): On IIS 5.0 (Windows 2000), the account used to execute web applications (IWAM xxx) needs read/write permissions to the content, siteconfig, and logs subdirectories. ({machinename}\ASPNET): The ASP.NET worker process identity, usually “{machinename}\ASPNET” on IIS5.0 (Windows 2000 and Windows XP) also need read/write access to the content, siteconfig, and logs subdirectories.       IIS6 Sites    (“NETWORK SERVICE”): on IIS 6.0 (Windows Server 2003), also need read/write access to the content, siteconfig, and logs subdirectories.   Permission gotcha’s: (These can apply to any host situation!) On some hosts the permissions for files in directories does not inherit properly. To insure that you do not have this problem, you should install dasblog using the following process. Create the required directories siteconfig, logs, and content on the host server and insure that they have Read Write permissions on the remote system BEFORE you upload the dasBlog web files.   If there is any concern that permissions were not replicated correctly or you have already uploaded these files and feel you may have a problem, set all the existing files to Read Wrire permissions. ASP.NET 2.0   Hosts running DasBlog on ASP.NET 2.0   If you are running DasBlog on ASP.NET 2.0, all the preceding applies but you will also need to modify your supplied web.config file to customize your installation for ASP.NET 2.0.   See the following web.config sections, make the changes documented:   <!-- ***IMPORTANT*** If you are using ASP.NET 2.0 to host dasBlog             you must uncomment the httpCookies section below,             as dasBlog was written for ASP.NET 1.1 and will             automatically add the HttpOnly flag to cookies automatically -->   <!---        <httpCookies httpOnlyCookies="false"/> --->   Note: (The comments tags are the <!--- and the trailing --->)   <!-- ***IMPORTANT*** If you are using ASP.NET 2.0 to host dasBlog             you must add cookieless="UseCookies" to the <forms>             element below! -->   <forms name=".DASBLOGAUTH" cookieless="UseCookies" protection="All" timeout="60" path="/"/>   Your entry should look something like the above: All IIS Sites:   After you have successfully uploaded all your web files retaining the directory structure that was defined in the download zip file, you the user, or maybe some ISP Hosts who setup dasblog for you will need to accomplish the following:   Go to the siteconfig directory in (likely in c:\inetpub\wwwroot\{sitename}) and open the site.Config file. In that file, change the settings (quite obvious when you look at them). The most important change is to set the <Root> value to the proper URL for your weblog.               Example <Root>http://domain.com/dasblogdirectory</Root>   Open the siteSecurity.config file in the same directory and set up your own account with a proper password.   If all the above have been accomplished correctly, then you should now have a functional dasblog system.   This weblog is sponsored by DasBlog. [Less]

Many thanks Scott and Omar (loving the custom macro plugin model)

/OldFiles/DasBlog-1.8.5223.2-Web-Files.zip

/OldFiles/DasBlog-1.8.5223.2-Web-Files.zip

/OldFiles/DasBlog-1.8.5223.2-Source.zip