Mapping

[Marshall]

I am unable to access mapped drives from VS2005 within the host. I see them in explorer, but VS does not see them.

Any suggestions?

Marshall

[Martin]

Use a real network share instead of the shared folder.
Shared folders don't implement all features to be used by applications.

[Marshall]

That worked.

Thanks.

Marshall

[revher]

Hi,
Thank you for the advice. But what do you mean by a real network share? Dose it mean
net use x: \\MYOSXNETWORK\myhomeonOSX
instead of using vboxsrv provided by the virtualbox extension?
net use z: \\VBOXSRV\myhomeonOSX

Both commands are successful and drives can be read/write by standard copy but as soon as you use, for example, Microsoft Visual Studio 2013, you can't compile a project belonging to x: or z:. It complains that the drive is not a 'local drive'. VS is then proposing to build on a local drive like C: on a temporary (Appdata tmp etc). It works but which it is not what we want: having a Windows 'build' stored on an OSX directory, for example myhomeonOSX/build.

Solution of altering windows protection with 'caspol' does not fully work according to different posts.

Solution of having part of the C: drive as a Windows share (myhomeonWindows/build) and mounted from OS/X with SMB is possible: you have to give a password to your Windows guest user (yourself) and mount it from the host side (OS/X) using Finder. Then you can make a symbolic link for this /Volumes/Users/myname/myhomeonWindows/build to /Users/myname/myhomeonSX/build/buildonwindows . It works but is complex.


What is strange, is that if you don't use the Visual Studio gui but the command line 'nmake' (or MINGW32-make) you don't have this write restriction that you get with a mounted drive x: or z:. And thus the solution for example for building using Visual Studio 2013 on Windows 64 bit using cmake is (assuming that your top CMakefiles.txt is on ./src):
x:> mkdir build
x:> cd build
x:> cmake -G "NMake Makefiles" ..\src
x:> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\vcvarsall.bat" amd64
x:> nmake

instead of (not working)

x:> cmake -G "Visual Studio 12 Win64" ..\src
and launching Visual Studio 13 in order to build using the Visual Studio GUI.

For resuming: I think that the following detailed documentation of VirtualBox "4.3.2. Automatic mounting" concerning a shared on a Linux guest :

-------------------------------
Note

Access to auto-mounted shared folders is only granted to the user group vboxsf, which is created by the VirtualBox Guest Additions installer. Hence guest users have to be member of that group to have read/write access or to have read-only access in case the folder is not mapped writable.
--------------------------------
is important, but the absence of any explanation concerning the same problem on a Windows guest is frustrating. And if there is no solution for Windows (I hope that I am wrong), please warn the reader.

[mpack]

A real network share is one which is accessed over a network, which GA shared folders are not. VirtualBox will provide the networking, the guest OS will provide the shared folders implementation, which will therefore do exactly what the guest OS expects.

The commands you mention are Windows guest specific. The first few assign a drive letter to a shared folder. This step is not necessary except to support old applications that will not work well with shared folders. I don't see the relevance of the later stuff you talk about.

[revher]

> A real network share is one which is accessed over a network, which GA shared folders are not.
> VirtualBox will provide the networking, the guest OS will provide the shared folders implementation,
> which will therefore do exactly what the guest OS expects.

Thank you for your prompt reply. In fact, the GA provides vboxsrv which make a host folder (here OS/X) easily mounted and used by a guest (here Windows 7), but it is not fully working and it doesn't behave as a "local drive". You can't use a shared folder for example to compile and link a project with Visual Studio 2013 because Visual Studio complains that the drive is not writable. On Unix, it will be easy to solve that privilege right but on Windows, I don't know how to do; as well many other VB users who posted various unsolved ideas.

As you said it is not linked to a drive letter. But because Martin said "Use a real network share instead of the shared folder." I thought that the problem was linked to a real network but it is not working too. It is a Windows question.

What is working, is using the Visual Studio command line. 'msbuild' is allowed to write on a shared folder, but the VS GUI is complaining. Download the free VS 2010 and try to build hello.c on a shared folder and tell us.

What is also working is the use of Samba, and a symbolic link, but if you want to build outside your Windows guest (for example for backup reason etc.) I don't have any solution yet.

[mpack]

VBoxSrv is not a network, it is an API accessed via the guest additions. It does however provide basic read/write access.

I'm afraid you'll have to go to a Microsoft form if you have questions about Visual Studio.