At work, we have a windows server 2003 with IIS and Subversion installed. We use it to publish and test locally
our ASP.NET websites. Every programmer has Tortoise installed on his PC and can update/commit content to the server. Hosting the repositories is working fine.
But the files kept in those repositories needs then to be copied to our local IIS (virtual directories).
What is an easy way to publish those subversion repositories to our local IIS?
Edit:
Thanks to puetzk I added a simple bat file that gets executed every time a commit occurs (check the subversion documentation about hooks). My bat file only contains:
echo off
setlocal
:: Localize the working copy where IIS points)
pushd E:\wwwroot\yourapp\trunk
:: Update your working copy
svn update
endlocal
exit
Just keep the web server's file area as a working copy, and perform an svn up in it whenever you want to "publish". Configure it to hide the contents of the .svn folders if they seem untidy to you (I don't specifically know how to do this, but I assume it can be done). They will already have the filesystem hidden bit, which may take care of this.
If you want it really automatic (updates as soon as someone commits), use a post-commit hook script on the SVN server to kick off the first process.
Others in the comments have suggested using export instead of checkout. That can work too, and avoids the .svn clutter, but has two drawbacks. One, it has to redownload the entire contents every time, not just the modified files (since it didn't keep the .svn dir to remember what it has). If you have a lot of files, this will be much slower. Two, update replaces the file atomically (writes the new version in .svn/tmp, then moves it into place). Export writes the file gradually into it's destination as it downloads. That means export could deliver an incomplete file to someone who browsed it at just the wrong time.
SVN doesn't support IIS; you can however run the standalone svnserve server as a windows service.
There's the SVN FAQ entry about it, and this blog post on Vertigo Software blog may be helpful too.
UPDATE:
After your clarification, I see that what you are looking for is a way to automatically update the code on the server after it's checked in. Look into CruiseControl.NET, after looking at the subversion integration tutorial it looks like it should do what you want.
UPDATE 2: This tutorial describes integrating Subversion, CruiseControl.NET and Nant.
maybe SVNIsapi can solve the problem (http://www.svnisapi.com). Cause it only utilizes an IIS installation, therefore you don't need an APACHE server or an SVNSERVER service. Secondly it should be possible to stack the ASP.NET ISAPI plugin onto the processing of SVNISAPI, so that a ASP.NET (.aspx) page will interpreted after read from the repository.
Cheers
Paolo
Use can use the free Visual-SVN Server to quickly install Subversion with Apache front end. It also have a nice MMC snap-in for managing the server and repositories.
You will than be able to access subversion with HTTP or HTTPS, but the port number must be different from the one your local IIS uses (default port for Visual-SVN server is 8080).
If you really need to access the repositories using your local IIS port 80, you can try SVN-IIS which acts as a bridge between your IIS and Apache. I haven't tried this one myself though.
Related
I am in an interesting situation where I maintain the code for a program that is used and distributed primarily by our sister company. We are ready to distribute the program to all of the 3rd party users and since it is technically our sister companies program, we want to host it on their website. (in the interest of anonimity, I'll use 'program' everywhere instead of the actual application name, and 'www.SisterCompany.com' instead of their actual URL.)
So I get everything ready to go, setup the Publish setting to check for updates at program start, the minimum required version, and I set the Insallation Folder URL and Update Location to "http://www.SisterCompany.com/apps/program/", with the actual Publishing Folder Location as "C:\LocalProjects\Program\Publish\". Everything else is pretty standard.
After publish, I confirm that everything installs and works correctly when running directly from the publish location on my C: drive. So I put everything on our FTP server, and the guy at our sister company pulls it down and places everything in the '/apps/program/' directory on their webserver.
This is where it goes bad. When I try to install it from their site, I get the - File, Program.exe.config, has a different computed hash than specified in manifest. Error. I tested it a bit, and I even get that error trying to install from any network location on our network other than my local C: drive.
After doing the initial publish in visual studio, I have changed no files (which is the answer/reason I've found by doing some searching about this error).
What could be causing this? Is it because I set the Installation Folder URL to a location that it isn't initially published too?
Let me know if any additional info is needed.
Thanks.
After bashing my head against this all weekend, I have finally found the answer. After unsigning the project and removing the hash on the offending file (an xml file), I got the program to install, but it was giving me 'Windows Side by Side' Errors. I drilled down into the App Cache were the file was, and instead of a config .xml file, it was one of the HTML files from the website the clickonce installer was hosted on. Turns out that the web server didn't seem to like serving up an .XML (or .mdb it turns out) file.
This MSDN article ended up giving me the final solution:
I had to make sure that the 'Use ".deploy" file extension' was selected so that the web server wouldn't mangle files with extensions it didn't like.
I couldn't figure out why that one file's hash would be different. Turns out it wasn't even the same file at all.
It is possible that one of the FTP transfers is happening in text mode, rather than binary?
For me the problem was that .config transformations were done after generating manifest.
To anyone else who's still having trouble, five years later:
The first problem was configuring the MIME type, which on nginx (/etc/nginx/mime.types) should look like this:
application/x-ms-manifest application
See Click Once Server and Client Configuration.
The weirder problem to me was that I was using git to handle the push to the server, i.e.
git remote add live ssh://user#mybox/path/to/publish
git commit -am "committing...";git push live master
Works great for most things, but it was probably being registered as a "change," which prevented the app from installing locally. Once I started using scp instead:
scp -r * user#mybox/path/to/dir/
It worked without a hitch.
It is unfortunate that there is not a lot of helpful information out there about this.
I would like to have a desktop PC and a laptop available for development. I am using XAMPP on the desktop which I use as my main workstation, however I'd like to just change location and be able to continue working on the laptop. It seems that it is possible to move the /htdocs folder to Dropbox so the XAMPP instances on both devices would use the same shared folder. That would be a part-solution, what about the question of databases, how would I go about that? I'm sure there are others who work in a similar fashion, so I'd like some pointers on how to set this up properly. Thanks
Your best bet is to set up version control. Given that you seem to assume you will basically always be networked, you might like to use github or bitbucket to create your "central" repository, and use your favourite DVCS to push changes between the repositories.
Conceptually the simplest, although perhaps not the best, depending on how you like to develop is to push all changes through the "master", and have both of your computers pull from there. Using mercurial or git, you can also push directly between the repositories on both of your computers.
I use bitbucket because it offers free, private repositories (github is free, but the free version only allows public repositories).
This also gives you the advantage of an offsite backup.
Try using a SVN or CVS solution...
You can use a development environment which is virtulized and have a high availability.
There are some virtualization services like (amazon, Microsoft) which you can utilize (They are paid services) .
If viruilization is not possible, you might want to maintain the scripts for the database in a version control tool . So when you switch commit the database changes in the version control tool , rerun the database scrips on the laptop to upgrade the database with latest information.
Also same thing applies for HTTP files.
If the database creation script is out of question you might want to create a database snapshot with raw datafile , which should be checked in into version control tool before switch and checkout on the other machine . Refer following link on which files you want to check-in into version control tool.
http://dev.mysql.com/doc/refman/5.0/en/replication-howto-rawdata.html
You could include a virtual machine in your Dropbox folder. This way you can encapsulate your development environment in a single file and take it with you wherever you want.
I have done that with an Ubuntu VM and never had a problem.
I'm trying to figure out a way to automate the deployment to our QA environment. The problem is that our release is quite big, so needs to be Zipped, FTP'd and then Unzipped on the QA server. I'm not sure how best to unzip remotely.
I can think of a few options, but none of them sound right:
Use PsExec to execute a remote commandline call on the QA server to unzip the release.
Host a web service on the QA server that unzips the release and copies it to the right place. This service can be called by our release when it's done uploading the files.
Host a windows service on the QA server that monitors a file location and does the unzipping.
None of these are pretty though. I wonder how others have solved this problem?
PS: we use CruiseControl.NET to execute a NAnt script that does the building, zipping and FTP.
Instead of compressing and un-compressing, you can use a tool like rsync; which can transparently compress data during file transfer. The -z option tells rsync to use compression.
But I assume you are in a Windows environment, in which case you could use cwRsync (which is "rsync for Windows").
Depending on your access to the QA box this might not be a viable solution. You'll need to:
install the cwRsync server on the remote machine and
allow the traffic through any firewalls.
At the last place I worked at, we had a guy write a Windows service on the CI box to do the unzipping. TFS Team Server finished the build and notified a service to zip the completed build and copy it to the CI box. The CI box picked up on the new file, and unzipped it. It may have been a bit heavy, but it worked well - and he was cognizant to log all actions to the event log, so it was easy to diagnose if a server had been reset and the service hadn't started.
Update: One thing that we would have liked to improve on that process was to have the service on the CI box check for zip files and uncompressed files that were older than x months, for purging purposes. We routinely ran out of disk space (it was a VM that we rarely looked at), and had to manually purge old builds when it happened.
We are currently using VSS for version control. Quite few of our developers are interested in a distributed model (And want to get rid of VSS). Our network is full of Windows machines and while our IT department has experience maintaining Linux machines they would prefer not to.
What DVCS systems can host their central repository on Windows while providing..
Push access to the repository.
Basic authentication. Mostly just a way to allow or deny access to the whole repository. No need for fine grained access.
Server process so users don't need write right to the repository reducing the risk of accidentally messing with it.
On the client side a GUI such as Tortoise would be more or less a requirement (Sorry, Windows shell sucks. :|). Ease of installation would be a huge plus as our IT department is already quite low on resources. And using windows credentials for authentication would be an advantage but not a requirement as long as the client is able to store the credentials.
I have had a (really) quick look at Git, Mercurial and Bazaar.
Git seemed to use ssh or simple WebDAV for repository access, requiring write permission for the users.
Mercurial had a built in http server, but this seemed to be only for pull purposes. Update: Mercurial supports push as well.
Bazaar Seemed to use sftp for repository access, again requiring a write permission for the users.
Are there windows server processes for any DVCS systems and has anyone managed to set one up in a Windows land?
And apologies if this is a duplicate question. I couldn't find one.
Update
Got Mercurial working for push purposes! Detailed list what was required can be found as an answer below.
Mercurial's almost certainly your easiest option on Windows.
If you didn't care about authentication, you actually can trivially allow hg serve to permit push. To do so, you merely need to add the following to the .hg/hgrc file in the repository you wish to serve:
[web]
allow_push = *
push_ssl = false
The first line says that anyone may push to this repository. The second tells Mercurial to allow pushing without SSL, since hg serve does not currently natively support HTTPS. At this point, users can push to your repository without having an account anywhere. If you're simply a small shop, that's probably fine--especially since you can use Mercurial's ability to sign changesets to guarantee a much higher level of verifiability than HTTP Basic will provide, anyway.
For a larger, shop, though, you'd be totally right in wanting at least a simple barrier for committing. To do that, you need to make two changes. First, you'll need to put Mercurial behind a web server with either reverse proxy support or CGI support. Thankfully, recent versions of IIS support both. You can consult the CGI directions in the Mercurial Redbook for Mercurial-specific steps, and Microsoft's guide to setting up CGI applications in IIS 6 for help on the IIS side.
Next, you'll need to set up some basic authentication. IIS provides HTTP Basic out-of-the-box, which, as a bonus, can authenticate directly against your domain, keeping administrative overhead to a minimum.
Finally, you'll want to change the allow_push line to support only specific users by specifying a comma-delimited list of user names. For example:
allow_push = benjamin, ted, the_cow
That's it. Mercurial will now allow push from users who can authenticate via HTTP Basic authentication, and allow pull from everyone else.
After Benjamin pointed out the HTTP serving CGI scripts I decided to try those out and managed to get a repository hosted over HTTP. The Redbook which Benjamin linked was of much help as were two Mercurial wiki articles. One which describes Mercurial publishing in general and another containing step by step instructions for setting up the HgWebDir CGI script.
These instructions weren't completely foolproof though so I had to poke around a bit. Most likely as I'm running 64bit Vista. The instructions below document what I did. Now that I've done it once I'd probably do things in another order so don't consider these step by step instructions.
Mercurial
First I acquired the Mercurial binary from http://mercurial.berkwood.com/ which got installed into d:\dev\Mercurial. I created a repository for testing under d:\dev\testRepo repository using hg init. The d:\dev\Mercurial\library.zip contains Mercurial library files required by the CGI script so they were extracted to d:\dev\Mercurial\library. Something which confused me at first is that when I opened the zip file I received an error message and saw no contents. Just extracting the file to a directory worked though.
For the web script, I downloaded Mercurial source which contained the hgwebdir.cgi which got moved and renamed to d:\dev\Mercurial\webroot\hgwebdir.py. The step by step article contains good instructions for modifying the hgwebdir script for Windows. They also contain instructions for hgweb.config which in my case ended up looking like this:
[paths]
/hg/hgwebdir.py/test = D:\dev\Mercurial\testRepo
Also the repository wanted the following config so I could push there without SSL. Note I am using Basic Authentication to authenticate users currently. I had to create the config in D:\dev\Mercurial\testRepo\.hg\hgrc and add the following lines to it:
[web]
allow_push = *
push_ssl = false
Python
The CGI script is a Python script so it requires Python. It's seems pretty picky on which Python version executes it. One of the articles mentioned that running it requires same version that was used to build the Mercurial. In the end I got it working on Python 2.5 x86 after trying Python 2.6 x64, Python 2.4, Python 2.5 x64.
IIS
Two things I missed and had to install were CGI support and Basic Authentication. Both of these were installed through Control Panel, Programs and Features. Once done with installation I created a virtual directory (Which I later changed to an Application) in IIS pointing to D:\dev\Mercurial\webroot. The virtual directory required an CGI handler for *.py files which could be added from Handler Mappings. The executable was D:\dev\SDKs\Python25_x86\Python.exe %s. Once IIS had permissions to the webroot directory I could navigate to http://localhost/hg/hgwebdir.py/test and see the repository.
So now the read access was working. When I tried pushing to the repository I received weird error messages telling me it wasn't a real repository.
After an hour of debugging I ended up copying the whole D:\dev\Mercurial\library\mercurial tree under webroot so that Python could find D:\dev\Mercurial\webroot\mercurial\hgweb\hgwebdir_mod.pyc. After this Wireshark was reportting Access Denied errors in the stack trace. No idea what the real reason to this was but changing the virtual directory into an Application in IIS and moving it on top of an application pool which ran using Local System account the access denied errors went away.
Also at some point I gave HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WinSock2\Parameters registry key more permissions so IIS could access it. Doubt that it requires these after using Local System account.
Once these were done pushing stuff to the repository using hg push http://localhost/hg/hgwebdir.cgi/test was working!
Problems and solutions
Where to find the library files.
They were in the library.dll under Mercurial installation folder. I just had to extract them even if my unzip program refused to view me its contents.
How to get the Python script to run
Download the correct Python version for x86 architecture as the script uses some x86 libraries. The correct Python version depends on the Mercurial version. For 1.2.1 it was Python 2.5 x86.
Alternatively you could try building Mercurial from sources with whatever Python version you want but in my case this failed when building extensions.
How to set CGI up in IIS
First make sure CGI is installed in IIS. This wasn't assumed to be true in the IIS instructions Benjamin posted.
Create a new Module Mapping for *.py in IIS Handler Mappings. The correct Module is CgiModule and the executable is your Python executable + %s
How to allow the CGI script to write to the repository
Make sure the script has everything it requires. I had to move the library\mercurial\hgweb\hgwebdir_mod.pyc to another place.
Make sure the script has permissions to everywhere it wants. I solved this by Creating a new Application Pool for the CGI script that used Local System account, converting the Virtual Directory to an Application in IIS and selecting the new Application Pool.
After reading Mikko's Answer which almost worked for me, I came up with my own notes for installation. My setup was designed to be a "non protected and open" repository that members of my team could use installed on a Windows 2008 Server.
1. Install Python.
The version of Python I used was Python 2.6.2 and I used the Windows x86 MSI Installer.
Install for all Users.
Install to C:\Mercurial\Python
Use Default Feature Options.
2. Install MinGW.
The version of Minimalist GNU for Windows I used was MinGW 5.1.4
Install the MinGW-5.1.4.exe.
Choose the Download and Install Option.
Choose the Current Package Option to Install.
For the Components to Install Select the "Minimal" option.
Install to C:\Mercurial\MinGW
3. Modify your path.
You need to add in locations to your environmental path at this point.
Add 'C:\Mercurial\Python26;C:\Mercurial\MinGW\bin' to the path (Order Matters.)
4. Install Mercurial.
The version of mercurial that I used was the latest release in the stable branch and I did not use the binaries, but used the source code. I wanted to compile mercurial myself so that it would work with whatever version of Python I had installed so I didn't have to worry about any compatability issues which I found to be the biggest challenge with other install methods. The easist way to get the source is by downloading the "zip" file.
Mercurial Stable Release
Extract Zip File to C:\Mercurial\Source.
Build the Source at command prompt.
python setup.py build --force -c mingw32
python setup.py install --force --skip-build
5. Modify your path.
You need to insert into your environmental path another location for the 'hg' command.
Add 'C:\Mercurial\Python26\Scripts;C:\Mercurial\Python26;C:\Mercurial\MinGW\bin' to the path (Order Matters.)
6. Create your Config file.
You need to have a default user name set if your going to do any commits locally on this server.
Create file '"C:\Documents and Settings{username}.hgrc"'
[ui]
editor = Notepad
username = your_name
6. Test your Install.
Open up a new command window and test with 'hg debuginstall' to validate. You should see something like the following.
Checking encoding (cp1252)...
Checking extensions...
Checking templates...
Checking patch...
Checking commit editor...
Checking username...
No problems detected
7. Setup Web Directory.
Create Directory 'C:\Mercurial\Web'
Copy the hgwebdir.cgi file from the 'C:\Mercurial\Source' to 'C:\Mercurial\Web'
8. Configure IIS7 for Centralized Repository.
I used the DefaultAppPool which is using .Net 2.0, Pipeline=Integrated, Identity = ApplicationPoolIdentity.
Ensure CGI features are available in IIS7.
Control Panel/Programs/Windows Features/IIS/App Development Features/CGI
Add App into IIS on the Website you wish.
Alias=Mercurial -- Physical Path=C:\Mercurial\Web
On the App select HTTP Modules and add a new Module Mapping.
Request Path=*.cgi, Module=CgiModule, Executable=C:\Mercurial\Python26\python.exe %s, Name=Mercurial.
When Prompted to add entry to ISAPI and CGI restrictions list say yes.
9. Test your Web Setup.
You should now be able to browse http://localhost/Mercurial/hgwebdir.cgi and see and empty repository list.
10. Configure IIS7 for Friendly URL
I did not like having the unfriendly URL and this step allows us to remap the URL to something more friendly. Install the URL Rewrite Moduel 1.1 Extension for IIS.
On the Mercurial IIS Application in IIS Manager featurs View select URL Rewrite Component and install a new Rule.
Choose Add Rules, then the Template 'Rule with rewrite map.' Rule Action=Rewrite, Specify Rewrite Map=Mercurial
Add a mapping Entry. OriginalValue='/Mercurial/Repo', New Value='/Mercurial/hgwebdir.cgi'
11. Create Mercurial Repository
You can now create a test repository.
Create a Directory C:\Mercurial\Repository and ensure IUSR account has the permissions to write to the directory. (If on Domain account is more like IUSR_{ComputerName}.
Create file C:\Mercurial\Web\hgweb.config to list the repositories.
[paths]
/ = C:\Mercurial\Repository\**
Add a directory C:\Mercurial\Repository\Test and initialize the repository with 'hg init'
** If you want now to be able to push without ssl create in the .hg directory of the repository a hgrc file the following lines.
[web]
allow_push = *
push_ssl = false
References:
Mercurial Wiki Windows Install
HG Book
Step by Step
Publishing Mercurial Repositories
For a team taking the first step away from VSS I would have suggested using SubVersion for source control and either TortoiseSVN or VisualSVN for the client.
But if the team has made the decision to switch to a DVCS then I'd suggest Mercurial because of it's better support for HTTP and windows on the client via TortoiseHg.
If you're looking for:
Distributed development support
Run Windows servers seamlessly
And a great GUI
You're exactly describing Plastic SCM
Excuse my necroposting and shameless self-promotion, but I've just released an alpha version of HgLab, which is a Mercurial Server for Windows with full pull-push support and Active Directory integration.
SCM-agnostic (to some degree) Windows-solution with Repository-frontent and management today may be SCM-Manager (Git, Mercurial, SVN repo out of a box with a single requirement of JVM)
I'll try to make this as straight forward as possible.
Currently our team has a VSS database where our projects are stored.
Developers grab the code and place on their localhost machine and develop locally.
Designated developer grabs latest version and pushes to development server.
The problem is, when a file is removed from the project (by deleting it in VS2008) then the next time another developer (not the one who deleted it) checks in, it prompts them to check in those deleted files because they still have a copy on their local machine.
Is there a way around this? To have VSS instruct the client machine to remove these files and not prompt them to check back in? What is the preferred approach for this?
Edit Note(s):
I agree SVN is better than VSS
I agree Web Application project is better than Web Site project
Problem: This same thing happens with files which are removed from class libraries.
You number one way around this is to stop using web site projects. Web Site Projects cause visual studio to automatically add anything it finds in the project path to the project.
Instead, move to Web Application Projects which don't have this behavior problem.
Web Site projects are good for single person developments.
UPDATE:
VB shops from the days gone past had similiar issues in that whatever they had installed affected the build process. You might take a page from their playbook and have a "clean" build machine. Prior to doing a deployment you would delete all of the project folders, then do a get latest. This way you would be sure that the only thing deployed is what you have in source control.
Incidentally, this is also how the TFS Build server works. It deletes the workspace, then creates a new one and downloads the necessary project files.
Further, you might consider using something like Cruise Control to handle builds.
Maybe the dev should take care to only check in or add things that they have been working on. Its kind of sloppy if they are adding things that they were not even using.
Your best solution would be to switch to a better version control system, like SVN.
At my job we recently acquired a project from an outsourcing company who did use VSS as their version control. We were able to import all of the change history into SVN from VSS, and get up and running pretty quickly with SVN at that point.
And with SVN, you can set up ignores for files and folders, so the files in your web projects dont get put into SVN and the ignore attributes are checked out onto each developer's machine
I believe we used VSSMigrate to do the migration to SVN http://www.poweradmin.com/sourcecode/vssmigrate.aspx
VSS is an awful versioning system and you should switch to SVN but that's got nothing to do with the crux of the problem. The project file contains references to what files are actually part of the project. If the visual studio project isn't checked in along with the changes to it, theres no way for any other developer to be fully updated hence queries to delete files when they grab the latest from VSS. From there you've got multiple choices...
Make the vbproj part of the repository. Any project level changes will be part of the commit and other developers can be notified. Problem here is it's also going to be on the dev server. Ideally you could use near the same process to deploy to dev as you would to deploy as release. This leads into the other way...
SVN gives you hooks for almost all major events, where hooks are literally just a properly named batch file / exe. For your purposes, you could use a post-commit hook to push the appropriate files, say via ftp, to the server on every commit. File problems solved, and more importantly closer towards the concept of continuous integration.
Something you may want to consider doing:
Get Latest (Recursive)
Check In ...
Its a manual process, but it may give you the desired result, plus if VS talks about deleted files, you know they should be deleted from the local machine in step 1.