Over the last few months we have been slowly moving the office over to a Git / Vagrant Development process. For 15 years, the company has been using a shared development environment to replicate production, and we (a few colleagues and myself) have finally managed to convince management the our current development processes is not only outdated, but is actually causing errors and negatively effecting our productivity. So we have been building Git servers, and deployment scripts in preparation for this transition to a relatively modern development process. The key part of this process is of course a localized development environment, Vagrant.
Vagrant uses virtual machines, VirtualBox by default, to spin up an easily distributed and provisioned copy of development environment and the idea is to try and produce a similar environment to your production environment. Our would be a Windows Server environment with ColdFusion running on IIS.
All is quick and easy to setup until we get to the point of pointing IIS to our sync'd directory. In order to use files from our Host (your local computer) to our Guest (the virtual machine), vagrant uses the provider (in this case VirtualBox) folder sharing abilities. In the case of VirtualBox and VMWare, this comes in the form on the Guest as a network drive or share. Our problem is that VirtualBox sets up a mimic'd UNC share which IIS cannot authenticate against. When pointed to the required location, IIS throws a 500.19 error stating that it cannot read the web.config file in the directory. The problem is that IIS cannot read the location at all.
At the time of this posting: No solution is available to get IIS on a VirtualBox machine to read the sync'd directories directly. IIS can and will read from a virtual directory however.
// Host Folder Name: site // Does Not Work => http://localhost/ path: \\working_share\site\ // Does Work => http://localhost/site path: C:\inetput\wwwroot\site\
This does not replicate our environment however. All relative paths in my site would need to be changed from /imgs/pic.jpg to /site/imgs/pic.jpg. This is not at all ideal and requires much more site environment configuration then its worth to deal with.
At this time, we moving on to a Vagrant-VMWare solution. I will post updates as I have them.