Problems with Visual Studio

J

Joanna Carter

Junior Member
Hi

I posted a message a while ago, asking why a script file inside an app bundle, created by Oxygene in Visual Studio never got its permissions set correctly.

John's initial response was that it was down to having the target directory on the Mac and that the shared permissions weren't set correctly.

Well, I have just run some more tests and found that, even if I compile the project on a Windows local disk in the VM, the permissions on the script file do not include "executable".

However, I have just purchased VMWare Fusion and, lo and behold, the problem does not exist under their VM, even though I compiled the project on the shared Mac disk and having done absolutely nothing to the shared permissions, over and above that which I did for Parallels.

Could someone please investigate this further, otherwise, I may well move to VMWare in the future. After all, I have just had to buy a copy, just to get around what would appear to be an unresolved bug in Parallels :-(
 
Could you post here link to thread that you mentioned.

with best regards
Alexander
 
Alexander, the previous thread wouldn't throw any more light on the problem.

I had made an assumption that the problem was caused by wrting to a shared folder.

Allow me to lay down the steps that reveal the problem :

Start Visual Studio, with Oxygene from RemObjects installed.

Create a new Oxygene Cocoa application for OS X, using a shared folder as the target.

Build the application.

Use Finder to locate the resulting application in the shared folder in OS X

Show contents of the app package and navigate to the Contents/MacOS folder, or use Terminal to list the contents of the Contents/MacOS folder.

You should find a script file, with the same name as the app, that should possess the attributes : -rwxr-xr-x

Instead, the file possesses the atttributes : -rw-r--r--


If I create the project in a folder on a Windows disk in the VM, I get a different result; the script file gets the attributes : -rw-rw-rw-

Either way, the executable permission is missing.

I have been in touch with RemObjects and they state that the attributes applied by VMWare Fusion (-rwxr-xr-x) are correct.

I would much prefer to stay with Parallels for my VMs but, at the moment, I have had to purchase VMWare Fusion to avoid this problem when demonstrating to developers' groups.

Do not hesitate to state if you need any more information to resolve this matter.

Thanks

Joanna
 
Last edited:
Hi John

Yes, I have tried sharing with and without Samba - no difference.

But that is not the problem.

Even if I create a VS/Oxygene project on a Windows drive in the VM, I still get a similar problem where, although the atributes are slightly different for the shared drive, the executable attribute is still missing.

So, unless I am missing something, this is nothing to do with shared folders, since it also occurs on Windows disks in the VM.
 
Joanna.

I followed up with your instructions: installed Oxygene, created Cocoa project on mapped Mac OS X share, but failed to build project due errors:

C:\Program Files\MSBuild\RemObjects Software\Oxygene\RemObjects.Oxygene.targets : Warning : (MSB3245) Could not resolve this reference. Could not locate the assembly "cocoa-sharp". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.
Z:\projects\CocoaApplication1\CocoaApplication1\ApplicationController.pas(7,3) : Error : (PE17) Namespace "Cocoa" does not exist or has no public types
Z:\projects\CocoaApplication1\CocoaApplication1\ApplicationController.Designer.pas(7,3) : Error : (PE17) Namespace "Cocoa" does not exist or has no public types
Z:\projects\CocoaApplication1\CocoaApplication1\FirstResponder.pas(7,3) : Error : (PE17) Namespace "Cocoa" does not exist or has no public types
Z:\projects\CocoaApplication1\CocoaApplication1\Interface.nib\classes.pas(19,5) : Error : (PE17) Namespace "Cocoa" does not exist or has no public types
Z:\projects\CocoaApplication1\CocoaApplication1\Program.pas(6,3) : Error : (PE17) Namespace "Cocoa" does not exist or has no public types
Z:\projects\CocoaApplication1\CocoaApplication1\ApplicationController.pas(10,48) : Error : (PE9) Unknown identifier "Cocoa.Object"
Z:\projects\CocoaApplication1\CocoaApplication1\ApplicationController.Designer.pas(10,48) : Error : (PE9) Unknown identifier "Cocoa.Object"
Z:\projects\CocoaApplication1\CocoaApplication1\Interface.nib\classes.pas(23,50) : Error : (PE9) Unknown identifier "Cocoa.Object"
Z:\projects\CocoaApplication1\CocoaApplication1\FirstResponder.pas(11,41) : Error : (PE9) Unknown identifier "Cocoa.Object"
Z:\projects\CocoaApplication1\CocoaApplication1\Interface.nib\classes.pas(27,43) : Error : (PE9) Unknown identifier "Cocoa.Object"
Z:\projects\CocoaApplication1\CocoaApplication1\ApplicationController.Designer.pas(18,58) : Error : (PE9) Unknown identifier "Notification"
Z:\projects\CocoaApplication1\CocoaApplication1\Interface.nib\classes.pas(22,14) : Error : (PE9) Unknown identifier "Register"
Z:\projects\CocoaApplication1\CocoaApplication1\ApplicationController.Designer.pas(17,12) : Error : (PE9) Unknown identifier "Export"
Z:\projects\CocoaApplication1\CocoaApplication1\ApplicationController.Designer.pas(20,12) : Error : (PE9) Unknown identifier "Export"
Z:\projects\CocoaApplication1\CocoaApplication1\Interface.nib\classes.pas(26,14) : Error : (PE9) Unknown identifier "Register"
Z:\projects\CocoaApplication1\CocoaApplication1\ApplicationController.Designer.pas(28,24) : Error : (PE174) There is no overloaded constructor with 1 parameters for class "CocoaApplication1.Interface.nib.ApplicationController"
Z:\projects\CocoaApplication1\CocoaApplication1\Program.pas(22,3) : Error : (PE9) Unknown identifier "Application"
Z:\projects\CocoaApplication1\CocoaApplication1\Program.pas(23,3) : Error : (PE9) Unknown identifier "Application"
Z:\projects\CocoaApplication1\CocoaApplication1\Program.pas(24,3) : Error : (PE9) Unknown identifier "Application"

I guess it's necessary to install something else for successful project build. Could you provide me with complete instructions what i must do? Thank you.

with best regards
Alexander
 
Hi Alexander

You need to install the CocoaSharp.dll as per the instructions on RemObjects site.

////////////

Unfortunately, Mono for Windows currently doesn't ship with the cocoa-sharp.dll required to build Cocoa# apps. But that's easily fixed - just copy the dll off your Mac (from /Library/Frameworks/Mono.framework/Versions/Current/lib/mono/cocoa-sharp) to Windows (to C:\Program Files\Mono 1.x\...). Remember to repeat this step if you upgrade to newer versions of Mono, as the cocoa-sharp.dll is still evolving and you will want to make sure that you use the latest version.

/////////////

The actual directory in which to install the dll should be [drive]:\Program Files\Mono-1.9.1\lib\mono\cocoa-sharp

Awkward, I know, but that should fix it :-)

