Somewhere along the line in the last week, Xamarin on my Windows machine started giving the above mentioned error any time I compile with MONO.
Specifically occurs when Project|Active Runtime is MONO - never happens when runtime is Microsoft.NET.
I've tried uninstalling/reinstalling MONO runtime (mono-3.2.3-gtksharp-2.12.11-win32-0.exe)
Any clues? Google searches come up with pretty much nothing
I get the same error today, (after an update yesterday to 4.2.4 Build 35) There is a bugfix here
Build works fine on another PC without the latest update (4.2.3 build 59). I guess the answer is to roll back to 4.2.3.
You can get it from your account page at Xamarin.com >> Downloads >> View all versions.
The solution from here says that you should either uncheck the box "Use MsBuild" in project settings or use .NET for building but then run with Mono if you want to test runtime compatibility.
Related
I try to run a program which was build upon PowerBuilder version 10.2.1.9637 on a Windows 10 computer. After startup it shows an error message:
Error loading library. Please check whether PowerBuilder Accessibility library can be located in the path.
Doing some research I found out that there is a pbaccess***.dll needed to get the program run under Windows 10. However, is there a way to get this .dll since I do not own this specific version of PowerBuilder?
Or are there any other workarounds to get the program run?
This is from an earlier build of PB 10.2.1, but you can see if it works.
https://drive.google.com/open?id=0B6J5FirdQZquUFgwVmdkb1QtT28
You would have to get pbacc100.dll from the application developer. Alternately you can disable accessibility in control panel.
Any ideas as to why MSBuild is always building all my platforms for my UWP solution even though I'm specifying to only build for the ARM platform. This is the command line I'm using:
MSBuild.exe C:\MyApp\MyApp.sln /p:Configuration=Release /p:Platform=ARM
Am I missing something or doing something wrong?
Thanks.
UPDATE - 1:
I've also tried specifying x86 as the platform, but it still builds all platforms.
After spending hours trying to figure out this problem, I have eventually figured out what's wrong, well partially at least!
As mentioned, the above does not work as expected, unless I first create a package via the .NET IDE and only select a single platform. Once I do this, the above command line will build the relevant platform that's specified in the command line!
I've just tried it again and created a package via the .NET IDE and re-selected all platforms and called my original command line once again, and it build all platforms rather than the one specified in the command line. There is obviously something in the solution file that's causing this but personally I think this behaviour is wrong and is a bug.
The following command lines seem to worked irrelevant of what has been selected via the .NET IDE:
To only build a package for ARM in Release mode:
msbuild "c:\myapp\myapp.sln" /p:configuration=release;platform=ARM;
AppxBundle=Always;AppxBundlePlatforms="ARM"
To only build a package for x86 in Debug mode:
msbuild "c:\myapp\myapp.sln" /p:configuration=debug;platform=x86;
AppxBundle=Always;AppxBundlePlatforms="x86"
While the above works, irrelevant of what's selected in the .NET IDE, I haven't figured out how to build all platforms.
I'll also investigate the original command line problem and the link with via the .NET IDE selection, and I'll update my answer if I find out what's causing it.
Hope this helps.
I started a new application and changed the target framework to v2.0 for Windows XP compatibility but when I run the debugger (with or without code) I get an error saying MSVSMON.exe appears to not be running. I tried restarting the project and even changing the target framework back to v4.5 but I still get the error. How do I fix this?
I know this is quite old, but in case somebody has the same issue I thought I'll answer it. I changed the platform target to 32bit and debugging worked. Setting it to 64 bit or Any CPU caused the error you are describing. Not really the perfect solution but at least I can debug now.
I upgraded from MacOS X 10.6 (Snow Leopard) to 10.7 (Lion) this morning, and also from Xcode 4.2 to Xcode 4.3.2. Perhaps more importantly, that means that I'm now building my project against the iOS 5.1 SDK instead of 5.0. That's a lot of changes, and one of them caused my project to break: the project will no longer build due to the following error:
Command /Applications/Xcode.app/Contents/Developer/usr/bin/dsymutil
failed with exit code 11
The full command given in the build results is as follows (full disclosure: I've changed the project name to 'MyProject' to protect the innocent):
GenerateDSYMFile /Users/caleb/xcode-build/MyProject-fmkmldxfmhvmoicxrcsqsptzuvjs/Build/Products/Debug-iphoneos/MyProject.app.dSYM /Users/caleb/xcode-build/MyProject-fmkmldxfmhvmoicxrcsqsptzuvjs/Build/Products/Debug-iphoneos/MyProject.app/MyProject
cd /Users/caleb/MyProject/iphone
setenv PATH "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:/Applications/Xcode.app/Contents/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin"
/Applications/Xcode.app/Contents/Developer/usr/bin/dsymutil /Users/caleb/xcode-build/MyProject-fmkmldxfmhvmoicxrcsqsptzuvjs/Build/Products/Debug-iphoneos/MyProject.app/MyProject -o /Users/caleb/xcode-build/MyProject-fmkmldxfmhvmoicxrcsqsptzuvjs/Build/Products/Debug-iphoneos/MyProject.app.dSYM
This only happens when I try to build for an iOS device; building for the simulator works fine.
I've done quite a bit of searching to find an explanation of this error, but haven't found anything yet that explains the error. I did find one SO question about the same error, caused in that case by a bad tag in an Info.plist file, but my Info.plist looks fine. Another question suggests creating a new target and copying everything over. I haven't tried that yet as my project is quite large, but it's looking like the best next step.
Can anyone tell me what "exit code 11" from dsymutil means and how to fix it?
Update: Running the dsymutil command at the command line shows that exit code 11 is a segmentation fault. Still don't know what causes it, though.
A workaround that's working for me so far is to change the Debug Information Format setting in the project from "DWARF with dsym" to plain old "DWARF".
This at least lets me build the project for iOS devices and debug, so that's a very good start. I'm not sure what we lose by leaving out dsym, so I'm going to keep looking.
Update: Apple DTS suggests reinstalling Xcode. I haven't been able to try that yet, but will update this answer if it's helpful.
For future users who come here via Google :
It happened to me because my working directory was full.
EDIT:
Clear Some Space in your disk.
P.S. You can always go ahead and delete everything residing in this directory if you have developed so many apps till date on the same machine. /Users/<username>/Library/Developer/Xcode/DerivedData
P.P.S: Don't forget to check the size of the directory to get surprised. It may take upto 4 hours deleting the entire path, so do it in free time, just delete 2-3 sub directories and resume your work.
Changing "iOS Deployment Target" from 6.1 to 4.0 helped me !
have you made sure that your project build settings, compiler version is set to system default?
I've been tearing my hair out over this, and Google hasn't yielded much so my problem must be caused by my own specific brand of stupidity.
Basically, having installed Xcode 4 I removed the /Developer-old folder (properly, can't remember the command but I used the uninstall script rather than sticking it in the trash).
Xcode builds projects fine, and the latest version of all the Objective-C frameworks seem to live in /System/Library/Frameworks, but when I compile something (which built fine in the Xcode 3 days) clang complains that it can't find any headers, e.g:
fatal error: 'Cocoa/Cocoa.h' file not found
I've tried forcing the framework search path with -F to no avail- is there a common underlying issue or have I just screwed my machine?
Reinstall the developer tools. It will take a lot less time than tracking down whatever you broke.