Joanna
 
Last edited:
Joanna.

I've made first investigation of problem on clear Windows host (not VM but hardware node) with mapped Mac OS X Samba share. By default all files creating on this share had permissions rwxr--r--. I checked /etc/smb.conf file on Mac OS X host and had noticed that all settings there are default (no special settings for parameters create mode or force create mode). So Samba behavior was correct in this case - it creates files with default creation mask 0744. I specified force create mode = 0755 at global section and determined that now all files creating with expecting rwxr-xr-x mask. So for clear Samba shares it's possible workaround.

I can't to check right now this test case through our VM because do not have ready VM with necessary development environment. But i guess i'm know where problem is. Seems we have problem at our driver using on guest OS side to work with files at host Mac OS X bound with convertion of Windows file permissions into Unix one. So i guess we'll investigate problem and fix it at our further versions. Sorry for inconveniences.

with best regards
Alexander
 
Hi Alexander

Is it a good idea to alter the smb.conf file, or would this cause problems elsewhere?

How soon do you reckon a fix could be made available, I really don't want to have to use VMWare for my presentations, in fact, I woiuld like to get a refund under their satisfaction (not) scheme.

Hopefully

Joanna
 
Joanna Carter said:
Hi Alexander

Is it a good idea to alter the smb.conf file, or would this cause problems elsewhere?
Click to expand...

Single problem with it that all files on shares will creating with another mask. Actually you have total control on this mask and can specify execute permission just for owners user and group (or just for owner user).

How soon do you reckon a fix could be made available, I really don't want to have to use VMWare for my presentations, in fact, I woiuld like to get a refund under their satisfaction (not) scheme.

Hopefully

Joanna
Click to expand...

Unfortunately can't to provide you with concrete date. I can just assume that this fix will present in new version of Parallels Desktop in nearest month or two. Also i guess this fix will included in nearest updates of PD 3.0.

with best regards
Alexander
 
OK Sandro

I have just installed, first build 5626 of v3, then v4 and, still, the problem of permissions is not fixed !!!

So, do I change to using and recommending VMWare Fusion for VS cross-platform development ???

Or is there a chance that the Parallels team can actually fix this in reasonable time i.e. less than the three months that it has taken so far ??
 
Hi Joanna.

Yes this issue still not fixed but presents at our bugtracking system. Unfortunately we currently haven't clear vision whether it's bug or not. Because VMware setting for all files creating at guest OS permissions rwx for owner without any logic and in your case it's good for you because resolving your problem but no guarantee that such behavior do not affect other cases (actually it's the same situation which we discussing with you above where i'd recommend you to configure Samba share). So currently we don't have clean decision with this problem and i can't to provide you with info whether it'll be fixed in nearest time or not. It's your right to select proper platform match to your purposes but i recommend you to take a look on our 4th version. I guess it'll be interesting for you especially as for developer: in this version of Desktop we have new architecture with open API to virtual machine which can be used for automation of your products installation testing on different OSes for example. Also many others features appeared at our new version.
 
Joanna.

I just have been noticed that this issue will be fixed in the next update of 4th version. It'll be configurable behavior with option at VM configuration file specifying should "execute" permission setting always on files creating on shares or not.
 
Hi Alexander

That certainly is good news; I have tried all sorts of things with editing the Samba configs for the relevant shares but all to no avail. Even though the folders and files right into the app bundle possess the correct 755 permissions, every time the compiler creates a script file in the {AppName.app}/Contents/MacOS folder, the permissions for that file are still only at 644.

Any idea how long that update will be ?
 
You must log in or register to reply here.
Back
Top